Documentation: Relaxed Memory Ordering maybe wrong statement?

[steckes]

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 :)

[steckes]

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".

[steckes]

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.

[steckes]

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.

[sbarral]

I would actually agree with @sainteckes analysis here: in my understanding, out-of-thin air values are literally values that are not stored at any point of the execution and the C++ spec actually forbids compilers from creating them.

It looks therefore to me more likely that this particular section in the Loom doc is about the specific execution order that @sainteckes mentioned (D before C), which Loom cannot emulate.

[Darksonn]

Yeah, I guess you're right. The problem is not just out-of-thin-air. Loom works by interleaving different accesses in many different ways, but atomics can involve cases where different threads disagree on the order in which things happened. With loom, those cases cannot happen.