shared methods

[Johannes Pfau]

Am Fri, 24 Jan 2014 22:30:13 +0000
schrieb "Kagamin" <spam at here.lot>:

> http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/
> As I understand, because Itanium doesn't have cache coherency, a 
> memory fence is needed to implement volatile load and store. On 
> x86 load and store are already volatile because of cache 
> coherency, so fences are not needed.

Seems like C#s volatile cares about "compiler optimizations and
processor optimizations.". I'd rather want a volatile for D (or as a
base for shared) which only cares about compiler optimizations, leaving
the processor part to the programmer.

(For example it isn't valid in D to access a shared variable with
normal operations anyway, AFAIK. You need to use the atomicOp things
and these will the worry about the hardware part, using the correct
instructions and so on)

See also:
http://www.drdobbs.com/parallel/volatile-vs-volatile/212701484

So volatile is a completely different thing in C#/JAVA and C/C++. This
is why I'm confused, C compilers are not supposed to guarantee that
another thread can see all changes to a volatile variable, volatile must
just prevent compiler optimizations. So if Itanium C compilers
automatically use the barrier/fence instructions for volatile that's
IMHO a compiler performance bug.

I also can't find any information the GCC adds barriers on Itanium.
Maybe this is just true for the Intel compiler, as the main source for
these claims are Intel pages.