RE: FW: sem_getvalue()

[Blanco Alejandro-EAB005 <Alex dot Blanco at motorola dot com>]

the case is 1 thread sleeping, 2 threads may wake up the thread.  the wakers check to see if someone is waiting so the sem value is not positive after both wakers' conditions are met.  there is an obvious race condition, but for the application, this is ok.  

regardless, the question is whether there is a defect in that 0 is returned when it should be -1.

alex

-----Original Message-----
From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com] 
Sent: Wednesday, September 08, 2004 3:59 PM
To: Blanco Alejandro-EAB005
Cc: pthreads-win32@sources.redhat.com
Subject: Re: FW: sem_getvalue()


> 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.