<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#c9">Comment # 9</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:johannespfau@gmail.com" title="Johannes Pfau <johannespfau@gmail.com>"> <span class="fn">Johannes Pfau</span></a>
</span></b>
<pre>@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>).
Regarding peek/poke functions: Don't you think that's too cumbersome?
I also think shared + peek/poke has the drawback that you can still
accidentally access it like a normal shared variable, without the peek/poke
guarantees.
I'd prefer introducing a volatile type qualifier that enforces only one
property: The compiler does not optimize access but we don't guarantee anything
about the actual execution on hardware.
Volatile memory also sometimes has properties which don't match traditional
memory: I think I've seen architectures where reading a register might return a
completely different value than the value written in a previous write. Most
functions dealing with 'standard' memory will produce incorrect results if they
operate on such memory. By using an additional 'volatile' type qualifier we can
make sure that only functions which explicitly accept volatile memory can be
used with volatile variables.
BTW: I finally finished the volatile DIP, see <a href="http://wiki.dlang.org/DIP62">http://wiki.dlang.org/DIP62</a> .
It'd be great to get some early feedback from you and Iain, and feel free to
edit the DIP :-)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>