On Mon, 18 Apr 2011 18:25:57 +0600, Artyom <artyomtnk@yahoo.com> 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)."