Adriano Vieira

Conheça o “GIL”

O GIL e o futuro - agora presente no Python-3.13 em diante.

O Python Global Interpreter Lock (GIL)¹ é um mecanismo de sincronização que permite que apenas uma thread execute código Python por vez em um processo.

É uma das características mais distintivas e, por vezes, controversas da implementação padrão do Python (CPython).

Como funciona o GIL

O GIL é essencialmente um mutex global que protege o acesso aos objetos Python, impedindo que múltiplas threads nativas executem código Python simultaneamente.

Quando uma thread precisa executar código Python, ela deve primeiro adquirir o GIL. Assim, outras threads ficam bloqueadas até que o GIL seja liberado.

Por que o GIL existe

O GIL foi criado para resolver problemas de gerenciamento de memória no CPython:

Proteção do contador de referências: O Python usa contagem de referências para gerenciamento de memória. Sem o GIL, múltiplas threads poderiam modificar simultaneamente os contadores de referência dos objetos, causando vazamentos de memória ou liberação prematura de objetos.
Simplicidade de implementação: O GIL simplifica significativamente a implementação do interpretador, evitando a necessidade de alocação em toda a base de código.
Proteção de extensões C: Muitas extensões C não são thread-safe, e o GIL garante que não sejam executadas concorrentemente.

Limitações do GIL

O GIL impõe restrições importantes ao paralelismo:

Threading limitado: Threads Python não podem executar código Python verdadeiramente em paralelo, limitando os benefícios do multithreading para tarefas de intensivo de CPU (CPU-intensivas).
Serialização de execução: Mesmo em sistemas multi-core, apenas um core pode executar código Python por vez.
Contenção: Em aplicações com muitas threads, a competição pelo GIL pode causar sobrecarga intensa.

E quando o GIL é liberado

O GIL é automaticamente liberado em certas situações, como:

Durante operações de I/O (leitura/escrita de arquivos, requisições de rede)
Quando executa funções C que explicitamente liberam o GIL
Em intervalos regulares durante loops longos (aproximadamente a cada 100 instruções)
Durante operações que podem bloquear (como time.sleep())

Alternativas e soluções

Multiprocessos: Usar processos separados em vez de threads contorna completamente o GIL, já que cada processo tem seu próprio interpretador.
Extensões C: Operações computacionalmente intensivas podem ser implementadas em C/Cython, que podem liberar o GIL durante a execução.
Implementações alternativas: Uso de diferentes engine como PyPy, Jython e IronPython que têm abordagens diferentes para threading, embora nem todas eliminem completamente o GIL.
Async/await: Para I/O concorrente, a programação assíncrona é frequentemente mais eficiente que threading.

Impacto prático

Para aplicações limitadas a I/O, o GIL raramente é um problema, pois é liberado durante operações de I/O. Para aplicações de uso intensivo de CPU que precisam de paralelismo real, o multiprocessamento ou extensões C são geralmente necessárias.

O GIL continua sendo um tópico de debate na comunidade Python, com propostas periódicas para sua remoção, mas sua eliminação representaria uma mudança estrutural na arquitetura do CPython com implicações significativas para compatibilidade e performance.

Exemplos de código com GIL

Aqui códigos em Python com exemplos práticos demonstrando:

Exemplo 1 - Tarefas CPU-intensivas: Mostra como o GIL impede paralelismo real em cálculos matemáticos. Threads não oferecem desempenho significativo, enquanto processos sim.

Código exemplo

# Exemplo 1: Tarefa CPU-intensiva que demonstra as limitações do GIL
def cpu_intensive_task(n):
    """Função que realiza cálculo intensivo de CPU"""
    result = 0
    for i in range(n):
        result += i ** 2
    return result

def demonstrate_gil_cpu_bound():
    """Demonstra como o GIL limita o paralelismo em tarefas CPU-intensivas"""
    n = 10_000_000

    # Execução sequencial básica
    start_time = time.time()
    _ = [cpu_intensive_task(n) for _ in range(4)]
    sequential_time = time.time() - start_time
    print(f"Execução sequencial: {sequential_time:.2f}s")

    # Execução com threads (limitada pelo GIL)
    start_time = time.time()
    with ThreadPoolExecutor(max_workers=4) as executor:
        _ = list(executor.map(cpu_intensive_task, [n] * 4))

    threading_time = time.time() - start_time
    print(f"Execução com threads: {threading_time:.2f}s")

    # Execução com processos (contorna o GIL)
    start_time = time.time()
    with ProcessPoolExecutor(max_workers=4) as executor:
        _ = list(executor.map(cpu_intensive_task, [n] * 4))

    multiprocessing_time = time.time() - start_time
    print(f"Execução com processos: {multiprocessing_time:.2f}s")

    print(f"Tempos: threads vs sequencial: {sequential_time/threading_time:.2f}x")
    print(f"Tempos: processos vs sequencial: {sequential_time/multiprocessing_time:.2f}x")

