Race Conditions

The view counter is wrong. Not wildly wrong — a hundred thousand page views recorded as ninety-nine thousand and something, and only on the busy days. The code that maintains it is three lines long: read the count, add one, write it back. You read those three lines a dozen times looking for the off-by-one; there isn’t one. The arithmetic is correct, and the counter is still losing numbers.

Picture a paper tally sheet pinned to the wall of a busy shop, and two clerks who each record a sale on it. The first glances at the sheet and sees 5. The second glances a moment later and also sees 5, because the first clerk is still reaching for the pen. Both cross out the 5 and write 6. Two sales happened, the sheet says one, and neither clerk did anything wrong: both glances landed before either pen did. That is a race condition — two things touching the same state, with the result decided by an order that nothing wrote down.

The lost update

The specific failure above has a name — the lost update — and it comes from a pattern that is everywhere: read a value, compute something from it, write the result back. Read-modify-write. Between the read and the write there is a window, and for however long that window is open, the value you are holding is a fact about the past.

If nobody else touches the state during the window, the code is correct. If somebody does, your write is based on a number that is no longer true, and it lands on top of their work as if it had never happened. Nothing throws, and there is no corrupted row, no stack trace, no log line — only a counter that is quietly a little too low, an inventory that says two left when there is one, or a balance a customer will notice before you do.

The scene below runs two workers against one counter twice. The first pass is the code as written; the second rewinds to the same starting value and runs the identical increments behind a lock.

Follow the first five steps and the bug stops being subtle: both reads land before either write, so both workers compute 6 from the same 5. The two badges sort the scene’s four writes by what each one did to the total — three counted a sale, one counted nothing, because it stored a number a stale read had already produced. They tally writes rather than showing the value of views, so they only climb. In the locked pass that interleaving cannot happen: B is unable to read until A releases, so it reads 6, and the counter reaches the 7 that two sales are supposed to produce.

Why they are so hard to catch

A race condition is not a rare kind of bug so much as a rare kind of timing.

The window is usually microseconds wide, so two operations have to land inside it to collide at all. At ten requests a minute you may never see it; at ten thousand it happens constantly.

Some rough arithmetic shows how steep that curve is. Say the window is 100 microseconds. At ten requests a minute, the chance that another request lands inside any one window is about 1 in 60,000, which comes to one lost update every four days or so. At ten thousand a minute, about 167 a second, the chance is 1 in 60, and you lose around 167 updates every minute. A thousand times the traffic brings a million times the losses, because each request is a thousand times likelier to be hit and there are a thousand times as many of them. The bug arrives with success, on the day you can least afford it.

It also disappears when you look at it. A debugger, a breakpoint, or a log line between the read and the write changes the timing of everything involved, and the interleaving you were hunting stops happening. That is common enough to have a name — a Heisenbug — and it is why these are found by reasoning about the code rather than by reproducing them.

Tests are no help by default: a test calls your function once and sees the correct answer. Catching this needs a test that runs both operations concurrently on purpose, which you only write once you already suspect the problem.

Here is the whole bug in one function, in a language with exactly one thread:

interface Counter {
  read(): Promise<number>;
  write(value: number): Promise<void>;
}

async function increment(counter: Counter): Promise<void> {
  const current = await counter.read();
  // The function suspends at that await. Whatever ran while it was away is
  // invisible here: `current` is a number from before the gap.
  await counter.write(current + 1);
}

async function twoSalesAtOnce(): Promise<number> {
  let views = 5;
  const counter: Counter = {
    read: async () => views,
    write: async (value) => {
      views = value;
    },
  };

  await Promise.all([increment(counter), increment(counter)]);
  return views; // 6, not 7: both reads returned 5, so both writes stored 6
}

JavaScript runs one statement at a time, and a run of statements cannot be interrupted partway through. But await ends a run: the function hands control back to the event loop and resumes later as a microtask, and everything that happened in between is invisible to it. That gap is the window, and it is open even here, where read resolves immediately and nothing goes over a network — await always suspends, even when the value is already there.

One honest note about that snippet: it loses the update every single time, which makes it a teaching example rather than a real race. Put a database behind Counter and the same code loses the update only sometimes, which is what makes the real thing so unpleasant.

let tail: Promise<unknown> = Promise.resolve();

function withLock<T>(work: () => Promise<T>): Promise<T> {
  const result = tail.then(work);
  tail = result.catch(() => undefined);
  return result;
}

async function lockedIncrement(counter: Counter): Promise<void> {
  await withLock(async () => {
    const current = await counter.read();
    await counter.write(current + 1);
  });
}

async function salesAtOnce(
  sales: number,
  inc: (counter: Counter) => Promise<void>,
): Promise<number> {
  let views = 5;
  const counter: Counter = {
    read: async () => views,
    write: async (value) => {
      views = value;
    },
  };
  await Promise.all(Array.from({ length: sales }, () => inc(counter)));
  return views;
}

console.log(await salesAtOnce(100, increment)); // 6: 99 sales lost
console.log(await salesAtOnce(100, lockedIncrement)); // 105: all 100 counted

Threads, and the network beyond them

The single-threaded version is the friendly case, because the suspension points are visible — every one of them is spelled await. With real threads, the interleaving can happen between machine instructions. count++ is not one operation; it is a load, an add, and a store, and another thread can be scheduled between any two of them. There is no keyword marking the window because the window is everywhere.

Shared memory is not required either. Two processes on two machines with no memory in common still race, because the shared state is the database row, the S3 object, or the file on disk. Check-then-act is the usual shape: two requests both check whether a username is taken, both find it free, and both insert it. The same applies to any two writes to one row, which is why a transaction alone does not save you — at the isolation levels most databases use by default, two transactions can both read 5 and both write 6 without either one being invalid.

Closing the window

There are four families of fix, in the order to reach for them.

Stop doing read-modify-write in your code. Hand the whole operation to whatever owns the state, so it becomes one indivisible step with no window to exploit: UPDATE pages SET views = views + 1 WHERE id = $1 in SQL, INCR in Redis, Atomics.add over a SharedArrayBuffer. It is the cheapest fix and the most often available, because most lost updates are arithmetic the store could have done itself.

When the work genuinely has to happen in your process, use mutual exclusion — a lock that admits one worker at a time to the stretch of code touching the shared state, which is the second pass in the scene above. It is general and it always works, and it buys you contention, reduced throughput, and a new failure mode — a deadlock — where two workers wait on each other forever.

Optimistic concurrency inverts the bet: rather than prevent the conflict, make the write conditional on what you read — UPDATE ... SET views = 6 WHERE views = 5, or a version column checked on every write — and retry when it matches no rows. Excellent when conflicts are rare, expensive when they are not, and only safe if the work is written to be repeated.

The last option is to stop sharing: give each worker its own counter and sum them when somebody asks. No shared state, no window, no lock — at the cost of a slower read and an answer that is a moment behind.