[Boost-users] Re: Re: Re: Re: Semaphore and barriers forboost-threads?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-02-19 17:02:57

"Victor A. Wagner, Jr." <vawjr_at_[hidden]> wrote in message
news:6.0.3.0.2.20040219140935.0448ef10_at_mail.rudbek.com...
> At Thursday 2004-02-19 00:08, you wrote:
> >Craig Rodrigues wrote:
> >
> > >> Look the the phrase "Much experience with semaphores shows" and
futher
> > >> paragraphs. In essense, it's says that semaphores are for
signal handlers
> > >> and for inter-process synchronization and discourages their use
anywhere
> > >> else.
> > >
> > > That's an interesting link, thanks!
> > > I don't interpret the text in the same way that you do, but
> > > maybe I am not understanding something properly.
> >
> >Maybe I don't, either. The standard cannot make definitive
statements that
> >"semaphore is bad". Folks on comp.programming.threads newsgroup
seem to
> >make such statements in more clear language ;-)
> >
> > > Further down from "Much experience with semaphores shows",
> > > there is this text:
> > >
> > > "Counting semaphores are well matched to dealing with
producer/consumer
> > > problems, including those that might exist between threads of
> > > different processes, or between a signal handler and a thread.
In
> > > the former case, there may be little or no memory shared by the
> > > processes; in the latter case, one is not communicating between
> > > co-equal threads, but between a thread and an interrupt-like
entity.
> > > It is for these reasons that IEEE Std 1003.1-2001 allows
semaphores
> > > to be used by threads."
> >
> >Doesn't it say that semaphores are retained for inter-process
communication
> >and for signal handlers?
> >
> > > This is the use-case that I am interested in.
> >
> >Which one? Signal handler or inter-process communication?
>
> does it really matter? semaphores are useful (and can be misused,
like a
> lot of other things in life).  Why the resistance to putting them
in?

For my part, I don't really have a strong opinion one way or the other
yet, but even if I decided I strongly supported adding semaphores to
Boost.Thread, I wouldn't have time to do anything about it for quite a
while. Are you (or is anyone else) willing to submit a design that
minimizes the possibilities of misuse, since that appears to be the
main concern? And, if Boosters like the design, are you (or is anyone
else) willing to implement it on the same platforms supported by the
current Boost.Thread? And write documentation that clearly states the
intended use cases and drawbacks of semaphores? And write unit tests,
examples, etc.?

Perhaps one way to limit the possibilities for misuse would be to
create a class or classes that, instead of directly exposing semaphore
functionality, somehow supports the main use cases for semaphores? I
don't really have a clear idea what this would mean--I'm just thinking
out loud.

Any ideas?

Mike

> >- Volodya
> >
> >
> >_______________________________________________
> >Boost-users mailing list
> >Boost-users_at_[hidden]
> >http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
> Victor A. Wagner Jr.      http://rudbek.com
> The five most dangerous words in the English language:
>                "There oughta be a law"