Am Fri, 24 Jan 2014 22:30:13 +0000 schrieb "Kagamin" <s...@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.