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 thread will block until the mutex
becomes available. Upon success the pthread_mutex_lock() function re-
turns with the 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
immediate error return is performed.

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