Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-08-14 07:34:40


--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> > > I'm giving up on this whole thing as of now. You've made it
totally
> > > clear that your mind is made up and you aren't prepared to
engage
> > in any
> > > sort of discussion. I'm going to stop beating my head against a
> > stone
> > > wall and go do something more productive.
> >
> > I'm sorry you feel that way. I feel that it's you who's not open
to
> > discussion on this topic, so it's probably just a communication
> > disconnect, but I don't know how to get past it.
> >
> > As for having made my mind up on CVs, that's true. I'm more than
> > willing to include events at a later date, but I'm not going to
budge
> > from the inclusion of CVs from the very beginning. I think you're
> > the only one that's got a problem with that, and most people
> > understand the reasoning behind this, and agree with it.
>
> This assumption is dangerous. I would say that "most people" simply
either
> don't understand the issues involved, or don't care.
>
> I'm not afraid to admit that I fall in the first category.
>
> For instance, what is the boost.threads way to do the following:
>
> void thread_function()
> {
> init();
>
> for(;;)
> {
> waitForMultipleEvents(wakeup_event, terminate_event);
> if(terminate_event signalled) break;
> do_work();
> }
>
> cleanup();
> }

This is one of the corner examples where no mutex is required and the
event solution is (at least conceptually) better. I've already
admitted to this and said I was willing to consider the addition of
events in the future.

That said, I have a few important comments about this particular
example. It relies on WaitForMultipleObjects(), something that will
be difficult to do in a portable library, and will likely result in
implementations that have very poor performance. To code such
functionality efficiently requires low level control of thread
scheduling. Also, because of the multi-event design it's actually a
wash as to which design is easier to understand and code. To
illustrate, the design with CVs is simply as follows:

void thread_function()
{
  init();

  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();
  }

  cleanup();
}

The length of the code increased some, but the design is just as easy
to follow.

> I don't think that in general such debates can be resolved by e-
mail without
> the opponents preparing a paper with their view.

I've pointed people to well known papers that already show how events
lead to race conditions.

Bill Kempf


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