Add some speaker notes to concurrency chapter.

src/concurrency/channels.md

@@ -24,6 +24,9 @@ fn main() {
 
 <details>
 
-* `send()` and `recv()` return `Result`. If they return `Err`, it means the counterpart `Sender` or `Receiver` is dropped and the channel is closed.
+* `mpsc` stands for Multi-Producer, Single-Consumer. `Sender` and `SyncSender` implement `Clone` (so
+  you can make multiple producers) but `Receiver` does not.
+* `send()` and `recv()` return `Result`. If they return `Err`, it means the counterpart `Sender` or
+  `Receiver` is dropped and the channel is closed.
 
 </details>

src/concurrency/shared_state/arc.md

@@ -26,9 +26,13 @@ fn main() {
 
 <details>
 
-* `Arc` stands for "Atomic Reference Counted", a thread safe version of `Rc` that uses atomic operations.
-* `Arc::clone()` has the cost of atomic operations that get executed, but after that the use of the `T` is free.
-* Beware of reference cycles, Rust does not have a garbage collector to detect those.
+* `Arc` stands for "Atomic Reference Counted", a thread safe version of `Rc` that uses atomic
+  operations.
+* `Arc<T>` implements `Clone` whether or not `T` does. It implements `Send` and `Sync` iff `T`
+  implements them both.
+* `Arc::clone()` has the cost of atomic operations that get executed, but after that the use of the
+  `T` is free.
+* Beware of reference cycles, `Arc` does not use a garbage collector to detect them.
     * `std::sync::Weak` can help.
-    
+
 </details>

src/concurrency/shared_state/example.md

@@ -52,6 +52,7 @@ fn main() {
 Notable parts:
 
 * `v` is wrapped in both `Arc` and `Mutex`, because their concerns are orthogonal.
+  * Wrapping a `Mutex` in an `Arc` is a common pattern to share mutable state between threads.
 * `v: Arc<_>` needs to be cloned as `v2` before it can be moved into another thread. Note `move` was added to the lambda signature.
 * Blocks are introduced to narrow the scope of the `LockGuard` as much as possible.
 * We still need to acquire the `Mutex` to print our `Vec`.

src/concurrency/shared_state/mutex.md

@@ -31,9 +31,15 @@ implementation.
     
 * `Mutex` in Rust looks like a collection with just one element - the protected data.
     * It is not possible to forget to acquire the mutex before accessing the protected data.
+* You can get an `&mut T` from an `&Mutex<T>` by taking the lock. The `MutexGuard` ensures that the
+  `&mut T` doesn't outlive the lock being held.
+* `Mutex<T>` implements both `Send` and `Sync` iff `T` implements `Send`.
 * A read-write lock counterpart - `RwLock`.
 * Why does `lock()` return a `Result`? 
-    * If the thread that held the `Mutex` panicked, the `Mutex` becomes "poisoned" to signal that the data it protected might be in an inconsistent state. Calling `lock()` on a poisoned mutex fails with a [`PoisonError`]. You can call `into_inner()` on the error to recover the data regardless.
+    * If the thread that held the `Mutex` panicked, the `Mutex` becomes "poisoned" to signal that
+      the data it protected might be in an inconsistent state. Calling `lock()` on a poisoned mutex
+      fails with a [`PoisonError`]. You can call `into_inner()` on the error to recover the data
+      regardless.
 
 [`PoisonError`]: https://doc.rust-lang.org/std/sync/struct.PoisonError.html