Hello Steven,

Monday, January 8, 2007, 11:26:29 PM, you wrote:

...

...

AMDG

...

Andrey Semashev wrote:

...

...

...

Oh, you're right. But isn't it enough just to mark "m_fInitialized" as "volatile"? According to 1.9/7 it would enforce the compiler to initialize "m_StatesInfo" prior to setting "m_fInitialized".

No, m_StatesInfo has to be volatile too.

Why? The Standard says all side effects prior to access to a volatile object will be completed at a sequence point (1.9/7, 1.9/11). There is a sequence point after returning from a function (1.9/17). At this sequence point all expressions of the function will be complete (IOW, m_StatesInfo will be initialized). So, in our case no matter what a compiler does, the call to "init_states_info" must be done before "m_fInitialized" assignment, shouldn't it? Actually, thinking of is some more I got some doubts about wether a compiler is allowed to shuffle expressions. The "init_states_info" function call and "m_fInitialized" assignment are both full-expressions and thus have sequence points at completion of each of them (1.9/16). So they should be executed in the the same order as they written in code. Sorry if I'm asking dumb questions, I'm just trying to get to the bottom of this. Am I wrong? The standard also says that the compiler can reorder anything it wants to as long as the sequence of volatile reads and writes and calls to library IO functions is unchanged (1.9/5-6). i.e. the compiler only has to make it appear that all previous side effects are completed at a sequence point. Without volatile the compiler can assume that no other thread refers to

AMDG Andrey Semashev wrote: the variables. So, you certainly do need volatile here. In Christ, Steven Watanabe