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