|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-14 08:51:03
From: "Scott McCaskill" <scott_at_[hidden]>
> ----- Original Message -----
> From: "Peter Dimov" <pdimov_at_[hidden]>
> > 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.
OK, I'm convinced. CVs can block the producer, as in Bill's code:
for(;;)
{
boost::mutex::scoped_lock lock(&mutex);
while (event == 0)
cond.wait(lock);
if (event == terminate_event) break;
assert(event == wakeup_event);
event = 0;
do_work();
}
or they can be used to achieve the non-blocking event equivalent, as in
Alexander's code:
for(;;)
{
int m;
{
mutex::scoped_lock lock( m );
while(q.empty())
cv.wait( lock );
m = q.pop();
}
if(m & 1) do_something_a();
if(m & 2) do_something_b();
if(m & 4) do_something_c();
}
}
The repeating pattern
{
mutex::scoped_lock lock( m );
while(condition)
cv.wait( lock );
action();
}
still bothers me a bit (it'd be nice to have it encapsulated somehow) but we
could live with it.
-- 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