Re: [Boost-users] [Serialization] Thread-unsafe singleton

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-05-25 00:45:57

Sohail Somani wrote:

>> 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?"

The issue is the invocation of a function which impliles the
construction of the required type.  This occurs as a side effect
of serializing the type in an archive.  But it could ust as well
be done explicitly before any threads are started.

This explanation is much confused by the fact that I've used
"registration" to mean more than one thing.  One thing
is the creation of the suitable extended_type_info object
(which is being discussed here).
while another thing is the construction of certain serialization
objects which occur for every combination of archive type
and serializable type which is serialized through a pointer.
This latter is also done as a side effect of just using serialization.

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

Your idea is to refine, and improve extended_type_info.  It
has utility outside the serialization package.  However to
make this as useful as it should be would require adding
some "missing" functions and improving the documentation
to make it more of a "first class" boost module.

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