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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk