Re: Thread and C++
Volatile helps little or nothing wrt threads in practice. It tells the
compiler that the value could have changed, but you still have no clue of
the outcome of any read, write or i++ like complex, if at the same time
other thread also access the same object.
You need to use sync primitives (mutex, membar, system-provided atomic
ops, etc) to play safe, and also good understanding of the implications.
And a couple of reviews on any thread interaction-involved code and
data...
I am talking about the case when mutexes (locks) are used. I am reading
about Qt these days, and they recommend using volatile definitions of
built-in types in addition to mutexes, to avoid possible compiler
optimisations that may mess things, and I wonder if the last can be true,
since we use mutexes.
Inside a critical secition (between a mutex lock/unlock) there is no point
to have volatile.
(As general: keep in mind, that access to volatiles is ordered wrt each
other, but there is no requirement on ordering volatiles wrt
nonnolatiles...)
In order for things to work, your comiler and system must understand the
special of the mutex op. And must not move any code that is inside the
section outside of it. If it does, you are hosed no matter what.