<html>
<head>
<base href="http://bugzilla.gdcproject.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c10">Comment # 10</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126">bug 126</a>
from <span class="vcard"><a class="email" href="mailto:ibuclaw@gdcproject.org" title="Iain Buclaw <ibuclaw@gdcproject.org>"> <span class="fn">Iain Buclaw</span></a>
</span></b>
<pre>(In reply to Johannes Pfau from <a href="show_bug.cgi?id=126#c9">comment #9</a>)
<span class="quote">> @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
> <a href="https://github.com/D-Programming-Language/dmd/pull/3070">https://github.com/D-Programming-Language/dmd/pull/3070</a>)
> 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
> (<a href="http://stackoverflow.com/a/6681505/471401">http://stackoverflow.com/a/6681505/471401</a>).
> </span >
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
---</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>