Re: [boost] [Serliazation] Thread-safety again

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-12-13 14:19:35

Roland Schwarz wrote:
> Sean Huang wrote:
>> I posted this about a year ago but got no definite answer from
>> Robert.
>> http://thread.gmane.org/gmane.comp.lib.boost.devel/132838/focus=132838
>> I vaguely remember that there were similar discussions about this
>> issue a few month back but do not know if it had reached any
>> conclusion. Now my programs started crashing because of this problem
>> and I am wondering if there is a good solution. Is making the
>> function scope static objects static member with its caveats the
>> best we could do?
>
> The short answer:
> There is no nice solution to this problem.
>
> The longer:
> Basically you would need to protect the static by a mutex, i.e.:

I'm not convinced its that bad.  We don't need a general solution - all we 
need is a specific one for this particular problem.  The alterations I 
checked into the HEAD rely on known special behavior of the serialization 
library.

The original method was for all globals to use a access functions containing 
a local static.  This was a general solution be fix the order of 
initialization and addressed problems associated with dynamic 
loading/unloading of DLLS containing serializable data types.  These 
functions are called things like "get_instance()"

But it trips up when mult-tasking.

So, an attempt has been make sure that these functions get called at 
pre-execution time or when a DLL containing serialization code is loaded. 
The idea is that these will be invoked before multi-tasking is initiated 
thereby avoiding the race condition.  I don't know if this has been achieved 
as it hard to figure out how to test it.

So, though I'm not sure its really fixed, I do believe that this can be 
fixed by considering the sequence of code execution paths which can really 
occur with these functions.  That is, a general solution is not required and 
a specific solution is (I believe) possible - if its not done already.

As an aside - I'm intrigued about the possibilities of Dave's 
boost/archive/detail/dynamically_initliazed.hpp as a more general approach 
to the problem.

Robert Ramey