Re: [boost] [locale] review part 2.2: source

Subject: Re: [boost] [locale] review part 2.2: source
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2011-04-19 00:01:46

On Mon, 18 Apr 2011 18:25:57 +0600, Artyom <artyomtnk_at_[hidden]> wrote:

>> > Not really
>> >
>> > I had a discussion with a  professor an expert in
>> > this area, no problems when mutexes are  full
>> > memory barriers and they are.
>>
>> I'm not an expert, but there  is no ReadRead/acquire barrier
>> in case if table_is_ready is true. IIUC, it  would be a problem
>> if you are targeting IA-64 using non-msvc or msvc before  8.0 (2005).
>> Could you detect and #error on such arch/compiler  combinations?
>>
> Mutex acquisition and release is full memory barrier.

There is no mutex acquisition/release on the code path
if table_is_ready is true.

>> > This mutexes are  explicitly globally initialized
>> > later.
>> >
>> > So all such  things should be solved on library start.
>>
>> Some compilers might not  execute init::init() ctor as
>> the do_init variable is not used. Also, could  you comment
>> your assumptions in the code?
>
> I'm not aware of such compilers and if they exist
> they are probably buggy.

I was referring to ISO/IEC-14882:2003, 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. 31) ..."

Just checked it and found that footnote 31 prohibits such behavior:

"31) An object defined in namespace scope having initialization
with side-effects must be initialized even if it is not used (3.7.1)."