[ECOS] No binary semaphore in C API?

[ECOS] No binary semaphore in C API?

[Grant Edwards]

Hi all,

I see that the kernel impliments binary semaphores, but I can't
see a C API for them.  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.]

So, I wanted to use binary semaphores, but can't find the API.
The program is using counting semaphores right now, but using a
binary ones would be a bit more "defensive".

Is there a technical reason that there isn't a C API for binary
semaphores, or is it something that just hasn't been done yet?

-- 
Grant Edwards
grante@visi.com

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

[Jonathan Larmour]

Grant Edwards wrote:
> 
> So, I wanted to use binary semaphores, but can't find the API.
> The program is using counting semaphores right now, but using a
> binary ones would be a bit more "defensive".
> 
> Is there a technical reason that there isn't a C API for binary
> semaphores, or is it something that just hasn't been done yet?

Certainly no technical reason. Nick may not have done it out of principle.
But right now he's on vacation, so it's best to wait till he returns.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

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

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.com> writes:

> Grant Edwards wrote:
> > 
> > So, I wanted to use binary semaphores, but can't find the API.
> > The program is using counting semaphores right now, but using a
> > binary ones would be a bit more "defensive".
> > 
> > Is there a technical reason that there isn't a C API for binary
> > semaphores, or is it something that just hasn't been done yet?
> 
> Certainly no technical reason. Nick may not have done it out of principle.
> But right now he's on vacation, so it's best to wait till he returns.
> 

It was never intended that the KAPI be a complete reflection of the
kernel implementation. It is meant to be a consistent, self-contained,
small API that can be used by C applications. Like the uITRON and
POSIX APIs it only exposes a subset. It was considered unnecessary to
export binary semaphores, since a counting semaphore initialized to 1
is functionally equivalent.

If I had had my way the KAPI would have been even more minimal that it
currently is.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

[Fabrice Gautier]

On 26 Mar 2001 12:39:07 +0100
Nick Garnett <nickg@cygnus.co.uk> wrote:
> 
> It was never intended that the KAPI be a complete reflection of the
> kernel implementation. [...]
> If I had had my way the KAPI would have been even more minimal that it
> currently is.

Aahhh... Is that why my (quite old now) patch implementing the C KAPI
for the clock conversion functions was never included in the official
tree ?

(Well, maybe it is now, havent look at it too closely recently)

Nevermind anyway,...

A+
-- 
Fabrice Gautier <gautier@email.enstfr>

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

[Grant Edwards]

On Mon, Mar 26, 2001 at 12:39:07PM +0100, Nick Garnett wrote:

> > > Is there a technical reason that there isn't a C API for binary
> > > semaphores, or is it something that just hasn't been done yet?
> > 
> > Certainly no technical reason. Nick may not have done it out of
> > principle. But right now he's on vacation, so it's best to wait
> > till he returns.
> 
> It was never intended that the KAPI be a complete reflection of
> the kernel implementation. It is meant to be a consistent,
> self-contained, small API that can be used by C applications.
> Like the uITRON and POSIX APIs it only exposes a subset. It was
> considered unnecessary to export binary semaphores,

Why impliment binary semaphores if there is no intent to
allow their use?

> since a counting semaphore initialized to 1 is functionally
> equivalent.

Not quite.  There are sequences of wait()/post() that will not
give the same results for an boolean and integer semaphore.

        Task 1                Task 2
        ------                ------
          [semaphore value == 1]
        wait()
        post()
        post()
        wait()                wait()

At this point, only one of the tasks is runnable with binary
semaphores, but both are runnable with a counting semaphore.

Admittedly, multiple posts is probably a bug if you intend the
semaphore to be used for mutual exclusion, but using a binary
semaphore protects you from such bugs.

-- 
Grant Edwards
grante@visi.com

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

[Nick Garnett]

Grant Edwards <grante@visi.com> writes:

