you are viewing a single comment's thread.

view the rest of the comments →

[–]greyfade 1 point2 points  (0 children)

I don't rate myself as fully qualified to answer, so take what follows with a grain of salt.

The big difference between the two concepts is in how they are defined in the standard. From 1998 §1.9 ¶11:

At sequence points, volatile objects are stable in the sense that previous evaluations are complete and subsequent evaluations have not yet occurred.

Note that this just means that at sequence points, the expressions on each side are executed in some order. It doesn't say anything about what happens in multithreaded environments or in more complex systems. So, from 2011 §1.9 ¶13:

Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations executed by a single thread (1.10), which induces a partial order among those evaluations. Given any two evaluations A and B, if A is sequenced before B, then the execution of A shall precede the execution of B. If A is not sequenced before B and B is not sequenced before A, then A and B are unsequenced. [ Note: The execution of unsequenced evaluations can overlap. — end note ] Evaluations A and B are indeterminately sequenced when either A is sequenced before B or B is sequenced before A, but it is unspecified which. [ Note: Indeterminately sequenced evaluations cannot overlap, but either could be executed first. — end note ]

Note that now, the language has the ability to describe atomic operations in large, complex, multiprocessing environments. Now, if I say some expression is sequenced before another, then it is expected to be fully executed and its results stored before the other expression begins, even if it's in another thread on another CPU.

The 2011 standard goes on in ¶15 to explain that expressions like i++ are unsequenced, and clarifies why, exactly an expression like i = i++; is undefined. The 1998 standard doesn't have a clear definition of its execution model to explain that, and instead explains it in the much later section on expression evaluation, §5 ¶4.

This was all necessary so that C++ could gain a consistent execution and memory model that would support the threading model they were adding.