Race conditions & synchronisation
P32.threads-processes.03 · Audience: guest, it-ml, language-pro · Prerequisites: Executors, futures & queues
The moment two threads touch the same variable, correctness is on the line. This
module reproduces a real data race, fixes it with a Lock, and then bounds
concurrency with a Semaphore — the two synchronisation primitives you reach for
most. All on the kernel, so the races are real.
ⓘ Concept: counter = counter + 1 is three steps, not one
balance = balance + amount reads the balance, computes the sum, then writes it back. If another thread reads the same starting balance in that gap, both write over each other and one update is lost. That gap is the data race.Why it matters — Data races are the hardest bugs to reproduce and the easiest to ship — understanding the read-modify-write gap is how you spot them in review.
Ask the mentor about this module
Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.
🎓 Practice ladder
2 graded rungs · ~25 minFix a losing bank account with a Lock, then cap concurrency with a
Semaphore — both on the kernel, where the races actually happen.
Rung 1 — fix a data race with a Lock (kernel)
Loading exercise…
Rung 2 — bound concurrency with a Semaphore (kernel)
Loading exercise…
Threads and processes give you parallelism; locks and semaphores keep it correct. The pillar's last track steps back to the question you should ask before writing any of this: which concurrency model does the job even need?