std:: memory_order

std::memory_order especifica cómo se deben ordenar los accesos a memoria, incluidos los accesos regulares no atómicos, alrededor de una operación atómica. Sin restricciones en un sistema multinúcleo, cuando múltiples hilos leen y escriben simultáneamente en varias variables, un hilo puede observar que los valores cambian en un orden diferente al orden en que otro hilo los escribió. De hecho, el orden aparente de los cambios puede incluso diferir entre múltiples hilos lectores. Algunos efectos similares pueden ocurrir incluso en sistemas monoprocesador debido a transformaciones del compilador permitidas por el modelo de memoria.

El comportamiento predeterminado de todas las operaciones atómicas en la biblioteca proporciona un ordenamiento secuencialmente consistente (ver discusión abajo). Ese valor predeterminado puede afectar el rendimiento, pero a las operaciones atómicas de la biblioteca se les puede dar un argumento adicional std::memory_order para especificar las restricciones exactas, más allá de la atomicidad, que el compilador y el procesador deben hacer cumplir para esa operación.

Constantes

Descripción formal

La sincronización entre hilos y el ordenamiento de memoria determinan cómo se ordenan las evaluaciones y los efectos secundarios de las expresiones entre diferentes hilos de ejecución. Se definen en los siguientes términos:

Secuenciado-antes

Dentro del mismo hilo, la evaluación A puede estar sequenced-before la evaluación B, como se describe en evaluation order .

Orden de modificación

Todas las modificaciones a cualquier variable atómica particular ocurren en un orden total que es específico para esta única variable atómica.

Las siguientes cuatro garantías se aplican a todas las operaciones atómicas:

Secuencia de liberación

Después de que se realice una operación de liberación A sobre un objeto atómico M, la subsecuencia continua más larga del orden de modificación de M que consiste en:

Se conoce como release sequence headed by A .

Se sincroniza con

Si un almacenamiento atómico en el hilo A es una operación de liberación , una carga atómica en el hilo B de la misma variable es una operación de adquisición , y la carga en el hilo B lee un valor escrito por el almacenamiento en el hilo A, entonces el almacenamiento en el hilo A se sincroniza con la carga en el hilo B.

Además, algunas llamadas de biblioteca pueden estar definidas para synchronize-with otras llamadas de biblioteca en otros hilos.

Sucede-antes entre hilos

Entre hilos, la evaluación A inter-thread happens before la evaluación B si cualquiera de las siguientes condiciones es verdadera:

Sucede fuertemente antes

Independientemente de los hilos, la evaluación A strongly happens-before la evaluación B si cualquiera de las siguientes condiciones es verdadera:

Efectos secundarios visibles

El efecto secundario A sobre un escalar M (una escritura) es visible con respecto al cálculo de valor B sobre M (una lectura) si ambas condiciones siguientes son verdaderas:

Si el efecto secundario A es visible con respecto al cálculo de valor B, entonces el subconjunto contiguo más largo de los efectos secundarios sobre M, en orden de modificación , donde B no sucede-antes de él se conoce como la secuencia visible de efectos secundarios (el valor de M, determinado por B, será el valor almacenado por uno de estos efectos secundarios).

Nota: la sincronización entre hilos se reduce a prevenir carreras de datos (estableciendo relaciones de sucede-antes) y definir qué efectos secundarios se vuelven visibles bajo qué condiciones.

Operación de consumo

La carga atómica con memory_order_consume o más fuerte es una operación de consumo. Nótese que std::atomic_thread_fence impone requisitos de sincronización más fuertes que una operación de consumo.

Operación de adquisición

La carga atómica con memory_order_acquire o más fuerte es una operación de adquisición. La operación lock() en un Mutex también es una operación de adquisición. Nótese que std::atomic_thread_fence impone requisitos de sincronización más fuertes que una operación de adquisición.

Operación de liberación

La operación de almacenamiento atómico con memory_order_release o más fuerte es una operación de liberación. La operación unlock() en un Mutex también es una operación de liberación. Nótese que std::atomic_thread_fence impone requisitos de sincronización más fuertes que una operación de liberación.

Explicación

Ordenamiento relajado

Las operaciones atómicas etiquetadas con memory_order_relaxed no son operaciones de sincronización; no imponen un orden entre los accesos concurrentes a memoria. Solo garantizan atomicidad y consistencia del orden de modificación.

Por ejemplo, con x y y inicialmente en cero,

