Thread-per-core assigns one continuously running thread to each CPU core, pins each thread to its core, and handles concurrency within the application rather than through routine operating-system scheduling. section 7.5.1 section 10.4.1
Each thread processes tasks from a work queue without yielding to another thread. This keeps core-local caches warm and avoids context-switching latency and its unpredictable spikes, but it requires every operation to be non-blocking. section 10.4.1 section 7.5.1
Use the design when its constraints match the workload:
- Combine dedicated threads with application-level concurrency such as coroutines or futures and promises. section 7.5.1
- Prefer it for event-driven architectures and asynchronous I/O workloads where blocking would otherwise stall a core. section 10.4.1
- Avoid it for traditional blocking I/O patterns, where a thread pool remains necessary. section 10.4.1
- Partition data for suitable CPU access when multicore memory topology makes DRAM latency non-uniform. section 3.1
Asynchronous runtime
A runtime modeled on Seastar assigns one thread to each core and feeds each thread tasks from a work queue, using non-blocking operations to sustain low-latency processing. section 10.4.1
