public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grante@visi.com>
To: Sergei Organov <osv@javad.ru>
Cc: bartv@redhat.com, ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] No binary semaphore in C API?
Date: Thu, 29 Mar 2001 11:49:00 -0000	[thread overview]
Message-ID: <20010329102642.A4641@visi.com> (raw)
In-Reply-To: <87puf1gh27.fsf@osv.javad.ru>

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

  reply	other threads:[~2001-03-29 11:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-16 12:01 Grant Edwards
2001-03-19 13:42 ` Jonathan Larmour
2001-03-26  3:53   ` Nick Garnett
2001-03-26  7:12     ` Fabrice Gautier
2001-03-26 11:37     ` Grant Edwards
2001-03-27  2:00       ` Nick Garnett
2001-03-27  5:32         ` Grant Edwards
2001-03-28  5:29         ` Bart Veer
2001-03-28  6:45           ` Sergei Organov
2001-03-28  7:38             ` Grant Edwards
2001-03-28  7:39             ` Bart Veer
2001-03-28 10:01               ` Jonathan Larmour
2001-03-28 10:01               ` Sergei Organov
2001-03-28 11:05                 ` Grant Edwards
2001-03-29 11:51                   ` Sergei Organov
2001-03-29 11:49                     ` Grant Edwards [this message]
2001-03-29 11:55           ` Chris Gray
2001-03-29 19:33             ` Bart Veer
2001-03-29 20:50               ` Grant Edwards
2001-03-30  2:22               ` Sergei Organov
2001-03-30  6:54                 ` Grant Edwards
2001-03-30  7:42                   ` Sergei Organov
2001-03-30  5:39 Rosimildo daSilva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010329102642.A4641@visi.com \
    --to=grante@visi.com \
    --cc=bartv@redhat.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=osv@javad.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).