// Hilo 1:
r1 = y.load(std::memory_order_relaxed); // A
x.store(r1, std::memory_order_relaxed); // B
// Hilo 2:
r2 = x.load(std::memory_order_relaxed); // C 
y.store(42, std::memory_order_relaxed); // D

se permite producir r1 == r2 == 42 porque, aunque A está secuenciado-antes de B dentro del hilo 1 y C está secuenciado antes de D dentro del hilo 2, nada impide que D aparezca antes que A en el orden de modificación de y , y que B aparezca antes que C en el orden de modificación de x . El efecto secundario de D en y podría ser visible para la carga A en el hilo 1 mientras que el efecto secundario de B en x podría ser visible para la carga C en el hilo 2. En particular, esto puede ocurrir si D se completa antes que C en el hilo 2, ya sea debido a reordenamiento del compilador o durante la ejecución.

// Thread 1:
r1 = y.load(std::memory_order_relaxed);
if (r1 == 42)
    x.store(r1, std::memory_order_relaxed);
// Thread 2:
r2 = x.load(std::memory_order_relaxed);
if (r2 == 42)
    y.store(42, std::memory_order_relaxed);

Un uso típico para el orden de memoria relajado es incrementar contadores, como los contadores de referencia de std::shared_ptr , ya que esto solo requiere atomicidad, pero no ordenamiento o sincronización (nótese que decrementar los std::shared_ptr contadores requiere sincronización de adquisición-liberación con el destructor).

#include <atomic>
#include <iostream>
#include <thread>
#include <vector>
std::atomic<int> cnt = {0};
void f()
{
    for (int n = 0; n < 1000; ++n)
        cnt.fetch_add(1, std::memory_order_relaxed);
}
int main()
{
    std::vector<std::thread> v;
    for (int n = 0; n < 10; ++n)
        v.emplace_back(f);
    for (auto& t : v)
        t.join();
    std::cout << "Final counter value is " << cnt << '\n';
}

Final counter value is 10000

Ordenamiento Liberar-Adquirir

Si un almacenamiento atómico en el hilo A está etiquetado como memory_order_release , una carga atómica en el hilo B de la misma variable está etiquetada como memory_order_acquire , y la carga en el hilo B lee un valor escrito por el almacenamiento en el hilo A, entonces el almacenamiento en el hilo A sincroniza-con la carga en el hilo B.

Todas las escrituras de memoria (incluyendo las no atómicas y atómicas relajadas) que happened-before del almacenamiento atómico desde el punto de vista del hilo A, se convierten en visible side-effects en el hilo B. Es decir, una vez que se completa la carga atómica, se garantiza que el hilo B verá todo lo que el hilo A escribió en la memoria. Esta promesa solo se cumple si B realmente devuelve el valor que A almacenó, o un valor posterior en la secuencia de liberación.

La sincronización se establece únicamente entre los hilos que liberan y que adquieren la misma variable atómica. Otros hilos pueden ver un orden diferente de accesos a memoria que cualquiera o ambos de los hilos sincronizados.

En sistemas fuertemente ordenados — x86, SPARC TSO, mainframe de IBM, etc. — el ordenamiento release-acquire es automático para la mayoría de operaciones. No se emiten instrucciones adicionales de CPU para este modo de sincronización; solo ciertas optimizaciones del compilador se ven afectadas (por ejemplo, se prohíbe al compilador mover almacenamientos no atómicos más allá del almacenamiento atómico-release o realizar cargas no atómicas antes que la carga atómica-acquire). En sistemas débilmente ordenados (ARM, Itanium, PowerPC), se utilizan instrucciones especiales de carga de CPU o barreras de memoria.

Los bloqueos de exclusión mutua, como std::mutex o atomic spinlock , son un ejemplo de sincronización de liberación-adquisición: cuando el bloqueo es liberado por el hilo A y adquirido por el hilo B, todo lo que ocurrió en la sección crítica (antes de la liberación) en el contexto del hilo A debe ser visible para el hilo B (después de la adquisición) que está ejecutando la misma sección crítica.

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_acquire)))
        ;
    assert(*p2 == "Hello"); // nunca falla
    assert(data == 42); // nunca falla
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

#include <atomic>
#include <cassert>
#include <thread>
#include <vector>
std::vector<int> data;
std::atomic<int> flag = {0};
void thread_1()
{
    data.push_back(42);
    flag.store(1, std::memory_order_release);
}
void thread_2()
{
    int expected = 1;
    // memory_order_relaxed is okay because this is an RMW,
    // and RMWs (with any ordering) following a release form a release sequence
    while (!flag.compare_exchange_strong(expected, 2, std::memory_order_relaxed))
    {
        expected = 1;
    }
}
void thread_3()
{
    while (flag.load(std::memory_order_acquire) < 2)
        ;
    // if we read the value 2 from the atomic flag, we see 42 in the vector
    assert(data.at(0) == 42); // will never fire
}
int main()
{
    std::thread a(thread_1);
    std::thread b(thread_2);
    std::thread c(thread_3);
    a.join(); b.join(); c.join();
}

