Quelle  memory-barriers.txt   Sprache: Text

NOTE:
This is a version of Documentation/memory-barriers.txt translated into
Spanish by Carlos Bilbao <carlos.bilbao.osdev@gmail.com>. If you find any
difference between this document and the original file or a problem with
the translation, please contact the maintainer of this file. Please also
note that the purpose of this file is to be easier to read for non English
(read: Spanish) speakers and is not intended as a fork. So if you have any
comments or updates for this file please update the original English file
first. The English version is definitive, and readers should look there if
they have any doubt.

    ======================================
    BARRERAS DE MEMORIA EN EL KERNEL LINUX
    ======================================

Documento original: David Howells <dhowells@redhat.com>
    Paul E. McKenney <paulmck@linux.ibm.com>
    Will Deacon <will.deacon@arm.com>
    Peter Zijlstra <peterz@infradead.org>

Traducido por: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
traducción, la única referencia válida es la documentación oficial en
inglés.

===========
ADVERTENCIA
===========

Este documento no es una especificación; es intencionalmente (por motivos
de brevedad) y sin querer (por ser humanos) incompleta. Este documento
pretende ser una guía para usar las diversas barreras de memoria
proporcionadas por Linux, pero ante cualquier duda (y hay muchas) por favor
pregunte. Algunas dudas pueden ser resueltas refiriéndose al modelo de
consistencia de memoria formal y documentación en tools/memory-model/. Sin
embargo, incluso este modelo debe ser visto como la opinión colectiva de
sus maintainers en lugar de que como un oráculo infalible.

De nuevo, este documento no es una especificación de lo que Linux espera
del hardware.

El propósito de este documento es doble:

 (1) especificar la funcionalidad mínima en la que se puede confiar para
     cualquier barrera en concreto, y

 (2) proporcionar una guía sobre cómo utilizar las barreras disponibles.

Tenga en cuenta que una arquitectura puede proporcionar más que el
requisito mínimo para cualquier barrera en particular, pero si la
arquitectura proporciona menos de eso, dicha arquitectura es incorrecta.

Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
para alguna arquitectura porque por la forma en que funcione dicha
arquitectura, la barrera explícita resulte innecesaria en ese caso.

==========
CONTENIDOS
==========

 (*) Modelo abstracto de acceso a memoria.

     - Operaciones del dispositivo.
     - Garantías.

 (*) ¿Qué son las barreras de memoria?

     - Variedades de barrera de memoria.
     - ¿Qué no se puede asumir sobre las barreras de memoria?
     - Barreras de dirección-dependencia (históricas).
     - Dependencias de control.
     - Emparejamiento de barreras smp.
     - Ejemplos de secuencias de barrera de memoria.
     - Barreras de memoria de lectura frente a especulación de carga.
     - Atomicidad multicopia.

 (*) Barreras explícitas del kernel.

     - Barrera del compilador.
     - Barreras de memoria de la CPU.

 (*) Barreras de memoria implícitas del kernel.

     - Funciones de adquisición de cerrojo.
     - Funciones de desactivación de interrupciones.
     - Funciones de dormir y despertar.
     - Funciones varias.

 (*) Efectos de barrera adquiriendo intra-CPU.

     - Adquisición vs accesos a memoria.

 (*) ¿Dónde se necesitan barreras de memoria?

     - Interacción entre procesadores.
     - Operaciones atómicas.
     - Acceso a dispositivos.
     - Interrupciones.

 (*) Efectos de barrera de E/S del kernel.

 (*) Modelo de orden mínimo de ejecución asumido.

 (*) Efectos de la memoria caché de la CPU.

     - Coherencia de caché.
     - Coherencia de caché frente a DMA.
     - Coherencia de caché frente a MMIO.

 (*) Cosas que hacen las CPU.

     - Y luego está el Alfa.
     - Guests de máquinas virtuales.

 (*) Ejemplos de usos.

     - Buffers circulares.

 (*) Referencias.


====================================
MODELO ABSTRACTO DE ACCESO A MEMORIA
====================================

Considere el siguiente modelo abstracto del sistema:

              :                :
              :                :
              :                :
  +-------+   :   +--------+   :   +-------+
  |       |   :   |        |   :   |       |
  |       |   :   |        |   :   |       |
  | CPU 1 |<----->| Memoria|<----->| CPU 2 |
  |       |   :   |        |   :   |       |
  |       |   :   |        |   :   |       |
  +-------+   :   +--------+   :   +-------+
      ^       :       ^        :       ^
      |       :       |        :       |
      |       :       |        :       |
      |       :       v        :       |
      |       :   +--------+   :       |
      |       :   |        |   :       |
      |       :   | Disposi|   :       |
      +---------->| tivo   |<----------+
              :   |        |   :
              :   |        |   :
              :   +--------+   :
              :                :

Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria.
En la CPU abstracta, el orden de las operaciones de memoria es muy
relajado, y una CPU en realidad puede realizar las operaciones de memoria
en el orden que desee, siempre que la causalidad del programa parezca
mantenerse. De manera similar, el compilador también puede organizar las
instrucciones que emite en el orden que quiera, siempre que no afecte al
funcionamiento aparente del programa.

Entonces, en el diagrama anterior, los efectos de las operaciones de
memoria realizadas por un CPU son percibidos por el resto del sistema a
medida que las operaciones cruzan la interfaz entre la CPU y el resto del
sistema (las líneas discontinuas a puntos).

Por ejemplo, considere la siguiente secuencia de eventos:

 CPU 1  CPU 2
 =============== ===============
 { A == 1; B == 2 }
 A = 3;  x = B;
 B = 4;  y = A;

El conjunto de accesos visto por el sistema de memoria en el medio se puede
organizar en 24 combinaciones diferentes (donde LOAD es cargar y STORE es
guardar):

STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4
STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3
STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4
STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4
STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3
STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4
STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4
STORE B=4, ...
...

y por lo tanto puede resultar en cuatro combinaciones diferentes de
valores:

x == 2, y == 1
x == 2, y == 3
x == 4, y == 1
x == 4, y == 3

Además, los stores asignados por una CPU al sistema de memoria pueden no
ser percibidos por los loads realizados por otra CPU en el mismo orden en
que fueron realizados.

Como otro ejemplo, considere esta secuencia de eventos:

 CPU 1  CPU 2
 =============== ===============
 { A == 1, B == 2, C == 3, P == &A, Q == &C }
 B = 4;  Q = P;
 P = &B;  D = *Q;

Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en
D depende en la dirección recuperada de P por la CPU 2. Al final de la
secuencia, cualquiera de los siguientes resultados son posibles:

  (Q == &A) y (D == 1)
  (Q == &B) y (D == 2)
  (Q == &B) y (D == 4)

Tenga en cuenta que la CPU 2 nunca intentará cargar C en D porque la CPU
cargará P en Q antes de emitir la carga de *Q.

OPERACIONES DEL DISPOSITIVO
---------------------------

Algunos dispositivos presentan sus interfaces de control como colecciones
de ubicaciones de memoria, pero el orden en que se accede a los registros
de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con
un conjunto de registros a los que se accede a través de un registro de
puerto de dirección (A) y un registro de datos del puerto (D). Para leer el
registro interno 5, el siguiente código podría entonces ser usado:

  *A = 5;
  x = *D;

pero esto podría aparecer como cualquiera de las siguientes dos secuencias:

  STORE *A = 5, x = LOAD *D
  x = LOAD *D, STORE *A = 5

el segundo de las cuales casi con certeza resultará en mal funcionamiento,
ya que se estableció la dirección _después_ de intentar leer el registro.


GARANTÍAS
---------

