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

[Grant Edwards <grante at visi dot com>]

On Wed, Mar 28, 2001 at 10:01:11PM +0400, Sergei Organov wrote:

> Yes, I see, but attempt was made to make general decisions
> about semantics of binary semaphore based on its incorrect use.

What incorrect use is that?

> Every primitive could be used incorrectly, -- this doesn't mean
> its semantics is unclear.
> 
> > You describe a different use for binary semaphores where the
> > assertion would be incorrect.
> 
> Yes, and I think that unlike initial poster I described correct
> use for binary semaphore.

Are you saying that using semaphores for mutual exlcusion is
an "incorrect" usage?  According the OS text we used (many
years ago), mutual exclusions was one ot standard uses for
semaphores. 

> > Hence there is confusion about semantics, which is pretty
> > disastrous for a synchronization primitive.
> 
> The key word here is "synchronization", I think. Using
> synchronization primitive for mutual exclusion is a mistake no
> matter which synchronization primitive is used.

Your usage of "mutal exclusion" vs. "synchronization" is new to
me. I was taught that mutual exclusion is one type of
synchronization.  What's your definition of "synchronization"?

> This has nothing to do with semantics of binary semaphore, I'm
> afraid. For example, the same way I can try to prove that mutex
> has confusing semantics: "I've tried to use it for task
> synchronization but that didn't work as expected" ;-) Didn't
> you hear about guys that try to lock mutex from one thread and
> then unlock it from another? I heard it many times, but nobody
> wants to remove mutexes or change their semantics because of
> this.
> 
> I believe that once semantics is documented, there should be no
> confusion about it. And the only semantics that seems to be
> reasonable for binary semaphore is the current one.

I also think that once you decide what to do about post() on a
true-valued semaphore, the semantics for a binary semphore are
not ambiguous or confusing at all.  Either a second post() is a
noop, or it's not allowed.

> > Arguably the better alternative would be to implement a new
> > mutex class which deals with thread groups, rather than
> > overloading binary semaphores.

I don't see how this is "overloading" a binary semaphore.  I
thought that mutual exclusion was one of the primary uses for
which binary semaphores were intended.

> > The latter could then be left with their existing semantics,
> > although people might still be confused and use them
> > incorrectly for mutual exclusion.

Again, why is it incorrect to use a binary semaphor for mutual
exclusion?  FWIW, that's how I was taught to do mutual
exclusion.  Way back when, all we had were semaphores (binary
or counting), and we got along just fine. ;) Both of the RTOS
kernels I designed had nothing other than binary semaphores for
mutual exclusion, and everybody seemed happy.

-- 
Grant Edwards
grante@visi.com