I remember the first time I heard about the double-checked locking
problem five years ago or more and then wasting an afternoon trying to
understand what the heck was going on. I was never the same again.
I sometimes long for those halcyon days when the universe was a simpler
place. :)
-Paul
J.P. Delport wrote:
Hi all,
for those interested in instruction order issues, these videos might be
interesting (search google video):
* Herb Sutter - Machine Architecture: Things Your Programming Language
Never Told You
* IA Memory Ordering
There is quite a bit of work going into the next C++ standard to address
some of these issues. Sutter & others have written a lot about it in the
last few months, a search should send you down the rabbit hole.
cheers
jp
I-Nixon, Anthony D wrote:
Thanks for the pointer Paul. The points you raise do apply to C++ as
well, and it seems the consensus is that it is not possible to implement
the double-checked locking pattern in portable C++ safely.
See Scott Meyer's and Andrei Alexandrescu's paper here
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
If Scott Meyer's says it can't be done, I tend to believe him :-)
From Scott's paper:
"In many cases, initializing a singleton resource during single-threaded
program startup
(e.g., prior to executing main) is the simplest way to offer fast,
thread-safe
singleton access."
So the best thing to do is to advertise in large bold letters somewhere
in the doco (and FAQ) that if you are going to use multithreading, all
instances need to be accessed before threading starts.
Anthony
-----Original Message-----
From: Paul Speed [mailto:[email protected]] Sent: Friday, 20 March
2009 2:21 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Multithreadingcrash due
toosgDb::Registry::instance()
Just a note for those of us who have been bitten by double check
locking issues in Java, this technique is highly dependent on the
threading and data architecture in use. There are subtle issues
between when a thread commits its local state and the possibility for
the compiler to reorder statements. This was less of an issue on
single-core boxes but comes up in multi-core where the local thread
state may not be committed. I can't be sure but there may have also
been some subtle statement reordering issues with respect to the
compiler not knowing that your guard release _must_ be run after the
instance_ = new Singleton has _fully_ executed.
I don't know if these problems crop up in C++ but it certainly seems
like they could depending on the threading implementation and
compiler optimization strategy.
Worst case for a singleton pattern is that you might get a race
condition where two instances are created. There are other
double-checked locking situations that are much more insidious.
-Paul
Paul Melis wrote:
Robert Osfield wrote:
2009/3/17 Schmidt, Richard <[email protected]
<mailto:[email protected]>>
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
<http://www.cs.wustl.edu/%7Eschmidt/PDF/DC-Locking.pdf>
Could you explain what the above document is all about...
I just read it an it describes a pattern where you use a mutex to
guard access to the singleton's _instance value, but in such a way
that the mutex is only needed when _instance == NULL, i.e.
class Singleton
{
public:
static Singleton *instance (void)
{
// First check
if (instance_ == 0)
{
// Ensure serialization (guard constructor
acquires lock_).
Guard<Mutex> guard (lock_);
// Double check.
if (instance_ == 0)
instance_ = new Singleton;
}
return instance_;
// guard destructor releases lock_.
}
private:
static Mutex lock_;
static Singleton *instance_;
};
This should give you thread-safe access to Singleton->instance() at
all times combined with correct initialization.
Quite neat actually,
Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
