Re: MSDN volatile sample
On Wed, 2 Jan 2008 11:27:34 -0600, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:
"Bo Persson" <bop@gmb.dk> wrote in message
news:5tv4lqF1fjbiiU1@mid.individual.net...
George wrote:
:: My confusion is, whether we should add both mutex and volatile to
:: the shared data?
No. If you use a mutex, volatile just slows down your code and confounds
your use of objects of class type, since no one declares member functions
volatile. As I explained in another message in this thread, volatile also
does not penetrate deeply enough into class types to be very useful.
Conversely, if you use volatile instead of a mutex, your code is probably
broken, except that simple, independent, atomic variable access may work,
depending on the compiler and the machine architecture, and if they don't
conspire as you hope they will (and from a portability perspective, the
hoping is akin to prayer), the phase of the moon is also a factor.
Using both of them is unneccessary.
Correct.
Except when there is a special
compiler extension (like VC8, VC9) , volatile is not enough for thread
synchronization.
Even then, volatile is typically not enough, because it doesn't make
anything atomic that isn't already atomic, and atomicity is frequently
required for "thread synchronization".
When you use something like a mutex, that also disables some reordering of
reads and writes, because either
- the compiler knows about mutexes, and behaves correctly, or
- the mutex is an OS level operation, so the compiler doesn't know enough
to optimize
Correct. However, the compiler doesn't really think in terms of "OS level"
and "not OS level". The significant and sufficient thing is that the
function call is opaque.
I think this isn't right, because aliasing analysis may permit a conforming
compiler to optimize access to private member variables even in the presence
of arbitrary function calls, if the address of the variable is never taken.
The same holds true for file-scoped variables (C static globals or C++ anon
namespace).
In order to optimize, the compiler has to prove the variables aren't
reachable from the opaque functions. This is quite a higher bar than simply
checking if the "address is taken". We talked about this recently,
culminating in my message:
http://groups.google.com/group/microsoft.public.vc.language/msg/d1534cb05d22879f
<q>In a nutshell...</q>
Did you find some evidence to support your claim in the meantime?
--
Doug Harrison
Visual C++ MVP