Concurrency lets multiple computational activities make progress during overlapping execution. In server-side systems, it keeps request handling, shared state, and background jobs responsive as demand grows. section 1.1 section 5.1
BEAM implements concurrency with lightweight processes rather than heavyweight operating-system threads or processes. Processes share no memory, communicate through asynchronous messages, and are scheduled across available CPU cores. section 1.1.2 section 5.1
This design gives concurrent systems several practical properties:
- Isolate failures: a process crash normally leaves unrelated processes running and avoids corrupting their memory. section 8.2
- Scale execution: many processes can use available CPU cores without one lengthy task blocking every pending request. section 5.1
- Simplify synchronization: asynchronous messages replace shared-memory locks, mutexes, and semaphores. section 1.1.2
- Support distribution: process communication works similarly within one BEAM instance or across remote instances. section 1.1.2
Starting work concurrently
In Elixir, spawn(fn -> ... end) creates a BEAM process and returns its PID immediately. The caller can continue while the new process runs. A closure can carry a query definition into the new process; because processes share no memory, the data is copied. Running five two-second queries concurrently returns immediately and prints their results together rather than waiting roughly ten seconds sequentially. section 5.2.1
Production designs assign independent work to separate processes. An HTTP server can give each connection or request its own process, allowing simultaneous requests to proceed independently while requests targeting the same stateful process are handled one by one. section 11.3.4
Use the BEAM scheduling diagram to relate one operating-system process and a few scheduler threads to many concurrent BEAM processes. section 1.1.2
