Concurrency structures applications whose parts can react independently and execute with overlapping activity. An actor-based simulator may give each part its own thread, while preserving concurrent behavior even in a single-threaded implementation. section 8.0
Treat concurrent design as an architectural problem because interactions among threads and shared mutable state create several failure modes:
- Race conditions can corrupt shared data or leave it invalid. section 9.1.1
- Deadlocks and livelocks can stop useful progress, while starvation can leave available threads unused. section 9.1.1
- Poor resource management can cause unclear lifetimes, leaks, overflow, and incorrect exception handling. section 9.1.1
Prefer structures that make concurrent behavior readable and maintainable. Composable software transactional memory reduces multithreading complexity, while IORefs, MVars, and STM TVars provide distinct state-handling choices. TVars are thread-safe and transactional; bare threads remain limited resources that require safe organization. section 9.1 section 9.3
Reactive simulator and application framework
A reactive simulator can assemble independent actor-like parts with concurrent state. A broader framework can place business logic in free monads, expose STM as an interface, and use STM at the implementation layer for safe concurrency. section 8.0 section 9.3
