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

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-12-15 17:51:21

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

> As far as "deadstripping" code - this has indeed been a big problem - 
> especially in release mode. I've referred to it as overzealous 
> optimization.

It isn't overzealous -- it's within the specifications of the standard, 
whether you like it or not.

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

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

>> I personally find it easier to register my
>> classes "manually" (note that systems other than the serialization
>> library also require class registration.)
>
> I'm not going to disagree with that.  This was the first method I used and 
> it works well and is portable.  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.