/*:#localized(key: "Overview")
 # Concurrency Hazards

 You've moved work off the main thread with queues, waited for batches with
 dispatch groups, and rationed access with semaphores. Now the sharp edges. The
 moment two pieces of work touch the *same* value at the same time, a new class of
 bug appears: one that passes every test on your machine, ships, and then
 corrupts a number for one user in a thousand. Picture a ticket-counter bank:
 one shared balance, a row of tellers, everyone reaching for the drawer at once.
 This chapter is about what goes wrong when they don't coordinate, and the
 classic tools that make them safe.

 ---
 
 ## What you'll learn

 * What a **race condition** and a **data race** are, and how to spot one by
 reading code.
 * Why races are **nondeterministic** (right most runs, wrong some runs) and so
 brutally hard to reproduce.
 * Two classic fixes: funnel writes through a **serial queue**, or use a
 **concurrent queue with a `.barrier`** (the readers-writers pattern).
 * What a **deadlock** is, and the one-line mistake that freezes an app forever.
 * What **priority inversion** is, in plain terms.
 * A checklist for reasoning about thread safety without running anything.

 When you're ready, turn to the next page and we'll break a shared bank balance
 on purpose.

 page 1 of 9  |  [Next: The Data Race](@next)
 */
