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: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
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
