Concorrência, paralelismo e o GIL

Duas ideias que parecem a mesma

Muita gente usa concorrência e paralelismo como sinônimos, e não são. Concorrência é uma questão de estrutura: você organiza o programa em tarefas que podem avançar de forma independente, e o sistema alterna entre elas rápido o bastante para parecer que rodam juntas. Paralelismo é uma questão de execução: você tem vários núcleos de processador fazendo trabalho de fato no mesmo instante. Um cozinheiro que cuida de três panelas revezando a atenção é concorrente; três cozinheiros, um em cada panela, são paralelos. Dá para ter concorrência sem paralelismo, e é exatamente isso que as threads do Python entregam na maioria dos casos.

O GIL, a trava que explica tudo

O GIL, ou Global Interpreter Lock, é uma trava global do interpretador CPython, a implementação padrão do Python. A regra dele é simples e drástica: só uma thread pode executar bytecode Python por vez. Mesmo que a sua máquina tenha oito núcleos, duas threads suas nunca rodam código Python puro ao mesmo tempo; elas se revezam, uma segurando a trava enquanto a outra espera. O GIL existe por um bom motivo. Ele simplifica o gerenciamento de memória do interpretador e protege as estruturas internas contra corrupção quando várias threads mexem nos mesmos objetos. O preço desse conforto é o paralelismo de CPU.

A grande sacada é entender quando o GIL é liberado. Quando uma thread faz uma operação de entrada e saída, como ler de um arquivo, chamar uma URL ou consultar um banco, ela solta o GIL enquanto espera a resposta. Nesse intervalo, outra thread pega a trava e trabalha. Como programas de rede passam a maior parte do tempo esperando, e não calculando, o revezamento acontece o tempo todo e o ganho é real. Já uma thread que só faz conta, sem parar para esperar nada, segura o GIL do começo ao fim, e as outras ficam na fila. Por isso threads não aceleram cálculo puro no CPython.

Quando threads valem a pena

A conclusão prática cabe em uma frase: threads no Python servem para tarefas que esperam, não para tarefas que calculam. Se o seu programa baixa cinquenta páginas da internet, cada download passa quase todo o tempo esperando a resposta do servidor. Com threads, enquanto uma espera, as outras já disparam seus pedidos, e o tempo total despenca. Esse é o cenário I/O bound, o reino das threads. Já se o programa precisa fatorar números gigantes ou processar imagens pixel a pixel, ele é CPU bound: o gargalo é a conta, o GIL serializa tudo e as threads só adicionam overhead. Aí o caminho é multiprocessing ou async, que você vê nos próximos módulos.