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

[Bart Veer <bartv at redhat dot com>]

>>>>> "Nick" == Nick Garnett <nickg@cambridge.redhat.com> writes:

    <snip>

    >> > since a counting semaphore initialized to 1 is functionally
    >> > equivalent.
    >> 
    >> Not quite. There are sequences of wait()/post() that will not
    >> give the same results for an boolean and integer semaphore.
    >> 
    >> Task 1                Task 2
    >> ------                ------
    >> [semaphore value == 1]
    >> wait()
    >> post()
    >> post()
    >> wait()                wait()
    >> 
    >> At this point, only one of the tasks is runnable with binary
    >> semaphores, but both are runnable with a counting semaphore.
    >> 
    >> Admittedly, multiple posts is probably a bug if you intend the
    >> semaphore to be used for mutual exclusion, but using a binary
    >> semaphore protects you from such bugs.

    Nick> I would say that binary semaphores mask the bug, rather that
    Nick> protect you. In the above example the second post() is just
    Nick> lost. With counting semaphores it has an effect, which you
    Nick> would hopefully pick up during testing.

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.

Bart