I apologize if this has been discussed before, but this message caught my attention and I decided to ask: why do you need any statics/globals for the serialization? I understand that you need global class registration to handle the case of reading a base pointer when the stream contains derived object, but when you serialize data you just assume that all classes have been registered ahead of time. Because you don't need mutable access to the class registration table, you don't have thread safety problems. The other piece of data that I can think of is the table that tracks which objects have already been serialized so that when you serialize a second pointer that points to the same object you don't serialize the object again, however this table has to be per-stream because I may have multiple opened streams that I'm reading from. Assuming you don't access the same stream from multiple threads, I see no thread safety problems here either. Am I missing something? ----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> Sent: Wednesday, December 13, 2006 11:19 AM Subject: Re: [boost] [Serliazation] Thread-safety again
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost