[Bug 126] Add support for attribute to mark data as volatile.

via D.gnu d.gnu at puremagic.com
Sun Jun 1 05:09:52 PDT 2014


http://bugzilla.gdcproject.org/show_bug.cgi?id=126

--- Comment #10 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(In reply to Johannes Pfau from comment #9)
> @Mike: AFAIK shared has some additional requirements which are not necessary
> for volatile:
> 
> 1.) Atomic access: Accessing shared variables must always use atomic access
> (This is not yet enforced, but see
> https://github.com/D-Programming-Language/dmd/pull/3070)
> 2.) Accessing shared variables should also prevent reordering by the CPU
> (I'm not 100% sure about this though), not only by the compiler, as volatile
> does.
> 
> I guess in the end shared variables will always be accessed via some
> function (atomicOp, synchronized statement + casting, ...).
> 
> Also shared variables could ignore requirement 1. At least in C++/11
> multiple accesses to atomics can be merged
> (http://stackoverflow.com/a/6681505/471401).
> 

That is a re-order by the compiler, which is (2) - there is still a guarantee
that the var isn't cached in some way.

Mike, this is the most common example of reordering I was mentioning about at
the conference.

---
shared int myshared;

myshared = 0;
foreach (i; 0 .. 12)
  myshared += 1;

---

Under volatile semantics, the loop would be unrolled and ordering kept.

mov    $0, _D4test4globOi(%rip)    ; myshared = 0

mov    _D4test4globOi(%rip), %eax  ; myshared += 1
add    $1, %eax
mov    %eax, _D4test4globOi(%rip)
; And so on...

---

In future, the compiler would memoize the loop and go straight for the
assignment.

mov    $12, _D4test4globi(%rip) 

---


Pull #3070 is interesting, as it would disallow most cases where the compiler
may get away with this kind of reordering behaviour.

The current implementation of core.atomic does mean that all atomicOps are
fully sequenced.  As soon as we switch over from the old-style __sync
intrinsics to C++x11 __atomic intrinsics, then this may change (MemoryOrder.raw
will be adhered to).

mov    $0, _D4test4globOi    ; glob = 0
mov    $12, %eax             ; count = 12
xor    %edx, %edx
jmp    .L2
.L1
mov    _D4test4globOi, %edx  ; atomicOp!"+="(glob, 1)
.L2
lock add $1, (%edx)          ;
subl   $1, %eax              ; count--
jne    .L1

---

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20140601/92ac1ac4/attachment-0001.html>


More information about the D.gnu mailing list