Cuando trabajas en sistemas de alta concurrencia, como un motor de renderizado o un motor de trading, un std::mutex puede ser demasiado costoso debido al overhead de la gestión del scheduler del sistema operativo. std::atomic<T> es la solución de bajo nivel que proporciona un envoltorio sobre tipos de datos para garantizar que las operaciones sobre ellos sean indivisibles: un hilo no puede ver un estado intermedio de una escritura. Esto funciona porque el compilador y el hardware se coordinan para utilizar instrucciones específicas de la CPU (como LOCK CMPXCHG en x86) que aseguran la atomicidad a nivel de caché y evitan que otros núcleos vean datos inconsistentes.
Debes usar estas primitivas cuando necesites implementar estructuras de datos lock-free o contadores compartidos donde la contención sea alta y el tiempo de espera de un mutex sea inaceptable. Sin embargo, si intentas usar std::atomic con tipos que no sean trivially copyable, entrarás en el terreno del undefined behavior (UB), ya que la atomicidad requiere que el objeto pueda ser movido o copiado mediante instrucciones de bus de memoria, no mediante llamadas a constructores complejos. Si no gestionas correctamente el modelo de memoria (memory ordering), el compilador o la CPU podrían reordenar tus instrucciones de forma que una bandera de “listo” se vea como escrita antes que los datos que la preceden, causando fallos catastróficos difíciles de depurar.
#include <atomic>
#include <iostream>
#include <thread>
#include <vector>
#include <cassert>
// Representa un contador de alto rendimiento con lógica personalizada
class LockFreeCounter {
std::atomic<int> value_{0};
public:
// Incremento condicional usando CAS (Compare-And-Swap)
// Implementa una operación compleja que no existe como fetch_add
void increment_if_not_limit(int limit) {
int current = value_.load(std::memory_order_relaxed);
// Usamos compare_exchange_weak en un bucle.
// Es preferible a 'strong' en arquitecturas RISC (como ARM)
// porque permite fallos espurios, lo que permite que la CPU
// sea más eficiente en el hardware.
while (current < limit &&
!value_.compare_exchange_weak(current, current + 1,
std::memory_order_release,
std::memory_order_relaxed)) {
// Si la comparación falla, 'current' se actualiza automáticamente
// con el valor actual de 'value_', por lo que no necesitamos re-leer.
}
}
int get() const { return value_.load(std::memory_order_acquire); }
};
struct SharedData {
int raw_data = 0; // Dato normal, no atómico
};
int main() {
LockFreeCounter counter;
SharedData data;
// C++20: std::atomic_ref permite tratar un objeto no-atómico
// como atómico durante un ámbito específico sin cambiar su tipo original.
// Esto es vital para optimizar buffers de datos pre-existentes.
auto worker = [&](int iterations) {
for (int i = 0; i < iterations; ++i) {
counter.increment_if_not_limit(10000);
// Operación atómica sobre un tipo normal mediante atomic_ref
std::atomic_ref<int> ref(data.raw_data);
ref.fetch_add(1, std::memory_order_relaxed);
}
};
std::vector<std::thread> threads;
for (int i = 0; i < 4; ++i) {
threads.emplace_back(worker, 2500);
}
for (auto& t : threads) {
t.join();
}
std::cout << "Counter: " << counter.get() << "\n";
std::cout << "Raw Data (via atomic_ref): " << data.raw_data << "\n";
// Verificación de capacidades del hardware
if (counter.get() >= 0) {
std::cout << "Implementación lock-free detectada.\n";
}
return 0;
}
Desglose del ejemplo
En la clase LockFreeCounter, la función increment_if_not_limit implementa un patrón clásico de lock-free programming. El corazón aquí es compare_exchange_weak. A diferencia de compare_exchange_strong, la versión weak puede devolver false incluso si los valores son iguales (un “fallo espurio”), lo cual es una característica de ciertas arquitecturas para evitar la sobrecarga de bucles internos de hardware. Al estar dentro de un while, aprovechamos esto: si la operación falla, el parámetro current es actualizado por la propia función con el valor más reciente de value_, permitiendo que la siguiente iteración del bucle intente la operación de nuevo inmediatamente.
Para la sincronización de memoria, utilizamos std::memory_order_release en la escritura exitosa y std::memory_order_acquire en la lectura (get()). Esto establece una relación happens-before entre el hilo que escribe y el que lee, garantizando que cualquier cambio en la memoria que haya ocurrido antes de la escritura sea visible para el hilo que lee. Si usáramos std::memory_order_relaxed, el compilador podría mover instrucciones críticas fuera del alcance de nuestra lógica, invalidando la sincronización.
Fíjate en std::atomic_ref<int> ref(data.raw_data). Esta es una característica de [C++20] que resuelve un problema de diseño histórico: antes de esto, si tenías un std::vector<int> y querías que un elemento fuera atómico durante un cálculo paralelo, tenías que declarar el vector como std::vector<std::atomic<int>>, lo cual impide usar funciones estándar como std::sort (porque std::atomic no es copiable ni movible). Con atomic_ref, podemos tratar un int común como atómico de forma temporal, manteniendo la compatibilidad con el resto del código no-atómico.
El error frecuente
Un error clásico de diseño es intentar implementar una operación atómica de “leer-modificar-escribir” de forma manual con load y store, lo que rompe la atomicidad.
std::atomic<int> x{10};
// ERROR: ESTO NO ES ATÓMICO
if (x.load() == 10) {
// Un hilo puede ser interrumpido aquí
x.store(11);
}
// CORRECTO: Operación indivisible
int expected = 10;
if (x.compare_exchange_weak(expected, 11)) {
// La comprobación y la asignación son una única operación atómica
}
En el código erróneo, entre el load() y el store(), otro hilo podría haber cambiado el valor de x. El hilo actual, al continuar, sobrescribiría el cambio del otro hilo sin saberlo. Este tipo de condiciones de carrera (race conditions) son silenciosas y no suelen ser detectadas por el compilador, aunque herramientas como ThreadSanitizer (-fsanitize=thread en gcc/clang) las capturarían en tiempo de ejecución.
N° 99