Hilos y condiciones de carrera

Lo correcto era 1. Se pidieron dos incrementos y solo uno sobrevive.

counter++ no es un paso indivisible. Tras la instrucción 2, T1 tiene un 1 en su registro, pero todavía no lo ha escrito: counter sigue en 0. El temporizador lo interrumpe justo ahí. T2 lee ese 0, suma 1 y también se queda con un 1. Al final los dos escriben 1. La escritura de T2 es obsoleta: la calculó a partir de un valor que ya no estaba al día, y borra el incremento de T1.

Una sola CPU basta. No hizo falta que los hilos corrieran a la vez en dos núcleos. Bastó con que el temporizador cortara a T1 entre su load y su store.

Esto se llama una condición de carrera: el resultado depende del orden en que el planificador intercala los hilos. El fragmento de código que toca el dato compartido, aquí las tres instrucciones de load a store, es una sección crítica. Lo que necesitamos es exclusión mutua: que, como mucho, un hilo esté dentro de la sección crítica a la vez.

Que funcione en las pruebas no demuestra nada. Con cuanto 3, cada turno contiene un counter++ completo y el resultado es 2. Pero nada en el código lo garantiza: otro hilo, un fallo de página o una interrupción mueven los turnos, y la carrera vuelve. Por eso se dice que el resultado es indeterminado: el mismo programa, con la misma entrada, da 1 o 2.

Un cuanto más largo no lo arregla. En Tres hilos, con cuanto 4, los turnos cortan el segundo incremento entre load y store, y se pierden 2 de 6. Menos interrupciones hacen la carrera más rara, no imposible.

Puede salir muy mal. En Tres hilos con cuanto 2, seis incrementos dejan counter en 2. Una sola escritura obsoleta puede borrar varios incrementos a la vez: todos los que otros hicieron entre su lectura y su escritura. Con dos hilos que hacen n incrementos cada uno (n ≥ 2), el resultado puede bajar hasta 2.

Qué comparten los hilos. El 1 de T1 estaba a salvo en su registro mientras T2 corría, porque cada hilo tiene sus propios registros y el sistema los guarda en cada cambio. counter, en cambio, existe una sola vez en la memoria. Justamente por eso hay carrera.

La solución del hardware: instrucciones atómicas. Los procesadores ofrecen instrucciones de lectura-modificación-escritura que se completan sin que otro hilo toque esa memoria en medio: lock xadd en x86, atomic_fetch_add en C11, std::atomic<int>::fetch_add en C++, AtomicInteger en Java. Con ellas counter++ es una sola operación indivisible y ningún intercalado puede partirla. Para secciones críticas más largas que una instrucción hacen falta cerrojos, el tema del siguiente módulo.

En sistemas reales. Con varios núcleos los hilos corren de verdad en paralelo y las cachés añaden sorpresas (reordenamiento de memoria), pero la actualización perdida aparece ya con un núcleo. En C y C++, dos accesos sin sincronizar a la misma variable, con al menos una escritura, son una carrera de datos y el comportamiento queda indefinido; herramientas como ThreadSanitizer las detectan. En Python, counter += 1 son varias instrucciones de bytecode y tampoco es atómico; la versión sin GIL (con soporte oficial desde Python 3.14) solo hace que la carrera aparezca más a menudo.