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
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk