- volatile in C++ is connected to optimization during access to variable - no optimization is allowed. Operations on nearby non volatile variables depends on compiler (can be move before or after volatile operation).
- operations on volatile in C++ does not guarantee atomicity - resolution is atomic
in C++ (or e.g. atomic_int in C) available in Boost (but I cannot find it) and will be in C++0x.
- volatile in managed environments (.Net, Java) does not allow to move some operations on nearby non volatile variables - "ordinary reads and writes can't move upward across (from after to before) an ordered atomic read, and can't move downward across (from before to after) an ordered atomic write. In brief, that could move them out of a critical section of code, and you can write programs that can tell the difference.".
- keeps order - lock free programming,
- allows some code optimizations - not good for interactions with hardware - but BTW managed environments does not allow to treat memory as a resource to write somewhere programmer might like to - unmanaged code have to be used (e.g. C++ with its volatile:).
- might not keep order - depends on compiler,
- does not allow code optimization - good for interactions with hardware.
Not sure points:
- atomicity of volatile operations in .Net/Java - for what variables, e.g. what about architectures 32, 64?,
- "These (volatile) are suitable for nearly all lock-free code uses, except for rare examples similar to Dekker's algorithm. .NET is fixing these remaining corner cases in Visual Studio 2010" - what are the problems?