Documentation: Relaxed Memory Ordering maybe wrong statement?

[sainteckes]

In the section about Relaxed Memory Ordering in the docs it is stated, that B can run before A.

loom/src/lib.rs

Line 294 in 31dfebd

//! ## Relaxed Memory Ordering

thread::spawn(move || {
  let r1 = y.load(Ordering::Relaxed); // A
  x.store(r1, Ordering::Relaxed);     // B
});
thread::spawn(move || {
  let r2 = x.load(Ordering::Relaxed); // C
  y.store(42, Ordering::Relaxed);     // D
});

How should the compiler be able to move B in front of A, if r1 is not existing at this time?
I guess you meant that D can run before C, what makes perfect sense, because D has no connection to C that is visible for the compiler.

I am quite new to understanding this stuff, so happy if you correct me :)

[sainteckes]

Okay, theoretically r1 could exist because of shadowing, but this is not the point that should be done here no? :D

[Darksonn]

The correct search term is "out of thin air values".

[sainteckes]

Oh very good hint, super interesting topic, I can't wait to understand more.
So it is actually right the B can run before A?

[Darksonn]

In general, reordering of operations is the wrong way to look at it. Different threads may disagree about the order things happened in, since they may see the effects of an atomic operation in a delayed manner.

[sainteckes]

But is my assumption here a valid path of execution?

1. D -> y = 42
2. A -> r1 = y (42)
3. B -> x = r1 (42)
4. C -> r2 = x (42)

Which would lead to r1 == r2 == 42, what only involved reordering D and C plus executing thread 1 in between.

I just read this blog article, where the person tries to explain the out of thin air value with a quite similar example.

So thread 1 reads r1 before storing it, but thread two sees the store before the load?

I saw that @jonhoo was writing this bit, do you think there is a way to make this a bit clearer in the documentation or do you think it is all good? In this case feel free to close this ticket. Thank you @Darksonn for the help.