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

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

> and there will never be one

There _is_ one.

> I guess as the problem that should be solved is rather complex
> and hopefully rare. Somebody (you?) described it as "mutual
> exclusion between thread groups".
>
> For me it belongs to the same class as read-write locks

What's a read-write lock?

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

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

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

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

This whole thread is basically:

 Why can't I use X?
 I don't like X.

 I need to do what X does.
 You don't want to use X.

 Yes I do.
 Using X is invalid.

 My product requires me to do what X does.
 Y is newer and cooler than X.

 Y won't work in my product, X will.
 X is obsolete, it's been replaced by Y.

 Y won't work in my product, X will.
 Yes, but in a different situation Y works better than X.

 Y won't work in my product. X will.
 You shouldn't be doing what X does.

 My product needs to do what X does.
 Y is better than X.

 Y won't work in my product, X will.
 X is obsolete. Use Y.

 ....

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