> On Mon, Mar 26, 2001 at 12:39:07PM +0100, Nick Garnett wrote:
> 
> > > > Is there a technical reason that there isn't a C API for binary
> > > > semaphores, or is it something that just hasn't been done yet?
> > > 
> > > Certainly no technical reason. Nick may not have done it out of
> > > principle. But right now he's on vacation, so it's best to wait
> > > till he returns.
> > 
> > It was never intended that the KAPI be a complete reflection of
> > the kernel implementation. It is meant to be a consistent,
> > self-contained, small API that can be used by C applications.
> > Like the uITRON and POSIX APIs it only exposes a subset. It was
> > considered unnecessary to export binary semaphores,
> 
> Why impliment binary semaphores if there is no intent to
> allow their use?

They are available from C++. Binary semaphores were one of the first
synchronization primitives I implemented. It happens that none of the
APIs use them, so they are somewhat redundant. I could always remove
them if that would make you happier :-)

> 
> > since a counting semaphore initialized to 1 is functionally
> > equivalent.
> 
> Not quite.  There are sequences of wait()/post() that will not
> give the same results for an boolean and integer semaphore.
> 
>         Task 1                Task 2
>         ------                ------
>           [semaphore value == 1]
>         wait()
>         post()
>         post()
>         wait()                wait()
> 
> At this point, only one of the tasks is runnable with binary
> semaphores, but both are runnable with a counting semaphore.
> 
> Admittedly, multiple posts is probably a bug if you intend the
> semaphore to be used for mutual exclusion, but using a binary
> semaphore protects you from such bugs.
>

I would say that binary semaphores mask the bug, rather that protect
you. In the above example the second post() is just lost. With
counting semaphores it has an effect, which you would hopefully pick
up during testing.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

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

[Grant Edwards]

On Tue, Mar 27, 2001 at 10:46:18AM +0100, Nick Garnett wrote:

> > Why impliment binary semaphores if there is no intent to
> > allow their use?
> 
> They are available from C++. Binary semaphores were one of the first
> synchronization primitives I implemented. It happens that none of the
> APIs use them, so they are somewhat redundant. I could always remove
> them if that would make you happier :-)

Sure -- then I don't have to be jealous.  Counting semaphores
are working just fine, but I was curious.

-- 
Grant Edwards
grante@visi.com

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

[Bart Veer]

>>>>> "Nick" == Nick Garnett <nickg@cambridge.redhat.com> writes:

    <snip>

    >> > since a counting semaphore initialized to 1 is functionally
    >> > equivalent.
    >> 
    >> Not quite. There are sequences of wait()/post() that will not
    >> give the same results for an boolean and integer semaphore.
    >> 
    >> Task 1                Task 2
    >> ------                ------
    >> [semaphore value == 1]
    >> wait()
    >> post()
    >> post()
    >> wait()                wait()
    >> 
    >> At this point, only one of the tasks is runnable with binary
    >> semaphores, but both are runnable with a counting semaphore.
    >> 
    >> Admittedly, multiple posts is probably a bug if you intend the
    >> semaphore to be used for mutual exclusion, but using a binary
    >> semaphore protects you from such bugs.

    Nick> I would say that binary semaphores mask the bug, rather that
    Nick> protect you. In the above example the second post() is just
    Nick> lost. With counting semaphores it has an effect, which you
    Nick> would hopefully pick up during testing.

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.

Bart

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

[Sergei Organov]

Bart Veer <bartv@redhat.com> writes:

> >>>>> "Nick" == Nick Garnett <nickg@cambridge.redhat.com> writes:
> 
>     <snip>
> 
>     >> > since a counting semaphore initialized to 1 is functionally
>     >> > equivalent.
>     >> 
>     >> Not quite. There are sequences of wait()/post() that will not
>     >> give the same results for an boolean and integer semaphore.
>     >> 
>     >> Task 1                Task 2
>     >> ------                ------
>     >> [semaphore value == 1]
>     >> wait()
>     >> post()
>     >> post()
>     >> wait()                wait()
>     >> 
>     >> At this point, only one of the tasks is runnable with binary
>     >> semaphores, but both are runnable with a counting semaphore.
>     >> 
>     >> Admittedly, multiple posts is probably a bug if you intend the
>     >> semaphore to be used for mutual exclusion, but using a binary
>     >> semaphore protects you from such bugs.
> 
>     Nick> I would say that binary semaphores mask the bug, rather that
>     Nick> protect you. In the above example the second post() is just
>     Nick> lost. With counting semaphores it has an effect, which you
>     Nick> would hopefully pick up during testing.
> 
> 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.