Hay algunas garantías mínimas que se pueden esperar de una CPU:

 (*) En cualquier CPU dada, los accesos a la memoria dependiente se
     emitirán en orden, con respeto a sí mismo. Esto significa que para:

 Q = READ_ONCE(P); D = READ_ONCE(*Q);

     donde READ_ONCE() es LEER_UNA_VEZ(), la CPU emitirá las siguientes
     operaciones de memoria:

 Q = LOAD P, D = LOAD *Q

     y siempre en ese orden. Sin embargo, en DEC Alpha, READ_ONCE() también
     emite una instrucción de barrera de memoria, de modo que una CPU DEC
     Alpha, sin embargo emite las siguientes operaciones de memoria:

 Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER

     Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador
     haga cosas inapropiadas.

 (*) Los loads y stores superpuestos dentro de una CPU en particular
     parecerán ser ordenados dentro de esa CPU. Esto significa que para:

 a = READ_ONCE(*X); WRITE_ONCE(*X, b);

     donde WRITE_ONCE() es ESCRIBIR_UNA_VEZ(), la CPU solo emitirá la
     siguiente secuencia de operaciones de memoria:

 a = LOAD *X, STORE *X = b

     Y para:

 WRITE_ONCE(*X, c); d = READ_ONCE(*X);

     la CPU solo emitirá:

 STORE *X = c, d = LOAD *X

  (Los loads y stores se superponen si están destinados a piezas
  superpuestas de memoria).

Y hay una serie de cosas que _deben_ o _no_ deben asumirse:

 (*) _No_debe_ asumirse que el compilador hará lo que usted quiera
     con referencias de memoria que no están protegidas por READ_ONCE() y
     WRITE ONCE(). Sin ellos, el compilador tiene derecho a hacer todo tipo
     de transformaciones "creativas", que se tratan en la sección BARRERA
     DEL COMPILADOR.

   (*) _No_debe_ suponerse que se emitirán loads y stores independientes
       en el orden dado. Esto significa que para:

 X = *A; Y = *B; *D = Z;

     podemos obtener cualquiera de las siguientes secuencias:

    X = LOAD *A,  Y = LOAD *B,  STORE *D = Z
    X = LOAD *A,  STORE *D = Z, Y = LOAD *B
    Y = LOAD *B,  X = LOAD *A,  STORE *D = Z
    Y = LOAD *B,  STORE *D = Z, X = LOAD *A
    STORE *D = Z, X = LOAD *A,  Y = LOAD *B
    STORE *D = Z, Y = LOAD *B,  X = LOAD *A

 (*) Se _debe_ suponer que los accesos de memoria superpuestos pueden
     fusionarse o ser descartados. Esto significa que para:

 X = *A; Y = *(A + 4);

  podemos obtener cualquiera de las siguientes secuencias:

X = LOAD *A; Y = LOAD *(A + 4);
Y = LOAD *(A + 4); X = LOAD *A;
{X, Y} = LOAD {*A, *(A + 4) };

  Y para:

*A = X; *(A + 4) = Y;

  podemos obtener cualquiera de:

STORE *A = X; STORE *(A + 4) = Y;
STORE *(A + 4) = Y; STORE *A = X;
STORE {*A, *(A + 4) } = {X, Y};

Y hay anti-garantías:

(*) Estas garantías no se aplican a los campos de bits, porque los
    compiladores a menudo generan código para modificarlos usando
    secuencias de lectura-modificación-escritura no atómica. No intente
    utilizar campos de bits para sincronizar algoritmos paralelos.

(*) Incluso en los casos en que los campos de bits están protegidos por
    cerrojos (o "cerrojos", o "locks"), todos los componentes en un campo
    de bits dado deben estar protegidos por un candado. Si dos campos en un
    campo de bits dado están protegidos por diferentes locks, las
    secuencias de lectura-modificación-escritura no atómicas del lock
    pueden causar una actualización a una campo para corromper el valor de
    un campo adyacente.

(*) Estas garantías se aplican solo a escalares correctamente alineados y
    dimensionados. De "tamaño adecuado" significa actualmente variables que
    son del mismo tamaño que "char", "short", "int" y "long".
    "Adecuadamente alineado" significa la alineación natural, por lo tanto,
    no hay restricciones para "char", alineación de dos bytes para "short",
    alineación de cuatro bytes para "int", y alineación de cuatro u ocho
    bytes para "long", en sistemas de 32 y 64 bits, respectivamente. Tenga
    en cuenta que estos garantías se introdujeron en el estándar C11, así
    que tenga cuidado cuando utilice compiladores anteriores a C11 (por
    ejemplo, gcc 4.6). La parte de la norma que contiene esta garantía es
    la Sección 3.14, que define "ubicación de memoria" de la siguiente
    manera:

    ubicación de memoria
  ya sea un objeto de tipo escalar, o una secuencia máxima
  de campos de bits adyacentes, todos con ancho distinto de cero

  NOTE 1: Dos hilos de ejecución pueden actualizar y acceder
  ubicaciones de memoria separadas sin interferir entre
  ellos.

  NOTE 2: Un campo de bits y un miembro adyacente que no es un campo de
  bits están en ubicaciones de memoria separadas. Lo mismo sucede con
  dos campos de bits, si uno se declara dentro de un declaración de
  estructura anidada y el otro no, o si las dos están separados por una
  declaración de campo de bits de longitud cero, o si están separados por
  un miembro no declarado como campo de bits. No es seguro actualizar
  simultáneamente dos campos de bits en la misma estructura si entre
  todos los miembros declarados también hay campos de bits, sin importar
  cuál resulta ser el tamaño de estos campos de bits intermedios.


==================================
¿QUÉ SON LAS BARRERAS DE MEMORIA?
==================================

Como se puede leer arriba, las operaciones independientes de memoria se
realizan de manera efectiva en orden aleatorio, pero esto puede ser un
problema para la interacción CPU-CPU y para la E/S ("I/O"). Lo que se
requiere es alguna forma de intervenir para instruir al compilador y al
CPU para restringir el orden.

Las barreras de memoria son este tipo de intervenciones. Imponen una
percepción de orden parcial, sobre las operaciones de memoria a ambos lados
de la barrera.

Tal cumplimiento es importante porque las CPUs y otros dispositivos en un
sistema pueden usar una variedad de trucos para mejorar el rendimiento,
incluido el reordenamiento, diferimiento y combinación de operaciones de
memoria; cargas especulativas; predicción de "branches" especulativos y
varios tipos de almacenamiento en caché. Las barreras de memoria se
utilizan para anular o suprimir estos trucos, permitiendo que el código
controle sensatamente la interacción de múltiples CPU y/o dispositivos.


VARIEDADES DE BARRERA DE MEMORIA
---------------------------------

