From a8bfbccf0b87034c19bd314345eec9ff1ca612a7 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 16 Jul 2018 10:47:27 +0200 Subject: [PATCH 1/1] avoid 'read reads' --- personal/_posts/2018-07-13-arc-synchronization.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/personal/_posts/2018-07-13-arc-synchronization.md b/personal/_posts/2018-07-13-arc-synchronization.md index 50a518c..1ad8a46 100644 --- a/personal/_posts/2018-07-13-arc-synchronization.md +++ b/personal/_posts/2018-07-13-arc-synchronization.md @@ -157,10 +157,10 @@ fn main() { {% endhighlight %} This program, finally, is free of data races and hence has no undefined behavior and is guaranteed to print "Hello World!". -They key point is that *when an `Acquire` read reads from a `Release` write, an order is induced between these two accesses*. +They key point is that *when a `load(Acquire)` reads from a `store(_, Release)`, an order is induced between these two accesses*. We also say that the two accesses *synchronize*. Together with the per-thread order, this means we have an order between the `DATA = Some(...)` in the first thread and the load of `DATA` in the second thread, through the accesses to `FLAG`. -Intuitively, the `Release` write in the first thread "releases" everything that has been changed by this thread so far, and the `Acquire` read in the second thread then "acquires" all that data and makes it accessible for access later in this thread. +Intuitively, the `store(_, Release)` in the first thread "releases" everything that has been changed by this thread so far, and the `load(Acquire)` in the second thread then "acquires" all that data and makes it accessible for access later in this thread. Now, most of the time a `Mutex` or `RwLock` is good enough to protect your data against concurrent accesses, so you do not have to worry about such details. (And, thanks to Rust thread safety guarantees, you never have to worry about such details in safe code!) -- 2.30.2