Re: [boost] Boost.Thread request: event object

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-01-26 09:30:57

At 12:38 AM 1/26/2004, Sean Kelly wrote:

 >> How is this different, and safer, than the traditional event variable?
 >>
 >> (See www.boost.org/libs/thread/doc/rationale.html#Events)
 >
 >I hadn't read that bit before, and I think it's kind of vague...

What is vague about  "event operations force the programmer to be aware of 
the relative speeds of the sending and receiving processes"?

In your sample program, you have made assumptions about the relative speeds 
that add_message() and process_msgs() work. (It is a little hard to know 
exactly what assumptions you have made without knowing the details of how 
process_msgs() uses sync.) If those assumptions are ever violated, 
add_message() will become unresponsive or events will get dropped.

Now it might be possible for the event object to detect a call to 
event::add() while there is still an event pending, and throw an exception. 
That would at least change a dropped event from a silent error into a noisy 
error. But that still doesn't solve the underlying design flaw of events 
that they are dependent on relative speeds of producers and consumers.

 >If for some reason I'm mistaken about how events work in Windows, please
 >let me know.  I've been using them in applications this way for years
 >and have never had a single problem.

That's the scary thing about events. A program runs OK for years, and then 
something changes the relative thread timings, like if the program gets 
moved from a single-cpu machine to a multi-cpu machine, and the program 
starts dropping events or otherwise misbehaving.

--Beman