Re: Work in progress list? And how about a singleton?

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 
systems.
> > There was considerable discussion of this in 
comp.lang.c++.moderated
> > a couple of years ago, but eventually everyone saw that it was 
unsafe.
> > 
> > On p. 148 of Alexandrescu's "Modern C++ Design" he nicely 
summarizes
> > 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 
one.
> >      ... Due to this rearranging of writes, the memory as seen by 
one
> >      processor might look as if the operations are not performed
> >      in the correct order by another processor...  the Double-
Checked
> >      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 
symmetric
> multiprocessor systems.  

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

> Second: I don't see how these systems could possibly claim to be 
conforming
> anyway -- I have the usual questions about the guarantee of 
observable
> 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 
problems
> 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