Exemplo 2 - Tarefas I/O-intensivas: Demonstra que para operações de I/O (como requisições de rede), o threading funciona bem porque o GIL é liberado durante essas operações.

Código exemplo

# Exemplo 2: Tarefa I/O-bound onde o GIL é liberado
def io_intensive_task(url_id):
    """Simula uma operação de I/O (requisição de rede)"""
    time.sleep(1)  # Simula latência de rede
    return f"Dados do URL {url_id}"

def demonstrate_gil_io_bound():
    """Demonstra como o GIL não impacta tarefas I/O-intensivas"""
    urls = range(5)

    # Execução sequencial
    start_time = time.time()
    _ = [io_intensive_task(url) for url in urls]
    sequential_time = time.time() - start_time
    print(f"Execução sequencial: {sequential_time:.2f}s")

    # Execução com threads (GIL é liberado durante I/O)
    start_time = time.time()
    with ThreadPoolExecutor(max_workers=5) as executor:
        _ = list(executor.map(io_intensive_task, urls))
    threading_time = time.time() - start_time
    print(f"Execução com threads: {threading_time:.2f}s")

    print(f"Temos: threads vs sequencial: {sequential_time/threading_time:.2f}x")

Exemplo 3 - Contenção e Race Conditions: Ilustra como mesmo com o GIL, race conditions podem ocorrer devido à alternância entre threads, e como locks adicionam overhead.

Código exemplo

# Exemplo 3: Demonstração da contenção do GIL
shared_counter = 0
lock = threading.Lock()

def increment_counter_unsafe(iterations):
    """Incrementa contador sem proteção - demonstra race conditions"""
    global shared_counter
    for _ in range(iterations):
        shared_counter += 1

def increment_counter_safe(iterations):
    """Incrementa contador com lock - demonstra overhead de sincronização"""
    global shared_counter
    for _ in range(iterations):
        with lock:
            shared_counter += 1

def demonstrate_gil_contention():
    """Demonstra contenção do GIL e race conditions"""
    global shared_counter
    iterations = 100_000
    num_threads = 4

    # Teste sem lock (race condition)
    shared_counter = 0
    threads = []

    start_time = time.time()
    for _ in range(num_threads):
        thread = threading.Thread(target=increment_counter_unsafe, args=(iterations,))
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()

    unsafe_time = time.time() - start_time
    print(f"Sem lock - Valor esperado: {iterations * num_threads}")
    print(f"Sem lock - Valor obtido: {shared_counter}")
    print(f"Sem lock - Tempo: {unsafe_time:.2f}s")

    # Teste com lock
    shared_counter = 0
    threads = []

    start_time = time.time()
    for _ in range(num_threads):
        thread = threading.Thread(target=increment_counter_safe, args=(iterations,))
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()

    safe_time = time.time() - start_time
    print(f"Com lock - Valor esperado: {iterations * num_threads}")
    print(f"Com lock - Valor obtido: {shared_counter}")
    print(f"Com lock - Tempo: {safe_time:.2f}s")
    print(f"Overhead do lock: {(safe_time - unsafe_time) / unsafe_time * 100:.1f}%")

Exemplo 4 - Alternância do GIL: Visualiza como o interpretador alterna a posse do GIL entre threads diferentes.

Código exemplo

# Exemplo 4: Visualização da alternância do GIL
def gil_switching_demo():
    """Demonstra como threads alternam a posse do GIL"""

    def worker(thread_id):
        for i in range(3):
            print(f"Thread {thread_id}: Executando iteração {i}")
            # Simula trabalho que pode causar alternância do GIL
            sum(range(1000))
            time.sleep(0.1)  # Força liberação do GIL

    threads = []
    for i in range(3):
        thread = threading.Thread(target=worker, args=(i,))
        threads.append(thread)
        thread.start()

    for thread in threads:
        thread.join()

Exemplo 5 - Async vs Threading: Compara programação assíncrona com threading para I/O concorrente.

Código exemplo

