Boost logo

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