This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: FW: sem_getvalue()
- From: Alexander Terekhov <TEREKHOV at de dot ibm dot com>
- To: Blanco Alejandro-EAB005 <Alex dot Blanco at motorola dot com>
- Cc: "'pthreads-win32 at sources dot redhat dot com'" <pthreads-win32 at sources dot redhat dot com>
- Date: Wed, 8 Sep 2004 21:58:55 +0200
- Subject: Re: FW: sem_getvalue()
- Sensitivity:
> if there are threads waiting on the semaphore
That's pretty useless info. Consider "fast" semaphore using "lock
queue" (Linux folks reinvented "half-or-less" of this thing and
proudly called it "a futex") address based parking interface with
"waiters bit" maintained by its implementation:
sema_lock:
WHILE // CAS/LL-SC
!atomic_decrement_if_binand_7FFFFFFF_is_not_zero_ccacq(&lock)
lock_queue_wait(&lock, 0) // wait if sem.value is zero
sema_unlock:
uintptr_t lock_queue;
IF atomic_increment_rel(lock_queue = &lock) > 0x80000000
THEN lock_queue_wake(lock_queue, 1)
(try/timed operations omitted for brevity)
BTW, fast mutex:
mutex_lock:
WHILE
atomic_bit_test_set_ccacq(&lock, 1)
lock_queue_wait(&lock, 1) // wait if locked bit is set
mutex_unlock:
uintptr_t lock_queue;
IF atomic_decrement_rel(lock_queue = &lock)
THEN lock_queue_wake(lock_queue, 1)
"ccacq" stands for acquire-but-with-"control condition"-hint
(to avoid redundant memory barrier(s) -- arch specific stuff).
"rel" is a classic release.
regards,
alexander.