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?


Bart Veer <bartv@redhat.com> writes:
> >>>>> "Sergei" == Sergei Organov <osv@javad.ru> writes:
> 
>     <snip>
> 
>     >> 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.
> 
>     Sergei> Sorry, but for me it seems that initial assumption --
>     Sergei> using semaphore for mutual exclusion -- is wrong, so the
>     Sergei> rest of argumentation doesn't make much sense for me.
>     Sergei> Don't we have mutexes for mutual exclusion? Just use
>     Sergei> mutexes and put corresponding 'CYG_ASSERT' into mutex
>     Sergei> implementation if it is not already there.
> 
> The original posting,
> http://sources.redhat.com/ml/ecos-discuss/2001-03/msg00250.html
> described why a binary semaphore was being used rather than a mutex.
> 
>   "I've got a mutual-exclusion requirement but can't use cyg_mutex_t
>    because one thread locks and a different thread unlocks the
>    resource. [It's kind of complicated, the mutal exclusion is between
>    two "groups" of threads.]"
>

I didn't try to solve initial poster's problem, -- I tried to argue against
changes in binary semaphore semantics. My apologies if it was not clear from
my post.

> In that context the assertion would be correct.

Yes, I see, but attempt was made to make general decisions about semantics of
binary semaphore based on its incorrect use. 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. If there are two possible semantics one of which is useful for
invalid use and another is useful for valid use, which one is preferred? For
me the answer is clear.

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

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

Exactly.

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

Yes, somebody will be confused no matter what. But again this is true for
every primitive. For example, sometimes people are confused by the fact that
sending two events may result in single wake-up. Does it make events semantics 
confusing? Is it a cause to change events semantics or remove their support?
How it is different from binary semaphores?

Sergei,
BinarySemaphoreGuard. :-)


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