Re: [boost] Re: Semaphores?

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

----- Original Message -----
From: "Jive Dadson" <jdadson_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 23, 2002 4:49 PM
Subject: [boost] Re: Semaphores?

>
> FYI, one of the inter-thread FIFO objects I implemented is quite like
> the one listed in
>
>
>
http://www.boost.org/libs/thread/doc/condition.html#class-condition-synopsis

Evidence that supports the FAQ, then.  BTW, an event queue is very similar
to this "bounded buffer" example, just a little more tailored for a
particular use (notification of an event).

> with one important difference: There are no while-loops.

Why is this important?  Note that the while loops are *NOT* busy waits.
They exist solely to deal with "spurious wakeups" which may occur on calls
to condition waits.

>  In the version
> I
> am using, the buffer_not_full and buffer_not_empty objects are counting
> semaphores.  I also separated out the concepts of mutex-locking the
> object
> (it_fifo<TYPE>) and semaphore-waiting/signaling (it_buffer<TYPE>).  In
> other
> words, the class that is equivalent to the "bounded_buffer" type in the
> example (except for the polling loops) is called "it_buffer<int>" and is
> implemented in terms of class semaphore and a mutex-locked class called
> "it_fifo<int>".  Class it_fifo<int> is implemented in terms of
> class mutex and std::queue<int>.

This convinces me ("polling loops") that you don't understand what condition
variables are.  I emphasize again: the example does not use a busy wait.

> Having done a lot of realtime programming, I am keenly aware of the
> dangers of race
> conditions. I've put systems into some scary applications, like nuclear
> power plants,
> oil platforms, and gasoline pumps - things that can go BOOM!  You want
> to do those right.
> Nevertheless, I don't go along with the argument that useful features
> should be omitted from
> development systems because a programmer can screw up when using them.
> A friend
> of mine has a saying: "You can't make a system fool-proof, because fools
> are ingenious."

There is no attempt to make the system fool proof.  That's, frankly,
impossible.  However, some concepts are simply very difficult to use safely,
while there are alternatives that can always be used instead that provide a
much safer solution.  This is the case when comparing events to condition
variables.  It may also be the case when comparing semaphores to condition
variables.  In fact, if we solely look at safety, it *IS* true.  However,
there are issues of performance that may be important enough to add the
samaphore back.

Bill Kempf