This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]