Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-11-16 15:21:59

--- In boost_at_y..., scleary_at_j... wrote:
> > From: Kevin Cline [mailto:kcline_at_o...]
> >
> > The double-checked locking idiom is not safe on multi-processor
> > There was considerable discussion of this in
> > a couple of years ago, but eventually everyone saw that it was
> >
> > On p. 148 of Alexandrescu's "Modern C++ Design" he nicely
> > the discussion:
> >
> > Very experienced multithreaded programmers know that even the
> > Double-Checked Locking system ... is not always correct
> > in practice.
> > In certain symmetric multiprocessor environments ... the
> > writes are
> > committed to the main memory in bursts, rather than one by
> > ... Due to this rearranging of writes, the memory as seen by
> > processor might look as if the operations are not performed
> > in the correct order by another processor... the Double-
> > Locking pattern is known to be defective for such systems.
> OK -- I had to go look up these discussions (I don't have group
access :( ).
> First, some scope: this applies only to relaxed-memory model
> multiprocessor systems.

Yes, but portable code must assume all systems fall into this

> Second: I don't see how these systems could possibly claim to be
> anyway -- I have the usual questions about the guarantee of
> behaviour, side effects, and sequence points -- which I'm sure
you've heard
> before. My question: why can't these guarantees be used to prevent
> with double-checked locking? I did not find any threads where
these were
> fully addressed.

Conforming to what? The C++ standard? Since threads are not part of
the C++ standard your program is non-conforming the second you start
using them. To POSIX? The pthreads section of the standard very
clearly specifies the gaurantees you can rely on here, and DCL
violates the contract.

For either POSIX or the C++ standard to specify behavior such that
the DCL would work there'd be a tremendous performance hit for all
applications. POSIX took the only viable option in this case.
> BTW, please respond privately; this really isn't a Boost discussion.

Actually, it is a Boost discussion. It's very important for this to
be fully understood by everyone in order for us to proceed with
specifying the behavior of Boost.Threads.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at