Thread-per-Core es un patrón de diseño y modelo de ejecución en el que un único hilo de ejecución (thread) está permanentemente anclado a un núcleo de CPU físico o lógico (hardware thread). A diferencia de los modelos tradicionales de sistemas operativos que programan múltiples hilos en un mismo núcleo y realizan cambios de contexto frecuentes, Thread-per-Core busca eliminar esta sobrecarga. Cada núcleo se dedica exclusivamente a su hilo asignado, procesando su carga de trabajo sin interrupciones externas por parte del scheduler del sistema operativo. Esto implica que la aplicación es responsable de su propia concurrencia y multiplexación de tareas dentro de ese hilo, a menudo utilizando un modelo de programación asíncrono o un event loop.
Este patrón es prevalente en sistemas de alto rendimiento y baja latencia donde la predictibilidad y la minimización de la sobrecarga son críticas. Ejemplos concretos incluyen frameworks de red de alto rendimiento como DPDK (Data Plane Development Kit), que utiliza Thread-per-Core para procesar paquetes de red directamente desde la NIC, evitando el kernel y sus interrupciones. Bases de datos in-memory y sistemas de procesamiento de transacciones de baja latencia, como algunos diseños de HFT (High-Frequency Trading), también adoptan este modelo para garantizar tiempos de respuesta consistentes. Otro ejemplo son los runtimes de lenguajes o frameworks que implementan sus propios schedulers de 'green threads' o 'fibers' sobre un modelo Thread-per-Core, como ScyllaDB (una reimplementación de Cassandra en C++ que usa el framework Seastar).
Para un Arquitecto, Thread-per-Core es una decisión de diseño estratégica con importantes trade-offs. Ofrece una latencia extremadamente baja y un rendimiento predecible al eliminar el overhead del scheduler del sistema operativo, las contenciones de locks y los 'cache misses' debido a cambios de contexto. Sin embargo, introduce una complejidad significativa en el diseño de la aplicación, ya que la concurrencia y la gestión de tareas deben ser manejadas explícitamente por el desarrollador (por ejemplo, con event loops o 'futures'). La escalabilidad horizontal es más sencilla, pero la utilización de recursos puede ser ineficiente si los hilos no tienen suficiente trabajo constante para mantener los núcleos ocupados. Es ideal para cargas de trabajo 'CPU-bound' o 'I/O-bound' intensivas que pueden ser particionadas y ejecutadas de forma aislada, pero menos adecuado para aplicaciones de propósito general con patrones de carga de trabajo impredecibles o que dependen fuertemente de servicios del sistema operativo.