Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at