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

[Sergei Organov <osv at javad dot ru>]

Grant Edwards <grante@visi.com> writes:

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

Sorry, maybe my wording is not exact once again :-( It's not invalid in the
weak sense of the word, i.e., program that uses them for mutual exclusion is
not necessarily invalid. But I believe that it's somewhat invalid use as the
only primitive that is designed for mutual exclusion in reasonably recently
developed systems is mutex.

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

Yes. Since mutexes were invented, semaphores shouldn't be used for mutual
exclusion anymore, I believe. I'm aware that some time ago binary semaphores
were being used for mutual exclusion and some people are used to it. Maybe
that's the primary source of confusion about usage of binary 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"?

Well, this is just terminology. I prefer to don't consider mutual exclusion a
kind of synchronization as they have different aims. The aim of mutual
exclusion is disallowing simultaneous access to a shared resource, while the
aim of synchronization is, well, to synchronize task activities. Such approach
just seems to be clearer to me and leads to less confusion, I believe. It also
seems to be more reasonable as different primitives are currently used for
these two purposes.

Though my opinion could be expressed using your terminology as well: "Use
mutexes for mutual exclusion and other primitives for other kinds 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.

Historically, yes. But currently old binary semaphores are called "mutexes", I
believe, and current binary semaphores just lost their initial purpose to be
used 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.

As I already answered above, I consider using binary semaphores for mutual
exclusion a mistake for those systems where mutexes exist. For those old
systems where binary semaphores are designed for mutual exclusion there is no
other choice than to use them. For their intended usage old binary semaphores
are similar to newer mutexes.

If everybody seemed happy with binary semaphores for mutual exclusion, why do
you think mutexes were invented after all?

Finally, all the above obviously is just my own understanding of the problem
and it could be the case that it has nothing to do with reality at all.

BR,
Sergei,
BinSemGuard.