public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
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

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