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
