Repository for the article Explaining Atomics in Rust
in the 'Release' part, it is said that: So not only do the operations need to be correctly ordered locally, there is also a guarantee that the changes must be visible to an observing core at this point. however, there is an example from this video, from 1:35: https://www.youtube.com/watch?v=rMGWeSjctlY ``` fn main(){ use std::sync::atomic::AtomicUsize; let x: &'static _ = Box::leak(Box::new(AtomicBool::new(false))); let y: &'static _ = Box::leak(Box::new(AtomicBool::new(false))); let z: &'static _ = Box::leak(Box::new(AtomicUsize::new(0))); let _tx = spawn(move ||{ x.store(true, Ordering::Release); }); let _ty = spawn(move ||{ y.store(true, Ordering::Release); }); let t1 = spawn(move ||{ while !x.load(Ordering::Acquire){} if y.load(Ordering::Acquire){ z.fetch_add(1, Ordering::Relaxed); } }); let t2 = spawn(move ||{ while !y.load(Ordering::Acquire){} if x.load(Ordering::Acquire){ z.fetch_add(1, Ordering::Relaxed); } }); t1.join().unwrap(); t2.join().unwrap(); let z = z.load(Ordering::SeqCst); println!("z is: {}", z); } ``` according to what the author claimed, the result of z might be 0 the above example is a classic demo, so I believe their conclusion is correct. however it is inconsistent with your statement that "there is also a guarantee that the changes must be visible to an observing core at this point" and here is the explanation: let we suppose the guarantee does exist, let we name "if y.load(Ordering::Acquire)" in t1 as statement1, and "if x.load(Ordering::Acquire)" in t2 as statement2. if statement1 and statement2 happens exactly at the same cpu clock cycle, then x and y should both have been set to true at that point, otherwise they couldn't reach there. since the store(Release) is visible immediately for load(Acquire), both statement1 and statement2 will load x and y as true, and inc z by 1. if statement1 and statement2 happens one after another, suppose t1 reaches statement1 first, when t2 reaches statement2, as t1 has reaches statement1 earlier, we know that x has already been set to true. then t2 will inc z by 1. likewise , if t2 reaches statement2 earlier than statement1, then t1 will inc z by 1. therefore z could never be 0 as per your guarantee so I guess maybe the guarantee does not exist for weakly ordered CPU?
This issue appears to be discussing a feature request or bug report related to the repository. Based on the content, it seems to be resolved. The issue was opened by star4evar and has received 2 comments.