Johan Torp:
I'm doing a thesis related to C++0x and threading. Peter Dimov suggested I could try and implement an event-like waiting primitive, similar to Windows' WaitForMultipleObjects. If we had such a primitive, we might get better ways to solve this problem. I think part of the reason this is so tricky is because condition_variable's aren't meant to be used for multiple waiting. Maybe Dimov or somebody else has sketches of such an interface.
I believe that futures only need the basic "manual reset event" in Windows terms: class event { private: bool is_set_; public: event(); // post: !is_set_ void set(); // post: is_set_ void reset(); // post: !is_set_ void wait(); // block until is_set_ bool try_wait(); bool try_wait_for(...); bool try_wait_until(...); }; The advantage of this primitive is that it maps to Windows directly. The disadvantage is that it's not robust when reset() is used because this introduces a race. This is not a problem for futures since they are one-shot and their underlying ready_ event is never reset. A more robust primitive is the so-called "eventcount" which doesn't need to be reset and avoids the race: class event { private: unsigned k_; public: event(); // post: k_ == 0 void signal(); // effects: ++k_ unsigned get(); // returns: k_ void wait( unsigned k ); // block until k_ != k // ... try_wait ... }; Typical use is // waiter for( ;; ) { unsigned k = event_.get(); if( predicate ) return; event_.wait( k ); } // setter predicate = true; event_.signal();