Re: [boost] [Serliazation] Thread-safety again

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-12-15 19:04:37

Emil Dotchevski wrote:
>>> Therefore, you are still prone to threading problems. There is
>>> nothing in the C++ standard which guarantees globals will be
>>> initialized before main().
>>
>> According to the reference I use: The C++ Programming Language by
>> Stroustrup page 244 10.4.9:
>> "A global, namespace or class static object which is created once
>> "at the start of the program" and destroyed at once at the
>> termination of the program." I've always interpreted this to mean
>> what it says and this is reflected in the standard..  But I'm sure
>> some else on this list can give a definitive answer as to what the
>> standard actually says.
>
> 3.6.2.3: It is implementation-defined whether or not the dynamic
> initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace
> scope is done before the first statement of main. If the
> initialization is deferred
> to some point in time after the first statement of main, it shall
> occur before the first use of any function or object defined in the
> same translation unit as the object to be initialized.

OK - of course we've actually observed this behavior in the loading
unloading of DLLS.  I have no idea whether the standard address dynamic
loading/unloading and the construction/destruction issues. I supposed not
and had to make changes when we came upon this.  I expect that these
same changes also address the

>> Compilers vary quite a bit in this regard and In practice it has been
>> addressed on an ad-hoc basis.  In some cases code has been marked
>> "_export" just so the optimizer doesn't drop it.  This is the
>> function of the module "force_include.hpp".
>
> If I find that a piece of code breaks when optimizations are enabled,
> I
> treat it as a bug. Sometimes it's bug in the compiler, but more often
> than not it isn't.

Actually when I first came upon this I thought it was a compiler bug.
As you've pointed out its not.  Not that it matters to me - it just one
more problem to be solved one way or another.

>>> In my opinion, the only portable option is to require manual
>>> registration,
>>
>> That may well be true.
>>
>>> and leave it up to the user to come up with their own,
>>> non-portable solution for automatic registration, and deal with
>>> multi-threading/deadstripping problems this could cause.
>>
>> Or the user could use the system included with the serialization
>> library which has already dealt with these issues.
>
> The only issue I see here is that you are trying to prevent the
> compiler
> from doing something that the standard allows it to do.

Agreed. That's exactly what we've done.

> Besides (I'm
> repeating myself here), the "problem" you are solving is beyond the
> scope of the serialization library, because there are other systems
> that also need type registration and other one-time dynamic
> initialization.

The "problem" is addressed in the context and only in the context of
the serialization library.  I'm aware that the "problem" is more general
and we have no illusion that this is anything other than an ad hoc
solution.  Its just the best we could do and it does address the
issue for this library.

> If there is a consensus that it is desirable to
> provide for automatic dynamic initialization of namespace-scope
> objects even if no function from their compilation unit is ever
> executed, perhaps this needs to be separated in a boost library of
> its own, as a first step of (possibly) adding such feature to the C++
> standard.

Great idea!  I'll look forward to seeing this!!  But as you point out
there's no way to do this in a portable way.  If there had been, we
would have done it that way.

>>But the lack of an
>> automatic method like "export" raised a chorus of howls which had to
>> be addressed.

> I've seen many instances of chorus of howls from folks that write
> sub-standard code and complain that it isn't working as they have
> hoped. I tend to quote the C++ standard in response.

Oh, I'm sure that's much appreciated.

I suppose I could have used the approach when this issue was first
raised.  But, had I done so, I don't think we would have any
serialization library today.  Sometimes real solutions to real problems
can't be crafted while restricting oneself to portable, standard conforming
code.

But we've come full circle.  If you want portability, stick to those
facilities - in ths case explicit registration - if it's not a concern you
have the other method available.

Robert Ramey