Boost logo

Boost :

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?


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