Concurrency without confusing it with parallelism

A process has an execution context and a virtual address space. Threads within a process share memory, while separate processes commonly exchange messages or use explicitly shared mappings. These are useful organizing models, not complete isolation guarantees. Runtime behavior varies: language implementations and native libraries can impose or release execution constraints. Check the actual runtime rather than assuming every thread always runs CPU-heavy work in parallel.

Asynchronous I/O allows a task waiting for an external event to yield so other work can progress. It is especially useful when requests spend time waiting on storage or networks. It does not make a CPU-bound calculation disappear. A long blocking calculation on an event loop can delay unrelated tasks. Separate the time spent computing, waiting, serializing, and coordinating before choosing threads, processes, asynchronous tasks, or a combination.

Suppose two workers read the same counter value, each adds one locally, and each writes the result. Both may write the same value, losing one increment. The program can look correct when executed slowly and fail under a different interleaving. A lock, an appropriate atomic operation, a transactional update, or single-owner message processing can address this particular problem, depending on the system's guarantees.

A bounded queue separates producers from consumers and makes overload visible. When producers outrun consumers, queued work accumulates until something changes. Backpressure asks upstream work to slow down; rejection prevents unlimited accumulation; cancellation avoids spending capacity on results nobody needs. Each policy affects users differently. Establish maximum queue age and memory consumption rather than treating an ever-growing queue as evidence that requests are safely handled.

A data-loading job might parallelize image decoding yet keep a single serial writer. Eventually the writer becomes the bottleneck. More decoders then increase queued memory rather than completed records per second. Separate-process workers may also serialize and copy inputs, and excessive parallelism can compete for memory bandwidth. The best worker count is a property of the workload and machine, not a universal number copied from a tutorial.

In the queue lab, increase arrival rate $\lambda$ while holding service rate $\mu$ fixed, then increase service. Its fluid backlog starts at four jobs and changes at rate $\lambda-\mu$, clipped at zero. This is not an operating-system scheduler or a proof of fairness. The separately labeled M/M/1 residence-time formula assumes Poisson arrivals, exponential service times, one server, and a stable rate balance. Use it to explain why extra waiting work does not automatically increase throughput, and identify which real measurements would distinguish a CPU bottleneck from an external dependency.