Cuando varios threads comparten datos, sus operaciones pueden entrelazarse (interleave) en medio de una actualización de varios pasos, produciendo una race condition — un bug donde el resultado depende de un timing impredecible. La sincronización es el conjunto de herramientas que fuerzan un orden seguro.
parece atómico pero en realidad es read-modify-write:
count++// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐ interleaving loses an update:
// thread B: read count (0) ─┤ both read 0, both write 1 → count == 1, not 2
// thread A: write 1 │
// thread B: write 1 ┘
La ventana entre leer y escribir es una critical section (sección crítica) — código que toca estado compartido y no debe ejecutarse de forma concurrente.
pthread_mutex_lock(&m);
count++; // sección crítica — exclusiva
pthread_mutex_unlock(&m);
Los locks resuelven las races pero introducen nuevos riesgos: deadlock (threads esperando los locks de los demás), priority inversion, y contention (los threads se serializan, matando el paralelismo). La regla general: mantén las critical sections cortas, y adquiere siempre varios locks en un orden global consistente.
Los bugs de concurrencia están entre los más difíciles de encontrar — son no deterministas y a menudo desaparecen bajo un debugger. Los entrevistadores quieren ver que puedes detectar una critical section, elegir el primitivo correcto (mutex vs semaphore vs atomic), y razonar sobre los modos de fallo (deadlock, contention). Esto aplica directamente a cualquier servidor multihilo, cache compartida o contador.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar