Boost logo

Boost :

From: Andrew J Bromage (ajb_at_[hidden])
Date: 2002-08-08 19:33:16


G'day all.

On Thu, Aug 08, 2002 at 09:35:19AM -0500, William E. Kempf wrote:

> I think I get what you mean, though I think you made some poor choices in
> comparison here. "Lightweight" mutexes are an optimization, as are atomic
> counters. Your "once" object, as pointed out, won't provide any
> optimisations.

Several people have claimed this, and I respectfully disagree in
part. It won't provide any optimisations on many platforms
(especially the ones we wouldn't optimise for), but I believe it
will on others.

> The abstraction might still be appealing, which I think was
> your point here, but it still misses the point that it's dynamically
> initialized, which is not thread safe.

I'm still thinking about this, by the way. I haven't completely
convinced myself that dynamic initialisation is inherently unsafe.
For example, is it sufficient to issue an explicit fence after the
hypothetical once object is initialised?

> Whoa. Careful there. There's a lot more to once routines then "protecting
> a read of a single flag which is only going to be mutated once in its
> lifetime". In fact, the flag is an implementation detail, *NOT* the
> resource that's being synchronized.

True. I was playing fast and loose with terminology here.

> What's being synchronized is the call to the routine,
> and the important thing is that any thread that attempts to
> call this either actually calls the routine if it was the first, or blocks
> until the routine has been called and returns.

You've mentioned two things that may happen. In fact there are three,
and the one you left out is precisely the one that the DCL idiom is
meant to optimise, namely, the case that the single routine call has
already completed and therefore does not need to be called again. In
this case, the caller should not (in theory) need to block.

The problem is the "in theory" part, of course.

Cheers,
Andrew Bromage


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