Sorry I'm late to this - been very slowly trying to catch up on my reading. Robert Ramey wrote:
David Abrahams wrote:
Suggestion: handle that by deferring the availability of the registrations associated with that DLL until the user explicitly says it's safe to add them. The idea is that every DLL adds things to its local registry and in a MT application, that is only combined with the global registry via an explicit call, when presumably the user knows no threads are doing serialization.
I have always presumed that loading of DLLS would be under the control of the user program so that he could take appropriate steps to
There are places where this sort of thing is not under the control of the application, or the person writing the code using serialisation has no control of. In our code we expose functionality through COM in a number of DLLs so the load order and timing of the DLLs is under control of the programs that use our objects. They can end up loading a DLL at any time and as our COM instances are used to implement web site functionality the timing of when COM objects are required is under control of the users visiting the sites. We have a similar requirement for a static library of factories for serialisation (in our case for O/RM, but the principle is the same) and when I put all of this together it seemed that the only way to do it reliably was to use a read/write mutex around accesses to the static data. This way most of the reads can still happen in parallel with the very occasional writes taking exclusive control of the structure.
a) be sure that loading/unloading of DLLS wasn't occurring while in the midst of serialization stomething.
b) loading/unloading DLLS occurred one at at time.
It seems to me that this is enough to avoid problems. Am I missing something?
I think that the lower level libraries don't have the information to tell this for sure -- your library users who are writing application level code can make a decision based on this, but anybody writing a library on top of yours still may not know enough to be able to control this either. Kirit