Las barreras de memoria vienen en cuatro variedades básicas:

 (1) Barreras de memoria al escribir o almacenar (Write or store memory
     barriers).

     Una barrera de memoria de escritura garantiza que todas las
     operaciones de STORE especificadas antes de que la barrera aparezca
     suceden antes de todas las operaciones STORE especificadas después
     de la barrera, con respecto a los otros componentes del sistema.

     Una barrera de escritura es un orden parcial solo en los stores; No
     es requerido que tenga ningún efecto sobre los loads.

     Se puede considerar que una CPU envía una secuencia de operaciones de
     store al sistema de memoria a medida que pasa el tiempo. Todos los
     stores _antes_ de una barrera de escritura ocurrirán _antes_ de todos
     los stores después de la barrera de escritura.

     [!] Tenga en cuenta que las barreras de escritura normalmente deben
     combinarse con read o barreras de address-dependency barriers
     (dependencia de dirección); consulte la subsección
     "Emparejamiento de barreras smp".


 (2) Barrera de dependencia de dirección (histórico).

     Una barrera de dependencia de dirección es una forma más débil de
     barrera de lectura. En el caso de que se realicen dos loads de manera
     que la segunda dependa del resultado de la primera (por ejemplo: el
     primer load recupera la dirección a la que se dirigirá el segundo
     load), una barrera de dependencia de dirección sería necesaria para
     asegurarse de que el objetivo de la segunda carga esté actualizado
     después de acceder a la dirección obtenida por la primera carga.

     Una barrera de dependencia de direcciones es una ordenación parcial en
     laods de direcciones interdependientes; no se requiere que tenga
     ningún efecto en los stores, ya sean cargas de memoria o cargas
     de memoria superpuestas.

     Como se mencionó en (1), las otras CPU en el sistema pueden verse como
     secuencias de stores en el sistema de memoria que la considerada CPU
     puede percibir. Una barrera de dependencia de dirección emitida por
     la CPU en cuestión garantiza que para cualquier carga que la preceda,
     si esa carga toca alguna secuencia de stores de otra CPU, entonces
     en el momento en que la barrera se complete, los efectos de todos los
     stores antes del cambio del load serán perceptibles por cualquier
     carga emitida después la barrera de la dependencia de la dirección.

     Consulte la subsección "Ejemplos de secuencias de barrera de memoria"
     para ver los diagramas mostrando las restricciones de orden.

     [!] Tenga en cuenta que la primera carga realmente tiene que tener una
     dependencia de _dirección_ y no es una dependencia de control. Si la
     dirección para la segunda carga depende de la primera carga, pero la
     dependencia es a través de un condicional en lugar de -en realidad-
     cargando la dirección en sí, entonces es una dependencia de _control_
     y se requiere una barrera de lectura completa o superior. Consulte la
     subsección "Dependencias de control" para más información.

     [!] Tenga en cuenta que las barreras de dependencia de dirección
     normalmente deben combinarse con barreras de escritura; consulte la
     subsección "Emparejamiento de barreras smp".

     [!] Desde el kernel v5.9, se eliminó la API del kernel para barreras
     de memoria de direcciones explícitas. Hoy en día, las APIs para marcar
     cargas de variables compartidas, como READ_ONCE() y rcu_dereference(),
     proporcionan barreras de dependencia de dirección implícitas.

 (3) Barreras de memoria al leer o cargar (Read or load memory
    barriers).

     Una barrera de lectura es una barrera de dependencia de direcciones,
     más una garantía de que todas las operaciones de LOAD especificadas
     antes de la barrera parecerán ocurrir antes de todas las operaciones
     de LOAD especificadas después de la barrera con respecto a los demás
     componentes del sistema.

     Una barrera de lectura es un orden parcial solo en cargas; no es
     necesario que tenga ningún efecto en los stores.

     Las barreras de memoria de lectura implican barreras de dependencia de
     direcciones, y por tanto puede sustituirlas por estas.

     [!] Tenga en mente que las barreras de lectura normalmente deben
     combinarse con barreras de escritura; consulte la subsección
     "Emparejamiento de barreras smp".

 (4) Barreras de memoria generales

     Una barrera de memoria general proporciona la garantía de que todas
     las operaciones LOAD y STORE especificadas antes de que la barrera
     aparezca suceden antes de que todas las operaciones LOAD y STORE
     especificadas después de la barrera con respecto a los demás
     componentes del sistema.

     Una barrera de memoria general es un orden parcial tanto en
     operaciones de carga como de almacenamiento.

     Las barreras de memoria generales implican barreras de memoria tanto
     de lectura como de escritura, de modo que pueden sustituir a
     cualquiera.

Y un par de variedades implícitas:

 (5)  ACQUIRE (de adquisición).

     Esto actúa como una barrera permeable unidireccional. Garantiza que
     toda las operaciones de memoria después de la operación ACQUIRE
     parezcan suceder después de la ACQUIRE con respecto a los demás
     componentes del sistema. Las operaciones ACQUIRE incluyen operaciones
     LOCK y smp_load_acquire(), y operaciones smp_cond_load_acquire().

     Las operaciones de memoria que ocurren antes de una operación ACQUIRE
     pueden parecer suceder después de que se complete.

     Una operación ACQUIRE casi siempre debe estar emparejada con una
     operación RELEASE (de liberación).


 (6) Operaciones RELEASE (de liberación).

     Esto también actúa como una barrera permeable unidireccional.
     Garantiza que todas las operaciones de memoria antes de la operación
     RELEASE parecerán ocurrir antes de la operación RELEASE con respecto a
     los demás componentes del sistema. Las operaciones de RELEASE incluyen
     operaciones de UNLOCK y operaciones smp_store_release().

     Las operaciones de memoria que ocurren después de una operación
     RELEASE pueden parecer suceder antes de que se complete.

     El uso de las operaciones ACQUIRE y RELEASE generalmente excluye la
     necesidad de otros tipos de barrera de memoria. Además, un par
     RELEASE+ACQUIRE NO garantiza actuar como una barrera de memoria
     completa. Sin embargo, después de un ACQUIRE de una variable dada,
     todos los accesos a la memoria que preceden a cualquier anterior
     RELEASE en esa misma variable están garantizados como visibles. En
     otras palabras, dentro de la sección crítica de una variable dada,
     todos los accesos de todas las secciones críticas anteriores para esa
     variable habrán terminado de forma garantizada.

     Esto significa que ACQUIRE actúa como una operación mínima de
     "adquisición" y RELEASE actúa como una operación mínima de
     "liberación".

Un subconjunto de las operaciones atómicas descritas en atomic_t.txt
contiene variantes de ACQUIRE y RELEASE, además de definiciones
completamente ordenadas o relajadas (sin barrera semántica). Para
composiciones atómicas que realizan tanto un load como store, la semántica
ACQUIRE se aplica solo a la carga y la semántica RELEASE se aplica sólo a
la parte de la operación del store.

Las barreras de memoria solo son necesarias cuando existe la posibilidad de
interacción entre dos CPU o entre una CPU y un dispositivo. Si se puede
garantizar que no habrá tal interacción en ninguna pieza de código en
particular, entonces las barreras de memoria son innecesarias en ese
fragmento de código.

Tenga en cuenta que estas son las garantías _mínimas_. Diferentes
arquitecturas pueden proporcionar garantías más sustanciales, pero no se
puede confiar en estas fuera de esa arquitectura en específico.


¿QUÉ NO SE PUEDE ASUMIR SOBRE LAS BARRERAS DE LA MEMORIA?
---------------------------------------------------------

