refactor atomics section

Author: connortsui20

week12/parallelism.md

@@ -33,6 +33,7 @@ code {
 - Multithreading
 - Mutual Exclusion
 - Atomics
+- Message Passing
 
 
 ---
@@ -641,8 +642,8 @@ We must eliminate one of the following:
 
 Take turns! No "cutting in" mid-update.
 
-1. `x` is shared memory
-2. `x` becomes incorrect mid-update
+1. `x` is in shared memory
+2. `x` temporarily becomes incorrect (mid-update)
 3. ~~Unsynchronized updates (parties can "cut in" mid-update)~~
 
 
@@ -764,26 +765,25 @@ why it is impossible to create any data races in safe rust.
 
 # Approach 2: Atomics
 
+One airtight, _atomic_ update! Cannot be "temporarily incorrect" mid-update.
 
-One airtight update! Cannot be "incorrect" mid-update.
-
-1. `x` is shared memory
-2. ~~`x` becomes incorrect mid-update~~
+1. `x` is in shared memory
+2. ~~`x` temporarily becomes incorrect (mid-update)~~
 3. Unsynchronized updates (parties can "cut in" mid-update)
 
 
 ---
 
 
-# Approach 2: Atomics
+# Code to Machine Instructions
 
-The compiler usually translates the following operation...
+Recall that the compiler will usually translate the following operation...
 
 ```c
 x += 1;
 ```
 
-...into the machine instruction equivalent of this:
+...into the machine instruction equivalent of this code:
 
 ```c
 int temp = x;
@@ -795,7 +795,7 @@ x = temp;
 ---
 
 
-# Approach 2: Atomics
+# Atomics
 
 However, we can use an atomic operation like this:
 
@@ -812,55 +812,89 @@ x += 1;
 * `fetch_and_add`: performs the operation suggested by the name, and returns the value that was previously in memory
   * Also `fetch_and_sub`, `fetch_and_or`, `fetch_and_and`, ...
 
+
 ---
 
-# Sneak Peak of CAS Atomic
+# Aside: `compare_and_swap`
 
-Other common atomic is `compare_and_swap`
-* If the current value matches some old value, then write new value into memory
-  * Depending on variant, returns a boolean for whether new value was written into memory
-* "Lock-free" programming:
+Another common atomic operation is `compare_and_swap`
+
+* If the current value matches an old value, update the value
+  * Returns whether or not the value was updated
+* You can do "lock-free" programming with just CAS
   * No locks! Just `compare_and_swap` until we successfully write new value
-  * Not necessarily more performant than lock-based solutions
-    * Contention is bottleneck, not presence of locks
-  
-<!--Speaker note: can skip over this slide during lecture and students can look at it if they want.
--->
+    * _Not necessarily more performant than lock-based solutions_
+
 
 <!-- Speaker note:
+Skip over this slide during lecture and students can look at it if they want.
+
 Rule of thumb: conventional wisdom is that locking code is perceived as slower than lockless code
 
 This does NOT mean that lock-free solutions are more performant than lock-based solutions.
 
 Lock-based solutions are slow due to _contention_ for locks, not _presence_ of locks
 If multiple threads are contending for same memory location, i.e. stuck in a `compare_and_swap` loop, that can be equally slow
-This is why benchmarking is importnat, because we can't crystal-ball the performance of our solutions!
+This is why benchmarking is important, because we can't crystal-ball the performance of our solutions!
 -->
+
+
 ---
 
+
 # Atomics
+
 These atomic operations are also implemented in the Rust standard library.
+
 ```rust
-use std::sync::atomic::{AtomicIsize, Ordering};
+use std::sync::atomic::{AtomicI32, Ordering};
 
-let x = AtomicIsize::new(0);
+let x = AtomicI32::new(0);
 
 x.fetch_add(10, Ordering::SeqCst);
 x.fetch_sub(2, Ordering::SeqCst);
 
 println!("Atomic Output: {}!", x);
 ```
-<!-- A trivial example, but gives a brief look at the atomic API in Rust. -->
+
+* The API is largely identical to C++20 atomics
+  * If interested in the `Ordering`, research "memory ordering"
+
+<!--
+A trivial example, but gives a brief look at the atomic API in Rust.
+
+Memory ordering has to do with memory ordering at the CPU cache level.
+-->
+
+
+---
+
+
+# Atomic Action
+
+Here is an example of incrementing an atomic counter from multiple threads!
+
+```rust
+static counter: AtomicUsize = AtomicUsize::new(0);
+
+fn main() {
+    // Spawn 100 threads that each increment the counter by 1.
+    let handles: Vec<JoinHandle<_>> = (0..100)
+        .map(|_| thread::spawn(|| counter.fetch_add(1, Ordering::Relaxed)))
+        .collect();
+
+    // Wait for all threads to finish.
+    handles.into_iter().for_each(|handle| { handle.join().unwrap(); });
+
+    assert_eq!(counter.load(Ordering::Relaxed), 100);
+}
+```
+
 
 ---
 
-# Atomics
 
-Rust provides atomic primitive types, like `AtomicBool`, `AtomicI8`, `AtomicIsize`, etc.
-* Provides a way to access values atomically from any thread
-  * Safe to share between threads implementing `Sync`
-* We won't cover it further in this course, but the API is largely 1:1 with the C++20 atomics
-  * If interested in pitfalls, read up on *memory ordering* in computer systems
+# **Message Passing**
 
 
 ---