Choosing a Concurrency Model

The models are usually compared on programmer experience. Compared on what they oblige the compiler to do, they separate much more sharply, and the obligations explain several things about the languages that adopted them.

If two threads may access the same location and at least one writes, the language must say what the second thread can observe. There is no way to leave this open: the hardware will answer it, differently on x86 and on AArch64, and the optimizer will answer it again by reordering. A language that does not define the answer has defined it as "whatever happens", which is unusable.

The consequence for this domain is that the memory model is a constraint on the optimizer, not a runtime feature. It is what forbids hoisting a load out of a loop when another thread may write to it, what forbids introducing a speculative write to a location the program never wrote, and what makes an acquire load a barrier that certain code motion may not cross. Those prohibitions are stated in the model and enforced in every pass — see [[semantics-drive-optimization]].

The invented-write prohibition is the one most worth knowing, because it is a real optimization that compilers used to perform and now may not. Speculatively storing to a variable inside a conditional — writing it unconditionally and then correcting — is legal in a single-threaded program and creates a data race in a concurrent one. C++11 and Java both had to forbid it explicitly, and that prohibition costs real optimization opportunities in code that has nothing to do with threads.

Async/await is the model whose implementation is most purely a compiler job. There is no new execution mechanism: the compiler rewrites each async function into a state machine, so that a function which suspends and resumes becomes an object holding its own local state plus a resume function containing a jump table over suspension points.

The consequence engineers actually hit is that everything live across an await moves into that state object, which is allocated on the heap. That is why an async function holding a large buffer across a suspension has a large state object, why async recursion needs indirection, and why the size of a future is a thing Rust programmers profile. It is also why holding a lock across an await is a hazard: the lock guard is now a field in a heap object that may be resumed on a different thread. See [[coroutine-lowering]].

The design decision inside the model is where suspension may occur and whether it is visible. Explicit await makes every suspension point syntactically apparent, so the reader knows where interleaving can happen and the compiler knows where to split the state machine. Implicit suspension — green threads that yield anywhere — removes the annotation burden and removes the reader's ability to see the points, and forces the runtime rather than the compiler to do the work. Go took the second path, which is why Go has no async keyword and does have a scheduler with stack-growth checks in function prologues.

Actors and CSP both answer the sharing question by restricting it, which converts a runtime problem into a checking problem — the same move ownership makes for memory, and it is not a coincidence that the languages doing one often do the other.

Erlang restricts absolutely: processes share nothing, messages are copied, and the compiler needs no aliasing analysis across processes because there is no aliasing across processes. The cost is copying, which is why the model works so well for the message sizes telecom switching involves and less well for large shared datasets. Swift's actors restrict by type: a value may cross an actor boundary only if it is Sendable, and the compiler checks it, producing compile-time errors where another language would have produced a data race.

Go's answer is the interesting middle. Channels are the recommended mechanism and shared memory is not forbidden, which means Go still needs a memory model and still has data races — and ships a race detector as a consequence. That is a coherent design choice rather than an oversight: it buys the ability to use shared memory where copying would be too expensive, and it pays by keeping the whole memory-model obligation that Erlang escaped.

The fifth model is the one where the compiler does the concurrency itself. Vectorizing a loop means executing several iterations at once in one instruction, and the entire difficulty is establishing that this preserves the program's meaning.

The preconditions are strict: no loop-carried dependence, no aliasing between the arrays written and the arrays read, a trip count the compiler can reason about, and — for floating-point reductions — permission to reassociate, which changes results and is therefore not granted by default. Most disappointing vectorization outcomes are one of these failing rather than the compiler being unwilling, and the missed-optimization remarks say which. See [[compiler-vectorization]] and [[alias-analysis]].

The language design decision is how much the programmer may assert. C has restrict, C++ has #pragma omp simd, Rust has iterator abstractions whose structure makes the independence apparent, and several array languages make the parallelism part of the semantics so no proof is needed at all. Each is a different answer to "who supplies the evidence", and the last one is the only answer that does not depend on an analysis succeeding.