Re: [osg-users] Multithreading crash 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_).
GuardMutex 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-openscenegraph.org
Re: [osg-users] Multithreading crash due toosgDb::Registry::instance()
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf Greetings, Richard Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Dienstag, 17. März 2009 10:07 An: OpenSceneGraph Users Betreff: Re: [osg-users] Multithreading crash due toosgDb::Registry::instance() Hi Anthony, I have avoided adding a mutex into the Registry::instance() method as it would incur a cost for every call to it, and it's only the very first call that it's an issue for so it's the only time you need to be careful about access to it. Given I don't want to introduce a mutex one then has to make sure the instance() method is called up front in your app, and most OSG applications will call it during the single thread init of the app, and in your case you'll just need to call it explictly. An alternative might be to have a proxy class call the instance() method, or perhaps just have the viewer constructor call instance() just in case. Robert. On Tue, Mar 17, 2009 at 6:25 AM, I-Nixon, Anthony D anthony.d.ni...@boeing.com wrote: I've encountered a crash when using CompositeViewer in Multithreaded mode due to concurrent access to osgDb::Registry::instance(). The usage scenario is having two views (that have an empty scene graph - since no data has been loaded, osgdb::Registry::instance() hasn't yet been called). On the first frame, each of the render threads calls osgDb::Registry::instance(), and one gets back a null pointer (which is kind of bad for an instance :-) The fix for me is easy - just call osgDb::Registry::instance() sometime before starting rendering, but a more general solution would be better, of course. This is with OSG 2.8.0 - although there don't appear to have been any changes in this area in the trunk, either. I've only confirmed this on Windows XP and Visual C++ 8. Anthony Nixon ___ 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-openscenegraph.org
Re: [osg-users] Multithreading crash due toosgDb::Registry::instance()
2009/3/17 Schmidt, Richard richard.schm...@eads.com http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdfhttp://www.cs.wustl.edu/%7Eschmidt/PDF/DC-Locking.pdf Could you explain what the above document is all about... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multithreading crash due toosgDb::Registry::instance()
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_).
GuardMutex 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
