Re: Lightweight locking primitive

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:
    The pthread_mutex_lock() function locks the mutex pointed to by mutex. If    mutex is already locked, the calling
threadwill block until the mutex    becomes available.  Upon success the pthread_mutex_lock() function re-    turns
withthe mutex locked and the calling thread as its owner.
 

In fact, they have a pthread_mutex_trylock() version that doesn't block:
    The pthread_mutex_trylock() function performs a non-blocking mutex lock    operation.  It behaves exactly like
pthread_mutex_lock()except that if    any thread (including the calling thread) currently owns the mutex, an
immediateerror return is performed.
 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026