To those of us just joining the thread (boost developers list), we are discussing the use of Myers Singleton in the Boost.Serialization code and it's ramifications for thread-safety. You can see the thread here: http://thread.gmane.org/gmane.comp.lib.boost.user/27457 On Wed, 2007-05-23 at 22:38 -0700, Robert Ramey wrote:
Sohail Somani wrote:
I can develop a patch using boost once that I think would work. Locally, I'm going to have to do this anyway. Fortunately, my test has ceased to fail so I can't test it. To make it as "pay for what you use", one can #ifdef it out if they have special knowledge of the platform/compiler.
OK - you've convinced me there could be a problem.
I don't see a magic bullet solution. I think users need a couple of options and a good explanation in the manual.
Options
a) don't use export - use explicit archive level registration instead. b) some sort of explicit type registration. Users could just put at after the main entry point and/or in the DLL loading phase
How is (b) different from (a)? Is this related to your "load/save by name?"
c) an automatic method using thread safety primitives - maybe there are some small ones. Then you have the *#ifdef ...
There is a very small one ;-) The idea is here (copied and tweaked to protect the innocent - may not compile): // thread-safe lazily initialized singleton template<typename T> struct singleton { public: static T & instance() { boost::call_once(call_once,once_); // the magic happens here return get_instance(); } private: <*structors>; // call_once *MUST* be called before calling this function static T & get_instance() { static T object; return object; } static void call_once() { get_instance(); } static boost::once_flag once_; }; // guaranteed to be called before main since it uses initialization // with a constant expression (3.6.2.1) - language lawyers help please. // Also, what happens with dlopen'ish stuff???? This is heavily platform // specific. Someone save us from this mess. template<typename T> boost::once_flag singleton<T>::once_ = BOOST_ONCE_INIT; Then usage would be something like: static extended_type_info * get_instance() { return &(singleton<extended_type_info_typeid_1<T> >::instance()); }
The main obstacle is that requires a detailed understandable explanation along with examples - a fair amount of work. Note that this really applies to all extended type info systems so the explanation is even more complex.
Well I would have to rely on you to tell me where we need to apply the fixes. I would be happy to add some documentation to a patch against 1.34.
And once embarks upon this kind of effort, its interesting to consider "finishing" extended type info with some missing functionality like "construct from export name".
I have no idea why the two affect each other!
It would also be interesting to investigate if there is some sort of lock free solution - At least on some compilers/ processors.
I'm not going to touch lock-free lazily initialized singletons! I'd rather have my code work ;-)
Just goes to show that no good idea goes unpunished.
:-)
SOOO I'm am positive about the idea. However, like most good ideas, its a lot bigger than it first appears.
Don't see why myself. In multi-threaded builds of serialization, we link with Boost.Thread and use boost::once.
Having written this, it would seem that this is territory well traveled by those working on a good Singleton suitable for such a purpose.
I've worked on the above singleton, tested it on a few x86 OSes and it seems to work. But I would be very happy if someone has a better solution that is tested.
(Amazingly, I don't even know if boost has such a thiing) Ideally, I would just like to use that (assuming it doesn't import everything on planet earth).
I believe that Boost has everything you need for a *correct* solution. Sohail