Gastón Gaitan

April 29, 2026 · 9 hours, 19 minutes ago

Concurrencia en Python

El GIL en Python: por qué limita el paralelismo y cuándo realmente importa

Entender el Global Interpreter Lock es clave para tomar decisiones correctas de arquitectura en sistemas backend. No es solo un detalle interno de Python: impacta directamente en performance, uso de CPU y diseño de concurrencia.

⚠️ El problema

Queremos usar múltiples threads para ejecutar tareas en paralelo, pero Python no aprovecha múltiples núcleos en tareas de cómputo.

💡 La realidad

Python sí permite múltiples threads, pero el GIL hace que solo uno ejecute código Python a la vez dentro de un proceso.

📌 Aclaración

El GIL no elimina los threads. Solo evita que se ejecuten en paralelo real cuando el trabajo es CPU-bound.

🧠 Antes que nada: ¿qué es un thread y qué es un proceso?

Estos dos conceptos son fundamentales en programación. Aparecen en todos los lenguajes y sistemas operativos modernos. Si los entendés bien, el GIL deja de ser un misterio.

🧵 Thread (hilo)

Un thread es la unidad más pequeña de ejecución dentro de un proceso. Varios threads comparten la misma memoria y los mismos recursos.

Ejemplo palpable: imaginá un restaurante (proceso) con varios mozos (threads) que comparten la misma cocina, las mismas mesas y la misma caja registradora. Cada mozo atiende mesas distintas, pero todos trabajan en el mismo local.

⚙️ Proceso

Un proceso es un programa en ejecución con su propia memoria, su propio espacio de direcciones y sus propios recursos del sistema operativo.

Ejemplo palpable: cada restaurante de una cadena (Chrome, Spotify, VS Code abiertos a la vez) es un proceso independiente. Cada uno tiene su propia cocina, su propio personal y su propia caja. No comparten nada entre sí salvo lo que el SO les permite.

🎯 Diferencia clave: los threads son livianos y comparten memoria (rápidos de crear, pero peligrosos si no se sincronizan). Los procesos son pesados y aislados (más seguros, pero más caros de crear y comunicar).

🔒 Qué es el GIL y por qué existe

El GIL (Global Interpreter Lock) es un mecanismo del intérprete estándar de Python (CPython) que asegura que solo un thread ejecute bytecode de Python a la vez dentro de un proceso.

Su principal objetivo no es limitar performance, sino simplificar la gestión de memoria interna. Python utiliza conteo de referencias para liberar objetos automáticamente.

Si múltiples threads modificaran ese contador al mismo tiempo, podrían generarse race conditions graves: memoria liberada dos veces, objetos corruptos o crashes del intérprete. El GIL actúa como un candado global que evita ese problema.

Thread 1

↓

🔒 GIL (lock activo)

↓

Ejecuta Python

↓

⏳ Thread 2 esperando

⚡ Qué implica en la práctica

Aunque creemos múltiples threads, estos no se ejecutan en paralelo real para tareas intensivas de CPU. En lugar de eso, el intérprete va alternando la ejecución entre ellos (lo que se conoce como concurrencia, no paralelismo).

✅ Los threads existen
✅ Comparten memoria
🔄 Pero se ejecutan por turnos
❌ No hay paralelismo real en CPU-bound

🚦 CPU-bound vs I/O-bound: dónde impacta realmente

🔥 CPU-bound (cómputo intensivo)

Procesamiento matemático
Algoritmos pesados (ML, criptografía)
Loops intensivos, compresión de datos

Acá el GIL es un cuello de botella porque impide usar múltiples núcleos.

🌊 I/O-bound (espera externa)

Requests HTTP / APIs externas
Lectura/escritura de archivos
Consultas a bases de datos

Acá los threads sí son útiles porque liberan el GIL mientras esperan.

📄 gil_cpu_problem.py

Ejemplo: threads no escalan en CPU-bound

import threading
import time
def task():
    x = 0
    for _ in range(10_000_000):
        x += 1
threads = []
start = time.time()
for _ in range(4):
    t = threading.Thread(target=task)
    t.start()
    threads.append(t)
for t in threads:
    t.join()
print(f"Tiempo: {time.time() - start:.2f}s")
# 4 threads tardan ≈ lo mismo que 1 solo. El GIL los serializa.

🚀 La solución: multiprocessing para paralelismo real

Para tareas CPU-bound, la solución es usar multiprocessing. Cada proceso tiene su propio intérprete y su propio GIL, lo que permite ejecutar código en paralelo real usando todos los núcleos del CPU.

