Concurrency

Concurrency is what happens when the threads the operating-systems topic introduced stop merely taking turns on one core and start genuinely running at the exact same instant, and that single change opens up an entire category of bugs that simply cannot occur in code that only ever runs one instruction stream at a time. A race condition happens when two threads read and write the same shared memory without any coordination: if thread A reads a shared counter, thread B reads the same old value before A writes back, and then both write their own incremented result, one of the two increments is silently lost, even though each individual line of code looks perfectly correct in isolation — this is exactly the danger the operating-systems topic warned about when it said a bug in one thread can corrupt data another thread depends on. Synchronization is the fix: a lock (or mutex) lets only one thread touch a piece of shared data at a time, forcing every other thread that wants it to wait its turn, which restores correctness at the direct cost of some of concurrency's speed, the same tradeoff the databases topic's transactions already made for exactly the same reason. A deadlock is what happens when synchronization is used carelessly: if thread A holds lock 1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1, neither thread can ever proceed, because each is waiting on a resource the other refuses to release — a cycle of waiting with no way out, the same circular-dependency shape the algorithms topic's graph coverage would flag as a cycle if the "waits for" relationships were drawn as a graph. Multicore computing sidesteps the scheduler's time-slicing illusion from the operating-systems topic entirely by giving each thread its own real, physical CPU core from the computer-architecture topic, so multiple instruction streams genuinely execute at the same instant rather than just appearing to. A GPU takes that idea to an extreme: instead of a handful of powerful, independent cores, a GPU packs thousands of small, simple cores that all execute the exact same instruction on different pieces of data simultaneously, which is a poor fit for a program full of branching decisions but an extremely good fit for the kind of uniform, repeated math — like running the identical calculation across millions of pixels or matrix entries — that later topics in this series, especially artificial intelligence, depend on almost entirely. None of this complexity is optional once a program needs to use more than one core at once; it is the price of real parallel speed, and the next topic, distributed systems, raises the exact same race-condition and coordination problems introduced here, except stretched across many separate machines connected only by the network the computer-networks topic already covered.

More than one thread needs to run at once
genuinely simultaneous, not just time-sliced
Race condition
unsynchronized access to shared memory corrupts data
Synchronization
a lock serializes access, trading speed for correctness
Deadlock
threads wait on each other in a cycle, forever
Multicore / GPU
real parallel cores, or thousands of simple ones
Match the concurrency model to the hardware and the problem
distributed systems (next) stretches these same problems across many machines
A Race Condition Loses an Update Shared counter starts at 5, two threads each add 1 Without a lock thread A reads 5 thread B reads 5 (before A writes) A writes 6, B writes 6 final value: 6, not 7 one entire increment vanished With a lock thread A locks, reads 5, writes 6, unlocks thread B locks, reads 6, writes 7, unlocks final value: 7, correct slower — B had to wait for A neither thread did anything wrong on its own — the bug only exists because of how their steps interleaved this is exactly why race conditions are so hard to reproduce and debug
Deadlock, and the Two Ways to Go Parallel A cycle of waiting, and two very different hardware shapes Deadlock: a cycle of waiting Thread A Thread B each waits on the other's lock A holds lock 1, wants lock 2 B holds lock 2, wants lock 1 Multicore vs. GPU multicore: a few full, independent CPU cores GPU: thousands of simple cores, same instruction, different data ideal for the uniform math behind machine learning, later in this series a deadlock's "waits for" relationships, drawn as a graph, form a cycle — exactly the shape this series' algorithms topic already covered one common fix: every thread must always acquire locks in the same fixed order

Take concurrency further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app