[dmd-internals] Regarding deprecation of volatile statements

[Alex Rønne Petersen]

On Wed, Aug 1, 2012 at 1:41 PM, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 08/01/12 03:59, Alex Rønne Petersen wrote:
>> implement a feature that is rather essential for a systems language,
>> and especially in the year 2012? I understand that there are
>> difficulties in working out the exact semantics, but I'm sure we can
>> get there, and I think we should, instead of just hack-fixing a
>
> The first step to getting there would be discussing changes to the
> /language/ in a more visible place... The only reason I had to subscribe
> to lists such as this one or 'beta' is because of the dubious ideas
> and suggestions that only appear here.

Don't misunderstand: As I said in my email, I don't plan to actually
propose DIP17 for inclusion until it has been published and debated on
the NG. I merely put it up for some initial review by the compiler
folks, because frankly, this is more about subtle compiler details
than anything else.

>
> D's volatile statements were a mistake; since they are already
> deprecated and obviously flawed, I never saw the need to actually
> even mention this; i was just waiting until they are gone, so that
> a sane 'volatile' can be introduced. Your suggestion has the same
> problems; it does not help, but instead would make fixing the language
> harder (by keeping the current broken incarnation of volatile around).

Please explain how they were a mistake. I have seen this "feature X
was a mistake, so we removed it" thing way too often... and the
deprecation page on dlang.org is certainly not helpful in explaining
this either...

Please also explain what you mean by "current incarnation of
volatile". The C volatile? Or the D volatile statement (which is
currently deprecated)?

>
> The issues w/ volatile statements are really obvious, eg
>
> What does this do?
>
>    C c; D d;
>    //...
>    volatile d.i = c.i++;
>    //...

I don't see what's wrong here.

First, the value of c.i is read and saved into a compiler-generated
temporary. Then, d.i is set to this temporary. Then the temporary is
incremented and stored into c.i.

I can only guess, but is the problem you're trying to point out that
there might be multiple reads from c.i depending on the compiler
implementation? If so, I already mentioned that this is insignificant:
Excessive reads have no impact on semantics, but writes do.

>
> What about this?
>
>    int e;
>    volatile e = c.i;

Fetches c.i and stores it into e? Can you be clearer about what's
wrong here? I don't see the problem. According to my proposal, all the
volatile would do is ensure that the e = c.i statement isn't moved
around with respect to other volatile statements, or folded into other
volatile operations.

>
> Even introducing volatile /expresions/ wouldn't solve the problem,
> it's just the wrong tool for the job. 'volatile' is a property of
> the data (access), not of expressions/statements.

I can't really respond to this without some clarification of the above.

I think the idea that volatile is a part of the data access is just an
idea somehow carried over from C. Who says that's the right way? Why
do we have to do it the way C does it?

>
> Now imagine if 'C.i' was marked with a 'volatile' attribute. Both
> of the above examples would get sane semantics, which otherwise
> can only be approximated using explicit temporary dummy variables.

Please clarify what is insane about the above examples.

Which is how almost all compiler IRs do it. You'll rarely find
compiler IRs that don't use explicit load and store instructions. And,
after all, defining volatile semantics is also a matter of
practicality for compiler engineers.

>
> 'volatile' statements are just as broken as 'shared' statements
> would be:
>
>    shared { a = b; } // which access is the shared one? both?

I don't see what's odd about this at all. It would be equivalent to:

atomicStore(&a, atomicLoad(&b));

(Memory fences omitted.)

>
> Your arguments in the DIP againts a C-like attribute are equally
> valid against the "rather nonsensical" volatile statements examples:
>
>    int i;
>
>    volatile
>    {
>       i = 1;
>       i = 2;
>    }

It would be if you think about volatile as a modifier of data access
semantics. But note that in DIP17, it's more of a constraint on
execution order in general.

I think I should have been clearer about that. The way I'd like to see
volatile is that it modifies the order in which execution must happen,
not just memory loads and stores.

>
> which, btw, are not entirely nonsensical, as you may want i's on-stack
> (or -heap in case of closures) representation to be kept updated at all
> times. Which isn't a common requirement, but there is no reason to disallow
> this usage. It can obviously be expressed using compiler barriers too, but
> having every access automatically treated specially is much better than
> having to always remember to mark it as 'volatile' everywhere or wrap it.
> Think templates, etc.

Right, that's why I generalized volatile as something higher level
than a data access modifier: It opens the door for much better control
than the C volatile.

But that is also why making a variable volatile and forcing all
accesses to be such is limiting. You won't be able to access it in a
non-volatile way should you so wish.

I understand that, here, it's a matter of safety versus control. But
no matter how I look at it, volatile seems to me to be something very
low-level that you would not use in normal code. Think @system code.
In fact, the only uses I can think of for volatile outside of kernel
space are for memory-mapped files and variables in signal handlers.
For the former, the mechanism is almost certainly wrapped in some kind
of I/O API (see std.mmfile). For the latter, you're already in
low-level @system land and should really know what you're doing.

But that being said, there are almost certainly other uses that I
haven't thought of. I just can't imagine any uses that would happen in
high-level user land code.

Thanks for the feedback!

Regards,
Alex