Condiciones de carrera reales: el contador

Ya sabes que el kernel es concurrente por defecto. Ahora vas a ver la carrera en carne viva: la operación más inocente de la programación, incrementar un contador, es en realidad tres pasos separados que dos núcleos pueden entrelazar hasta perder datos. Diseccionarla te da el ojo para reconocer el patrón en cualquier sitio, y el mapa de las herramientas que lo curan.

El incremento que miente

Este código parece trivial e intachable:

static int contador;   /* compartido, sin proteccion */

static void incrementa(void)
{
	contador++;    /* parece una sola operacion... no lo es */
}

El problema es que contador++ no es una instrucción. La CPU no sabe incrementar memoria de golpe: la lleva a un registro, la modifica, y la devuelve. Son tres pasos —un read-modify-write (RMW)— que el compilador emite más o menos así: mov para leer contador a un registro, add para modificar el registro, y mov para escribir el registro de vuelta a contador. Entre esos tres pasos hay dos ventanas por las que otro núcleo puede colarse.

Cómo se pierde un incremento

Supón que contador vale 5 y dos núcleos ejecutan incrementa() a la vez. El resultado correcto es 7. Mira este entrelazado:

• La CPU 0 lee contador a su registro: obtiene 5.
• La CPU 3 lee contador a su registro: obtiene 5 también (la CPU 0 aún no ha escrito).
• La CPU 0 modifica: su registro pasa a 6. La CPU 3 modifica: su registro pasa a 6.
• La CPU 0 escribe 6 en contador. La CPU 3 escribe 6 en contador.

Dos incrementos, y contador vale 6, no 7. Un incremento se perdió sin dejar rastro. Se llama lost update, y no hace falta SMP: en un solo núcleo, una interrupción o una preempción entre el leer y el escribir produce exactamente lo mismo. Este es un ejemplo típico entre proceso y softirq:

static u64 paquetes_rx;    /* estadistica compartida */

/* Contexto de proceso: lee la estadistica */
static u64 leer_stats(void)
{
	return paquetes_rx;
}

/* Softirq de red: la actualiza en cada paquete */
static void rx_handler(void)
{
	paquetes_rx++;         /* carrera con cualquier lector o con otro RX */
}

Fíjate en que rx_handler corre en softirq. Aunque la máquina tuviera un solo núcleo, esa softirq puede saltar encima de otro código a medio incrementar paquetes_rx; y un lector puede leer un valor a medio escribir, porque en 32 bits un u64 se escribe en dos mitades (el fenómeno del word tearing: ver la mitad nueva y la mitad vieja de un mismo número). La carrera no necesita SMP: le bastan dos contextos y un dato compartido en medio.

Por qué el bug es un fantasma

Lo que hace a las condiciones de carrera aterradoras no es el fallo, sino su no determinismo. El entrelazado maligno solo ocurre cuando los tiempos coinciden justo: el ancho de esa ventana es de nanosegundos. Tu código puede pasar un millón de ejecuciones en tu portátil y fallar una vez de cada mil millones en producción, bajo carga, en una máquina de 128 núcleos que no tienes. Es el clásico Heisenbug: al añadir un printk para depurarlo, cambias los tiempos y desaparece. No puedes depurar por reproducción lo que no se deja reproducir.

Por eso el kernel trae un cazador especializado: KCSAN (Kernel Concurrency Sanitizer). Con CONFIG_KCSAN, instrumenta los accesos a memoria y detecta data races aunque no lleguen a manifestarse, avisándote de qué dos accesos a qué dirección chocaron sin sincronización. Es a las carreras lo que KASAN es a la memoria: no esperes al crash, deja que la herramienta te lo señale antes. Su primo lockdep vigila lo complementario —el uso correcto de los locks, los órdenes de adquisición, los deadlocks potenciales— y juntos forman la red de seguridad con la que el kernel caza errores de concurrencia que ningún test reproduciría.

Si no puedes testear la corrección de este código, tienes que diseñarla. Y diseñarla es escoger, para cada dato compartido, una herramienta que niegue alguna de las tres condiciones de la carrera: volver el acceso indivisible, serializarlo, o eliminar la compartición. Ese es el arsenal.

El arsenal: cuatro herramientas y cuándo

El kernel no te da una solución única, sino un espectro, porque el coste y las restricciones importan. Estas son las cuatro grandes, de más ligera a más pesada:

La decisión se reduce a dos preguntas: ¿qué protejo? y ¿puedo dormir aquí?:

flowchart TD
D[Dato compartido] -->|un contador o unos flags| AT[atomic_t y bitops]
D -->|seccion corta que no duerme| SP[spinlock]
D -->|seccion larga o puede dormir| MU[mutex]
D -->|lectura mayoritaria escritura rara| RC[RCU]
style AT fill:#a6e3a1,color:#11111b
style SP fill:#89b4fa,color:#11111b
style MU fill:#f9e2af,color:#11111b
style RC fill:#cba6f7,color:#11111b

Existen más piezas, cada una afinada para un patrón concreto: rwlock_t admite muchos lectores o un solo escritor; seqlock_t deja leer sin bloquear y reintentar si un escritor pasó en medio (así se lee el reloj del sistema); los semáforos (struct semaphore) generalizan el mutex a N poseedores simultáneos. Todas son, en el fondo, combinaciones de las cuatro ideas anteriores, construidas —lo adivinaste— sobre operaciones atómicas.

Hay además un orden de coste que conviene grabar: un atómico es más barato que un spinlock sin contención, que es más barato que un mutex, que es más barato que dormir y despertar a un hilo. Pero el coste nunca es el primer criterio: la regla del contexto (¿puedo dormir aquí?) descarta opciones antes que el rendimiento. En este nivel 14 nos quedamos con la base de la pirámide, las operaciones atómicas, sobre la que todo lo demás se levanta. Las siguientes lecciones las abren en canal.