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
Isn't this type of operation a very common one in multithreaded programs?
(Especially on uniprocessors?) I cannot imagine that this is not possible
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk