CONCEPT Cited by 1 source

Thread-per-core scheduling

Definition

In a thread-per-core runtime (e.g., Seastar), each CPU core owns its data and communicates only via message passing. Shared mutable state is forbidden by design. This constraint shapes every coordination algorithm: any solution that needs to synchronize shards — deciding who uploads what and when — must minimize cross-shard communication.

The constraint means classical centralized-scheduler designs (one coordinator polling all shards, collecting work, dispatching) become bottlenecks not because of compute but because of synchronization overhead (Source: sources/2026-06-18-redpanda-adaptive-write-request-scheduling).

Design implications

1. No global locks: Solutions must rely on atomic counters, local state machines, or message-passing rather than shared mutexes.
2. Local decisions preferred: An algorithm that only needs to inspect its own state and one neighbor's state (like the buddy allocator) fits naturally.
3. Per-shard data ownership: Each shard accumulates its own write requests; any batching across shards requires explicit collection phases.

Seen in

• systems/redpanda — built entirely on Seastar's thread-per-core model
• systems/redpanda-cloud-topics — write scheduler designed around this constraint