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

Paul Speed pspeed at progeeks.com
Fri Mar 20 08:02:16 PDT 2009


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: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
>>
> 




More information about the osg-users mailing list