# Exemplo 5: Comparação com async/await para I/O
def io_intensive_task(url_id):
    """Simula uma operação de I/O (requisição de rede)"""
    time.sleep(1)  # Simula latência de rede
    return f"Dados do URL {url_id}"

async def async_io_task(task_id):
    """Tarefa assíncrona que simula I/O"""
    await asyncio.sleep(1)
    return f"Resultado async {task_id}"

async def demonstrate_async_vs_threading():
    """Compara threading com programação assíncrona"""
    # Execução assíncrona
    start_time = time.time()
    tasks = [async_io_task(i) for i in range(5)]
    _ = await asyncio.gather(*tasks)
    async_time = time.time() - start_time
    print(f"Execução assíncrona: {async_time:.2f}s")

    # Para comparação, executar threading novamente
    start_time = time.time()
    with ThreadPoolExecutor(max_workers=5) as executor:
        _ = list(executor.map(io_intensive_task, range(5)))
    threading_time = time.time() - start_time
    print(f"Execução com threads: {threading_time:.2f}s")

Resultados esperados dos exemplos:

CPU-bound: Threading será quase tão lento quanto execução sequencial
I/O-bound: Threading mostrará diferenças de tempo significativo
Multiprocessing: Mostrará o melhor diferenças de tempo para CPU-bound
Async: Será eficiente para I/O sem overhead de threads

O GIL pode ser desativado?

SIMMMmmm, o Global Interpreter Lock pode ser desativado, e isso já é uma realidade desde o Python 3.13!

Status Atual - Python 3.13

O Python 3.13, lançado em outubro de 2024, inclui suporte experimental para desabilitar o GIL através do “free-threaded mode”.

Você pode executar a versão sem GIL usando o comando python3.13t no Fedora Linux, por exemplo.

PEP 703 - A Proposta Aprovada

A PEP 703 propõe adicionar uma configuração de build (--disable-gil) ao CPython para executar código Python sem o GIL e com as mudanças necessárias para tornar o interpretador thread-safe.

O Python Steering Council sinalizou intenção de aprovar a PEP 703, a medida que for obtendo retorno positivo da comunidade.

Implementação Gradual

A implementação da PEP 703 é um projeto de longo prazo que ocorrerá em múltiplas etapas ao longo de vários anos, onde o CPython transitará para tornar a versão sem GIL primeiro opcional, depois suportada, e finalmente a versão padrão.

Como faz então

Para testar o Python sem GIL atualmente já se pode instalar a versão experimental já compilada sem, por exemplo:

# Instalar versão experimental
## No Fedora Linux: 
sudo dnf install python3.13-freethreading # Python 3.13 ou
sudo dnf install python3.14-freethreading # Python 3.14

# Ou compilar a partir do código-fonte com:
./configure --disable-gil
make

Limitações Atuais

Experimental: O Python 3.13 oferece apenas um modo experimental que desabilita o GIL
Compatibilidade: Extensões construídas para a ABI estável não funcionarão com o CPython 3.13 sem GIL
Performance: Pode haver degradação de performance em código single-threaded

Implementações Alternativas

Outras implementações Python já ofereciam alternativas ao GIL:

PyPy: Usa STM (Software Transactional Memory)
Jython: Executa na JVM, sem GIL
IronPython: Executa no .NET, sem GIL

Futuro

A Meta² se comprometeu com três anos-engenheiro de suporte (de engenheiros experientes em CPython) entre a aceitação da PEP 703 e o final de 2025 para implementar suavemente a PEP 703 no CPython.

Em resumo: O GIL já pode ser desativado experimentalmente no Python 3.13, e está no caminho para se tornar totalmente opcional e eventualmente removido nas próximas versões do Python.

Referências

Global Interpreter Lock, or GIL https://wiki.python.org/moin/GlobalInterpreterLock ↩︎
Enhancing the Python ecosystem with type checking and free threading, Meta, em https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/ ↩︎

Adriano Vieira

Pythonista - Conheça o Global Interpreter Lock (GIL)

Conheça o “GIL”

Como funciona o GIL

Por que o GIL existe

Limitações do GIL

E quando o GIL é liberado

Alternativas e soluções

Impacto prático

Exemplos de código com GIL

Resultados esperados dos exemplos:

O GIL pode ser desativado?

Status Atual - Python 3.13

PEP 703 - A Proposta Aprovada

Implementação Gradual

Como faz então

Limitações Atuais

Implementações Alternativas

Futuro

Referências

Tabela de conteúdos