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:psp...@progeeks.com] > 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 <richard.schm...@eads.com > >> <mailto:richard.schm...@eads.com>> > >> > >> 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 > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > > org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
