I've been reading this thread with increasing alarm. I agree with Martin Ecker and Vladimir Prus that the synchronization in question belongs inside the serialization library. The system we are building will have several inter-process communication mechanisms, which I'm hoping to be able to build on top of Boost.Serialization. (As noted in another thread, I've run across some performance issues, which might be addressed by resetting and reusing archives, rather than constructing new archives all the time.) It is expected in our system design that it will be possible to dynamically load DLLs containing new types which support serialization, and then create new IPC connections (with associated archives) to/from which instances of those newly loaded types can be serialized. It is not a requirement that previously existing IPC connections (and their associated archives, either presently in use, or available for reuse if archive resetting is used) support these new types, since the type information for the connection is specified at connection creation time. We expect a substantial number of such connections to exist at any one time, with many threads involved, and they have some latency requirements. We presently plan to punt support for unloading DLLs, on the basis that the benefit (in our system) would be small compared to the design / implementation / documentation cost for supporting unloading safely and correctly. (We might revisit the decision about unloading, but for now supporting it is not a requirement for us.) I'm pretty sure that intertwining runtime DLL loading with all of our clients of the serialization library is just not going to fly. I think that making it a configuration option whether the library protects its internal data structures is a reasonable approach, since some applications won't need it (either because they are single-threaded or are willing to deal with the issues at the application level) and might not want to pay the cost. But for some applications, having the library be responsible for the consistency of its internal data structures is really the only realistic option. I think the only way I will be able to sell the use of the serialization library for our project is to either convince you to change on this issue, or to obtain or develop a patch and carry it forward. The latter might be less work in the long term than developing the subset of serialization features that we actually need, but the long-term maintenance headache for a patch is worrisome.