From: Kevin Cline (kcline_at_[hidden])
Date: 2001-11-15 14:48:59
> Providing locking for "every access" wouldn't actually gain anything -- the
> lock would be released when the pointer is returned. Therefore, one
> solution (only lock on the *first* access, using the double-checked locking
> idiom) fits every 'real' problem -- you only have the overhead of one lock
> per singleton in your program.
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
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.
> Look at the smart pointer classes -- in my code, I have a header that simply
> imports the boost smart pointers and STL smart pointer, and adds two of my
> auto_array 
> mt_shared_ptr 
> There has been some talk on this list about using policy classes, and having
> a single smart pointer generator. We could allow different deallocation
> mechanisms, different sharing capabilities, hooks for user callbacks... But
> how many users would ever use them? We'd be adding a lot of complexity with
> a small payback.
I would support that. Loki::SmartPtr has more functionality than those
seven put together, and I found it easier to understand.
-- Kevin Cline
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk