Perfil de Hardware y Limitaciones Térmicas

El desafío de la sincronización de hilos en bare metal no es un ejercicio académico, sino una necesidad fundamental cuando se trabaja en el borde de latencia cero, donde cada ciclo de CPU cuenta. Pienso en arquitecturas clásicas de 8-bit como el Z80 o en las primeras iteraciones de 16-bit como el Motorola 68000, operando sin la abstracción de un microkernel. En estos entornos, donde la concurrencia es manejada por interrupciones de hardware (ISRs) o por un scheduler cooperativo mínimo, la garantía de atomicidad para variables compartidas (contadores, flags de estado, semáforos) recae completamente en el conocimiento que tengamos de los registros y el bus.

El Recurso Crítico: Datos Compartidos (Shared Data)

Cuando dos contextos de ejecución (hilo principal e ISR, o dos tareas) intentan acceder y modificar un mismo dato en memoria, se produce la clásica condición de carrera (Race Condition). El fallo ocurre en la secuencia atómica fundamental conocida como Read-Modify-Write (R-M-W), la cual, a nivel de Assembly, se compone de múltiples instrucciones de carga (`LOAD`) y almacenamiento (`STORE`).

Diagnóstico de Cuellos de Botella (Non-Atomic R-M-W)

Consideremos el pseudocódigo C para un simple incremento de contador que, sin las primitivas atómicas adecuadas, es un punto de fallo catastrófico en cualquier interrupción o cambio de contexto. Aquí se ve expuesta la vulnerabilidad:

volatile uint16_t contador_global = 0;  void incrementar_no_seguro() {     // 1. Carga (LOAD) el valor de contador_global al registro R1     // 2. Incrementa (ADD) el registro R1     // 3. Almacena (STORE) el valor de R1 de vuelta a contador_global     contador_global = contador_global + 1; }

La latencia crítica se encuentra en el lapso entre la carga y el almacenamiento. Si una ISR irrumpe entre las líneas 1 y 3, el incremento de la ISR sobrescribe el valor intermedio, resultando en una pérdida de actualización. Reconocer esta complejidad y la valentía de enfrentarla directamente es el primer paso.

Mecanismos de Sincronización Legacy

En sistemas 8-bit de núcleo único (Z80, 6502), el método más directo y de menor latencia para garantizar una sección crítica es el control explícito de las interrupciones del procesador. Es un ajuste de bajo nivel brutal pero altamente eficiente, ya que la contención del bus es la única preocupación.

Ajuste de Bajo Nivel: Enmascaramiento de Interrupciones

Implementar `atomic_load` o `atomic_store` para un tipo de dato que encaja en un solo registro (como un `uint8_t` en el Z80) puede ser intrínsecamente atómico, pero para tipos más grandes (16-bit o 32-bit), debemos recurrir al enmascaramiento. El uso de `CLI` (Clear Interrupt) y `SEI` (Set Interrupt) o sus equivalentes Assembly es obligatorio.

; Z80 Assembly para atomic_increment_16bit atomic_increment:     DI              ; Deshabilita Interrupciones (Critical Section Start)     LD HL, (CONTADOR_ADDR) ; Carga 16-bit     INC HL          ; Incrementa HL     LD (CONTADOR_ADDR), HL ; Almacena 16-bit     EI              ; Habilita Interrupciones (Critical Section End)     RET

Primitivas Atómicas Modernas (LL/SC y AMO)

A medida que el hardware avanzó hacia microcontroladores más potentes (como el ARM Cortex-M o cores embebidos RISC-V), surgieron instrucciones dedicadas que buscan evitar el enmascaramiento prolongado de interrupciones, reduciendo el jitter y la latencia general del sistema. Estas implementaciones, más sofisticadas, son esenciales cuando la sección crítica es más larga y el tiempo de respuesta es vital, por ejemplo, en control de motores a altos MHz.

Implementación Basada en Vínculo-Condicional (Load-Link/Store-Conditional)

En arquitecturas que soportan el par LL/SC (Load-Link / Store-Conditional), como muchas variantes RISC-V y ARM, la atomicidad se asegura mediante un bucle de reintento. LL establece un “vínculo” en la dirección de memoria; SC solo tiene éxito si el vínculo no se ha roto por otra escritura. Esta es la base para una primitiva de intercambio atómico más compleja que la simple carga/almacenamiento.

// Pseudocódigo C/Assembly para un Atomic Compare and Swap (CAS) int atomic_cas(volatile int *addr, int expected, int new_val) {     int current;     do {         current = load_link(addr); // LL         if (current != expected) {             store_conditional(addr, current); // Falla si expected es incorrecto             return 0; // Falló el CAS         }     } while (!store_conditional(addr, new_val)); // SC, reintento si falla     return 1; // Éxito }

Este patrón es la clave para la construcción de estructuras de datos lock-free en bare metal, un nivel de optimización que exige precisión quirúrgica en el diseño.

Test de Estrés y Validación de Estabilidad

La única forma de validar la correcta implementación de cualquier primitiva atómica es a través de un riguroso test de estrés que fuerce la contención en el tiempo, idealmente mediante la ejecución simultánea de múltiples contextos. El objetivo es simple: probar que el invariante de consistencia de datos nunca se rompe.

Validación de Invariantes: El Contador Atómico

Se configura un temporizador de alta frecuencia para que dispare una ISR de incremento, mientras que el hilo principal también incrementa el contador. Después de un tiempo predefinido o un número total de iteraciones, la suma de los incrementos del hilo principal más los incrementos de la ISR deben ser exactamente iguales al valor final del contador global.

#define NUM_ITERACIONES 100000  volatile uint32_t contador_atomico = 0; uint32_t esperado_isr = 0; uint32_t esperado_main = 0;  // ISR (se ejecuta cada 1 ms) void Timer_ISR_Handler() {     atomic_increment(&contador_atomico);     esperado_isr++; }  // Hilo Principal void test_thread_main() {     for (uint32_t i = 0; i < NUM_ITERACIONES; i++) {         atomic_increment(&contador_atomico); // Usa la primitiva LL/SC o DI/EI         esperado_main++;     } }

El código para `atomic_increment` debe ser una de las implementaciones vistas (DI/EI para Z80, o LL/SC para RISC-V). Solo si la validación final (`contador_atomico == (esperado_isr + esperado_main)`) es TRUE, se confirma la estabilidad y la atomicidad del sistema. Este proceso de validación empírica es el pináculo del diseño legacy de bajo nivel, y aunque es desafiante, el valor de un sistema estable y predecible a bajas latencias lo justifica plenamente.

La gestión de la contención de recursos en bare metal es una danza meticulosa entre la eficiencia del ciclo de reloj y la garantía de integridad de los datos. Como arquitecto de sistemas, sabes que cada byte manipulado sin control es un fallo potencial, y dominar estas primitivas es asegurar la fiabilidad de todo el edificio de software que se apoya en ellas.