Re: [ECOS] No binary semaphore in C API?

[Grant Edwards <grante at visi dot com>]

On Thu, Mar 29, 2001 at 12:18:40PM +0100, Bart Veer wrote:

> Now, I am not entirely convinced that this use of binary semaphores is
> a good idea. Specifically, consider the sequences of events
> wait/post/post/wait and wait/post/wait/post, where the waits and the
> posts happen in different threads and are not otherwise synchronized.
> Depending on very subtle timing differences, e.g. when the thread
> doing the posts gets timesliced, both sequences are equally likely to
> happen but the resulting behaviour would be very different. I am
> somewhat uncomfortable with a synchronization primitive that can lead
> to such non-deterministic behaviour.

The same problem arises with almost any synchronization
primitive.  Consider a mutex: if two threads do a lock() at the
"same" time, a tiny change in timing alters which task obtains
the resource -- resulting in a possibly large change in program
behavior for an infinitely small change in timing.  The
behavior of systems with unsychronized inputs is like that.

> The current binary semaphore implementation does not have the
> assertion, so it is not the best solution for mutual
> exclusion. That argues for a new class, e.g. Cyg_UnownedMutex,
> to serve that purpose. The Cyg_Binary_Semaphore class could
> then be left as is, i.e. behaving as per Sergei's event
> signalling usage. That could still confuse people who are used
> to thinking about binary semaphores as a legal mutual
> exclusion primitive, as per old reference titles. To avoid
> that we could also rename Cyg_Binary_Semaphore to something
> else, breaking the historical association.

Since the binary semaphore isn't exported as part of the
kernel's C api, it's largely a moot question.  :)

-- 
Grant Edwards
grante@visi.com