Sorry, but for me it seems that initial assumption -- using semaphore for
mutual exclusion -- is wrong, so the rest of argumentation doesn't make much
sense for me. Don't we have mutexes for mutual exclusion? Just use mutexes and 
put corresponding 'CYG_ASSERT' into mutex implementation if it is not already
there.

Binary semaphores could be used for task synchronization when their behavior
fits better than those of two other light-weight primitives, events (signals)
and counting semaphores. To send event one needs to know task id to send event
to, and using counting semaphore doesn't allow to get single wake-up after
multiple posts without additional logic. Thus the binary semaphore combines
two useful features of events and counting semaphores in one primitive that
makes it pretty useful.

This makes me feel that completely clear semantics for binary semaphore does
exist and matches its current semantics in the eCos kernel, i.e., neither
suggested 'CYG_ASSERT' nor removing binary semaphore support are good ideas,
IMHO.

Sergei.

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

[Grant Edwards]

On Wed, Mar 28, 2001 at 06:45:06PM +0400, Sergei Organov wrote:

> >     Nick> I would say that binary semaphores mask the bug, rather that
> >     Nick> protect you. In the above example the second post() is just
> >     Nick> lost. With counting semaphores it has an effect, which you
> >     Nick> would hopefully pick up during testing.
> > 
> > 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.
> 
> Sorry, but for me it seems that initial assumption -- using
> semaphore for mutual exclusion -- is wrong, so the rest of
> argumentation doesn't make much sense for me. Don't we have
> mutexes for mutual exclusion? Just use mutexes and put
> corresponding 'CYG_ASSERT' into mutex implementation if it is
> not already there.

I can't use a mutex because a mutex must be unlocked by the
same thread that locked it.  In my application the mutual
exclusion is between two groups of threads.  In each group of
threads there is one thread that acquires the resource and then
some time later a different thread releases it.  One of the
groups of threads is a legacy application and I don't have time
to re-design it.  [I've already got a legacy eCos app I'm
trying to integrate into a newer eCos based system.]

> Binary semaphores could be used for task synchronization when
> their behavior fits better than those of two other light-weight
> primitives, events (signals) and counting semaphores. To send
> event one needs to know task id to send event to, and using
> counting semaphore doesn't allow to get single wake-up after
> multiple posts without additional logic. 

In my application multiple posts aren't supposed to happen, so
if it does it's a bug.  With counting semaphores the bug has
noticable results.  With a binary semaphore *where a second
post is defined as noop* the bug is masked. OTOH, I think it
could be easily argued that a post on a binary semaphore
already in state 1 should be defined to be illegal or have
undefined behavior.

> Thus the binary semaphore combines two useful features of
> events and counting semaphores in one primitive that makes it
> pretty useful.
> 
> This makes me feel that completely clear semantics for binary
> semaphore does exist and matches its current semantics in the
> eCos kernel, i.e., neither suggested 'CYG_ASSERT' nor removing
> binary semaphore support are good ideas, IMHO.

-- 
Grant Edwards
grante@visi.com

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

[Bart Veer]

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

In that context the assertion would be correct. You describe a
different use for binary semaphores where the assertion would be
incorrect. Hence there is confusion about semantics, which is pretty
disastrous for a synchronization primitive.

Arguably the better alternative would be to implement a new mutex
class which deals with thread groups, rather than overloading
binary semaphores. The latter could then be left with their existing
semantics, although people might still be confused and use them
incorrectly for mutual exclusion.

Bart

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

[Sergei Organov]

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

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

[Jonathan Larmour]

Bart Veer wrote:
> 
> Arguably the better alternative would be to implement a new mutex
> class which deals with thread groups, rather than overloading
> binary semaphores. The latter could then be left with their existing
> semantics, although people might still be confused and use them
> incorrectly for mutual exclusion.

