Concurrency & the Hardware

Concurrency and the Hardware · Open board

Two cores reaching for the same shared counter at once, and the three fixes for it: a lock, an atomic add, and giving each core its own copy.

Before you start. Processes, Threads & the Kernel gave you a thread, one flow of instructions moving through a program, and a process, the box that can hold several threads sharing the same memory. This lesson is about what happens the instant two of those threads reach into that shared memory at once, using the CPU’s one-instruction-at-a-time steps from The CPU (fetch-decode-execute, the ISA, assembly).

The idea in 30 seconds

Concurrency is how a job is structured so many tasks can be in flight together; parallelism is more than one core working at the same instant, and you cannot have parallelism with only one core.
counter = counter + 1 is really three steps: read, add, write. Two cores can interleave between those steps and silently lose an update. That is a race condition, the bug that overdosed real patients on a hospital machine in the 1980s.
A lock stops the race by letting one core touch the shared value at a time, correctly, at the cost of every other core waiting its turn.
An atomic add fixes the same race in one uninterruptible hardware step with no waiting line, but every core still pays to catch up with whoever wrote last.
Not sharing at all beats both fixes: give each core its own counter and add the totals at the end.
More cores never buy proportional speed forever. Whatever fraction of a job cannot be split sets a hard ceiling on how much any number of cores can help.

Read the story · Skip to the numbers