public inbox for
 help / color / mirror / Atom feed
From: Blanco Alejandro-EAB005 <>
To: "'Alexander Terekhov'" <>,
	Blanco Alejandro-EAB005 <>
Subject: RE: FW: sem_getvalue()
Date: Wed, 08 Sep 2004 20:17:00 -0000	[thread overview]
Message-ID: <31173C0B4EF5D611A021009027CB2CBD04EE2CCC@fl08exm04> (raw)

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.


-----Original Message-----
From: Alexander Terekhov [] 
Sent: Wednesday, September 08, 2004 3:59 PM
To: Blanco Alejandro-EAB005
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:


      lock_queue_wait(&lock, 0) // wait if sem.value is zero


  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:


    atomic_bit_test_set_ccacq(&lock, 1) 
      lock_queue_wait(&lock, 1) // wait if locked bit is set


  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.


             reply	other threads:[~2004-09-08 20:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-08 20:17 Blanco Alejandro-EAB005 [this message]
2004-09-08 20:34 ` Alexander Terekhov
  -- strict thread matches above, loose matches on Subject: below --
2004-09-09 14:12 Blanco Alejandro-EAB005
2004-09-09 14:26 ` Alexander Terekhov
2004-09-09 12:59 Blanco Alejandro-EAB005
2004-09-09 13:55 ` Alexander Terekhov
2004-09-08 18:59 Blanco Alejandro-EAB005
2004-09-08 19:59 ` Alexander Terekhov
2004-09-09  9:11 ` Ross Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31173C0B4EF5D611A021009027CB2CBD04EE2CCC@fl08exm04 \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).