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