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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-12-13 16:30:20

Emil Dotchevski wrote:
> 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?

The static instantiations are used for a couple of things:

a) maintaining  table which is used to convert between different pointers to 
different types of objects at runtime  - with or without RTTI existing.  See 
void_cast ...

b) To hold a constant string type "export" key as RTTI systems don't provide 
a portable one.

c) To hold pointers to serialization functions for derived pointers.

d) To guarentee instantiation of serialization functions not otherwise 
explicitly referred to.

For more information - feel free to preuse the code.

>
> 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.

Not necessarily.  The export functionality eliminates the requirement to 
explicitly register all derived types.  Its original implementation 
initialized the type table upon first usage - the current one intializes the 
type table on start-up.  This one of the changes I've been referring to in 
my belief that the situation may no longer exist.

>Because you don't need mutable access to the class
> registration table, you don't have thread safety problems.

Iff and only iff you can get everthing initialize at pre-main time or upon 
DLL loading.  Which has been exactly the problem up until now.

> 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.

This is correct - there are no theading problems associated with
tracking.

Robert Ramey