Barreras de CPU: smp_mb, smp_rmb, smp_wmb y el emparejamiento

READ_ONCE (nivel 18.2) calla al compilador, pero no le dice nada al silicio. En un núcleo débil como ARM, el hardware sigue reordenando tus accesos a su gusto. Las barreras de CPU son instrucciones reales —fences— que restringen el motor fuera de orden y el store buffer. Y tienen una ley férrea: una barrera aislada no hace nada; solo sirve emparejada con otra en el núcleo contrario.

Del compilador al silicio

READ_ONCE y WRITE_ONCE fuerzan una carga y una escritura reales, pero no imponen orden entre ellas en la CPU. En x86, por el TSO, sueles librarte; en ARM, POWER o RISC-V, no. Una barrera de CPU es una instrucción máquina que le prohíbe al núcleo completar accesos en cierto orden relativo. Modelamos el reordenamiento como cuatro casos según qué va antes y qué después: Carga-Carga, Carga-Escritura, Escritura-Carga y Escritura-Escritura.

Las tres barreras y qué ordenan

Que smp_rmb y smp_wmb sean casi gratis en x86 pero fences reales en ARM es precisamente por qué debes escribirlos siempre: tu código tiene que ser correcto en el modelo débil, aunque en tu portátil x86 no cuesten nada.

Qué emite cada arquitectura

Para desmitificarlo, mira las definiciones reales. En x86 (arch/x86/include/asm/barrier.h), por el TSO, solo la barrera total cuesta una instrucción:

/* x86-64: smp_mb drena el store buffer; las otras dos son solo compilador */
#define __smp_mb()   asm volatile("lock; addl $0,-4(%%rsp)" ::: "memory", "cc")
#define __smp_rmb()  barrier()
#define __smp_wmb()  barrier()

En arm64 (arch/arm64/include/asm/barrier.h), débilmente ordenado, las tres emiten un dmb con distinto dominio de ordenación:

#define __smp_mb()   dmb(ish)     /* inner shareable, total */
#define __smp_rmb()  dmb(ishld)   /* solo carga-carga */
#define __smp_wmb()  dmb(ishst)   /* solo escritura-escritura */

El mismo código C portable se traduce a “nada” o a un fence según dónde compile. Escribes para el peor caso; el mejor lo regala el hardware.

smp_ frente a las bare: entre núcleos o hacia el hardware

El prefijo smp_ tiene un significado preciso. En una compilación monoprocesador (CONFIG_SMP=n) estas barreras degeneran a barrier() —solo compilador— porque un único núcleo siempre ve sus propios accesos en orden. En SMP emiten el fence real. Es decir, smp_mb sirve para ordenar memoria normal entre núcleos.

Las variantes desnudas mb(), rmb(), wmb() emiten el fence siempre, incluso en monoprocesador. Son para ordenar accesos a memoria de dispositivo (MMIO), donde el “otro observador” es un motor de DMA o el hardware. No uses smp_* para MMIO, ni las bare para coordinar núcleos: sería desperdicio en ambos sentidos.

El emparejamiento: una barrera nunca va sola

Una barrera solo restringe el orden en que un núcleo hace visibles u observa sus accesos. Aislada no significa nada: debe emparejarse con una barrera en el otro núcleo. La de escritura del productor se empareja con la de lectura del consumidor. Así se arregla el flag+datos del nivel 18.1:

/* CPU 0: productor */
data = 42;
smp_wmb();               /* empareja con smp_rmb de CPU 1  */
WRITE_ONCE(ready, 1);    /* la escritura de data queda antes de esta */

/* CPU 1: consumidor */
while (READ_ONCE(ready) == 0)
	cpu_relax();
smp_rmb();               /* empareja con smp_wmb de CPU 0  */
usar(data);              /* la carga de ready queda antes de esta */

Sin el smp_wmb del productor, ready = 1 podría llegar a memoria antes que data = 42. Sin el smp_rmb del consumidor, CPU 1 podría cargar data antes de confirmar ready. Cada fence es la mitad del contrato; hacen falta los dos.

flowchart TB
subgraph W [CPU0 productor]
  W1[escribe data 42] --> WB[smp_wmb] --> W2[escribe ready 1]
end
subgraph R [CPU1 consumidor]
  R1[lee ready 1] --> RB[smp_rmb] --> R2[lee data 42]
end
WB -. se emparejan .- RB
W2 == ready visible ==> R1

Barreras alrededor de atómicos

Muchas operaciones atómicas de lectura-modificación-escritura (atomic_inc, atomic_dec) no ordenan memoria por sí solas en todas las arquitecturas: son relajadas salvo que uses una variante con sufijo. Para añadir orden a su alrededor sin pagar un smp_mb entero existen parejas específicas:

smp_mb__before_atomic();   /* ordena los accesos previos frente al atómico */
atomic_inc(&contador);
smp_mb__after_atomic();    /* ordena el atómico frente a los accesos posteriores */

En x86 suelen ser gratis (el lock del atómico ya es barrera total); en ARM emiten justo el fence necesario. También existe smp_store_mb(var, val), una escritura seguida de barrera total, habitual al soltar estado y necesitar orden Escritura-Carga después.

Dependencias de dirección: orden gratis

En casi todas las arquitecturas (tras la retirada de Alpha) una dependencia de dirección aporta orden sin barrera: si cargas un puntero y luego lo desreferencias, el desreferenciado no puede adelantarse a la carga del puntero, porque el núcleo necesita la dirección para leer. Sobre esa garantía se construye rcu_dereference (nivel 18.4), y por eso los lectores de RCU (nivel 17) no necesitan smp_rmb. Alpha fue la única arquitectura que rompía esto y exigía smp_read_barrier_depends; ese caso se plegó dentro de READ_ONCE y quedó obsoleto.