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?


On Wed, Mar 28, 2001 at 06:45:06PM +0400, Sergei Organov wrote:

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

I can't use a mutex because a mutex must be unlocked by the
same thread that locked it.  In my application the mutual
exclusion is between two groups of threads.  In each group of
threads there is one thread that acquires the resource and then
some time later a different thread releases it.  One of the
groups of threads is a legacy application and I don't have time
to re-design it.  [I've already got a legacy eCos app I'm
trying to integrate into a newer eCos based system.]

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

In my application multiple posts aren't supposed to happen, so
if it does it's a bug.  With counting semaphores the bug has
noticable results.  With a binary semaphore *where a second
post is defined as noop* the bug is masked. OTOH, I think it
could be easily argued that a post on a binary semaphore
already in state 1 should be defined to be illegal or have
undefined behavior.

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

-- 
Grant Edwards
grante@visi.com


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