Hay ciertas cosas que las barreras de memoria del kernel Linux no
garantizan:

 (*) No hay garantía de que ninguno de los accesos a la memoria
     especificados antes de una barrera de memoria estará _completo_ al
     completarse una instrucción de barrera de memoria; se puede considerar
     que la barrera dibuja una línea en la cola de acceso del CPU que no
     pueden cruzar los accesos del tipo correspondiente.

 (*) No hay garantía de que la emisión de una barrera de memoria en una CPU
     tenga cualquier efecto directo en otra CPU o cualquier otro hardware
     en el sistema. El efecto indirecto será el orden en que la segunda CPU
     ve los efectos de los primeros accesos que ocurren de la CPU, pero lea
     el siguiente argumento:

 (*) No hay garantía de que una CPU vea el orden correcto de los efectos
     de los accesos de una segunda CPU, incluso _si_ la segunda CPU usa una
     barrera de memoria, a menos que la primera CPU _también_ use una
     barrera de memoria coincidente (vea el subapartado "Emparejamiento de
     barrera SMP").

 (*) No hay garantía de que alguna pieza intermedia fuera del hardware[*]
     del CPU no reordenará los accesos a la memoria. Los mecanismos de
     coherencia de caché del CPU deben propagar los efectos indirectos de
     una barrera de memoria entre las CPU, pero es posible que no lo hagan
     en orden.

 [*] Para obtener información sobre bus mastering DMA y coherencia, lea:

     Documentation/driver-api/pci/pci.rst
     Documentation/core-api/dma-api-howto.rst
     Documentation/core-api/dma-api.rst


BARRERA DE DEPENDENCIA DE DIRECCIÓN (HISTÓRICO)
-----------------------------------------------

A partir de la versión 4.15 del kernel Linux, se agregó un smp_mb() a
READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que
necesitan prestar atención a esta sección son aquellas que trabajan en el
código específico de la arquitectura DEC Alpha y aquellas que trabajan en
READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que
estén interesados desde un punto de vista histórico, aquí está la historia
de las barreras de dependencia de dirección.

[!] Si bien las dependencias de direcciones se observan tanto en carga a
carga como en relaciones de carga a store, las barreras de dependencia de
dirección no son necesarias para situaciones de carga a store.

El requisito de las barreras de dependencia de dirección es un poco sutil,
y no siempre es obvio que sean necesarias. Para ilustrar, considere la
siguiente secuencia de eventos:

 CPU 1        CPU 2
 ===============       ===============
 { A == 1, B == 2, C == 3, P == &A, Q == &C }
 B = 4;
 <barrera de escritura>
 WRITE_ONCE(P, &B);
         Q = READ_ONCE_OLD(P);
         D = *Q;

[!] READ_ONCE_OLD() corresponde a READ_ONCE() del kernel anterior a 4.15,
que no implica una barrera de dependencia de direcciones.

Hay una clara dependencia de dirección aquí, y parecería que al final de
la secuencia, Q debe ser &A o &B, y que:

 (Q == &A) implica (D == 1)
 (Q == &B) implica (D == 4)

¡Pero! La percepción de la CPU 2 de P puede actualizarse _antes_ de su
percepción de B, por lo tanto dando lugar a la siguiente situación:

 (Q == &B) y (D == 2) ????

Si bien esto puede parecer una falla en el mantenimiento de la coherencia
o la causalidad, no lo es, y este comportamiento se puede observar en
ciertas CPU reales (como DEC Alfa).

Para lidiar con esto, READ_ONCE() proporciona una barrera de dependencia
de dirección implícita desde el lanzamiento del kernel v4.15:

 CPU 1        CPU 2
 ===============       ===============
 { A == 1, B == 2, C == 3, P == &A, Q == &C }
 B = 4;
 <barrera de escritura>
 WRITE_ONCE(P, &B);
         Q = READ_ONCE(P);
         <barrera de dependencia de dirección implícita>
         D = *Q;

Esto refuerza la ocurrencia de una de las dos implicaciones, y previene la
tercera posibilidad de surgir.


[!] Tenga en cuenta que esta situación extremadamente contraria a la
intuición surge más fácilmente en máquinas con cachés divididos, de modo
que, por ejemplo, un banco de caché procesa líneas de caché pares y el otro
banco procesa líneas impares de caché. El puntero P podría almacenarse en
una línea de caché impar y la variable B podría almacenarse en una línea de
caché con número par. Entonces, si el banco de números pares de la memoria
caché de la CPU de lectura está extremadamente ocupado mientras que el
banco impar está inactivo, uno podría ver el nuevo valor del puntero P
(&B), pero el antiguo valor de la variable B (2).


No se requiere una barrera de dependencia de dirección para ordenar
escrituras dependientes porque las CPU que admite el kernel Linux no
escriben hasta que están seguros (1) de que la escritura realmente
sucederá, (2) de la ubicación de la escritura, y (3) del valor a escribir.
Pero, por favor, lea atentamente la sección "DEPENDENCIAS DEL CONTROL" y el
archivo Documentation/RCU/rcu_dereference.rst: el compilador puede romperse
y romper dependencias en muchas formas altamente creativas.

 CPU 1        CPU 2
 ===============       ===============
 { A == 1, B == 2, C = 3, P == &A, Q == &C }
 B = 4;
 <barrera de escritura>
 WRITE_ONCE(P, &B);
         Q = READ_ONCE_OLD(P);
         WRITE_ONCE(*Q, 5);

Por lo tanto, no se requiere ninguna barrera de dependencia de direcciones
para ordenar la lectura en Q con el load en *Q. En otras palabras, este
resultado está prohibido, incluso sin una barrera de dependencia de
dirección implícita del READ_ONCE() moderno:

 (Q == &B) && (B == 4)

Tenga en cuenta que este patrón debe ser raro. Después de todo, el objetivo
del orden de dependencia es -prevenir- escrituras en la estructura de
datos, junto con los costosos errores de caché asociados con tales
escrituras. Este patrón se puede utilizar para registrar raras condiciones
de error y similares, y el orden natural de las CPUs evita que se pierdan
tales registros.


Tenga en cuenta que el orden proporcionado por una dependencia de dirección
es local para la CPU que lo contiene. Lea la sección sobre "Atomicidad
multicopia" para más información.


La barrera de dependencia de dirección es muy importante para el sistema
RCU, por ejemplo. Vea rcu_assign_pointer() y rcu_dereference() en
include/linux/rcupdate.h. Esto permite que el objetivo actual de un puntero
RCU sea reemplazado con un nuevo objetivo modificado, sin que el objetivo
del reemplazo parezca estar inicializado de manera incompleta.

Consulte también la subsección sobre "Coherencia de caché" para obtener un
ejemplo más completo.

DEPENDENCIAS DE CONTROL
-----------------------

Las dependencias de control pueden ser un poco complicadas porque los
compiladores actuales no las entienden. El propósito de esta sección es
ayudarle a prevenir que la ignorancia del compilador rompa su código.

Una dependencia de control load-load (de carga a carga) requiere una
barrera de memoria de lectura completa, no simplemente una barrera
(implícita) de dependencia de direcciones para que funcione correctamente.
Considere el siguiente fragmento de código:

 q = READ_ONCE(a);
 <barrera implícita de dependencia de direcciones>
 if (q) {
  /* BUG: No hay dependencia de dirección!!! */
  p = READ_ONCE(b);
 }

Esto no tendrá el efecto deseado porque no hay una dependencia de dirección
real, sino más bien una dependencia de control que la CPU puede
cortocircuitar al intentar predecir el resultado por adelantado, para que
otras CPU vean la carga de b como si hubiera ocurrido antes que la carga de
a. En cuyo caso lo que realmente se requiere es:

   q = READ_ONCE(a);
   if (q) {
    <barrera de lectura>
    p = READ_ONCE(b);
   }

Sin embargo, los stores no se especulan. Esto significa que ordenar -es-
provisto para dependencias de control de load-store, como en el siguiente
ejemplo:

 q = READ_ONCE(a);
 if (q) {
  WRITE_ONCE(b, 1);
 }

Las dependencias de control se emparejan normalmente con otros tipos de
barreras. Dicho esto, tenga en cuenta que ni READ_ONCE() ni WRITE_ONCE()
son opcionales! Sin READ_ONCE(), el compilador podría combinar la carga de
'a' con otras cargas de 'a'. Sin WRITE_ONCE(), el compilador podría
combinar el store de 'b' con otros stores de 'b'. Cualquiera de estos casos
puede dar lugar a efectos en el orden muy contrarios a la intuición.

Peor aún, si el compilador puede probar (decir) que el valor de la
variable 'a' siempre es distinta de cero, estaría dentro de sus derechos
para optimizar el ejemplo original eliminando la declaración "if", como:

 q = a;
 b = 1;  /* BUG: Compilador y CPU pueden ambos reordernar!!! */

Así que no deje de lado READ_ONCE().

Es tentador tratar de hacer cumplir el orden en stores idénticos en ambos
caminos del "if" de la siguiente manera:

 q = READ_ONCE(a);
 if (q) {
  barrier();
  WRITE_ONCE(b, 1);
  hacer_algo();
 } else {
  barrier();
  WRITE_ONCE(b, 1);
  hacer_otra_cosa();
 }

Desafortunadamente, los compiladores actuales transformarán esto de la
siguiente manera en casos de alto nivel de optimización:

   q = READ_ONCE(a);
   barrier();
   WRITE_ONCE(b, 1);  /* BUG: No hay orden en load de a!!! */
   if (q) {
    /* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */
    hacer_algo();
   } else {
    /* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */
    hacer_otra_cosa();
   }

Ahora no hay condicional entre la carga de 'a' y el store de 'b', lo que
significa que la CPU está en su derecho de reordenarlos: El condicional es
absolutamente necesario y debe estar presente en el código ensamblador
incluso después de que se hayan aplicado todas las optimizaciones del
compilador. Por lo tanto, si necesita ordenar en este ejemplo, necesita
explícitamente barreras de memoria, por ejemplo, smp_store_release():


 q = READ_ONCE(a);
 if (q) {
  smp_store_release(&b, 1);
  hacer_algo();
 } else {
  smp_store_release(&b, 1);
  hacer_otra_cosa();
 }

Por el contrario, sin barreras de memoria explícita, el control de un if
con dos opciones está garantizado solo cuando los stores difieren, por
ejemplo:

   q = READ_ONCE(a);
   if (q) {
    WRITE_ONCE(b, 1);
    hacer_algo();
   } else {
    WRITE_ONCE(b, 2);
    hacer_otra_cosa();
   }

Aún se requiere el inicial READ_ONCE() para evitar que el compilador toque
el valor de 'a'.

Además, debe tener cuidado con lo que hace con la variable local 'q', de lo
contrario, el compilador podría adivinar el valor y volver a eliminar el
necesario condicional. Por ejemplo:

   q = READ_ONCE(a);
   if (q % MAX) {
    WRITE_ONCE(b, 1);
    hacer_algo();
   } else {
    WRITE_ONCE(b, 2);
    hacer_otra_cosa();
   }

Si MAX se define como 1, entonces el compilador sabe que (q % MAX) es igual
a cero, en cuyo caso el compilador tiene derecho a transformar el código
anterior en el siguiente:

   q = READ_ONCE(a);
   WRITE_ONCE(b, 2);
   hacer_otra_cosa();

Dada esta transformación, la CPU no está obligada a respetar el orden entre
la carga de la variable 'a' y el store de la variable 'b'. Es tentador
agregar una barrier(), pero esto no ayuda. El condicional se ha ido, y la
barrera no lo traerá de vuelta. Por lo tanto, si confia en este orden, debe
asegurarse de que MAX sea mayor que uno, tal vez de la siguiente manera:

   q = READ_ONCE(a);
   BUILD_BUG_ON(MAX <= 1); /* Orden de carga de a con store de b */
   if (q % MAX) {
    WRITE_ONCE(b, 1);
    hacer_algo();
   } else {
    WRITE_ONCE(b, 2);
    hacer_otra_cosa();
   }

Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran
idénticos, como se señaló anteriormente, el compilador podría sacar ese
store fuera de la declaración 'if'.

También debe tener cuidado de no confiar demasiado en el cortocircuito
de la evaluación booleana. Considere este ejemplo:

   q = READ_ONCE(a);
   if (q || 1 > 0)
   WRITE_ONCE(b, 1);

Debido a que la primera condición no puede fallar y la segunda condición es
siempre cierta, el compilador puede transformar este ejemplo de la
siguiente manera, rompiendo la dependencia del control:

   q = READ_ONCE(a);
   WRITE_ONCE(b, 1);

Este ejemplo subraya la necesidad de asegurarse de que el compilador no
pueda adivinar su código. Más generalmente, aunque READ_ONCE() fuerza
al compilador para emitir código para una carga dada, no fuerza al
compilador para usar los resultados.

Además, las dependencias de control se aplican solo a la cláusula then y
la cláusula else de la sentencia if en cuestión. En particular, no se
aplica necesariamente al código que sigue a la declaración if:

   q = READ_ONCE(a);
   if (q) {
    WRITE_ONCE(b, 1);
   } else {
    WRITE_ONCE(b, 2);
   }
   WRITE_ONCE(c, 1);  /* BUG: No hay orden para la lectura de 'a'. */

Es tentador argumentar que, de hecho, existe un orden porque el compilador
no puede reordenar accesos volátiles y tampoco puede reordenar escrituras
en 'b' con la condición. Desafortunadamente para esta línea de
razonamiento, el compilador podría compilar las dos escrituras en 'b' como
instrucciones de movimiento condicional, como en este fantástico idioma
pseudo-ensamblador:

         ld r1,a
         cmp r1,$0
         cmov,ne r4,$1
         cmov,eq r4,$2
         st r4,b
         st $1,c

Una CPU débilmente ordenada no tendría dependencia de ningún tipo entre la
carga de 'a' y el store de 'c'. Las dependencias de control se extenderían
solo al par de instrucciones cmov y el store dependiente de ellas. En
resumen, las dependencias de control se aplican solo a los stores en la
cláusula then y la cláusula else de la sentencia if en cuestión (incluidas
las funciones invocado por esas dos cláusulas), no al código que sigue a
esa declaración if.


Tenga muy en cuenta que el orden proporcionado por una dependencia de
control es local a la CPU que lo contiene. Vea el apartado de "Atomicidad
multicopia" para más información.


En resumen:

  (*) Las dependencias de control pueden ordenar cargas anteriores para
      stores posteriores. Sin embargo, no garantizan ningún otro tipo de
      orden: No cargas previas contra cargas posteriores, ni
      almacenamientos previos y luego nada. Si necesita tales formas de
      orden, use smp_rmb(), smp_wmb() o, en el caso de stores anteriores y
      cargas posteriores, smp_mb().

  (*) Si ambos caminos de la declaración "if" comienzan con stores
      idénticos de la misma variable, entonces esos stores deben ser
      ordenados, ya sea precediéndoles a ambos con smp_mb() o usando
      smp_store_release() para realizar el store. Tenga en cuenta que -no-
      es suficiente usar barrier() al comienzo de cada caso de la
      declaración "if" porque, como se muestra en el ejemplo anterior, la
      optimización de los compiladores puede destruir la dependencia de
      control respetando al pie de la letra la ley de barrier().

  (*) Las dependencias de control requieren al menos un condicional en
      tiempo de ejecución entre la carga anterior y el almacenamiento
      posterior, y este condicional debe implicar la carga previa. Si el
      compilador es capaz de optimizar el condicional y quitarlo, también
      habrá optimizado el ordenar. El uso cuidadoso de READ_ONCE() y
      WRITE_ONCE() puede ayudar a preservar el necesario condicional.

  (*) Las dependencias de control requieren que el compilador evite
      reordenar las dependencia hasta su inexistencia. El uso cuidadoso de
      READ_ONCE() o atomic{,64}_read() puede ayudarle a preservar la
      dependencia de control. Consulte la sección BARRERA DEL COMPILADOR
      para obtener más información al respecto.

  (*) Las dependencias de control se aplican solo a la cláusula then y la
      cláusula else de la sentencia "if" que contiene la dependencia de
      control, incluyendo cualquier función a la que llamen dichas dos
      cláusulas. Las dependencias de control no se aplican al código que
      sigue a la instrucción if que contiene la dependencia de control.

  (*) Las dependencias de control se emparejan normalmente con otros tipos
      de barreras.

  (*) Las dependencias de control no proporcionan atomicidad multicopia. Si
      usted necesita todas las CPU para ver un store dado al mismo tiempo,
      emplee smp_mb().

  (*) Los compiladores no entienden las dependencias de control. Por lo
      tanto es su trabajo asegurarse de que no rompan su código.


EMPAREJAMIENTO DE BARRERAS SMP
------------------------------

Cuando se trata de interacciones CPU-CPU, ciertos tipos de barrera de
memoria deben estar siempre emparejados. La falta del apropiado
emparejamiento es casi seguro un error.

Las barreras generales se emparejan entre sí, aunque también se emparejan
con la mayoría de otro tipo de barreras, aunque sin atomicidad multicopia.
Una barrera de adquisición se empareja con una barrera de liberación, pero
ambas también pueden emparejarse con otras barreras, incluidas, por
supuesto, las barreras generales. Una barrera de escritura se empareja con
una barrera de dependencia de dirección, una dependencia de control, una
barrera de adquisición, una barrera de liberación, una barrera de lectura
o una barrera general. Del mismo modo, una barrera de lectura se empareja
con una de dependencia de control o barrera de dependencia de dirección con
una barrera de escritura, una barrera de adquisición, una barrera de
liberación o una barrera general:

 CPU 1        CPU 2
 ===============       ===============
 WRITE_ONCE(a, 1);
 <barrera de escritura>
 WRITE_ONCE(b, 2);     x = READ_ONCE(b);
         <barrera de lectura>
         y = READ_ONCE(a);

O bien:

 CPU 1        CPU 2
 ===============       ===============================
 a = 1;
 <barrera de escritura>
 WRITE_ONCE(b, &a);    x = READ_ONCE(b);
         <barrera de dependencia de dirección implícita>
         y = *x;

O incluso:

 CPU 1        CPU 2
 ===============       ===============================
 r1 = READ_ONCE(y);
 <barrera general>
 WRITE_ONCE(x, 1);     if (r2 = READ_ONCE(x)) {
            <barrera de control implícita>
            WRITE_ONCE(y, 1);
         }

 assert(r1 == 0 || r2 == 0);

Básicamente, la barrera de lectura siempre tiene que estar ahí, aunque
puede ser del tipo "más débil".

[!] Tenga en cuenta que normalmente se esperaría que los stores antes de la
barrera de escritura se hagan coincidir con los stores después de la
barrera de lectura o la barrera de dependencia de dirección, y viceversa:

 CPU 1                               CPU 2
 ===================                 ===================
 WRITE_ONCE(a, 1);    }----   --->{  v = READ_ONCE(c);
 WRITE_ONCE(b, 2);    }    \ /    {  w = READ_ONCE(d);
 <barrera de escritura>            \        <barrera de lectura>
 WRITE_ONCE(c, 3);    }    / \    {  x = READ_ONCE(a);
 WRITE_ONCE(d, 4);    }----   --->{  y = READ_ONCE(b);


EJEMPLOS DE SECUENCIAS DE BARRERA DE MEMORIA
--------------------------------------------

En primer lugar, las barreras de escritura actúan como orden parcial en las
operaciones de store. Considere la siguiente secuencia de eventos:

 CPU 1
 =======================
 STORE A = 1
 STORE B = 2
 STORE C = 3
 <barrera de escritura>
 STORE D = 4
 STORE E = 5

Esta secuencia de eventos es finalizado para con el sistema de coherencia
de memoria en un orden que el resto del sistema podría percibir como el
conjunto desordenado { STORE A, STORE B, STORE C} todo ocurriendo antes del
conjunto desordenado { STORE D, STORE E}:


 +-------+       :      :
 |       |       +------+
 |       |------>| C=3  |     }     /\
 |       |  :    +------+     }-----  \  -----> Eventos perceptibles para
 |       |  :    | A=1  |     }        \/       el resto del sistema
 |       |  :    +------+     }
 | CPU 1 |  :    | B=2  |     }
 |       |       +------+     }
 |       |   wwwwwwwwwwwwwwww }   <--- En este momento la barrera de
 |       |       +------+     }        escritura requiere que todos los
 |       |  :    | E=5  |     }        stores anteriores a la barrera
 |       |  :    +------+     }        sean confirmados antes de que otros
 |       |------>| D=4  |     }        store puedan suceder
 |       |       +------+
 +-------+       :      :
                    |
                    | Secuencia por la cual los stores son confirmados al
                    | sistema de memoria por parte del CPU 1
                    V

