Lectures

We break down why races are possible even with coroutines: concurrent execution on Dispatchers . Default, issues with shared mutable state, compound operations like counter ++, and the check-then-act trap. We learn to formulate invariants (for example, tickets >= 0) and identify critical sections, and we also build a training sandbox TicketOffice for the next lectures.

We break down why coroutines need Mutex and how to define a critical section correctly with withLock: protect not a “variable” but an invariant, hold the lock for the shortest possible time, avoid the anti-pattern of runBlocking inside helpers, and build a thread-safe expense ledger ( ExpenseLedger) with safe reads via snapshot().

We break down atomic types from java.util.concurrent.atomic on Kotlin/JVM: how AtomicInteger makes increments safe without Mutex, why the get() → set() combo does not “glue together” into atomicity, how CAS works via compareAndSet, and why AtomicReference<T> is almost always worth using with immutable state (via copy()). At the end: a tool-selection map and common mistakes.

We break down the confinement approach in coroutines: how to eliminate races “by construction,” when mutable state belongs to a single owner and everyone else communicates with it via messages. In practice, we build an actor based on Channel: a minimal counter without Mutex, a typed command protocol via sealed class, multiple senders, request/response via SendChannel, rules for correct shutdown ( Stop vs close()), and a set of common mistakes.

We break down three “anti-progress” patterns in concurrent Kotlin-coroutines code: deadlock (mutual waiting), livelock (busy activity with no outcome), and starvation (tasks getting starved). Using examples with Mutex, withLock, and tryLock(), we show how mistakes grow out of lock-acquisition order, overly long critical sections, and “polite” retries—and then we fix them with rules: a single order by id, a short withLock, backoff, and (when possible) a switch to confinement/ actor design.