Most bugs are reliable: give a program the same bad input twice, and it fails the same way twice. A race condition breaks that pattern entirely. It's a bug that depends on the precise, microsecond-level timing of two or more pieces of code running at once, which means the exact same program, run on the exact same input, can work perfectly a thousand times and then fail on the thousand-and-first — because that time, the timing happened to line up differently.
Two threads, one shared value, and a gap in between
The simplest race condition involves two threads of execution both reading and updating the same shared piece of data. Incrementing a counter, for instance, usually isn't a single atomic step at the hardware level — it's really three steps: read the current value, add one to it, write the new value back. If two threads both read the counter's value before either has written its update back, both threads add one to the same original number and write back the same result, and one of the two increments is silently lost. Whether that actually happens depends entirely on the precise timing of when each thread happens to read and write, which can vary run to run based on factors as small as which other tasks the operating system's scheduler decided to run first.
Why it survives testing and shows up in production
Race conditions are notoriously difficult to catch during development because most test runs, and most single-user testing sessions, simply don't create enough simultaneous, overlapping activity to trigger the specific interleaving that causes the failure. The bug can sit dormant through months of testing and then appear the moment real-world load — many users, or many parallel processes, all hitting the same shared resource at once — makes the unlucky timing far more likely to occur. This is also why race conditions are so hard to reproduce once reported: a developer trying to recreate the bug on a quiet machine, one step at a time, is often changing the very timing conditions that caused it, without realising that's exactly what makes it disappear.
What we're still unsure about
The mechanisms that prevent race conditions — locks, mutexes, atomic operations, and more structured approaches like message-passing between threads instead of shared memory — are well understood and widely used, so this isn't a mystery at the level of individual bugs. The harder, still-unsolved problem is at the scale of entire systems: as software increasingly runs across many parallel threads, processes, and distributed machines simultaneously, reliably proving a large, complex system is completely free of every possible bad interleaving is generally considered infeasible by exhaustive testing alone, which is why formal verification of concurrent systems remains a specialised and still-developing area of computer science rather than a routine, solved part of software engineering.
This sits inside Concurrency & Multithreading, one of eight topics in Programming, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.