---

yaml
---
r: 222715
b: refs/heads/tmp
c: 18067e4
h: refs/heads/master
i:
  222713: c8ef22d
  222711: 48a1e99
v: v3

Author: Gankra

[refs]

@@ -25,7 +25,7 @@ refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
 refs/tags/0.12.0: f0c419429ef30723ceaf6b42f9b5a2aeb5d2e2d1
 refs/heads/beta: 2b45108ecb944d63daba0f1b5529ac4c8afdc295
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
-refs/heads/tmp: 108a697b1c225dafef16a77076e30149b1d0ebe7
+refs/heads/tmp: 18067e41090938ff5d642bbef05604c939e542dc
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: e58601ab085591c71a27ae82137fc313222c2270
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828

branches/tmp/concurrency.md

@@ -154,15 +154,44 @@ only to data races?
 
 # Atomics
 
-Rust pretty blatantly just inherits LLVM's model for atomics, which in turn is
-largely based off of the C11 model for atomics. This is not due these models
-being particularly excellent or easy to understand. Indeed, these models are
-quite complex and are known to have several flaws. Rather, it is a pragmatic
-concession to the fact that *everyone* is pretty bad at modeling atomics. At very
-least, we can benefit from existing tooling and research around C's model.
+Rust pretty blatantly just inherits C11's memory model for atomics. This is not
+due this model being particularly excellent or easy to understand. Indeed, this
+model is quite complex and known to have [several flaws][C11-busted]. Rather,
+it is a pragmatic concession to the fact that *everyone* is pretty bad at modeling
+atomics. At very least, we can benefit from existing tooling and research around
+C.
 
-Trying to fully explain these models is fairly hopeless, so we're just going to
-drop that problem in LLVM's lap.
+Trying to fully explain the model is fairly hopeless. If you want all the
+nitty-gritty details, you should check out [C's specification][C11-model].
+Still, we'll try to cover the basics and some of the problems Rust developers
+face.
+
+The C11 memory model is fundamentally about trying to bridge the gap between C's
+single-threaded semantics, common compiler optimizations, and hardware peculiarities
+in the face of a multi-threaded environment. It does this by splitting memory
+accesses into two worlds: data accesses, and atomic accesses.
+
+Data accesses are the bread-and-butter of the programming world. They are
+fundamentally unsynchronized and compilers are free to aggressively optimize
+them. In particular data accesses are free to be reordered by the compiler
+on the assumption that the program is single-threaded. The hardware is also free
+to propagate the changes made in data accesses as lazily and inconsistently as
+it wants to other threads. Mostly critically, data accesses are where we get data
+races. These are pretty clearly awful semantics to try to write a multi-threaded
+program with.
+
+Atomic accesses are the answer to this. Each atomic access can be marked with
+an *ordering*. The set of orderings Rust exposes are:
+
+* Sequentially Consistent (SeqCst)
+* Release
+* Acquire
+* Relaxed
+
+(Note: We explicitly do not expose the C11 *consume* ordering)
+
+TODO: give simple "basic" explanation of these
+TODO: implementing Arc example (why does Drop need the trailing barrier?)
 
 
 
@@ -184,5 +213,5 @@ with everyone else's stuff.
 
 
 
-[llvm-conc]: http://llvm.org/docs/Atomics.html
-[trpl-conc]: https://doc.rust-lang.org/book/concurrency.html
+[C11-busted]: http://plv.mpi-sws.org/c11comp/popl15.pdf
+[C11-model]: http://en.cppreference.com/w/c/atomic/memory_order