Concurrency means structuring a program so many tasks can 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.

The practical call: 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 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 hides because the bad interleaving is rare. Scheduling is nondeterministic and shifts with load, timing, and the machine. A test can pass thousands of times and still fail in production.

That nondeterminism is exactly 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. None of that is free.

The biggest cost is the stack. A default thread stack reserves from one 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 sounds tiny, but it dwarfs the microsecond-scale work you often hand it. 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 pain is not the running; it is the constant birth and death under load.

A mutex (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. The lost-update problem vanishes because no two threads read-modify-write the same value at once.

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

The cost is real. While one thread holds the lock, others block and do nothing. Hold it too long and you turn parallel work back into sequential work.

So a mutex trades some throughput for correctness. Lock only the shared state, keep the region small, and always release even when errors happen.

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

All four Coffman conditions must hold at once:

• Mutual exclusion: a resource can be held by only one thread.
• 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.

This matters because deadlocks rarely show in testing and freeze real services silently. Knowing the four conditions gives you concrete levers to design them out.

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

Reusing threads dodges the birth-and-death cost of spawning one per task. That setup, tens of microseconds each, adds up fast under load. Warm threads skip it entirely.

A pool also caps concurrency. With a bounded worker count, you never accidentally launch ten thousand threads and exhaust memory or thrash the scheduler. The queue absorbs bursts instead.

The tradeoff is tuning. Too few workers and tasks wait in the queue; too many and they fight over cores. Size the pool to the workload: roughly core count for compute, higher for I/O-bound work.

The JavaScript event loop runs one piece of code at a time on a single thread. It repeatedly takes the next callback from a queue, runs it to completion, then grabs the next. Nothing interrupts a running function.

Async work does not run on that thread. 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 is placed on a queue. The loop runs it only after the current work returns and the stack is empty. That is why order can surprise you.

This model avoids locks entirely, 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.