Formal understanding of volatile semantic

Question

5.1.2.3 defines the following:

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or through volatile access to an object).

The definition sounds a bit vague to me. I'm particularly concerned about Sequenced before definition and how (if) it is tied to volatile.

Consider the following function as an example:

void foo(volatile int* a, int *b, volatile int *c){
    *a = 1;
    *b = 2;
    *c = 3;
}

Basically I have 2 questions:

1. Is *a = 1; sequenced before *c = 3?
2. Is *a = 1; sequenced before *b = 2;?

If so, why?

Sequenced before is defined at 5.1.2.3 as:

Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations executed by a single thread, which induces a partial order among those evaluations

Answer 1

Further down in the same part of the "sequenced before" definition C17 5.1.2.3 §3:

The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B.

This is crystal clear and leaves no room for interpretations.

In your code, every ; marks a sequence point (end of a full expression). So it is without doubt sequenced from the top to the bottom and that much has nothing to do with volatile.

---

Another question is if the optimizing compiler is allowed to re-order the expressions. The C concept of "the abstract machine" is muddy and generally unhelpful, but what it says is:

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).
/--/
Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine.

"The semantics" and "the rules of the abstract machine" refers (among other things) to the "sequenced before" part previously mentioned.

This can't very well get interpreted in any other way than that instruction re-ordering of volatile object access is forbidden.

However, the *b=2; expression is not volatile qualified. Here's where it gets muddy. One may read the quoted parts above as "no instruction re-ordering across volatile access is allowed". That is - volatile access must act as a memory barrier - which I think is the correct interpretation.

But as it happens, various CPU manufacturers implementing concurrent execution with pre-fetch and/or pipelining in multiple cores aren't necessarily digging this deep in the C standards during design. So the hardware might dictate how re-ordering will happen and then there's just so much the compiler vendor can do to fix it. Such hardware and the compiler for that hardware port might be a non-conforming implementation of the C language.

---

We may also note that the behavior of volatile changes slightly in the upcoming C23. A volatile access is now treated just as a volatile object access, meaning that stuff like *(volatile int*)0x1234 didn't strictly speaking play by the same rules as volatile int* ptr = (volatile int*)0x1234; ... *ptr. This was a defect, there is a defect report, and it has been fixed in C23.

Answer 2

The semantics of volatile-qualified accesses are implementation-defined. Many commercial compilers like MSVC are designed to refrain from ordering any memory operations across a volatile write, and limit actions that would reorder reads ahead of volatile reads to those which would consolidate them with previous reads, so a sequence like:

in_buff_ptr = my_buff;
in_buff_count = 4;
do {} while(in_buff_count);
doSomething(in_buff);

would be reliable if whatever might access the buffer would do so when accessing ordinary memory within a core that is cache-coherent with the core running the above code (note that on most embedded systems, all cores are cache coherent--if nothing else because that trait applies to all single-core systems).

The Standard would allow for the possibility that volatile accesses get processed by being enqueued somehow and processed by something outside the control of the executing code, a scenario that often applies to I/O devices. Code would be required to behave as though actions were enqueued in the order specified, but the Standard would be completely agnostic with regard to what happens after that, including whether the actions occur in the specified sequence. On some real-world systems, it would be entirely plausible that when executing a sequence of events like:

IOPINS = x; // IOPINS is volatile and when written sets the state of some I/O pins
y = IOPINS; // Reading IOPINS reports the clock-synchronized state of those pins

the read might yield the state of the pins just prior to when the write occurred. If systems tried to read the instantaneous state of I/O pins directly, bad things might happen if a pin state were to change precisely as it was being read. If code were doing something like "ADD R0,IOPINS" at just the wrong moment while R0 held 255 and the value on the pins was changing from 0 to 1, the physical bits within register 0 may be left in what's called a "metastable" state. To avoid this, some systems pass port bits through what's called a "double synchronizer" which avoids this issue, but add a delay between when pins actually change state and when they're observed as changing state.

If one wants to perform reliable read-modify-write operations with such I/O devices, it's important to read and understand the hardware manuals for them. Compiler writers generally won't have any way of knowing what kinds of I/O devices might be accessed via volatile-qualified operations, and what special precautions would be required to deal with them. The best a compiler can do is generally to refrain from performing its own reordering across volatile-qualified accesses, and leave hardware issues up to programmers.

Answer 3

Inside the abstract machine the standard uses to specify semantics, *a = 1; is before *b = 2;, and the latter is before *c = 3;.

Outside the abstract machine, the C standard specifies nothing about *b = 2; except that the observable behavior of the program must be the same as that of the abstract machine. The standard does not require an implementation to implement *b = 2; at all. There is not even any meaning for what *b = 2; is outside the abstract machine; the C standard does not even require that *b exist in any sense, let alone that it be after *a = 1; or *c = 3;.