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

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-12-13 14:35:49

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_at_[hidden]>
To: <boost_at_[hidden]>
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
>