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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-01-25 20:32:10

At 04:05 PM 1/24/2004, Sean Kelly wrote:
 >The condition object is needlessly complex for instances where a thread
 >must wait on a signal but isn't immediately concerned with shared data.
 >Basically, I'd like a simplified version of condition that supports wait
 >and timed_wait without the predicate and without the need to pass a 
mutex.
 >It might be used like this:
 >
 >mutex sync;
 >queue<T> mq;
 >event ev;
 >
 >void add_message( T const& msg ) {
 >   lock l( sync );
 >    mq.add( msg );
 >    ev.set();
 >}
 >
 >void process_msgs() {
 >    // synchronized access to mq
 >    // acts on messages
 >}
 >
 >
 >void loop() {
 >    for(;;) {
 >        ev.wait();
 >        ev.reset();
 >        process_msgs();
 >    }
 >}
 >
 >
 >On the Windows side the event object could purely use the CreateEvent and
 >WaitForSingleObject calls.  On the pthread side it could use a
 >internal mutex, boolean to indicate whether the event has been signalled,
 >and the cond_wait process from the condition object.  Ideally, there
 >should be a way to specify on construction whether the event will
 >auto-reset or if it needs to be reset manually (as in the above example).
 >
 >I've personally found that I use the above processing method far more 
than
 >what the condition object requires, and it would be nice to be able to
 >avoid any more synchronization code than necessary.  Comments?

How is this different, and safer, than the traditional event variable?

(See www.boost.org/libs/thread/doc/rationale.html#Events)

In your code above, if queue<> doesn't itself protect against races, what 
happens if process_msgs() and add_message() modify mq at the same time. 
OTOH, if queue<> is multithread safe, why do you need ev at all?

What am I missing?

--Beman