Re: Lightweight locking primitive - Mailing list pgsql-hackers

From Doug McNaught
Subject Re: Lightweight locking primitive
Date
Msg-id m3y9gxt7j1.fsf@varsoon.denali.to
Whole thread Raw
In response to Re: Lightweight locking primitive  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Doug McNaught wrote:
> > They're basically the same thing.  Currently, pthread_mutexes on Linux
> > (implemented in glibc) are fairly gross in the contended case, since
> > there is no clean way to wait for lock release, and they interact
> > fairly nastily with signal semantics.  The futex patches create a new
> > system call which lets you cleanly wait for a locked futex (an
> > unlocking task checks for waiting lockers and calls into the kernel
> > for wakeups if it finds any).
> 
> Strange that it doesn't wait for the lock.  BSD/OS has:

It does wait.  If the lock is already locked (atomic test in
userspace) the process makes a futex_wait system call, which puts the
process on a kernel waitqueue. 

From what I can see, the new Linux locks are not a replacement for
POSIX locks/semaphores, they're simply a fairly clean way of
implementing them.  They also just went into the development kernel,
so any appearance in production systems may take a few months at
least. 

-Doug
-- 
Doug McNaught       Wireboard Industries      http://www.wireboard.com/
     Custom software development, systems and network consulting.     Java PostgreSQL Enhydra Python Zope Perl Apache
LinuxBSD...
 


pgsql-hackers by date:

Previous
From: Matthew Kirkwood
Date:
Subject: Re: Lightweight locking primitive
Next
From: Igor Kovalenko
Date:
Subject: Re: Lightweight locking primitive