Concurrent Programming

Concurrent programming writes code that correctly executes multiple tasks whose operations overlap in time. It addresses thread management, locks, atomic operations, message passing, and the patterns that prevent data races and deadlocks in shared-memory and distributed systems.

itSoftware engineering

Don't Panic — Concurrent Programming

Concurrent programming is the art of letting several pieces of work make progress during the same stretch of time without allowing them to turn the program into a haunted house of timing accidents. The tasks might take turns on one core, or run together on several. That second arrangement is parallelism. It is related, but it is not the same creature wearing a faster hat.

Before concurrency, the comforting default was sequential code: one operation finishes, then the next begins. Once a scheduler can interleave tasks, many orders become valid. A test that passes once has therefore proved that one order was polite on one occasion. It has not made a treaty with the other orders.

The first thing to remember is ownership: who may change a mutable value? The nicest answer is often one task, or no task because the value is immutable. The next best answer may be a message passed through a queue or channel. When state really must be shared, use synchronization to protect the whole invariant, not one nearby-looking line. A counter and an account transfer both have a talent for becoming more than one operation when nobody is watching.

The second is ordering. A lock, channel operation, thread start, join, or documented atomic operation can establish happens-before: the visibility and ordering promise another task may rely on. The calendar does not establish it. Neither does a log line that happened to arrive first, which is unfortunate because logs look so confident.

The third is lifetime. Tasks need an owner, a cancellation path, an error path, and a cleanup path. Bounded pools and queues add backpressure, which means overload becomes an explicit decision instead of a slow conversion of memory into anxiety. A caller that stops waiting while its work continues has not solved the problem; it has merely moved it somewhere less conversational.

Read the introduction for the full map of processes, threads, tasks, coroutines, and synchronization. Use the slides when the relationships need a diagram. Keep the cheatsheet nearby when choosing a primitive, tracing a liveness failure, or reviewing queue and shutdown rules. The quiz is where the terms stop nodding politely and start asking whether they have been understood.

Don't Panic — Concurrent Programming

Relevant careers