From: Bart Veer <bartv@redhat.com>
To: osv@javad.ru
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] No binary semaphore in C API?
Date: Wed, 28 Mar 2001 07:39:00 -0000 [thread overview]
Message-ID: <200103281539.f2SFdAE07390@sheesh.cambridge.redhat.com> (raw)
In-Reply-To: <87u24ehs0d.fsf@osv.javad.ru>
>>>>> "Sergei" == Sergei Organov <osv@javad.ru> writes:
<snip>
>> Arguably there should be an assert in
>> Cyg_Binary_Semaphore::post(),
>>
>> CYG_ASSERT( false == state, "Posting to unlocked binary semaphore");
>>
>> However I am not sure that there is sufficient agreement on the
>> general semantics of binary semaphores to make that assertion
>> valid. Some people might expect multiple posts to be a no-op.
>> IMO the absence of completely clear semantics for a
>> synchronization primitive is a good argument for removing that
>> primitive completely.
Sergei> Sorry, but for me it seems that initial assumption --
Sergei> using semaphore for mutual exclusion -- is wrong, so the
Sergei> rest of argumentation doesn't make much sense for me.
Sergei> Don't we have mutexes for mutual exclusion? Just use
Sergei> mutexes and put corresponding 'CYG_ASSERT' into mutex
Sergei> implementation if it is not already there.
The original posting,
http://sources.redhat.com/ml/ecos-discuss/2001-03/msg00250.html
described why a binary semaphore was being used rather than a mutex.
"I've got a mutual-exclusion requirement but can't use cyg_mutex_t
because one thread locks and a different thread unlocks the
resource. [It's kind of complicated, the mutal exclusion is between
two "groups" of threads.]"
In that context the assertion would be correct. You describe a
different use for binary semaphores where the assertion would be
incorrect. Hence there is confusion about semantics, which is pretty
disastrous for a synchronization primitive.
Arguably the better alternative would be to implement a new mutex
class which deals with thread groups, rather than overloading
binary semaphores. The latter could then be left with their existing
semantics, although people might still be confused and use them
incorrectly for mutual exclusion.
Bart
next prev parent reply other threads:[~2001-03-28 7:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-16 12:01 Grant Edwards
2001-03-19 13:42 ` Jonathan Larmour
2001-03-26 3:53 ` Nick Garnett
2001-03-26 7:12 ` Fabrice Gautier
2001-03-26 11:37 ` Grant Edwards
2001-03-27 2:00 ` Nick Garnett
2001-03-27 5:32 ` Grant Edwards
2001-03-28 5:29 ` Bart Veer
2001-03-28 6:45 ` Sergei Organov
2001-03-28 7:38 ` Grant Edwards
2001-03-28 7:39 ` Bart Veer [this message]
2001-03-28 10:01 ` Sergei Organov
2001-03-28 11:05 ` Grant Edwards
2001-03-29 11:51 ` Sergei Organov
2001-03-29 11:49 ` Grant Edwards
2001-03-28 10:01 ` Jonathan Larmour
2001-03-29 11:55 ` Chris Gray
2001-03-29 19:33 ` Bart Veer
2001-03-29 20:50 ` Grant Edwards
2001-03-30 2:22 ` Sergei Organov
2001-03-30 6:54 ` Grant Edwards
2001-03-30 7:42 ` Sergei Organov
2001-03-30 5:39 Rosimildo daSilva
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=200103281539.f2SFdAE07390@sheesh.cambridge.redhat.com \
--to=bartv@redhat.com \
--cc=ecos-discuss@sourceware.cygnus.com \
--cc=osv@javad.ru \
/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).