Múltiples QThread, QMutex y concurrencia
Manejar varios QThread a la vez, proteger zonas críticas con QMutex y por qué las señales son la forma segura de actualizar la GUI desde múltiples hilos.
memory
Múltiples QThread
Hasta ahora teníamos un QThread. Ahora queremos una cantidad variable ejecutándose a la vez. La clave: siempre guardar una referencia en memoria a cada QThread.
Si no guardas la referencia, el _garbage collector_ puede recolectar el objeto y el thread "desaparece". Por eso se usa una lista donde se almacena cada QThread creado.
python
class MiThread(QThread): # Señal con varios parámetros: (indice, texto) senal_actualizar = pyqtSignal(int, str) def __init__(self, indice: int, tiempo: float) -> None: super().__init__() self.indice = indice self.tiempo = tiempo def run(self) -> None: for i in range(10): sleep(self.tiempo) self.senal_actualizar.emit(self.indice, str(i)) self.senal_actualizar.emit(self.indice, 'Status: QThread terminado')python
def ejecutar_threads(self) -> None: for thread in self.threads: if thread.isRunning(): return self.threads = [] for i in range(1, 6): thread = MiThread(i, i / 10) thread.senal_actualizar.connect(self.actualizar_labels) self.threads.append(thread) # guardamos la referencia thread.start()Fíjate que la señal lleva dos parámetros (int, str): el índice identifica a qué _label_ corresponde el mensaje, de modo que cada thread actualiza el suyo.
Si no guardas la referencia al QThread en una variable o lista, el recolector de basura puede eliminarlo y el thread dejará de funcionar de forma impredecible.
Advertencia
Cargando Quiz...
tune
QMutex: zona crítica
Así como QThread es la versión PyQt de Thread, QMutex es la versión PyQt del _lock_. Permite controlar el acceso de varios threads a una zona crítica de código.
Con los métodos lock() y unlock() garantizamos que cierto fragmento sea ejecutado por un solo thread a la vez.
python
from PyQt6.QtCore import QMutex class MiThread(QThread): senal_actualizar = pyqtSignal(int, str) def __init__(self, indice, tiempo, mutex: QMutex) -> None: super().__init__() self.indice = indice self.tiempo = tiempo self.mutex = mutex schema
Señales vs. cambio directo
¿Qué pasa si, en lugar de usar señales, cada thread modifica directamente la interfaz (por ejemplo con label.move(x, y))? Con pocos threads parece funcionar, pero al crear decenas o centenas el programa colapsa o deja de verse el movimiento.
python
# MAL: el thread modifica la GUI directamenteclass Cuadrado(QThread): @posicion.setter def posicion(self, nueva): self._posicion = nueva x, y = nueva self.label.move(x, y) # cambio directo a la interfaz desde el threadEl problema: muchos threads hacen cambios directos y casi simultáneos sobre la interfaz, abriendo la puerta a errores de concurrencia clásicos.
architecture
Ejemplo aplicado: front-end y back-end
Reuniendo todo, se construye una app donde varios cuadrados se mueven de un extremo a otro a distinta velocidad, y al hacer clic en uno cambia de color y se detiene. Cada cuadrado se modela con un QThread.
El proyecto se modulariza separando responsabilidades:
main.py: archivo principal a ejecutar.parametros_general.py: constantes compartidas por back-end y front-end.backend/: la lógica del movimiento (logica_qthread.pyconQThread, ologica_thread.pyconthreading.Thread).frontend/ventana.py: la ventana y todo lo visual.
La gran ventaja de esta separación: el backend/logica_qthread.py y el backend/logica_thread.py son intercambiables. La única diferencia es la herencia (y marcar el Thread como _daemon_). Cambiando ese archivo, el front-end no se toca y el programa sigue funcionando igual.
Una buena modularización front-end / back-end permite cambiar la implementación interna (de QThread a threading) sin alterar la interfaz. El front depende del contrato, no de los detalles del back.
Tip
Cargando Quiz...