Why don't we just make a CDL variable controlling which behaviour you get,
with the failsafe assert version the default? That way the behaviour is
implementation defined, not undefined.

Personally I think binary semaphores are a useful paradigm, *complementary*
to other sync primitives. I think it's better to provide a useful toolkit
than try to enforce personal preferences about the way to write
multi-threaded code.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

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

[Grant Edwards]

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

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

[Grant Edwards]

On Thu, Mar 29, 2001 at 11:39:12AM +0400, Sergei Organov wrote:

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

So semaphores not only have defined semantics, but defined
things you're allowed to do in a program using those semantics?
That seems a bit odd.  That's like saying "you're allowed to
use integer math to count blue widgets but not orange widgets."

> > > Every primitive could be used incorrectly, -- this doesn't mean
> > > its semantics is unclear.

How can a primitive use be use incorrect if you are using the
defined semantics to accomplish a goal?  I can see a usage as
being incorrect if it depends on undefined behavior or
platform-dependant side-effects.

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

Can you explain why do you believe that?  Binary semaphores
have defined semantics. The semantics for binary semaphores are
those of mutual exclusion.  Mutual exclusion is what binary
semaphores do. If you don't use binary semaphores for mutual
exclusion, what is the correct usage?

What is the difference between a mutex and a binary semaphore?

The only one I can see in a quick glance at the sources is that
a mutex has to be unlocked by the same thread that locked it.

Othewise they are the same thing.

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

They still are.  They just changed the spelling from "binary
semaphore" to "mutex".  ;)

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

Yup.

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

I consider that synchronization.  You're trying to control the
states of tasks over time with respect to each other.

> while the aim of synchronization is, well, to synchronize task
> activities.

Like making sure that they don't try to do a certain thing at
the same time? :)

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

OK, if we change mutexes so that they can be unlocked by a
thread different than the on that did the lock, what is the
difference in semantics between a binary semaphore and a mutex?

As far as I can tell, they are identical.

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

So it's OK to use a binary semaphore for mutual exclusion as
long as you spell it "mutex" and not "binary semaphore." 

BTW, what is the difference between an "old binary semaphore"
(now called a mutex) and a "current binary semaphore"?

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

Frankly, I can't see that mutexes are anything different than
binary semaphores, so I don't know how one could claim to have
"invented" mutexes.  Prior art and all that.  Perhaps I haven't
looked at the internals enough, but the invention of the
"mutex" seems to be mainly a change in spelling of the function
name.

-- 
Grant Edwards
grante@visi.com

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

[Sergei Organov]

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.

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

[Chris Gray]

Bart Veer wrote:

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

As I understand it, the theoretical semantics of a binary semaphore is that

you "cannot" post to it twice.  To the theoretician, the question of what
happens
when something that can't happen happens is purely hypothetical.

In the system I'm currently working on (which uses ThreadX, but may one day

move to eCos), we have a macro assertSemaphore which is most often used in
the form "assertSemaphore(&s,1)" -- in other words to check that binary
semaphore semantics are being respected. So maybe such an optional runtime
check is all you need to add to counting semaphores to make them usable as
binary ones.

Regards

Chris

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

[Bart Veer]

>>>>> "Chris" == Chris Gray <gray@acunia.com> writes:

    Chris> Bart Veer wrote:
    >> 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.

    Chris> As I understand it, the theoretical semantics of a binary
    Chris> semaphore is that you "cannot" post to it twice. To the
    Chris> theoretician, the question of what happens when something
    Chris> that can't happen happens is purely hypothetical.

Maybe it is time to look at some history.

Looking at a 15-year old copy of an OS reference book, Peterson and
Silberschatz, it describes the use of semaphores for mutual exclusion.
However there are some problems with this use: most importantly a
semaphore does not have the concept of a current owner thread, so the
system can do nothing about priority inversion problems. Hence the
introduction of a new primitive, the mutex, for mutual exclusion.
Semaphores are still very useful, but as a means of communicating
information between threads rather than for mutual exclusion.

