Re: MSDN volatile sample

From:

"Alexander Grigoriev" <alegr@earthlink.net>

Newsgroups:

microsoft.public.vc.language

Date:

Mon, 31 Dec 2007 08:45:09 -0800

Message-ID:

<#mJg6w8SIHA.484@TK2MSFTNGP06.phx.gbl>

You only need to care about memory ordering issues if you don't use any OS
functions to guard modification of your data. Then you need to be very
careful about order of modification, and I would not recommend to even think
about it.

But if you use, for example, CRITICAL_SECTION for data protection, it will
guarantee that all writes will be committed.

"George" <George@discussions.microsoft.com> wrote in message
news:8D20539E-2DBB-4A5A-AFDF-111070EA34A0@microsoft.com...

Thanks Alexander,

I agree. Do you think we need to add both volatile and synchronized
approach
to thread shared data?

I have this concern is because if we only add synchronization (e.g.
mutex),
but no volatile, compiler may do wrong optimization (as showed in the MSDN
sample) to change the designed function in a wrong/unexpected way.

Could you prove that adding synchronization will prevent compiler from
wrong
optimization? I have not found any formal document about this topic, so
this
is the core issue of this topic people are confused. :-)

regards,
George

"Alexander Grigoriev" wrote:

"George" <George@discussions.microsoft.com> wrote in message
news:EF48E84B-2180-4EC5-A5AB-00D0920D2710@microsoft.com...

Well Bo,

For a status bar, it is actually enough if it works most of the time.
It is only approximate anyway. For more important stuff, I would
certainly use a critical section to synchronze the threads. Or perhaps
one of the _Interlocked intrinsics on Windows.

For your concern, I begin to suspect all of the code I wrote before
about
multi-threaded parts. Maybe I need to add volatile to all shared data.

Adding 'volatile' would be wrong approach. Using proper synchronization
should do the right thing.