Concurrency
Concurrency questions show up in three places:
- “Now make it thread safe”, at the end of a low level design round.
- “Implement a bounded blocking queue”, as a coding question.
- “What happens when two requests hit this at once”, in system design.
All three test the same small set of ideas. This track covers exactly that set, in six pages.
Start with threads and race conditions
Watch a race happen
Section titled “Watch a race happen”Concurrency bugs are hard to learn from text, because the code looks correct. Every line is right.
Only the order is wrong. So every page here hands you the scheduler. Each thread’s code sits in its
own lane. You choose which thread runs its next line, and you watch the bug happen. Then the page
fixes it in stages, and the same buttons prove the fix. Try it: two threads each run count++
once.
- tmp = count // load
- tmp = tmp + 1 // add
- count = tmp // store
ready
- tmp = count // load
- tmp = tmp + 1 // add
- count = tmp // store
ready
Two threads each run count++ once on a shared count of 0. You are the scheduler: press Step A or Step B to run one line of that thread. Try A, B, A, B, A, B.
Code on every page comes in Java, Python, C#, Go and TypeScript. It’s written the way each language’s engineers actually write it. Every broken version comes with a test that shows it failing. Every fix comes with the same test passing.
Your path
Section titled “Your path”Read the stages in order. Each tool exists to fix a failure that the page before it shows. The dots show the level: ●○○ Foundation, ●●○ Mid-level.
- 4 pages
Foundations
Threads, race conditions, locks, atomics, condition variables, semaphores and deadlock: the primitives every "make it thread safe" interview question is built on, with step-through demos.
The designbeyondcode digest, every Saturday
New deep dives, interview tips and site news in one short email. Free. Leave with one click.
We never sell or share your email. We only use it to send this newsletter.