The original posting that started this thread involved a scenario
where a mutex could not be used for mutual exclusion, so a binary
semaphore was substituted instead. A side effect of this is that the
system cannot help avoid priority inversion problems, so that will
have to be addressed at the application level. For mutual exclusion
usage, you need to worry about what happens if the application
incorrectly executes a sequence lock/unlock/unlock/lock. IMO this
should result in an assertion failure inside the second unlock, to
facilitate tracking down the problem.

Sergei described an alternative usage of binary semaphores as a
synchronization primitive, for communication between threads:
basically a way of informing other threads that some event has
happened at least once. For this usage multiple posts to a binary
semaphore should be equivalent to a single post, i.e. there is no
difference in behaviour between wait/post/wait and
wait/post/post/wait. For this usage, the assertion would be incorrect.

Now, I am not entirely convinced that this use of binary semaphores is
a good idea. Specifically, consider the sequences of events
wait/post/post/wait and wait/post/wait/post, where the waits and the
posts happen in different threads and are not otherwise synchronized.
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 current binary semaphore implementation does not have the
assertion, so it is not the best solution for mutual exclusion. That
argues for a new class, e.g. Cyg_UnownedMutex, to serve that purpose.
The Cyg_Binary_Semaphore class could then be left as is, i.e. behaving
as per Sergei's event signalling usage. That could still confuse
people who are used to thinking about binary semaphores as a legal
mutual exclusion primitive, as per old reference titles. To avoid that
we could also rename Cyg_Binary_Semaphore to something else, breaking
the historical association.

I am not sure anybody would be happy with this solution.

Bart

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

[Grant Edwards]

On Thu, Mar 29, 2001 at 12:18:40PM +0100, Bart Veer wrote:

> Now, I am not entirely convinced that this use of binary semaphores is
> a good idea. Specifically, consider the sequences of events
> wait/post/post/wait and wait/post/wait/post, where the waits and the
> posts happen in different threads and are not otherwise synchronized.
> 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 same problem arises with almost any synchronization
primitive.  Consider a mutex: if two threads do a lock() at the
"same" time, a tiny change in timing alters which task obtains
the resource -- resulting in a possibly large change in program
behavior for an infinitely small change in timing.  The
behavior of systems with unsychronized inputs is like that.

> The current binary semaphore implementation does not have the
> assertion, so it is not the best solution for mutual
> exclusion. That argues for a new class, e.g. Cyg_UnownedMutex,
> to serve that purpose. The Cyg_Binary_Semaphore class could
> then be left as is, i.e. behaving as per Sergei's event
> signalling usage. That could still confuse people who are used
> to thinking about binary semaphores as a legal mutual
> exclusion primitive, as per old reference titles. To avoid
> that we could also rename Cyg_Binary_Semaphore to something
> else, breaking the historical association.

Since the binary semaphore isn't exported as part of the
kernel's C api, it's largely a moot question.  :)

-- 
Grant Edwards
grante@visi.com

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

[Sergei Organov]

Bart Veer <bartv@redhat.com> writes:

[...]

> Maybe it is time to look at some history.
>
> Looking at a 15-year old copy of an OS reference book, Peterson and
> Silberschatz, it describes the use of semaphores for mutual exclusion.
> However there are some problems with this use: most importantly a
> semaphore does not have the concept of a current owner thread, so the
> system can do nothing about priority inversion problems. Hence the
> introduction of a new primitive, the mutex, for mutual exclusion.
> Semaphores are still very useful, but as a means of communicating
> information between threads rather than for mutual exclusion.

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. Using binary semaphore
for mutual exclusion resembles using of bathroom lock that is easily unlocked
from outside. 

>
> The original posting that started this thread involved a scenario
> where a mutex could not be used for mutual exclusion, so a binary
> semaphore was substituted instead. A side effect of this is that the
> system cannot help avoid priority inversion problems, so that will
> have to be addressed at the application level. For mutual exclusion
> usage, you need to worry about what happens if the application
> incorrectly executes a sequence lock/unlock/unlock/lock. IMO this
> should result in an assertion failure inside the second unlock, to
> facilitate tracking down the problem.

