Concurrency & Multithreading.

Concurrency means structuring a program so many tasks make progress in overlapping time windows. Parallelism means literally running tasks at the same instant on separate cores. A single-core machine can be concurrent but never truly parallel.

A concurrent design interleaves tasks by pausing one and resuming another. This helps when tasks wait on input, network, or disk. Parallelism helps when you have real compute to split across cores.

You can have either without the other. A single-threaded event loop is concurrent, not parallel. A numeric loop spread across eight cores is parallel. Most real systems mix both.

Reach for concurrency when tasks mostly wait, and parallelism when tasks mostly compute. Confusing them leads to adding cores that never help, or adding threads to work that has no waiting to overlap.

A race condition is a bug where the outcome depends on the timing of two or more threads. When they touch shared data and the order is not controlled, results vary from run to run.

Take two threads each reading a counter, adding one, and writing back. If both read the same value before either writes, one increment is lost. The count is wrong only for certain interleavings.

It is hard to reproduce because the bad interleaving is rare. Scheduling is nondeterministic and shifts with load, timing, and the machine. That is why rerunning does not debug a race. You fix it by reasoning about shared state and adding synchronization, not by hunting for the one crash.

Creating a thread is expensive because each one needs its own stack and kernel bookkeeping. The operating system allocates memory, registers the thread with its scheduler, and sets up later cleanup.

The biggest cost is the stack. A default thread stack reserves from half a megabyte to eight, depending on the platform. Spawn thousands and you burn gigabytes of address space on stacks alone.

In wall-clock terms, creating and destroying a thread takes tens of microseconds. That dwarfs the microsecond-scale work you often hand it, so per-request spawning spends more on setup than on the task.

This is why servers reuse threads from a pool instead of making one per request. The cost is in the constant creation and teardown under load.

A mutex, short for mutual exclusion lock, is a gate that only one thread can hold at a time. A thread locks it before touching shared data and unlocks it when done. Others must wait.

By forcing threads to take turns, a mutex serializes access to a critical section. That is how it stops a race condition. No two threads read, modify, and write the same value at once, so the lost-update problem vanishes.

mutex.lock();
counter = counter + 1; // no other thread runs this line now
mutex.unlock();

A mutex trades some throughput for correctness. While one thread holds it, the others block and do nothing. Lock only the shared state, and always release the mutex, even when errors happen.

A deadlock is a standstill where two or more threads each wait for a resource another holds. None can proceed, so all stay stuck forever. The program hangs without crashing.

All four Coffman conditions must hold at once:

• Mutual exclusion: only one thread can hold a resource.
• Hold and wait: a thread keeps what it has while waiting for more.
• No preemption: you cannot forcibly take a resource away.
• Circular wait: a cycle of threads each waits on the next.

Break any one and deadlock cannot form. The most common fix targets circular wait by making every thread acquire locks in the same order.

A thread pool is a fixed set of worker threads that pull tasks from a shared queue. You submit work, and an idle worker picks it up, runs it, then loops back for more. The workers live for the life of the program.

Reusing threads skips the cost of creating and destroying one per task. That setup, tens of microseconds each, adds up fast under load.

A pool also caps concurrency. You never launch ten thousand threads and exhaust memory or thrash the scheduler, because the queue absorbs bursts instead.

The tradeoff is sizing. Too few workers leave tasks waiting, and too many fight over cores. Use roughly the core count for compute, and more for I/O-bound work.

The JavaScript event loop lets the system do the waiting for async work, then runs each callback on its one thread. It takes the next callback from a queue, runs it to completion, then grabs the next.

When you start a timer, network request, or file read, the runtime hands it to the system or a background pool. Your thread moves on right away.

When the operation finishes, its callback joins a queue. The loop runs it only after the current work returns and the stack is empty. So a ready callback still waits behind the running code.

This model avoids locks, since only one callback runs at a time. The catch is that any slow synchronous function freezes everything. One blocking loop stalls every pending timer, request, and click.