How concurrency works.

When two threads touch the same data at once, the result depends on who wins the race — and the answer changes run to run. This lost-update bug is the root of most concurrency pain; once you can see it happen step by step, everything else in the course is a response to it.

A mutex is a turnstile: only one thread holds it at a time, so the critical section runs alone and the race is gone. Locks are the first real tool against shared-state bugs — and, as the next episode shows, the first source of brand-new ones.

Two threads each hold a lock the other needs, and neither will let go — the program freezes forever. See the four conditions that must all hold for deadlock, the dining-philosophers picture of it, and the simple lock-ordering rule that makes it impossible.

Threads share memory and are cheap to switch between — great for speed, dangerous for safety. Processes are isolated and robust but heavier. Which you choose decides how work is shared and how far a single crash can spread.

A single thread can juggle thousands of tasks by refusing to wait: fire off the I/O, move on to the next thing, and come back when the result is ready. The event loop is how one thread stays busy instead of blocked — the model behind Node, nginx and modern async runtimes.

Concurrency is dealing with many things at once; parallelism is doing many things at once. One barista alternating between orders versus five baristas working in parallel — the distinction that clears up most of the confusion and tells you where more cores actually help.

The finale flips the whole problem: if nothing is shared, nothing can race. Actors own their private state and communicate only by sending messages to each other's mailboxes — so locks and races simply can't happen. It's the model behind Erlang, Akka and a lot of resilient distributed systems.