En segundo lugar, las barreras de dependencia de dirección actúan como
órdenes parciales sobre la dirección de cargas dependientes. Considere la
siguiente secuencia de eventos:

 CPU 1   CPU 2
 ======================= =======================
  { B = 7; X = 9; Y = 8; C = &Y }
 STORE A = 1
 STORE B = 2
 <barrera de escritura>
 STORE C = &B  LOAD X
 STORE D = 4  LOAD C (consigue &B)
    LOAD *C (lee B)

Sin intervención, la CPU 2 puede percibir los eventos en la CPU 1 en orden
aleatorio a efectos prácticos, a pesar de la barrera de escritura emitida
por la CPU 1:

 +-------+       :      :                :       :
 |       |       +------+                +-------+  | Secuencia de
 |       |------>| B=2  |-----       --->| Y->8  |  | actualizado de
 |       |  :    +------+     \          +-------+  | percepción en CPU 2
 | CPU 1 |  :    | A=1  |      \     --->| C->&Y |  V
 |       |       +------+       |        +-------+
 |       |   wwwwwwwwwwwwwwww   |        :       :
 |       |       +------+       |        :       :
 |       |  :    | C=&B |---    |        :       :       +-------+
 |       |  :    +------+   \   |        +-------+       |       |
 |       |------>| D=4  |    ----------->| C->&B |------>|       |
 |       |       +------+       |        +-------+       |       |
 +-------+       :      :       |        :       :       |       |
                                |        :       :       |       |
                                |        :       :       | CPU 2 |
                                |        +-------+       |       |
     Percepción de B      --->  |        | B->7  |------>|       |
     aparentemente incorrecta!  |        +-------+       |       |
                                |        :       :       |       |
                                |        +-------+       |       |
     La carga de X frena --->    \       | X->9  |------>|       |
     el mantenimiento de          \      +-------+       |       |
     la coherencia de B            ----->| B->2  |       +-------+
                                         +-------+
                                         :       :


