This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


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

Re: No binary semaphore in C API?


>>>>> "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


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