[osg-users] Multithreadingcrash due toosgDb::Registry::instance()

J.P. Delport jpdelport at csir.co.za
Thu Mar 19 23:39:17 PDT 2009


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:pspeed at 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.Schmidt at eads.com 
>>>> <mailto:Richard.Schmidt at 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 at lists.openscenegraph.org
>>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
>>> org
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
> negraph.org
> _______________________________________________
> osg-users mailing list
> osg-users at 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.




More information about the osg-users mailing list