En el ejemplo anterior, la CPU 2 percibe que B es 7, a pesar de la carga de
*C (que sería B) viniendo después del LOAD de C.

Sin embargo, si se colocara una barrera de dependencia de dirección entre
la carga de C y la carga de *C (es decir: B) en la CPU 2:

 CPU 1   CPU 2
 ======================= =======================
  { B = 7; X = 9; Y = 8; C = &Y }
 STORE A = 1
 STORE B = 2
 <barrera de escritura>
 STORE C = &B  LOAD X
 STORE D = 4  LOAD C (consigue &B)
    <barrera de dependencia de dirección>
    LOAD *C (reads B)

entonces ocurrirá lo siguiente:

 +-------+       :      :                :       :
 |       |       +------+                +-------+
 |       |------>| B=2  |-----       --->| Y->8  |
 |       |  :    +------+     \          +-------+
 | CPU 1 |  :    | A=1  |      \     --->| C->&Y |
 |       |       +------+       |        +-------+
 |       |   wwwwwwwwwwwwwwww   |        :       :
 |       |       +------+       |        :       :
 |       |  :    | C=&B |---    |        :       :       +-------+
 |       |  :    +------+   \   |        +-------+       |       |
 |       |------>| D=4  |    ----------->| C->&B |------>|       |
 |       |       +------+       |        +-------+       |       |
 +-------+       :      :       |        :       :       |       |
                                |        :       :       |       |
                                |        :       :       | CPU 2 |
                                |        +-------+       |       |
                                |        | X->9  |------>|       |
                                |        +-------+       |       |
   Se asegura de que      --->   \   aaaaaaaaaaaaaaaaa   |       |
   los efectos anteriores al      \      +-------+       |       |
   store de C sean percibidos      ----->| B->2  |------>|       |
   por los siguientes loads              +-------+       |       |
                                         :       :       +-------+


Y en tercer lugar, una barrera de lectura actúa como un orden parcial sobre
las cargas. Considere la siguiente secuencia de eventos:

 CPU 1   CPU 2
 ======================= =======================
  { A = 0, B = 9 }
 STORE A=1
 <barrera de escritura>
 STORE B=2
    LOAD B
    LOAD A

Sin intervención, la CPU 2 puede elegir percibir los eventos en la CPU 1 en
algún orden aleatorio a efectos prácticos, a pesar de la barrera de
escritura emitida por la CPU 1:

 +-------+       :      :                :       :
 |       |       +------+                +-------+
 |       |------>| A=1  |------      --->| A->0  |
 |       |       +------+      \         +-------+
 | CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
 |       |       +------+        |       +-------+
 |       |------>| B=2  |---     |       :       :
 |       |       +------+   \    |       :       :       +-------+
 +-------+       :      :    \   |       +-------+       |       |
                              ---------->| B->2  |------>|       |
                                 |       +-------+       | CPU 2 |
                                 |       | A->0  |------>|       |
                                 |       +-------+       |       |
                                 |       :       :       +-------+
                                  \      :       :
                                   \     +-------+
                                    ---->| A->1  |
                                         +-------+
                                         :       :

