sequenced-before modification order consistency
Asked Answered
U

3

7

from http://en.cppreference.com :

Relaxed ordering Atomic operations tagged std::memory_order_relaxed are not synchronization operations, they do not order memory. They only guarantee atomicity and modification order consistency. For example, with x and y initially zero,

// Thread 1:
r1 = y.load(memory_order_relaxed); // A
x.store(r1, memory_order_relaxed); // B
// Thread 2:
r2 = x.load(memory_order_relaxed); // C 
y.store(42, memory_order_relaxed); // D

is allowed to produce r1 == r2 == 42 because, although A is sequenced-before B and C is sequenced before D, nothing prevents D from appearing before A in the modification order of y, and B from appearing before C in the modification order of x.

Question: What it is the thing that confer to the above code the property A is sequenced-before B and C is sequenced before D?

EDIT:

int A, B;

void foo()
{
    A = B + 1; (A)
    B = 0; (B)
}

lead to

$ gcc -O2 -S -masm=intel foo.c
$ cat foo.s
        ...
        mov     eax, DWORD PTR B
        mov     DWORD PTR B, 0
        add     eax, 1
        mov     DWORD PTR A, eax
        ...

under GCC 4.6.1 with -02 option

so we clearly see that (A) and (B) have been switched

Undersigned answered 13/12, 2014 at 19:45 Comment(2)
The true answer was hidden by moderators: "Your misunderstanding here is obviously based on the idea you believe the standard is well written and sound and that programs can have defined behavior. None of that is true. There is no definition of thread semantics, not even the glimpse of the beginning of it."Cake
@BooberBunz "This does not provide an answer to the question" It does actually. It's the one and only one possible answer. If you disagree, leave a comment, don't censor answers.Cake
C
6

The sequenced-before (not the same as happens-before) relationships are not specific to multithreading. They happen in single threaded programs as well. Any expression that ends with a semicolon is sequenced-before the next, so in this case A is sequenced before B and C before D because each of them is a full-expression.

From the Standard 1.9 Program execution 14:

Every value computation and side effect associated with a full-expression is sequenced before every value computation and side effect associated with the next full-expression to be evaluated.

You can find an explanation here:

Order of evaluation

Combustible answered 13/12, 2014 at 20:20 Comment(7)
compiler and processor can reorder the instructionUndersigned
@Guillaume07 Without memory fences yes.Combustible
I meant in the code I post there is no fence, so according to my knowledge nothing avoid compiler or processor to do reordoring.But it seems there is a sequenced-before relationship, but I don't see where here and how it works, that the goal of my questionUndersigned
@Guillaume07 Ok, then yesCombustible
@Guillaume07 The sequenced-before relationships count within the thread only. It means that the first thread will see the side effects of A before the side effects of B, but there is no guarantee of which order the second thread will see them.Combustible
according to what it is said in the following link: preshing.com/20120625/memory-ordering-at-compile-time even in a single thread full expression can be reordering by the compilerUndersigned
@Guillaume07 Yup, but the side effects (in the abstract machine not the actual program) of an expression sequenced-before another one are guaranteed to be perceived first, IN THE SAME THREAD. I think you are misunderstanding what a sequenced-before relationship is and you meant to ask about happens-before relationship and memory reordering.Combustible
I
1

"Sequenced-before" applies to the visible observable behaviour of your program. The compiler is free to reach that behaviour in any way it wants; it can reorder writes to memory or eliminate them completely, as long as the visible behaviour is the same.

Irs answered 14/12, 2014 at 1:5 Comment(0)
C
-3

The question is not answerable. There is no standard thread semantic, end of story.

Saying that there is standardized thread semantic, or any semantic of any program, is a hoax.

Cake answered 21/1, 2020 at 19:46 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.