Re: [boost] Re: Semaphores?

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-24 09:24:12

----- Original Message -----
From: "Jive Dadson" <jdadson_at_[hidden]>
> Bill Kempf wrote:
> >From: "Jive Dadson" <jdadson_at_[hidden]>
> >> Are there any plans to add semaphores to the boost threads library?  Or
> >> are they already there and I missed them?  How about timer events and
> >> such?  Waiting on any of a list of events?
> >
> >Semaphores were in the submission library, but were removed as "too
> >dangerous".  See the rationale page.
>
> I looked at the rationale page.  The word "semaphore" does not occur.
> Are you refering to the section on "event queues" and whatnot?  I will
> read up, and attempt to find out what all the brouhaha is about.

Sorry, I should have looked it up first.  The rationale isn't on the
rationale page, but in the FAQ.  It's also very short on technical
explanations... but that's mostly because the issue isn't settled yet.

> >> Applications I write and maintain use semaphores to moderate
> >> inter-thread communication via shared FIFO's.  Perhaps Boost has plans
> >> for implementing that higher level concept.
> >
> >No plans for this today.  I currently believe that such event queues are
too
> >high level and beyond the scope of Boost.Threads (for one thing, they are
> >useful even with ST applications).
>
> Did not grok.  The sort of thing I am talking about is a general purpose
> interthread message FIFO.  Containers of that type are as natural in
> realtime systems as linked lists and dictionaries are in batch
> programming.

Maybe we're talking about very different concepts... maybe not.  I thought
you were talking about event queues.  FIFO structures used to communicate
the occurence of events.  Such event queues aren't restricted to the realm
of realtime systems or MT (multi-threaded) applications.  For instance, the
Windows operating system is almost entirely based on the concept of an event
queue, and said event queue is used just as often (actually more) in ST
(single-threaded) applications.  MT causes the implementation and design to
be more complicated, but the concept isn't a MT concept.

> What are ST applications?  Single thread applications?  The type of
> semaphore controlled FIFO I am thinking of cannot be used in a single
> thread application.  It makes no sense for a thread to suspend until a
> dropbox has something in it, if there is no other thread to put
> something in the dropbox.

Again, the Windows OS (and most other GUI systems) use event queues
extensively, and often operate in ST applications.

> >I've tried to encourage a few others to
> >provide such a queue as a separate Boost library submission ...
>
> Ah. You suggest putting it in Boost, but not in Boost.Threads.
> Bookkeeping aside, you still need semaphores, or monitors, or something
> equivalent.  I implemented the interthread queues using a mutex and one
> or two semaphores.  Without semaphores or something like them, you wind
> up spinning, which for me is right out.

Boost.Threads has the concept of a condition variable (boost::condition)
which can be used to implement the "monitor pattern" which behaves the same
as a language realized monitor.  To quote the FAQ: "The same effect can be
achieved with greater safety by the combination of a mutex and a condition
variable."  For an event queue there's no need for semaphores because we
have mutexes and condition variables.

> > ... however, and
> >still think that's a very good idea for someone to take on.
>
> And be called a racist??? :-)

Huh?

Bill Kempf