Proceso 1 → Core 1

↓

Proceso 2 → Core 2

↓

Proceso 3 → Core 3

↓

✨ Paralelismo real

🌍 ¿Y por qué C y Java no tienen este "problema"?

Lenguajes como C, C++, Rust, Go o Java no tienen un GIL. Sus threads corren realmente en paralelo en múltiples núcleos. La razón está en cómo gestionan la memoria y cómo se compilan.

⚙️ C / C++ (compilados a nativo)

Compilan directamente a código máquina que ejecuta el CPU. No hay un intérprete intermedio que necesite proteger sus estructuras internas.

La gestión de memoria es manual (malloc/free) o vía RAII en C++. El programador es responsable de sincronizar (mutex, semáforos), pero el lenguaje permite paralelismo total.

☕ Java (compilado a bytecode + JIT)

Compila a bytecode que corre sobre la JVM. La JVM usa un Garbage Collector sofisticado (G1, ZGC) y estructuras internas thread-safe.

No necesita un lock global porque la JVM fue diseñada desde el día uno para multithreading real, con primitivas como synchronized y java.util.concurrent.

🦀 Rust / 🐹 Go (modernos)

Rust garantiza seguridad de memoria en compile-time con su sistema de ownership: paralelismo sin data races sin necesidad de un GIL.

Go usa goroutines ligeras (M:N scheduling) que se distribuyen automáticamente entre núcleos.

📝 Importante: Python también es compilado, pero a bytecode interpretado por CPython. La diferencia con Java es que CPython no fue diseñado originalmente con multithreading paralelo en mente, y cambiar eso ahora rompería décadas de extensiones nativas en C que dependen del GIL.

📊 Threads vs Procesos

Característica	Threads	Procesos
Memoria	Compartida	Separada (aislada)
GIL	Compartido	Uno por proceso
Costo de creación	Bajo (rápido)	Alto (lento)
Comunicación	Variables compartidas	IPC (pipes, queues, sockets)
CPU-bound	❌ No escala	✅ Escala
I/O-bound	✅ Muy útil	Menos necesario

💡 Idea clave: el problema no es Python, es usar la herramienta incorrecta para el tipo de tarea.

🆚 Comparativa entre lenguajes

Lenguaje	Compilación	¿Tiene GIL?	Threads paralelos reales
Python (CPython)	Bytecode interpretado	Sí 🔒	No
C / C++	Nativo	No	Sí ✅
Java	Bytecode + JIT (JVM)	No	Sí ✅
Go	Nativo	No	Sí ✅ (goroutines)
Rust	Nativo	No	Sí ✅ (con safety)
JavaScript (Node)	JIT (V8)	N/A (single-thread)	Worker threads / cluster

📄 ParallelDemo.java

El mismo ejemplo en Java: paralelismo real

public class ParallelDemo {
    public static void main(String[] args) throws InterruptedException {
        Thread[] threads = new Thread[4];
        for (int i = 0; i < 4; i++) {
            threads[i] = new Thread(() -> {
                long x = 0;
                for (int j = 0; j < 10_000_000; j++) x++;
            });
            threads[i].start();
        }
        for (Thread t : threads) t.join();
        // 4 threads ejecutan en paralelo real → ≈ 4x más rápido
    }
}

🔮 El futuro: ¿Python sin GIL?

La gran noticia es que la comunidad de Python está trabajando activamente para eliminar el GIL. Esto se materializó en el PEP 703, aprobado por el Steering Council, que introduce el modo "free-threaded Python" (también conocido como nogil).

📅 Hitos del nogil:

Python 3.13 (2024): primera versión experimental con build opcional --disable-gil.
Python 3.14 (2025): el modo free-threaded pasa a ser oficialmente soportado (aún opcional).
Python 3.15+ (futuro): el plan es que se vuelva el modo por defecto, una vez que el ecosistema (NumPy, PyTorch, librerías en C) esté adaptado.

⚠️ El cambio no es trivial: implica re-implementar el conteo de referencias de forma thread-safe, adaptar miles de extensiones en C y aceptar una pequeña pérdida de performance en código single-threaded a cambio de paralelismo real.

🎯 Conclusión

El GIL no es un bug ni una limitación accidental, sino una decisión de diseño que simplifica el manejo de memoria en CPython.

Entender cuándo impacta y cuándo no es lo que diferencia a alguien que "usa Python" de alguien que realmente diseña sistemas con Python.

En resumen: threads para I/O, multiprocessing para CPU, y atentos al nogil 👀