how to use volatile key word?

[Bo Persson]

Dombo skrev 2012-06-28 22:26:

Op 28-Jun-12 21:16, Ian Collins schreef:

I don't know what the C++ 11 standard says about this but, on VS2010 it
does nothing special to keep volatile variables out of the cache.

That's because VS2010 only targets platforms where the hardware does the
cache sync. So it doesn't have to do anything.

It also means that the code can easily be non-portable, because "works
on x86" doesn't mean "works elsewhere".


Bo Persson

 

[Nobody]

That's because VS2010 only targets platforms where the hardware does the
cache sync. So it doesn't have to do anything.

It's more because "volatile" is normally understood as requesting that the
compiler doesn't re-order or coalesce load/store operations, not that it
should provide workarounds for re-ordering performed by the CPU. If you
want the latter, you need to use explicit (and platform-specific) fence
operations.

It also means that the code can easily be non-portable, because "works
on x86" doesn't mean "works elsewhere".

x86 has one of the strongest memory consistency models. At the other
extreme, Alpha, PPC, IA-64 and ARM have very weak consistency.

Coupled with the lack of any alignment constraints, x86 is about the worst
test platform if you want portable code, as it papers over the most common
issues. On the upside, being little-endian means that omitting
host-order/network-order conversions will show up.

 

[88888 Dihedral]

Nobodyæ–¼ 2012å¹´7月2日星期一UTC+8上åˆ12時05分15秒寫é“：

It's more because "volatile" is normally understood as requesting that the
compiler doesn't re-order or coalesce load/store operations, not that it
should provide workarounds for re-ordering performed by the CPU. If you
want the latter, you need to use explicit (and platform-specific) fence
operations.


x86 has one of the strongest memory consistency models. At the other
extreme, Alpha, PPC, IA-64 and ARM have very weak consistency.

Coupled with the lack of any alignment constraints, x86 is about the worst
test platform if you want portable code, as it papers over the most common
issues. On the upside, being little-endian means that omitting
host-order/network-order conversions will show up.

The X86 memory related instructions were designed in the period that
the DRAM chips were expensive in the consumer markete in the 70's.

But Intel did support the virtual mode long time ago.

 

[Stuart Redmann]

On 28 Jun., Scott Lurndal wrote:

[snipped discussion about proper use of keyword "volatile"]

The caching hardware itself ensures that the caches on all cores/sockets are
coherent, such that there will only be one core that holds a modified
value of the memory line (64-bytes for most) and all other cores will invalidate any
copies of the cache line.
[snip]

volatile
has nothing to do with the hardware architecture - it is simply a directive to
the compiler that ensures that every reference results in a corresponding load
instruction, and every modification results in a corresponding store instruction.

[snip]

I think that this is pretty much the answer to Paavo's question
whether the C++ standard guarantees this behaviour. Do you happen to
know chapter and verse of the C++ standard?

Thanks in advance,
Stuart

 

[Philip Lantz]

Fortunately, on x86 anyway, loads from the integral data types (byte,
word, doubleword and extended doubleword (8, 16, 32 and 64)) are always
atomic without the LOCK prefix.

However, if the atomic being loaded is related to some other variable (e.g.
the count
of entries in a queue and the queue listhead), then the LOCK prefix should
be used on loads of the atomic value to ensure that all prior stores are
completed before the load issues.

The LOCK prefix can be used only on read-modify-write instructions with
a memory destination. It cannot be used on a load instruction. (You
could use a locked xadd or cmpxchg to load a value; is that what you
meant?)