[ECOS] No binary semaphore in C API?
Tue Mar 27 02:00:00 GMT 2001
Grant Edwards <firstname.lastname@example.org> writes:
> On Mon, Mar 26, 2001 at 12:39:07PM +0100, Nick Garnett wrote:
> > > > Is there a technical reason that there isn't a C API for binary
> > > > semaphores, or is it something that just hasn't been done yet?
> > >
> > > Certainly no technical reason. Nick may not have done it out of
> > > principle. But right now he's on vacation, so it's best to wait
> > > till he returns.
> > It was never intended that the KAPI be a complete reflection of
> > the kernel implementation. It is meant to be a consistent,
> > self-contained, small API that can be used by C applications.
> > Like the uITRON and POSIX APIs it only exposes a subset. It was
> > considered unnecessary to export binary semaphores,
> Why impliment binary semaphores if there is no intent to
> allow their use?
They are available from C++. Binary semaphores were one of the first
synchronization primitives I implemented. It happens that none of the
APIs use them, so they are somewhat redundant. I could always remove
them if that would make you happier :-)
> > 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() 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.
I would say that binary semaphores mask the bug, rather that protect
you. In the above example the second post() is just lost. With
counting semaphores it has an effect, which you would hopefully pick
up during testing.
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK
More information about the Ecos-discuss