Message Passing: std.concurrency
D's default and recommended concurrency model, built into std.concurrency, is share-nothing message passing modeled on Erlang: spawn(&worker, args) starts a new logical thread of execution (a Tid, or thread ID) that has no default access to the caller's mutable state, and communication happens exclusively by send(tid, message) and receive((Type msg) { ... }) pattern-matching on message type. Because the compiler enforces that only immutable or Tid-safe (implicitly unique/shared) data can cross thread boundaries via send/receive, D catches an entire class of accidental data races at compile time that would otherwise require careful discipline in a language like C++ using raw threads and mutexes.
Cricket analogy: It's like a cricket board's central control room communicating with each stadium's PA announcer only via official written match-update slips passed through a runner — no announcer can directly rewrite another stadium's scoreboard, they can only react to the specific messages they receive.
Shared Memory: shared, synchronized, and immutable
When message passing isn't the right fit, D exposes traditional shared-memory concurrency through the shared type qualifier, which marks a variable as accessible from multiple threads and forces the compiler to reject implicit unprotected reads/writes that aren't atomic or explicitly synchronized — you typically pair shared with core.sync.mutex.Mutex or with a synchronized class/method, where D generates the lock-acquire/release automatically around the method body. Crucially, immutable data (deeply, transitively immutable, guaranteed by the type system) can be freely shared across threads with no locking at all because the compiler proves it can never be mutated, which is why converting read-only shared configuration to immutable is a common D idiom to eliminate synchronization overhead entirely.
Cricket analogy: It's like a single team physio's treatment table that only one player can use at a time, requiring a sign-up sheet to avoid two players colliding (shared + Mutex), whereas the printed fixture list on the dressing-room wall can be read by every player simultaneously with zero coordination needed (immutable).
import core.sync.mutex : Mutex;
import core.thread : Thread;
synchronized class Counter
{
private int count;
void increment() { count++; } // lock auto-acquired/released
int get() const { return count; }
}
void main()
{
auto counter = new shared Counter();
auto workers = new Thread[4];
foreach (i, ref t; workers)
t = new Thread({ foreach (_; 0 .. 1000) counter.increment(); }).start();
foreach (t; workers) t.join();
assert(counter.get() == 4000);
}A plain (non-shared, non-immutable) variable accessed from multiple threads without synchronization is a compile-time type error in idiomatic D once you try to pass it across a thread boundary that requires shared — but casting away shared with cast(int) to silence the compiler reintroduces real data races, so treat such casts as a major red flag in code review.
Data Parallelism with std.parallelism
For CPU-bound, data-parallel workloads — as opposed to message-passing coordination — std.parallelism provides a higher-level taskPool that can parallelize a foreach loop over a range with a single .parallel property call, automatically partitioning work across worker threads sized to the host's core count, and taskPool.reduce!(fn)(range) for parallel map-reduce style aggregation. This is the idiomatic D equivalent of OpenMP's #pragma omp parallel for: you keep ordinary sequential-looking code and opt into parallel execution declaratively, while D's type system still requires that any shared mutable state touched inside the parallel body be properly shared or protected, preventing the classic silent-race-condition bugs common in careless C/C++ parallel loops.
Cricket analogy: It's like a groundstaff team assigning each of four mowers to a separate section of the outfield simultaneously rather than one mower covering the whole ground sequentially, though using too many mowers on a tiny practice net wastes more time coordinating than it saves.
import std.parallelism : parallel, taskPool;
import std.array : array;
double[] computeSquares(double[] input)
{
auto output = new double[input.length];
foreach (i, x; input.parallel)
output[i] = x * x; // each iteration runs on a worker thread
return output;
}std.parallelism's taskPool defaults to totalCPUs - 1 worker threads, but you can size it explicitly with new TaskPool(n) — always benchmark, since parallelizing a loop with too little work per iteration can be slower than sequential execution due to thread-coordination overhead.
- std.concurrency implements Erlang-style message passing: spawn(), send(), and receive() with no shared mutable state by default.
- The compiler enforces that only immutable or otherwise thread-safe data can cross thread boundaries via std.concurrency messages.
- The shared type qualifier marks data as multi-thread-accessible and blocks implicit unsynchronized access at compile time.
- synchronized classes/methods have the compiler automatically generate mutex lock/unlock around the method body.
- Deeply immutable data can be freely shared across threads with zero locking overhead, since it can never mutate.
- std.parallelism's .parallel range adaptor and taskPool.reduce enable declarative data parallelism similar to OpenMP.
- Casting away shared to silence the compiler reintroduces real data races and should be treated as a serious code-review red flag.
Practice what you learned
1. What is the default concurrency model recommended in D via std.concurrency?
2. Why can immutable data be shared across D threads with no locking?
3. What does declaring a class as 'synchronized' in D do?
4. What does the .parallel property do when applied to a range in a foreach loop via std.parallelism?
5. Why is casting away the shared qualifier considered dangerous?
Was this page helpful?
You May Also Like
Error Handling in D
Learn D's split between recoverable Exceptions and unrecoverable Errors, the scope(exit)/failure/success guards, and std.exception helpers like enforce and nothrow.
Ranges in D
Learn how D's range interface unifies iteration over arrays, containers, and lazy sequences, and how to compose algorithms with std.range and std.algorithm.
Compile-Time Function Execution (CTFE)
Understand how D executes ordinary functions at compile time to compute constants, validate data, and generate code before the program ever runs.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics