Hilos
En resumen: Un hilo es una línea de ejecución separada dentro del programa; en Python el GIL deja que un solo hilo ejecute código a la vez, por eso los hilos ayudan cuando el programa espera.
Problema
Tres informes, uno tras otro
time.sleep(segundos) detiene el programa durante esos segundos.import time
def download(file, seconds): time.sleep(seconds) print(f"Descargué {file}")
download("marzo.pdf", 0.6)download("abril.pdf", 0.2)download("mayo.pdf", 0.4)print("Listo")Descargué marzo.pdfDescargué abril.pdfDescargué mayo.pdfListoLa idea
Proceso e hilo
Cuando ejecutas el programa, el sistema operativo le da un proceso: su propia memoria, sus propios archivos abiertos. Dentro del proceso trabajan uno o más hilos (threads). Un hilo es una secuencia de instrucciones que se ejecutan una tras otra. Hasta ahora, cada uno de tus programas tenía un solo hilo: el que ejecuta el archivo de arriba abajo.
Los hilos de un mismo proceso comparten su memoria: ven los mismos objetos. Eso los hace prácticos (se pasan datos con facilidad) y peligrosos (pueden estorbarse entre sí, como verás en un momento).
- En paralelo significa de verdad al mismo tiempo, en distintos núcleos del procesador.
- Concurrente significa en un solo núcleo, turnándose tan rápido que parece al mismo tiempo.
Para quien programa, la diferencia rara vez importa: en los dos casos no sabes qué hilo continuará y cuándo.
Python (CPython, el de python.org) tiene una trampa: el GIL (global interpreter lock). En cada momento solo un hilo ejecuta código Python, aunque el procesador tenga muchos núcleos. Por eso los hilos ayudan cuando el programa espera (red, archivos, sleep): mientras uno espera, otro trabaja. Para cálculos pesados los hilos no aceleran nada. Ahí se usan procesos, que verás en el ejercicio.
Más precisamente, para curiosos
- El navegador Chrome lanza un proceso aparte para cada pestaña. Por eso un sitio que se cuelga no detiene a los demás, y también por eso el navegador usa mucha memoria.
- Todo programa que hace varias cosas a la vez usa hilos: un juego reproduce el sonido en un hilo y ejecuta la lógica en otro; un servidor web atiende a cada cliente en su propio hilo.
- El precio: cada hilo tiene su propia pila, y la memoria para ella se reserva por separado. Miles de hilos cuestan mucho. Por eso los programas reales usan un grupo de hilos (la última idea de la lección). - Python 3.13 tiene además una versión aparte sin GIL (free-threaded). Todavía es experimental, así que aquí hablamos del Python normal.
Míralo
El primer hilo
La clase Thread del módulo threading es un hilo. Con target le dices qué función ejecutar, y con args qué argumentos pasarle (una tupla):
worker = threading.Thread(target=download, args=("abril.pdf", 0.2))worker.start()print("El programa no espera")worker.join()print("El informe está descargado")El programa no esperaDescargué abril.pdfEl informe está descargadostart()lanza el hilo nuevo y vuelve enseguida. El programa sigue sin esperar, por eso «El programa no espera» se imprime primero.join()hace que el programa espere a que el hilo termine.
download es la función de la primera tarjeta. Python no tiene excepciones comprobadas, así que aquí no hay nada que declarar.
Más precisamente, para curiosos
target es la forma más corta, pero no la única. También te encontrarás una subclase de Thread que escribe su propio run(), y una lambda:class ReportThread(threading.Thread): def run(self): print("1. una subclase de Thread")
def report_job(): print("2. una función como target")
a = ReportThread()b = threading.Thread(target=report_job)c = threading.Thread(target=lambda: print("3. una lambda"))for t in [a, b, c]: t.start() t.join()1. una subclase de Thread2. una función como target3. una lambdaMíralo
Tres a la vez
start = time.time()march = threading.Thread(target=download, args=("marzo.pdf", 0.6))april = threading.Thread(target=download, args=("abril.pdf", 0.2))may = threading.Thread(target=download, args=("mayo.pdf", 0.4))march.start()april.start()may.start()march.join()april.join()may.join()seconds = time.time() - startprint(f"Listo en menos de un segundo: {seconds < 1}")Descargué abril.pdfDescargué mayo.pdfDescargué marzo.pdfListo en menos de un segundo: TrueLos hilos arrancan en el orden marzo, abril, mayo, pero terminan en el orden de las pausas: abril (0,2 s), mayo (0,4 s), marzo (0,6 s). La espera completa dura lo que la más larga, 0,6 segundos en lugar de 1,2.
El sistema operativo decide en qué orden llegan los hilos aprint. Aquí las pausas son lo bastante distintas, así que el orden es siempre el mismo. Si fueran iguales, podría cambiar en cada ejecución.Pruébalo
start o run
¿Qué imprimirá el programa? (name es el nombre del hilo)
class Report(threading.Thread): def run(self): print(f"Se ejecuta en: {threading.current_thread().name}")
t = Report(name="descarga")t.run()t.start()t.join()t.run() es una llamada normal a un método: el código se ejecuta enseguida, en el hilo principal, que Python llama MainThread. No hay ningún hilo nuevo. Solo t.start() lanza el hilo «descarga», que ejecuta el mismo run(). Escribir run() en lugar de start() es un error frecuente: el programa funciona, solo que nada va al mismo tiempo.La idea
La vida de un hilo
is_alive() te dice si el hilo está trabajando en este momento: desde start() hasta el final de su función:t = threading.Thread(target=download, args=("mayo.pdf", 0.5))print(t.is_alive())t.start()time.sleep(0.1)print(t.is_alive())t.join()print(t.is_alive())try: t.start()except RuntimeError as e: print(f"RuntimeError: {e}")FalseTrueDescargué mayo.pdfFalseRuntimeError: threads can only be started oncePython no te dice más que eso: no se ve si espera o calcula. Un hilo se lanza una sola vez. Un segundo start() sobre el mismo hilo lanza RuntimeError.
Más precisamente, para curiosos
- Un hilo en Python no se puede detener desde fuera. Si tiene que detenerse, él mismo comprueba una señal, por ejemplo un
threading.Eventque otro hilo activa conset(). nameynative_idson el nombre y el número del hilo.threading.current_thread()te da el hilo en el que se está ejecutando el código.time.sleep(0)sugiere que el hilo puede ceder el paso a otro. Lo usaremos en un momento.
Problema
Las visitas perdidas
increment() 10 000 veces. Entre leer y escribir el contador, el hilo hace otra cosa. Aquí eso es time.sleep(0): «deja trabajar a los otros hilos un momento»:class Counter: def __init__(self): self.count = 0
def increment(self): value = self.count time.sleep(0) # aquí el hilo cede el paso al otro self.count = value + 1
visits = Counter()
def work(): for i in range(10_000): visits.increment()
first = threading.Thread(target=work)second = threading.Thread(target=work)first.start()second.start()first.join()second.join()print(f"Visitas: {visits.count}")Esperas 20 000. Cinco ejecuciones:
Visitas: 10000Visitas: 10001Visitas: 10001Visitas: 10000Visitas: 10000Cada vez menos, casi la mitad. La razón es que el aumento no es un solo paso, sino tres:
value = self.count # 1. leervalue = value + 1 # 2. sumar 1self.count = value # 3. escribirclass Counter: def __init__(self): self.count = 5 self.lock = threading.Lock()
def increment(self): self.count += 1 # leer, sumar 1, escribir
def safe_increment(self): with self.lock: self.count += 1Paso a paso, en palabras
- count vale 5. Los hilos A y B llaman a increment() al mismo tiempo.
- A lee count: 5.
- B lee count antes de que A haya escrito: también 5.
- A suma 1 en su propia copia y escribe 6.
- B también escribe 6. Dos llamadas, y count vale 6, no 7: una de las sumas se ha perdido.
- Otra vez desde el principio, con with self.lock: A toma el cerrojo, lee 5 y escribe 6.
- B llega a with self.lock y espera hasta que A suelte el cerrojo.
- B toma el cerrojo, lee 6 y escribe 7: no se pierde nada.
Cuando los dos hilos leen el mismo valor antes de que alguno haya escrito, una de las sumas se pierde. Esto se llama condición de carrera (race condition). Que ocurra o no depende de cuándo se cambia de hilo, por eso el resultado es distinto en cada ejecución.
Más precisamente, para curiosos
Sin time.sleep(0), con self.count += 1 y 100 000 aumentos por hilo, cinco ejecuciones en Python 3.12 dieron cinco veces 200 000:
class Counter: def __init__(self): self.count = 0
def increment(self): self.count += 1Visitas: 200000Visitas: 200000Visitas: 200000Visitas: 200000Visitas: 200000No es porque sea seguro. El GIL cambia de hilo solo en ciertos puntos de la ejecución, y aquí, por casualidad, no es entre la lectura y la escritura. Python no lo promete: otra versión, otro código en el método o Python sin GIL pierden visitas. Por eso los datos compartidos se protegen siempre con un cerrojo.
La idea
Lock: de uno en uno
threading.Lock: el bloque with self.lock: es para un solo hilo en cada momento:class Counter: def __init__(self): self.count = 0 self.lock = threading.Lock()
def increment(self): with self.lock: value = self.count time.sleep(0) self.count = value + 1Visitas: 20000El hilo toma el cerrojo al entrar en with y lo suelta al salir, incluso si hay una excepción. El otro hilo espera delante del with. Ahora el resultado es 20 000 en cada ejecución. Python no tiene un contador atómico ya hecho como Java: el cerrojo es la forma.
Más precisamente, para curiosos
Condition:wait()ynotify_all(): un hilo dentro del bloque with de una Condition puede soltar el cerrojo y dormirse hasta que otro hilo lo despierte. Así la cocina espera un pedido, y la caja espera a que la cocina recoja el anterior (el problema del «productor y consumidor»):
class OrderBox: def __init__(self): self.order = None self.changed = threading.Condition()
def put(self, new_order): with self.changed: while self.order is not None: self.changed.wait() self.order = new_order self.changed.notify_all()
def take(self): with self.changed: while self.order is None: self.changed.wait() result = self.order self.order = None self.changed.notify_all() return result
box = OrderBox()
def kitchen(): for i in range(3): print(f"La cocina recibió {box.take()}")
cook = threading.Thread(target=kitchen)cook.start()box.put("pizza")box.put("ensalada")box.put("sopa")cook.join()La cocina recibió pizzaLa cocina recibió ensaladaLa cocina recibió sopawait() está dentro de un while, no de un if: el hilo puede despertarse sin motivo, así que vuelve a comprobar la condición. queue.Queue(maxsize=1) hace lo mismo ya hecho: put espera si la cola está llena, y get espera si está vacía.
- Interbloqueo (deadlock): dos hilos se esperan mutuamente para siempre. La oficina tiene la impresora y espera el escáner, y la recepción tiene el escáner y espera la impresora:
printer = threading.Lock()scanner = threading.Lock()
def office(): with printer: time.sleep(0.1) with scanner: print("La oficina está copiando")
def reception(): with scanner: time.sleep(0.1) with printer: print("La recepción está copiando")El programa se cuelga y nunca imprime nada. La forma de evitarlo es que todos los hilos tomen los cerrojos en el mismo orden.
- Los hilos en Python no tienen prioridades. Hay hilos en segundo plano (
daemon=True): el programa termina sin esperarlos:
report = threading.Thread(target=download, args=("anual.pdf", 0.1), daemon=True)print(report.name, report.daemon)Thread-1 (download) TruePruébalo
Dos cajeros automáticos
Elige la línea con el error.
La comprobación self.balance >= amount y el retiro no son un todo. Si se cambia de hilo entre ellos, los dos ven 100 y los dos retiran. Con el GIL ocurre pocas veces, y eso hace el error traicionero: pasa mil veces y falla en casa del cliente. La corrección es un cerrojo alrededor de las dos líneas:
class Account: def __init__(self): self.balance = 100 self.lock = threading.Lock()
def withdraw(self, amount): with self.lock: if self.balance >= amount: self.balance -= amountEntonces el segundo cajero espera al primero, ve 20 € y rechaza el retiro. El saldo se queda en 20 €.
La idea
Grupo de hilos y Future
ThreadPoolExecutor (de concurrent.futures):def size_of(file, seconds): time.sleep(seconds) return len(file) * 100files = ["marzo.pdf", "abril.pdf", "mayo.pdf", "junio.pdf"]with ThreadPoolExecutor(max_workers=2) as pool: sizes = [pool.submit(size_of, file, 0.3) for file in files] for file, size in zip(files, sizes): print(f"{file}: {size.result()} KB")marzo.pdf: 900 KBabril.pdf: 900 KBmayo.pdf: 800 KBjunio.pdf: 900 KBThreadPoolExecutor(max_workers=2)crea un grupo de 2 hilos. Las cuatro tareas se turnan en ellos.submit(función, argumentos)recibe una tarea y enseguida te da unFuture: una promesa de que el resultado llegará.result()espera a que la tarea termine y devuelve el resultado. Si la tarea lanzó una excepción,result()la vuelve a lanzar.withdetiene el grupo al final: espera a que terminen las tareas y detiene sus hilos.
Más precisamente, para curiosos
Future. El final del with espera a todas:with ThreadPoolExecutor(max_workers=2) as pool: for i in range(1, 6): pool.submit(download, f"informe-{i}.pdf", 0.1)print("Todos terminaron.")Descargué informe-2.pdfDescargué informe-1.pdfDescargué informe-3.pdfDescargué informe-4.pdfDescargué informe-5.pdfTodos terminaron.with, escribes pool.shutdown(wait=True) al final.Pruébalo
¿Qué resultado sale primero?
«archivo.zip» tarda 0,6 s en descargarse, y «nota.txt», 0,1 s. ¿Qué imprimirá el programa?
with ThreadPoolExecutor(max_workers=2) as pool: big = pool.submit(size_of, "archivo.zip", 0.6) small = pool.submit(size_of, "nota.txt", 0.1) print(f"Grande: {big.result()}") print(f"Pequeño: {small.result()}")El archivo pequeño de verdad está listo primero. Pero big.result() es la primera línea, y espera al grande. Cuando este llega, small.result() devuelve enseguida, porque el resultado ya está ahí. El orden de la salida es el orden de las llamadas a result(), así que es el mismo en cada ejecución.
Ejercicio
Programas con hilos
Resuélvelos en tu editor.
1. Suma en paralelo. La lista sales tiene 1 000 000 de ventas, sales[i] = i % 100. Divídelo en 4 partes iguales y suma cada una en su propio hilo. Cada hilo escribe en su propio lugar de la lista partial, así que no necesitas sincronización. Espéralos con join y suma las partes:
Partes: [12375000, 12375000, 12375000, 12375000]Total: 49500000Más precisamente, para curiosos
Por el GIL, los cuatro hilos no calculan más rápido que uno. De verdad en paralelo es con procesos: ProcessPoolExecutor lanza copias separadas de Python, cada una con su propio GIL. Se les pasan las partes, y el resultado vuelve:
from concurrent.futures import ProcessPoolExecutor
if __name__ == "__main__": sales = [i % 100 for i in range(1_000_000)] size = len(sales) // 4 chunks = [sales[p * size:(p + 1) * size] for p in range(4)] with ProcessPoolExecutor(max_workers=4) as pool: partial = list(pool.map(sum, chunks)) print(f"Partes: {partial}") print(f"Total: {sum(partial)}")Partes: [12375000, 12375000, 12375000, 12375000]Total: 49500000if __name__ == "__main__": evita que el código principal se ejecute de nuevo en cada proceso: en Windows y macOS un proceso arranca cargando el archivo desde el principio.
2. Descarga con un grupo. Descarga seis informes (marzo.pdf, abril.pdf, mayo.pdf, junio.pdf, julio.pdf, agosto.pdf) con un grupo de 3 hilos. Usa size_of(file, 0.3) de la tarjeta del grupo. Imprime los tamaños en el orden de los archivos, el total, y si todo tardó menos de 1,5 segundos (uno tras otro serían 1,8 s):
marzo.pdf: 900 KBabril.pdf: 900 KBmayo.pdf: 800 KBjunio.pdf: 900 KBjulio.pdf: 900 KBagosto.pdf: 1000 KBTotal: 5400 KBMenos de 1,5 segundos: True3. Un contador sin pérdidas. Cuatro hilos, cada uno con 50 000 visitas, aumentan un contador compartido. Escribe el contador de forma que el resultado sea siempre 200 000. Pruébalo primero sin Lock y con time.sleep(0) entre la lectura y la escritura y mira cuánto se pierde, luego corrígelo con un Lock.
Visitas: 200000Más tareas
- Una prueba para el contador. Escribe una prueba de unittest que lance 8 hilos con 10 000 aumentos cada uno y compruebe 80 000 con
assertEqual. Ejecútala varias veces contra el contador contime.sleep(0)y sin Lock. Un test que falla solo a veces es la señal típica de una condición de carrera. - El interbloqueo. Ejecuta el ejemplo de la impresora y el escáner de «Más precisamente» (con dos hilos y
join) y mira cómo se cuelga. Corrígelo de forma que los dos hilos tomen primero la impresora.
Test