Sin embargo, si se colocara una barrera de lectura entre la carga de B y la
carga de A en la CPU 2:

 CPU 1   CPU 2
 ======================= =======================
  { A = 0, B = 9 }
 STORE A=1
 <barrera de escritura>
 STORE B=2
    LOAD B
    <barrera de lectura>
    LOAD A

entonces el orden parcial impuesto por la CPU 1 será percibido
correctamente por la CPU 2:

 +-------+       :      :                :       :
 |       |       +------+                +-------+
 |       |------>| A=1  |------      --->| A->0  |
 |       |       +------+      \         +-------+
 | CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
 |       |       +------+        |       +-------+
 |       |------>| B=2  |---     |       :       :
 |       |       +------+   \    |       :       :       +-------+
 +-------+       :      :    \   |       +-------+       |       |
                              ---------->| B->2  |------>|       |
                                 |       +-------+       | CPU 2 |
                                 |       :       :       |       |
                                 |       :       :       |       |
   En este punto la barrera ----> \  rrrrrrrrrrrrrrrrr   |       |
   de lectura consigue que         \     +-------+       |       |
   todos los efectos anteriores     ---->| A->1  |------>|       |
   al almacenamiento de B sean           +-------+       |       |
   perceptibles por la CPU 2             :       :       +-------+


Para ilustrar esto de manera más completa, considere lo que podría pasar si
el código contenía una carga de A a cada lado de la barrera de lectura:

 CPU 1   CPU 2
 ======================= =======================
  { A = 0, B = 9 }
 STORE A=1
 <barrera de escritura>
 STORE B=2
    LOAD B
    LOAD A [primer load de A]
    <rbarrera de lectura>
    LOAD A [segundo load de A]

Aunque las dos cargas de A ocurren después de la carga de B, ambas pueden
obtener diferentes valores:

 +-------+       :      :                :       :
 |       |       +------+                +-------+
 |       |------>| A=1  |------      --->| A->0  |
 |       |       +------+      \         +-------+
 | CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
 |       |       +------+        |       +-------+
 |       |------>| B=2  |---     |       :       :
 |       |       +------+   \    |       :       :       +-------+
 +-------+       :      :    \   |       +-------+       |       |
                              ---------->| B->2  |------>|       |
                                 |       +-------+       | CPU 2 |
                                 |       :       :       |       |
                                 |       :       :       |       |
                                 |       +-------+       |       |
                                 |       | A->0  |------>| 1st   |
                                 |       +-------+       |       |
   En este punto la barrera ----> \  rrrrrrrrrrrrrrrrr   |       |
   de lectura consigue que         \     +-------+       |       |
   todos los efectos anteriores     ---->| A->1  |------>|       |
   al almacenamiento de B sean           +-------+       |       |
   perceptibles por la CPU 2             :       :       +-------+

Pero puede ser que la actualización a A desde la CPU 1 se vuelva
perceptible para la CPU 2 antes de que la barrera de lectura se complete de
todos modos:

 +-------+       :      :                :       :
 |       |       +------+                +-------+
 |       |------>| A=1  |------      --->| A->0  |
 |       |       +------+      \         +-------+
 | CPU 1 |   wwwwwwwwwwwwwwww   \    --->| B->9  |
 |       |       +------+        |       +-------+
 |       |------>| B=2  |---     |       :       :
 |       |       +------+   \    |       :       :       +-------+
 +-------+       :      :    \   |       +-------+       |       |
                              ---------->| B->2  |------>|       |
                                 |       +-------+       | CPU 2 |
                                 |       :       :       |       |
                                  \      :       :       |       |
                                   \     +-------+       |       |
                                    ---->| A->1  |------>| 1st   |
                                         +-------+       |       |
                                     rrrrrrrrrrrrrrrrr   |       |
                                         +-------+       |       |
                                         | A->1  |------>| 2nd   |
                                         +-------+       |       |
                                         :       :       +-------+

La garantía es que la segunda carga siempre dará como resultado A == 1 si
la carga de B resultó en B == 2. No existe tal garantía para la primera
carga de A; esto puede dar como resultado A == 0 o A == 1.


BARRERAS DE MEMORIA DE LECTURA FRENTE A ESPECULACIÓN DE CARGA
-------------------------------------------------------------

Muchas CPU especulan con las cargas: es decir, ven que necesitarán cargar
un elemento de la memoria, y encuentran un momento en el que no están
usando el bus para ningún otra carga, y también en la carga por adelantado,
aunque en realidad no lo hayan llegado a ese punto en el flujo de ejecución
de instrucciones todavía. Esto permite que la instrucción de carga real
potencialmente complete de inmediato, porque la CPU ya tiene el valor a
mano.

Puede resultar que la CPU en realidad no necesitara el valor, tal vez
porque una condición eludió la carga, en cuyo caso puede descartar el valor
o simplemente almacenar en caché para su uso posterior.

Considere:

 CPU 1   CPU 2
 ======================= =======================
    LOAD B
    DIVIDE  } Instrucciones de división
    DIVIDE  } tardan mucho en terminar
    LOAD A

donde DIVIDE es DIVIDIR. Que podría aparecer como esto:

                                         :       :       +-------+
                                         +-------+       |       |
                                     --->| B->2  |------>|       |
                                         +-------+       | CPU 2 |
                                         :       :DIVIDE |       |
                                         +-------+       |       |
 La CPU ocupada con la división ---> --->| A->0  |~~~~   |       |
 especula sobre el LOAD de A             +-------+   ~   |       |
                                         :       :   ~   |       |
                                         :       :DIVIDE |       |
                                         :       :   ~   |       |
 Una vez completadas las divisiones  --> :       :   ~-->|       |
 la CPU puede realizar el                :       :       |       |
 LOAD con efecto inmediato               :       :       +-------+


Colocando una barrera de lectura o una barrera de dependencia de dirección
justo antes de la segundo carga:



 CPU 1   CPU 2
 ======================= =======================
    LOAD B
    DIVIDE
    DIVIDE
    <rbarrera de lectura>
    LOAD A

obligará a reconsiderar cualquier valor obtenido especulativamente en una
medida dependiente del tipo de barrera utilizada. Si no se hizo ningún
cambio en la ubicación de memoria especulada, entonces el valor especulado
solo se usará:

                                         :       :       +-------+
                                         +-------+       |       |
                                     --->| B->2  |------>|       |
                                         +-------+       | CPU 2 |
                                         :       :DIVIDE |       |
                                         +-------+       |       |
  La CPU ocupada con la división ---> --->| A->0  |~~~~   |       |
  especula sobre el LOAD de A             +-------+   ~   |       |
                                         :       :   ~   |       |
                                         :       :DIVIDE |       |
                                         :       :   ~   |       |
                                         :       :   ~   |       |
                                     rrrrrrrrrrrrrrrr~   |       |
                                         :       :   ~   |       |
                                         :       :   ~-->|       |
                                         :       :       |       |
                                         :       :       +-------+


pero si había una actualización o una invalidación de otra CPU pendiente,
entonces la especulación será cancelada y el valor recargado:

                                         :       :       +-------+
                                         +-------+       |       |
                                     --->| B->2  |------>|       |
                                         +-------+       | CPU 2 |
                                         :       :DIVIDE |       |
                                         +-------+       |       |
  La CPU ocupada con la división ---> --->| A->0  |~~~~   |       |
  especula sobre el LOAD de A             +-------+   ~   |       |
                                         :       :   ~   |       |
                                         :       :DIVIDE |       |
                                         :       :   ~   |       |
                                         :       :   ~   |       |
                                     rrrrrrrrrrrrrrrrr   |       |
                                         +-------+       |       |
 La especulación es descartada --->  --->| A->1  |------>|       |
 y un valor actualizado                  +-------+       |       |
 es conseguido                           :       :       +-------+

