Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-18 12:00:24

Vladimir Prus wrote:
> I think you're going contrary to the basic threading assumption in
> the C++. If I explicitly use the same object from two different
> threads, I must use locking myself.

This is what I disagree with.  I don't any problem with multiple threads 
accessing the same data structures as long as the accesses are read-only and 
the structures are not being modified.

>If, for all appearence, I don't
> use the same object in two threads, but there's some *internal*
> shared data structure, it should be protected *internally*. In this
> case, there's some internal serialization table that I know nothing
> about, so it should be protected by serialization library.

Repeat, I don't think this is necessary.

>> So I believe your concern could be addressed by a
>> code
>> which inhibited loading/unloading of DLLS while any archives are
>> open.  I don't think this has to be part of the serialization
>> library.

> To begin with, those internal structures are present even when no
> archives are open, arent't they?

True

>Besides, I don't understand how you
> can "inhibit loading of DLLS". Say, one thread has created an archive
> and does something with it. Some other thread tries to open DLL. What
> should happen? Should  that other thread get "sorry, some archives are 
> open" error? And what
> will  it do?

A couple of possibilities.  It could somehow check to see that no archives 
are open. (The serialization library might have to add support for this). 
It could throw an exception if an attempt is made to change a global 
structure when when an archive is open.

>Wait until the other thread is done with archive? And what if
> the other thread uses archive to talk over network and will never
> close the achrive? And even if it will close archive, how will the
> other thread wait for that? There's no public method that tells that
> any archive is open.

Correct, but this could be remedied without dragging threads in to it.

There's another aspect here.  The code for serialization presumes that the 
global tables are static during the lifetime of the archive.  For example, 
as a particular item is serialized, its class identifier is saved in an 
archive specific table.  Thus the save code used the object identifier to 
invoke the save method for the specific class.  Same goes for the load side. 
Now, if the global table changes while an archive is open, all bets are off 
because the save/load code may not be around anymore.  So.

a) global tables can't be changed while an archive is open an still expect 
the system to function.
b) thus DLLS should be loaded/unloaded only when there are no archives open.
c) respecting this rule is the responsability of the calling program.
d) The library (with some reaonsable addition) can detect violations of the 
above rules.

While we're at it, I would also like to consider enforcing a rule that there 
can be at most one instance of serialization code for a specific type 
existing at one time.

a) it can make the system slightly (but measurably?)  more efficiant.
b) I'm very uncomfortable with the idea that there might (accidently) two 
different versions of serialization for a particular type floating around. 
This could happen if multiple DLLS implement serialization for a specific 
type.  I expect this would be an accident. But even if intentional it would 
create a situation which would he hellish to debug.

This rule could be enforced by the serialization library by throwing an 
exception.  It could also be implemented by using only the first loaded DLL 
and keeping a counter. (or maybe shared pointer).  But that would then 
require a new rule - that DLLS containing serialization code be unloaded in 
the reverse order of their loading.

OK - lets hear it from someone who is going to say the really need to be 
able to create multiple different simultaneaous serializations.

To summarize, I believe this situation should be handled by adding code to 
the serialization library which will permit one to query whether any archive 
is open, and throwing an acceptiion if a global table is modified when any 
archives are open.  Fairly simple, 100% effective, and doesn't require 
dependency on any other library.

Robert Ramey