/*:#localized(key: "ReasoningAboutThreadSafety")
 # How to reason about thread safety

 A checklist you can run in your head, before you ever hit **Run**:

 * **Find the shared mutable state.**  
 Any `var` (a property, a captured variable, a collection) reachable from
 more than one task at once. No shared *and* mutable state, no data race.
 (Immutable, or unshared, is automatically safe.)
 * **Ask who writes.**  
 If everyone only reads, you're fine. The danger begins with the first 
 concurrent writer.
 * **Look for the read-then-write gap.**  
 `x += 1`, "check then act", "read a dictionary then update it". Anything 
 that reads a value and later writes based on it has a gap another task can 
 corrupt.
 * **Name the coordination.**  
 For each piece of shared mutable state, point to the *one* thing serializing 
 access: a serial queue, a barrier, a semaphore, (later) an actor. If you 
 can't name it, assume it's racy.
 * **Prefer to hide it.**  
 Wrap the state and its coordination in a type (like `Account` before) so 
 callers can't touch the raw value or forget to lock.

 Reasoning beats running here, because running can't be trusted: a race that's
 invisible on your editor may be a crash on someone's older iPhone.

 [Previous](@previous)  |  page 8 of 9  |  [Next: Wrapping Up](@next)
 */
