C ++ 11 Implementación de Spinlock usando el encabezado “

Question 1

Implementé la clase SpinLock, como sigue

struct Node {
    int number;
    std::atomic_bool latch;

    void add() {
        lock();
        number++;
        unlock();
    }
    void lock() {
        bool unlatched = false;
        while(!latch.compare_exchange_weak(unlatched, true, std::memory_order_acquire));
    }
    void unlock() {
        latch.store(false , std::memory_order_release);
    }
};

Implementé la clase anterior e hice dos subprocesos que llaman al método add() de una misma instancia de la clase Node 10 millones de veces por subproceso.

el resultado es, lamentablemente, no 20 millones. ¿Que me estoy perdiendo aqui?

Question 2

El problema es ese compare_exchange_weak actualiza el unlatched variable una vez que falla. De la documentación de compare_exchange_weak:

Compara el contenido del valor contenido del objeto atómico con el esperado: – si es verdadero, reemplaza el valor contenido con val (como store).
– si es falso, reemplaza esperado con el valor contenido.

Es decir, después de la primera falla compare_exchange_weak, unlatched se actualizará a truepor lo que la siguiente iteración del bucle intentará compare_exchange_weak true con true. Esto tuvo éxito y acaba de tomar un candado que estaba en manos de otro subproceso.

Solución: asegúrese de configurar unlatched de regreso false antes de cada compare_exchange_weakp.ej:

while(!latch.compare_exchange_weak(unlatched, true, std::memory_order_acquire)) {
    unlatched = false;
}

Question 3

Como menciona @gexicide, el problema es que el compare_exchange las funciones actualizan el expected variable con el valor actual de la variable atómica. Esa es también la razón por la que tienes que usar la variable local unlatched en primer lugar. Para solucionar esto puedes configurar unlatched vuelve a falso en cada iteración del bucle.

Sin embargo, en lugar de usar compare_exchange para algo para lo que su interfaz no es adecuada, es mucho más simple de usar std::atomic_flag en cambio:

class SpinLock {
    std::atomic_flag locked = ATOMIC_FLAG_INIT ;
public:
    void lock() {
        while (locked.test_and_set(std::memory_order_acquire)) { ; }
    }
    void unlock() {
        locked.clear(std::memory_order_release);
    }
};

Fuente: preferencia cp

Especificar manualmente el orden de la memoria es solo un ajuste menor de rendimiento potencial, que copié de la fuente. Si la simplicidad es más importante que el último bit de rendimiento, puede ceñirse a los valores predeterminados y simplemente llamar locked.test_and_set() / locked.clear().

Por cierto.: std::atomic_flag es el único tipo que está garantizado para estar libre de bloqueo, aunque no conozco ninguna plataforma, donde las operaciones en std::atomic_bool no están libres de bloqueo.

Actualizar: Como se explica en los comentarios de @David Schwartz, @Anton y @Technik Empire, el bucle vacío tiene algunos efectos no deseados, como predicción errónea de ramas, inanición de subprocesos en los procesadores HT y un consumo de energía demasiado alto; en resumen, es una forma bastante ineficiente de Espere. El impacto y la solución son específicos de la arquitectura, la plataforma y la aplicación. No soy un experto, pero la solución habitual parece ser agregar un cpu_relax() en linux o YieldProcessor() en las ventanas al cuerpo del bucle.

EDIT2: Para que quede claro: la versión portátil presentada aquí (sin las instrucciones especiales de cpu_relax, etc.) ya debería ser lo suficientemente buena para muchas aplicaciones. Si tu SpinLock gira mucho porque otra persona mantiene el bloqueo durante mucho tiempo (lo que ya podría indicar un problema general de diseño), probablemente sea mejor usar un mutex normal de todos modos.

¿Ha sido útil esta solución?