Boost logo

Boost :

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
>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
>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?


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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at