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

[Sergei Organov <osv at javad dot ru>]

Grant,

For me it seems that I didn't express my intentions clearly enough. I don't
argue against your usage of binary semaphore as this usage is not for mutual
exclusion in its classic form (for which we have mutexes now). Also, your
usage of anything doesn't affect me, so why bother. I'm arguing against adding
assertion to the current binary semaphore and against removing it
entirely. That's my point.

Having that it seems that both you and I are trying to achieve the same goal
and thus we don't have to dispute.

More below...

Grant Edwards <grante@visi.com> writes:
> On Fri, Mar 30, 2001 at 02:22:43PM +0400, Sergei Organov wrote:
>
> > Exactly. I started to write my own explanation of differences,
> > but you already explained it perfectly. The only thing that I'd
> > like to make more explicit is that having owner concept not
> > only makes provision for implementing of priority inheritance,
> > but also is a good thing by itself as unlocking mutex by
> > non-owner is explicitly prohibited. It's like bathroom door
> > lock, -- once you entered the bathroom and locked the door,
> > nobody else can enter until you unlock it, -- that's what
> > mutual exclusion is about.
>
> In my situation, two people enter the bathroom.  One is
> responsible for locking the door, the other is responsible for
> unlocking the door.  The other pair of people isn't allowed to
> enter until the first pair is done.
>
> I won't speculate on why two people need to be in a locked
> bathroon. ;)
>
> This is apparently "wrong" in the opinion of many, but the
> application would be made far more complex and diffucult to
> maintain if I had to do the same amount of work with half the
> threads.  I'd bascially have to have "superloop" threads
> polling for all outside inputs rathr than having one thread
> blocking on rx data from each source.  I apologize if my system
> requirements don't fit the expectations of kernel theorists,
> but that's life.
>
> > Using binary semaphore for mutual exclusion resembles using of
> > bathroom lock that is easily unlocked from outside.
>
> A mutex is equally as easy to bypass -- you just don't call
> lock() before accessing the shared resource.  There's no way to
> enforce the semantics that you call lock() on a mutex before
> accessing the resource just as there's no way to enforce the
> semantics that only one of the "owners" of a semaphore used for
> mutual exclusion perform the post().  Incorrect programs do not
> work right regardless of the semantics of the primitives.

Bypassing mutex (either don't call it or attempt to unlock) is more like
breaking (physically destroying) the lock. It has nothing to do with its
semantics. Semantics of binary semaphore explicitly allows to unlock it by
anybody.

>
> > I think that original post has a scenario for which there is no
> > primitive in eCos that exactly matches requirements
>
> No, eCos's binary semaphore has the _exact_ semantics I needed
> (including what happens on multiple post() calls).

I meant your high-level semantics (direct support for two persons in bathroom
one of which locks the door), not low-level semantics of binary semaphore.

> Since it's
> not available in the C API, I used a counting semaphore -- the
> semantics aren't exactly what I desired, but they're close
> enough to be workable.

What I don't understand in your explanation though is why binary semaphore is
better for your problem than counting semaphore? It seems that it should make
no difference for you.

[...]

> What's a read-write lock?

Read-write lock grants multiple threads simultaneous read-only access to a
resource. Thread that wishes to write to the resource should get
exclusive access though. Thus this object has at least 'lock_for_read',
'lock_for_write', and 'unlock' methods. Multiple readers, single writer.

>
> > but apparently is even more complicated. One of solutions,
> > IMHO, is to implement special object on top of primitives that
> > eCos provides and use it in the application.
>
> I suppose I could impliment a binary semaphore object using a
> counting semaphore.  Seems silly.

Once again it's not clear why binary semaphore doesn't fit.

>
> > Then it will be this object that will take care of preserving
> > semantics of eCos primitives it uses. And if it is possible to
> > build it on top of current binary semaphore,
>
> The semantics I want _is_ the current binary semaphore! The
> semantic difference between the binary and counting semaphore
> only differ for cases that "can't" happen in my program, so I'm
> just using the counting semaphore at the moment.

Great. What's a problem then? Does it mean that you actually don't need binary
semaphore?

>
> > it is also possible to build it on top of current counting
> > semaphore, I believe. I'm still not convinced that tuning eCos
> > primitive for such questionable usage is a good idea especially
> > as it prohibits another possible application.
>
> I didn't ask for anything to be tuned.  I asked (out of
> curiosity) why an existing primitive whose semantics matched my
> needs exactly wasn't made visible to the user.

I know you didn't. Other(s) did, and I've tried to prevent it.

>
> > > Depending on very subtle timing differences, e.g. when the
> > > thread doing the posts gets timesliced, both sequences are
> > > equally likely to happen but the resulting behaviour would be
> > > very different. I am somewhat uncomfortable with a
> > > synchronization primitive that can lead to such
> > > non-deterministic behaviour.
> >
> > The intended usage assumes that the two sequences you've
> > mentioned don't actually make visible behavior of the program
> > different, otherwise there is a race condition and thus the
> > program is just incorrect. If a program is broken, it's just
> > broken no matter what primitive is used.
>
> Exactly.
>
> > In the simplest case the suggested use for (otherwise
> > obsolete?) binary semaphore
>
> I don't understand why binary semaphores have been declared
> "obsolete".  I have an application where I need a binary
> semaphore (call it a "un-owned mutex" if you want -- it's still
> nothing more than a binary semaphore).  Do I tell management
> that we can't ship this product because one of the parts I need
> has gone obsolete? The hardware guys are always using _that_
> excuse. ;)
>
> > I have nothing against having both semantics, I just doesn't
> > think it is worth efforts.
>
> What I asked about was using the existing binary semaphore.
> The amount of effort required to add the existing binary
> semaphore to the C api would be trivial.  It wasn't done for
> philosophical reasons.

And I didn't ask for anything that would made your life harder, I believe. In
fact I've asked for the same thing as you, but by means of giving another
example of use of binary semaphore. So I'm on your side, not on the other.

[...]

Sergei.