Ordenamiento Liberar-Consumir

#include <atomic>
#include <cassert>
#include <string>
#include <thread>
std::atomic<std::string*> ptr;
int data;
void producer()
{
    std::string* p = new std::string("Hello");
    data = 42;
    ptr.store(p, std::memory_order_release);
}
void consumer()
{
    std::string* p2;
    while (!(p2 = ptr.load(std::memory_order_consume)))
        ;
    assert(*p2 == "Hello"); // never fires: *p2 carries dependency from ptr
    assert(data == 42); // may or may not fire: data does not carry dependency from ptr
}
int main()
{
    std::thread t1(producer);
    std::thread t2(consumer);
    t1.join(); t2.join();
}

Ordenamiento secuencialmente consistente

Las operaciones atómicas etiquetadas con memory_order_seq_cst no solo ordenan la memoria de la misma manera que el ordenamiento de liberación/adquisición (todo lo que ocurrió-antes de un almacenamiento en un hilo se convierte en un efecto secundario visible en el hilo que realizó una carga), sino que también establecen un orden de modificación total único de todas las operaciones atómicas que están etiquetadas de esta manera.

// Hilo 1:
x.store(1, std::memory_order_seq_cst); // A
y.store(1, std::memory_order_release); // B
// Hilo 2:
r1 = y.fetch_add(1, std::memory_order_seq_cst); // C
r2 = y.load(std::memory_order_relaxed); // D
// Hilo 3:
y.store(3, std::memory_order_seq_cst); // E
r3 = x.load(std::memory_order_seq_cst); // F

La ordenación secuencial puede ser necesaria en situaciones de múltiples productores-múltiples consumidores donde todos los consumidores deben observar las acciones de todos los productores ocurriendo en el mismo orden.

La ordenación secuencial total requiere una instrucción de barrera de memoria completa de la CPU en todos los sistemas multinúcleo. Esto puede convertirse en un cuello de botella de rendimiento ya que fuerza a que los accesos a memoria afectados se propaguen a cada núcleo.

#include <atomic>
#include <cassert>
#include <thread>
std::atomic<bool> x = {false};
std::atomic<bool> y = {false};
std::atomic<int> z = {0};
void write_x()
{
    x.store(true, std::memory_order_seq_cst);
}
void write_y()
{
    y.store(true, std::memory_order_seq_cst);
}
void read_x_then_y()
{
    while (!x.load(std::memory_order_seq_cst))
        ;
    if (y.load(std::memory_order_seq_cst))
        ++z;
}
void read_y_then_x()
{
    while (!y.load(std::memory_order_seq_cst))
        ;
    if (x.load(std::memory_order_seq_cst))
        ++z;
}
int main()
{
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join(); b.join(); c.join(); d.join();
    assert(z.load() != 0); // will never happen
}

Relación con volatile

Dentro de un hilo de ejecución, los accesos (lecturas y escrituras) a través de volatile glvalues no pueden ser reordenados más allá de efectos secundarios observables (incluyendo otros accesos volátiles) que estén sequenced-before o sequenced-after dentro del mismo hilo, pero este orden no está garantizado que sea observado por otro hilo, ya que el acceso volátil no establece sincronización entre hilos.

Además, los accesos volátiles no son atómicos (la lectura y escritura concurrente es una data race ) y no ordenan la memoria (los accesos a memoria no volátil pueden reordenarse libremente alrededor del acceso volátil).

Una excepción notable es Visual Studio, donde, con la configuración predeterminada, cada escritura volátil tiene semántica de liberación y cada lectura volátil tiene semántica de adquisición ( Microsoft Docs ), y por lo tanto los volátiles pueden usarse para sincronización entre hilos. La semántica estándar de volatile no es aplicable a programación multiproceso, aunque son suficientes para, por ejemplo, comunicación con un std::signal handler que se ejecuta en el mismo hilo cuando se aplica a variables sig_atomic_t . La opción del compilador /volatile:iso puede usarse para restaurar el comportamiento consistente con el estándar, que es la configuración predeterminada cuando la plataforma objetivo es ARM.

Véase también

Enlaces externos