Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-14 05:36:07


From: "Alexander Terekhov" <terekhov_at_[hidden]>
> another problem you have with the code above
> is the following.. suppose you have N worker
> threads active in q.pop loop crunching fairly
> big queue.. at some point in time they will
> run out of work and will try to wait for more
> work via waiting on wakeup event. but they
> could become preempted on their way to
> waitFor(wakeup) in favor of one or more producer
> threads which could fill the queue again. now..
> when the first/fastest worker thread would call
> waitFor(wakeup).. it will consume the auto-reset
> event (signaled multiple times) which could result
> in all other worker threads remained blocked on
> wakeup event even with queue full of work which
> is supposed to keep multiple worker threads busy;
> not blocked!

True. This, and the other problem Beman mentioned, are inherent properties
of the event solution; as far as I understand, CVs avoid the problem by
blocking the producer until a consumer is free to process the request.

But sometimes, as I already said, "lost wakeups" (they aren't really "lost")
are exactly the behavior I want (especially in "single consumer" mode); I
don't want to block the producer.

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk