Re: [boost] Re: Threads docs updated in CVS

From: Scott McCaskill (scott_at_[hidden])
Date: 2001-08-14 08:15:57

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, August 14, 2001 5:36 AM
Subject: Re: [boost] Re: Threads docs updated in CVS

> 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.
>

In what way would the CV solution block the producer?  AFAIK,
condition::notify_one/all do not block the caller.