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

[Sergei Organov <osv at javad dot ru>]

Bart Veer <bartv@redhat.com> writes:

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

Sorry, but for me it seems that initial assumption -- using semaphore for
mutual exclusion -- is wrong, so the rest of argumentation doesn't make much
sense for me. Don't we have mutexes for mutual exclusion? Just use mutexes and 
put corresponding 'CYG_ASSERT' into mutex implementation if it is not already
there.

Binary semaphores could be used for task synchronization when their behavior
fits better than those of two other light-weight primitives, events (signals)
and counting semaphores. To send event one needs to know task id to send event
to, and using counting semaphore doesn't allow to get single wake-up after
multiple posts without additional logic. Thus the binary semaphore combines
two useful features of events and counting semaphores in one primitive that
makes it pretty useful.

This makes me feel that completely clear semantics for binary semaphore does
exist and matches its current semantics in the eCos kernel, i.e., neither
suggested 'CYG_ASSERT' nor removing binary semaphore support are good ideas,
IMHO.

Sergei.