From: Blanco Alejandro-EAB005 <Alex.Blanco@motorola.com>
To: "'Alexander Terekhov'" <TEREKHOV@de.ibm.com>,
Blanco Alejandro-EAB005 <Alex.Blanco@motorola.com>
Cc: pthreads-win32@sources.redhat.com
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.
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.
next 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31173C0B4EF5D611A021009027CB2CBD04EE2CCC@fl08exm04 \
--to=alex.blanco@motorola.com \
--cc=TEREKHOV@de.ibm.com \
--cc=pthreads-win32@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).