Barreras de compilador: barrier(), READ_ONCE y WRITE_ONCE

El reordenamiento (nivel 18.1) tiene dos culpables: el compilador y la CPU. Se domestican con herramientas distintas y en ese orden. Esta lección ataca al compilador. Su arma total es barrier(); su bisturí, READ_ONCE() y WRITE_ONCE(), que no cuestan ni una instrucción de CPU pero impiden que el optimizador destroce silenciosamente tus accesos compartidos.

barrier(): la valla mínima

La barrera de compilador más simple es una línea de ensamblador vacía con un clobber de memoria:

/* include/linux/compiler.h */
#define barrier() __asm__ __volatile__("" ::: "memory")

El clobber "memory" le dice a GCC o Clang: “asume que esta instrucción lee y escribe toda la memoria”. Efecto: no puede mover ningún acceso a memoria a través de la valla, ni conservar valores en registros de un lado al otro. No emite ni una sola instrucción; su coste en la CPU es cero. Es puramente una restricción al compilador, no al silicio.

El problema de barrier() es que es un instrumento romo: vala toda la memoria. Normalmente solo quieres proteger una variable compartida sin frenar la optimización del resto. Para eso existen READ_ONCE y WRITE_ONCE.

READ_ONCE y WRITE_ONCE: acceso quirúrgico

Viven en include/asm-generic/rwonce.h. Su esencia es un cast a volatile alrededor de un único acceso:

/* Versión simplificada; la real añade comprobación de tipo y tamaño */
#define READ_ONCE(x)        (*(const volatile typeof(x) *)&(x))
#define WRITE_ONCE(x, val)  (*(volatile typeof(x) *)&(x) = (val))

El volatile obliga al compilador a emitir exactamente una carga o escritura, del ancho exacto del tipo, en el punto exacto del código. Ni la duplica, ni la elimina, ni la fusiona, ni la parte. Fíjate en que el volatile califica el acceso, no la variable: esa es la diferencia clave con declarar la variable volatile, práctica prohibida en el kernel (Documentation/process/volatile-considered-harmful.rst).

Los cuatro pecados que evitan

El pecado más didáctico es el izado. Este código, correcto a la vista, cuelga la máquina:

/* MAL: el compilador iza la carga de ready a un registro */
while (ready == 0)
	;
usar(data);

Si ready valía 0 al entrar, el compilador la lee una vez, la deja en un registro y gira sobre él eternamente, aunque otro núcleo la ponga a 1. La corrección es un acceso fresco por iteración:

/* BIEN: una carga real de memoria en cada vuelta */
while (READ_ONCE(ready) == 0)
	cpu_relax();   /* pista al núcleo: es una espera activa */
usar(data);

El desgarro en concreto

El tearing no es teórico. En una arquitectura de 32 bits, escribir un u64 puede compilarse a dos escrituras de 32 bits, y un lector concurrente ve la mitad nueva y la mitad vieja. Incluso cuando el tipo cabe en una palabra, el compilador puede construir un valor grande por partes si el inmediato no cabe cómodo en la instrucción:

u64 estado;

estado = 0x00000000FFFFFFFFULL;              /* podría emitirse en dos mitades */
WRITE_ONCE(estado, 0x00000000FFFFFFFFULL);   /* garantiza una única escritura */

WRITE_ONCE garantiza atomicidad de copia única (single-copy atomicity) solo para escalares alineados de tamaño palabra o menor. Por eso READ_ONCE incorpora un compiletime_assert_rwonce_type: si le pasas un tipo mayor que una palabra, no compila, obligándote a repensar el diseño en vez de asumir una atomicidad que el hardware no ofrece.

barrier() frente a READ_ONCE: cuestión de ámbito

barrier() vala toda la memoria en un punto: sirve cuando lo que importa es el lugar de la valla y no una variable concreta (tras preempt_disable para fijar el planificador, o dentro de cpu_relax en una espera). READ_ONCE y WRITE_ONCE valan un solo acceso y dejan que el compilador optimice todo lo demás. La regla práctica: si otro hilo, otro núcleo o una interrupción pueden tocar la variable, cada acceso normal a ella es un bug latente, así que márcalo. Si el dato es privado del hilo, o está bajo un lock que ya aporta sus barreras (nivel 18.4), los accesos normales son correctos —aunque muchos mantenedores los marcan igual para que KCSAN no tenga que adivinar la intención.

Qué NO hacen, y KCSAN

READ_ONCE y WRITE_ONCE son solo para el compilador. En ARM la CPU todavía puede reordenar dos READ_ONCE entre sí; para ordenar entre núcleos necesitas las barreras smp_* (nivel 18.3) o la semántica acquire/release (nivel 18.4). Además exigen un escalar alineado de tamaño palabra o menor: sobre eso garantizan atomicidad; sobre tipos mayores, no.

Su segundo papel es documental. El Kernel Concurrency Sanitizer (KCSAN) trata los accesos normales a datos compartidos como candidatos a carrera de datos, y los accesos marcados (READ_ONCE, WRITE_ONCE, atómicos) como concurrencia intencionada. Bajo el LKMM, una carrera entre dos accesos normales es un bug por definición. La macro data_race() marca un acceso como carrera benigna deliberada y silencia a KCSAN de forma explícita y auditable.