Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-24 09:08:43


--- In boost_at_[hidden], "Thomas Holenstein" <tholenst_at_i...> wrote:
> Hy,
>
> > Another key point in this example: the classic paper only
defines a
> > signal() which is analogous to notify_one(). There is nothing
> > analogous to notify_all().
>
> This has, in fact a very good reason. As far as I remember, only
> leaving threads are allowed to signal().

I don't think so. He does discuss optimizations that can be done for
that case, and suggests that because of the optimizations a signal
should always be the last operation, but he doesn't make it a
requirement of the pattern. Since our monitor is purely a pattern,
and not a language construct, I don't think we can achieve the same
optimizations any way.

> Thus, if you call signal()
> your next statement MUST be return. That way, you don't have to
> specify what happens if you call signal() and then change internal
> state vars. Thus you surely can't have notify_all, every exiting
> thread must notify itself, if necessary.

I don't follow. Why is notify_all() not possible just because signal
() should be the last statement?
 
> I would, in fact, provide Monitors as suggested by Hoare as good as
> possible. Don't forget that other people probably now a monitor,
thus
> it would be easiest to use, if it is exactly like Hoare's Monitor.

Hoare's model of the Monitor isn't the only model used in the history
of concurrent programming. You could argue that it's the simplest
model, and it's definately the first. However, I'd contend that it's
not the most well known. Pthreads are probably much more well known
than the classic paper, and pthread conditions allow for a notify_all
(). I'm not purporting this as evidence that we should include
notify_all() in our model, I'm just saying that the argument about
familiarity actually works against the classic Monitor, not in favor
of it. The real criteria should come down to safety and
expressiveness.

Bill Kempf


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