CODEWITHSUNDEEP
c++multithreadingthread-safetymemory-modelstdatomic
curiousguy
curiousguy

Reputation: 8288

Is the concept of release-sequence useful in practice?

C++ atomic semantics only guarantee visibility (through happen-before relation) of memory operations performed by the last thread that did a release write (simple or read-modify-write) operation.

Consider 

int x, y;
atomic<int> a;

Thread 1:

x = 1;
a.store(1,memory_order_release);

Thread 2:

y = 2;
if (a.load(memory_order_relaxed) == 1))
  a.store(2,memory_order_release);

Then the observation of a == 2 implies visibility of thread 2 operations (y == 2) but not thread 1 (one cannot even read x).

As far as I know, real implementations of multithreading use concepts of fences (and sometimes release store) but not happen-before or release-sequence which are high level C++ concepts; I fail to see what real hardware details these concepts map to.

How can a real implementation not guarantee visibility of thread 1 memory operations when the value of 2 in a is globally visible?

In other words, is there any good in the release-sequence definition? Why wouldn't the release-sequence extend to every subsequent modification in the modification order?

Consider in particular silly-thread 3:

if (a.load(memory_order_relaxed) == 2))
  a.store(2,memory_order_relaxed);

Can silly-thread 3 ever suppress any visibility guarantee on any real hardware? In other words, if value 2 is globally visible, how would making it again globally visible break any ordering?

Is my mental model of real multiprocessing incorrect? Can a value of partially visible, on some CPU but note another one?

(Of course I assume a non crazy semantic for relaxed writes, as writes that go back in time make language semantics of C++ absolutely nonsensical, unlike safe languages like Java that always have bounded semantics. No real implementation can have crazy, non-causal relaxed semantic.)

Upvotes: 4

Views: 404

Answers (1)

xskxzr
xskxzr

Reputation: 13040

Let's first answer your question:

Why wouldn't the release-sequence extend to every subsequent modification in the modification order?

Because if so, we would lose some potential optimization. For example, consider the thread:

x = 1;                            // #1
a.store(1,memory_order_relaxed);  // #2

Under current rules, the compiler is able to reorder #1 and #2. However, after the extension of release-sequence, the compiler is not allowed to reorder the two lines because another thread like your thread 2 may introduce a release sequence headed by #2 and tailed by a release operation, thus it is possible that some read-acquire operation in another thread would be synchronized with #2.

You give a specific example, and claim that all implementations would produce a specific outcome while the language rules do not guarantee this outcome. This is not a problem because the language rules are intended to handle all cases, not only your specific example. Of course the language rules may be improved so that it can guarantee the expected outcome for your specific example, but that is not a trivial work. At least, as we have argued above, simply extending the definition for release-sequence is not an accepted solution.

Upvotes: 4

Related Questions