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

[via D.gnu]

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

--- Comment #20 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(In reply to Mike from comment #19)
> Oh, and about atomic access... I agree that memory-mapped IO is shared,
> global state, but I also agree that it is wasteful to wrap each and every
> access in atomic accessors.  A large amount of memory mapped I/O is done
> during core, peripheral, and board initialization, before any threads or
> interrupts are even possible.  There is absolutely no need to wrap these in
> atomic accessors.  I believe the only one capable of making the best
> decision about when and where to add atomic access is the programmer, not
> the compiler.
>

FYI: This change is in 2.066 out next month.

https://github.com/D-Programming-Language/dmd/commit/7535f3dc86e9e88c4ee609dd98b5305224c3b88a

Having such a restriction in place makes a need for volatile types even more so
crucial for any future in embedded development.

It's worth noting that shared has been in a persistent state of slow definition
for the last two years, for instance there was a time when it was thought that
shared should imply volatile ( https://issues.dlang.org/show_bug.cgi?id=9163#c1
).  Infact in retrospect, part of the reasoning behind removing volatile was
that shared was expected to replace volatile, but come with safer guarantees.

Yet two years on, this viewpoint has changed.  Just from reading discussions of
this even in the last months, people are questioning the usefulness of shared
as a suitable replacement for the now removed volatile.

The way I see it, we have two camps.  On the one side, there's a real need to
have a specialised type for use of hardware access.  On the other, it's trying
to bend a type that has been tailored for safe inter-thread communication.  In
other words, shared is not just a property of memory, but a property its
actions, to which a volatile memory access may or may not uphold. 

I certainly do understand where you are coming from when you talk about scaling
volatileSet/volatileGet - however it is hard to get that across sometimes when
it seems the core developer only see it as "porting a 2 line function between
systems".


Recently, I stumbled upon a previously rejected DIP which proposed to keep
volatile and why (written by Zor) http://wiki.dlang.org/DIP17

He had some interesting points that I thought be worth examining two years on.

In summary, he explains that the shared type qualifier has been suggested as a
solution to the problems volatile tries to solve.  He notes however the
following drawbacks: 

> It is not implemented in any compiler, so practically using it now is not possible at all.

This is true, atomic types are a relatively new concept in a compiler, but this
is has changed over time since C++x11 atomic support has been introduced. 
Compilers are much better quipped today to handle at least some aspects of what
shared tries to solve.

> It does not have any well-defined semantics yet.

I think the change in the upcoming 2.066 release changes this, in that we are
now saying shared is clearly defined in both its transitivity (which will
improve with library support), and it's thread @safety by disallowing
operations that perform more than one operation without the safety of
core.atomic memory barriers/fences.

> It will most likely not be portable because it's designed for the x86 memory model.

Again with C++x11 atomics, this has been disproved.  Infact it's probably of no
coincidence that the way core.atomic's memory model is designed, it maps pretty
much 1:1 to C++x11 atomics.

> If ever implemented, it will result in memory fences and/or atomic operations, which is **not** what volatile memory operations are about. This will severely affect pipelining and performance in general.

This is the number one reason why volatile is needed. And why shared is wholly
unsuitable.


Further to his arguments, he also tries to disprove the use of "two-liner"
inline assembly to solve the problem, I won't bother reviewing these, the whole
point of the matter why volatile is needed is that I am asking you (politely)
to not use the inline assembler as an excuse to *not* implement a feature that
is rather essential for a systems language.

-- 
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/20140615/b5f17436/attachment-0001.html>