Re: [boost] Re: Boost.Thread: Wrapping Native Windows Event Variables possible?

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-01-05 11:57:11

(Michael Glassford <glassfordm_at_[hidden]>) wrote:

> The simplest way of avoiding that is simply not to unlock the monitor 
> mutex. The reason the wait function of a condition variable unlocks the 
> mutex is so that another thread can obtain the mutex, perform some 
> operation, then signal that the condition has become true. Since in this 
> case the write operation doesn't need to obtain the mutex in order to 
> complete, there's no need to unlock it. Unless there are other reasons I 
> don't know about?
> 
>  > As far as I can understand, this normally is
> > avoided through the while loop that belongs to the "condition variable pattern".
> 
> Not really. The while loop handles the case where a thread "wakes up" 
> but the condition isn't really true yet; it "puts it back to sleep" by 
> making it wait some more.
> 

I think I can understand your explanation, and I have tried to rephrase my
question, but then decided not to post it, because I think it  was not
clearer than my first post.

In principle everything boils down to the following question:

How do I simultaneously wait for a condition _or_ a pending IO operation
becoming notified/signalled.

Isn't this type of operation a very common one in multithreaded programs?
(Especially on uniprocessors?) I cannot imagine that this is not possible
using boost.threads.

Perhaps there is a (portable) solution available using boost.threads which
I am not aware of?

If this really is not possible, isn't there a need to provide such a feature?
If not, please could you tell me why?

regards,
Roland