Hmmm - well that is interesting. I believe I used this idiom in order to address a problem where global static variables couldn't be guarenteed to be instantiated in a particular order and this was the fix recommended. So now what do we do? Robert Ramey Daniel F. Savarese wrote:

In message , "Robert Ramey" writes:

...

So now you know my intention - and I believe that the code reflects that.

Here's what's happening with static oserializer & instantiate(){ static oserializer instance; return instance; } Thread 1 calls instantiate and is pre-empted in the middle of constructing instance the first time control passes through its declaration. Thread 2 then calls instantiate and returns a reference to an incompletely constructed instance. Then thread 2 bombs in basic_oarchive_impl::save_object the first time it tries to dereference the object to invoke a virtual function (in this case class_info()) of an incompletely constructed object (i.e., no virtual function table). And now I'm reminded why whenever I see a static local variable I have the knee-jerk reaction: "not thread-safe." I had to reeducate myself by exercising the debugger and revisiting what the C++ standard has to say about the initialization of static storage.

daniel

-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.- software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/