Fundamentos

Riesgos del estado compartido

Dos hilos que tocan la misma variable sin coordinarse producen resultados que dependen del azar del planificador. En una planta eso significa contadores de piezas que no cuadran, motores que se activan dos veces o robots que colisionan. Estos son los fallos que hay que conocer antes de escribir la primera línea de sincronización.

Condición de carrera

Dos hilos de una línea de envasado comparten el contador de cajas que faltan por llenar:

int cajasPendientes = 0;   // COMPARTIDO por dos hilos

void hCintaA() {
    // ... llega una caja ...
    cajasPendientes = cajasPendientes + 1;   // ← no atómico
}

void hCintaB() {
    // ... llega otra caja ...
    cajasPendientes = cajasPendientes + 1;   // ← no atómico
}

x = x + 1 son en realidad tres pasos: leer el valor, sumar y escribir. Si ambos hilos leen el mismo valor antes de que ninguno escriba, una de las cajas se pierde:

El resultado correcto era 2; el real, 1. El fallo depende del interleaving (entrelazado) de las instrucciones y por eso es tan difícil de reproducir: «en las pruebas siempre funcionaba».

Atomicidad

Una operación es atómica cuando se ejecuta como un todo indivisible: ningún hilo puede observar ni interrumpir un estado intermedio. x++ no lo es en la mayoría de arquitecturas; las operaciones sobre std::atomic<int> sí lo son (se estudian en Atómicos). La otra forma de conseguir atomicidad es encerrar la región crítica con un mutex.

Data race: comportamiento indefinido

Cuando dos hilos acceden a la misma posición de memoria, al menos uno escribe, y no hay sincronización entre ellos, el estándar lo llama data race y el programa tiene comportamiento indefinido: puede dar valores erróneos, corromper estructuras o fallar solo en producción. Detectarlos a ojo es imposible; para eso existen las herramientas:

• ThreadSanitizer (-fsanitize=thread en GCC/Clang): avisa de data races en tiempo de ejecución.
• Helgrind / DRD (Valgrind): detecta carreras y mal uso de candados.
• Analizadores estáticos (clang-tidy, Visual Studio): encuentran patrones sospechosos sin ejecutar.

# Compila con información de depuración y ThreadSanitizer
g++ -std=c++20 -g -fsanitize=thread planta.cpp -o planta -pthread
./planta        # el informe de carreras aparece en la consola

Interbloqueo (deadlock)

Dos hilos se esperan mutuamente y ninguno puede avanzar. El ejemplo clásico con dos recursos (la prensa y el robot):

• El hilo de la prensa toma el mutex de la prensa y pide el del robot.
• El hilo de entrada toma el mutex del robot y pide el de la prensa.
• Cada uno tiene lo que el otro necesita: bloqueo permanente.

Reglas para evitarlo:

1. Orden fijo de adquisición: todos los hilos toman los candados en el mismo orden.
2. std::scoped_lock: toma varios mutex de una vez con algoritmo anti-deadlock.
3. No mantener candados mientras se espera por otro recurso bloqueante.
4. Usar esperas con timeout (try_acquire_for, wait_for) para detectar el problema.

Inanición y prioridad inversa

• Inanición (starvation): un hilo nunca consigue el recurso porque otros lo acaparan. Se evita con colas de espera justas (FIFO) o turnos.
• Inversión de prioridad: un hilo de baja prioridad retiene un mutex que necesita uno de alta; en tiempo real se mitiga con herencia de prioridad o protocolos de acceso.

Resumen de amenazas