I think that original post has a scenario for which there is no primitive in
eCos that exactly matches requirements and there will never be 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 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. 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, 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.

>
> Sergei described an alternative usage of binary semaphores as a
> synchronization primitive, for communication between threads:
> basically a way of informing other threads that some event has
> happened at least once. For this usage multiple posts to a binary
> semaphore should be equivalent to a single post, i.e. there is no
> difference in behaviour between wait/post/wait and
> wait/post/post/wait. For this usage, the assertion would be incorrect.
>
> Now, I am not entirely convinced that this use of binary semaphores is
> a good idea. Specifically, consider the sequences of events
> wait/post/post/wait and wait/post/wait/post, where the waits and the
> posts happen in different threads and are not otherwise synchronized.
> 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.

In the simplest case the suggested use for (otherwise obsolete?) binary
semaphore is a producer-consumer model where consumer should process the
recent produced data as soon as possible and it's not required to process
every peace of produced data. Here single producer thread makes posts and
single consumer thread makes waits on binary semaphore. It also seems to be
valid to have multiple consumer threads that otherwise do the same job. This
could be useful on multiprocessor systems to increase performance.

>
> The current binary semaphore implementation does not have the
> assertion, so it is not the best solution for mutual exclusion. That
> argues for a new class, e.g. Cyg_UnownedMutex, to serve that purpose.
> The Cyg_Binary_Semaphore class could then be left as is, i.e. behaving
> as per Sergei's event signalling usage. That could still confuse
> people who are used to thinking about binary semaphores as a legal
> mutual exclusion primitive, as per old reference titles. To avoid that
> we could also rename Cyg_Binary_Semaphore to something else, breaking
> the historical association.
>
> I am not sure anybody would be happy with this solution.

Now about names. For me Cyg_UnownedMutex sounds strange. Maybe I don't
understand something very basic, but for me "Unowned" and "Mutex" are
contradicting terms. Mutex should have owning semantics, I believe. Either it
is only single thread that can own mutex or "group of threads", but concept of
owning is what differs mutex from semaphore, as you correctly said at the
beginning of the message.

To add even more to the discussion, binary semaphore could be considered to be
just a counting semaphore with upper bound of count equal to 1. Current
counting semaphore is then counting semaphore with upper bound set to
arbitrary rather large number, e.g., INT_MAX. Then back to initial
question. What is semantics when counting semaphore is at upper bound and
'post' is invoked?  The discussion indicates that both semantics could be
useful. Unfortunately strict semantics that disallows such operation makes it
impossible to use the primitive for the purpose above. Less  restrictive
semantics does allow both uses. It just doesn't help to catch some programming
mistakes. Having that, I think it's OK to have only a no-op semantics.

I have nothing against having both semantics, I just doesn't think it is worth 
efforts.

Sergei.

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

[Grant Edwards]

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

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

[Sergei Organov]

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.

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

[Rosimildo daSilva]

>From: Sergei Organov <osv@javad.ru>
>To: bartv@redhat.com
>CC: ecos-discuss@sourceware.cygnus.com
>Subject: Re: [ECOS] No binary semaphore in C API?
>Date: 30 Mar 2001 14:22:43 +0400
>

>I think that original post has a scenario for which there is no primitive 
>in
>eCos that exactly matches requirements and there will never be 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 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. 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, 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 believe that the primitive(s) that Sergei was talking about
is more in line with the semantic of the WIN32/OS/2 "Event"
primitives. Something that has a semantic of a switch ( on/off ).

This semaphore, called from now "EventX", has two states,

  + Reseted, Posted.

Once reseted, any thread "waiting" on that semaphore will block. Once,
the semaphore is "posted", all threads are unblocked, and it remains on that 
state until it is explicited put back on the "Reseted" state.

Interface:

  class EventX
  {
    public:

    void post();
    bool wait( some timeout here );
    void reset();
  };

As he mentioned on the first message, this type of primitive
is very handy, because you do not need a "thread id" of the
receiving thread to be used. I have used the "Binary"
semaphores to archieve this semantic in some cases,
but they never matches 100%.

Rosimildo.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com