ATOMICIDAD MULTICOPIA
---------------------

La atomicidad multicopia es una noción profundamente intuitiva sobre el
orden que no es siempre proporcionada por los sistemas informáticos reales,
a saber, que un determinada store se vuelve visible al mismo tiempo para
todos las CPU o, alternativamente, que todas las CPU acuerdan el orden en
que todos los stores se vuelven visibles. Sin embargo, el soporte para
atomicidad multicopia completa descartaría valiosas optimizaciones
hardware, por lo que una versión más débil conocida como ``otra atomicidad
multicopia'' en cambio, solo garantiza que un store dado se vuelva visible
al mismo tiempo en todas las -otras- CPUs. El resto de este documento
discute esta versión más débil, pero por brevedad lo llamaremos simplemente
``atomicidad multicopia''.

El siguiente ejemplo demuestra la atomicidad multicopia:

 CPU 1   CPU 2   CPU 3
 ======================= ======================= =======================
  { X = 0, Y = 0 }
 STORE X=1  r1=LOAD X (reads 1) LOAD Y (reads 1)
    <barrera general> <barrera de lectura>
    STORE Y=r1  LOAD X

Suponga que la carga de la CPU 2 desde X devuelve 1, que luego almacena en
Y, y la carga de la CPU 3 desde Y devuelve 1. Esto indica que el store de
la CPU 1 a X precede a la carga de la CPU 2 desde X y el store de esa CPU 2
a Y precede la carga de la CPU 3 desde Y. Además, las barreras de memoria
garantizan que la CPU 2 ejecuta su carga antes que su almacenamiento, y la
CPU 3 carga desde Y antes de cargar desde X. La pregunta entonces es
"¿Puede la carga de la CPU 3 desde X devolver 0?"

Debido a que la carga de la CPU 3 desde X en cierto sentido viene después
de la carga de la CPU 2, es natural esperar que la carga de la CPU 3 desde
X deba devolver 1. Esta expectativa se deriva de la atomicidad multicopia:
si una carga que se ejecuta en la CPU B sigue una carga de la misma
variable que se ejecuta en la CPU A (y la CPU A no almacenó originalmente
el valor que leyó), entonces en sistemas atómicos multicopia, la carga de
la CPU B debe devolver el mismo valor que hizo la carga de la CPU A o algún
valor posterior. Sin embargo, el kernel Linux no requiere que los sistemas
sean atómicos multicopia.

El uso de una barrera de memoria general en el ejemplo anterior compensa
cualquier falta de atomicidad multicopia. En el ejemplo, si la carga de la
CPU 2 de X devuelve 1 y la carga de la CPU 3 de Y devuelve 1, entonces la
carga de la CPU 3 desde X debe de hecho también devolver 1.

Sin embargo, las dependencias, las barreras de lectura y las barreras de
escritura no siempre son capaces de compensar la atomicidad no multicopia.
Por ejemplo, supongamos que la barrera general de la CPU 2 se elimina del
ejemplo anterior, dejando solo la dependencia de datos que se muestra a
continuación:

 CPU 1   CPU 2   CPU 3
 ======================= ======================= =======================
  { X = 0, Y = 0 }
 STORE X=1  r1=LOAD X (escribe 1) LOAD Y (lee 1)
    <dependencia de datos> <barrera de lectura>
    STORE Y=r1  LOAD X (lee 0)

Esta sustitución permite que la atomicidad no multicopia se desenfrene: en
este ejemplo, es perfectamente legal que la carga de la CPU 2 desde X
devuelva 1, la carga de la CPU 3 desde Y devuelva 1, y su carga desde X
tenga valor 0.

El punto clave es que aunque la dependencia de datos de la CPU 2 ordena su
carga y store, no garantiza ordenar el store de la CPU 1. De forma que, si
este ejemplo se ejecuta en un sistema atómico no multicopia donde las CPU 1
y 2 comparten un buffer de almacenamiento o un nivel de caché, la CPU 2
podría tener acceso anticipado de escritura a CPU 1. Por lo tanto, se
requieren barreras generales para garantizar que todas las CPU acurden el
orden combinado de accesos múltiples.

Las barreras generales pueden compensar no solo la atomicidad no
multicopia, pero también pueden generar orden adicional que puede asegurar
que -todas- las CPU percibirán el mismo orden de -todas- las operaciones.
Por el contrario, una cadena de parejas de liberación-adquisición no
proporciona este orden adicional, lo que significa que solo se garantiza
que las CPU de la cadena estén de acuerdo en el orden combinado de los
accesos. Por ejemplo, cambiando a código C en deferencia al fantasma de
Herman Hollerith:

 int u, v, x, y, z;

 void cpu0(void)
 {
  r0 = smp_load_acquire(&x);
  WRITE_ONCE(u, 1);
  smp_store_release(&y, 1);
 }

 void cpu1(void)
 {
  r1 = smp_load_acquire(&y);
  r4 = READ_ONCE(v);
  r5 = READ_ONCE(u);
  smp_store_release(&z, 1);
 }

 void cpu2(void)
 {
  r2 = smp_load_acquire(&z);
  smp_store_release(&x, 1);
 }

 void cpu3(void)
 {
  WRITE_ONCE(v, 1);
  smp_mb();
  r3 = READ_ONCE(u);
 }

Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas
smp_store_release()/smp_load_acquire(), el siguiente resultado estaría
prohibido:

 r0 == 1 && r1 == 1 && r2 == 1

Además, debido a la relación liberación-adquisición entre cpu0() y cpu1(),
cpu1() debe ver las escrituras de cpu0(), de modo que el siguiente
resultado estaría prohibido:

 r1 == 1 && r5 == 0

Sin embargo, el orden proporcionado por una cadena de
liberación-adquisición es local a las CPU que participan en esa cadena y no
se aplica a cpu3(), al menos aparte de los stores. Por lo tanto, es posible
el siguiente resultado:

 r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0

Por otro lado, también el siguiente resultado es posible:

 r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 && r5 == 1

Aunque cpu0(), cpu1() y cpu2() verán sus respectivas lecturas y escrituras
en orden, las CPU que no participan en la cadena de liberación-adquisición
pueden estar en desacuerdo con el orden. Este desacuerdo se debe al hecho
de que las instrucciones de barrera de memoria débiles utilizadas para
implementar smp_load_acquire() y smp_store_release() no son necesarios para
ordenar stores anteriores contra cargas posteriores en todos los casos.
Esto significa que cpu3() puede ver el store de cpu0() suceder -después- de
la carga de cpu1() desde v, aunque tanto cpu0() como cpu1() están de
acuerdo en que estas dos operaciones ocurrieron en el orden previsto.

Sin embargo, tenga en cuenta que smp_load_acquire() no es mágico. En
particular, simplemente lee de su argumento en orden. Es decir, -no-
asegura que se leerá cualquier valor en particular. Por lo tanto, los
siguiente resultados son posibles:

 r0 == 0 && r1 == 0 && r2 == 0 && r5 == 0

Tenga en cuenta que este resultado puede ocurrir incluso en un mítico
sistema, consistente en secuencia, donde nunca se reordena nada.

Para reiterar, si su código requiere un orden completo de todas las
operaciones, utilice barreras generales en todo momento.


==============================
BARRERAS EXPLÍCITAS DEL KERNEL
==============================

El kernel Linux tiene una variedad de diferentes barreras que actúan a
diferentes niveles:

  (*) Barrera del compilador.

  (*) Barreras de memoria de la CPU.


BARRERA DEL COMPILADOR
-----------------------

El kernel de Linux tiene una función de barrera del compilador explícita
que evita que el el compilador mueva los accesos a la memoria de cualquier
lado al otro:

 barrier();

Esta es una barrera general: no hay variantes de barrier() para casos de
lectura-lectura o escritura-escritura. Sin embargo, READ_ONCE() y
--> --------------------

--> maximum size reached

--> --------------------