Threads And Shared Memory

What Threads Provide

Threads are execution contexts that run within a process and can usually access the same memory. That makes sharing data cheap in one sense: a pointer, reference, object, or handle can be visible to multiple threads without serializing it through a message format.

The cost is coordination. If multiple threads can read and write the same state, the program needs rules for synchronization, visibility, mutation, ownership, and cleanup. Those rules may be enforced by the language, by runtime libraries, by locks and atomics, or by project discipline.

Common Patterns

Threaded programs often use mutexes, read-write locks, condition variables, atomics, thread pools, queues, barriers, and futures. Managed runtimes usually add scheduler, memory-model, and library behavior around OS threads. Native languages expose lower-level control but place more responsibility on the programmer.

Rust's ownership and type system restrict which values can cross thread boundaries and which values can be shared safely. Java and .NET provide mature thread and synchronization libraries with specified memory behavior. Python exposes threads, but CPython's global interpreter lock shapes CPU-bound parallelism differently than I/O-bound concurrency.

Watch Points

Shared-memory bugs are often timing-dependent. Data races, deadlocks, priority inversion, lock-order cycles, starvation, memory visibility errors, and accidental shared mutation may not appear in simple tests.

Use shared memory when it simplifies the design. Use message passing, task queues, actors, immutable values, or process boundaries when they make ownership and failure behavior clearer.

Related Concepts

Threaded code should be read with Data Races And Memory Models, Structured Concurrency, Actor Model And Message Passing, and Memory Safety.