Escolher entre threads, processos e asyncio

Em uma execução sequencial, a tarefa B só começa quando a tarefa A termina.

Há concorrência quando mais de uma tarefa faz progresso em períodos que se sobrepõem. Isso pode ocorrer por alternância: enquanto A aguarda algo, B executa.

Há paralelismo quando duas tarefas estão efetivamente executando ao mesmo tempo.

Observe que a sobreposição no tempo não significa, por si só, dois trechos executando no mesmo instante.

Uma tarefa é limitada por entrada e saída (I/O-bound) quando passa a maior parte do tempo aguardando recursos externos, como rede, banco de dados, disco ou outro serviço.

Ela é limitada por processamento (CPU-bound) quando a maior parte do tempo é consumida executando cálculos no processador.

A classificação depende do que domina a duração total, e não apenas de existir uma leitura de arquivo ou um laço no código.

Compare a distribuição de tempo nas duas situações.

Muitas cargas combinam espera e cálculo. Por exemplo, baixar arquivos, decodificá-los e gerar miniaturas envolve rede, armazenamento e processamento.

Nesses casos, não force um único rótulo para o programa inteiro. Descreva as etapas e identifique qual delas tem maior peso no cenário analisado.

Uma mesma carga pode alternar entre espera e trabalho ativo.

Uma thread é um fluxo de execução dentro de um processo. Um mesmo processo pode ter mais de uma thread avançando em tarefas diferentes ao longo do tempo.

A consequência central é que as threads do processo usam o mesmo espaço de memória. Portanto, elas podem acessar os mesmos objetos Python — por exemplo, a mesma lista, dicionário ou instância.

Observe que os fluxos são separados, mas os objetos pertencem ao mesmo processo.

Threads são candidatas úteis para coordenar chamadas bloqueantes de bibliotecas síncronas quando a carga é predominantemente de entrada e saída, como rede ou armazenamento.

Enquanto uma thread aguarda uma resposta, outra pode avançar. Isso depende do comportamento da operação e da biblioteca: criar threads, por si só, não transforma qualquer chamada em concorrente nem garante redução do tempo total.

Uma thread fica aguardando uma resposta de rede; outra continua seu trecho de trabalho no mesmo processo.

Um processo é uma unidade de execução com seu próprio espaço de memória. Diferentemente das threads de um mesmo processo, processos distintos não acessam diretamente os mesmos objetos Python.

Se dois processos começam a partir de dados parecidos, cada um trabalha sobre sua própria cópia lógica daqueles dados. Alterar uma lista em um processo não atualiza automaticamente a lista do outro.

Observe que a mudança feita pelo Processo A permanece no espaço de memória dele.

Processos podem executar trabalho ao mesmo tempo em diferentes núcleos de CPU, se houver núcleos e recursos disponíveis. Isso os torna uma alternativa a avaliar para tarefas de processamento intensivo e suficientemente independentes.

Mas o isolamento tem um preço: entradas precisam ser enviadas ao trabalhador, e resultados precisam ser trazidos de volta. Essa troca não acontece por memória compartilhada automática.

O processo principal distribui partes independentes do trabalho e recebe os resultados para reunir a resposta final.

Criar processos consome tempo e memória. Além disso, transportar dados tem custo. Se cada tarefa recebe ou devolve um volume grande de informações, a comunicação pode consumir parte importante do benefício esperado do paralelismo.

Por isso, processos tendem a fazer mais sentido quando o cálculo de cada unidade de trabalho é relevante em comparação com os dados que precisam circular. Se as tarefas dependem intensamente de um estado compartilhado ou exigem trocas frequentes, a coordenação pode ficar cara.

O asyncio coordena tarefas por meio de um laço de eventos, normalmente executado em uma única thread. Por isso, ele pode produzir concorrência — avanço alternado de tarefas — sem criar paralelismo de processamento por conta própria.

Quando uma tarefa chega a uma espera compatível com asyncio, ela pode se suspender e devolver o controle ao laço. O laço então deixa outra tarefa pronta avançar. Isso é especialmente útil quando há muitas esperas de entrada e saída, como rede.

Observe que a espera de uma tarefa abre espaço para outra, mas apenas uma executa código na thread do laço em cada instante.

No CPython com o GIL habilitado, o GIL é um bloqueio do interpretador que restringe a execução de código Python a uma thread por vez dentro do mesmo interpretador.

Isso limita o paralelismo de processamento de código Python entre threads. Ainda assim, várias threads podem fazer progresso concorrente: enquanto uma aguarda uma operação de entrada e saída, outra pode avançar.

Observe a diferença entre alternar o acesso ao interpretador e executar em processos separados.

Muitas operações de entrada e saída liberam o GIL durante a espera. Algumas extensões nativas também podem liberá-lo e realizar trabalho fora do código Python puro. Portanto, dizer que threads “nunca” executam processamento em paralelo é uma simplificação incorreta.

A expectativa correta depende da operação, da biblioteca e da configuração em uso.

Processos separados não disputam um único GIL do mesmo interpretador. Por isso, podem ser candidatos para tarefas independentes e intensivas em código Python quando o GIL está habilitado, considerando os custos de memória e de transportar dados.

Também existem versões e configurações compatíveis com execução sem GIL. Porém, não conclua a configuração apenas pela versão do Python: verifique o interpretador efetivamente usado. Mesmo sem GIL, não há garantia automática de aceleração nem de segurança para estado compartilhado.

Use esta ordem: 1) identifique a etapa que mais domina o tempo; 2) verifique o tipo de API disponível; 3) considere a configuração do interpretador; 4) avalie estado compartilhado, isolamento e custo de comunicação.

O resultado é uma escolha inicial plausível, não uma promessa de que o programa ficará mais rápido.

A natureza da carga direciona a análise, mas bibliotecas, dados e custos podem alterar a decisão.

Threads e tarefas do mesmo laço podem acessar os mesmos objetos: isso facilita trocar dados, mas exige coordenação ao alterar estado compartilhado. Processos isolam memória, porém resultados e entradas precisam circular explicitamente.

Em uma carga mista, examine as etapas. Um pipeline pode esperar arquivos na maior parte do tempo e depois realizar uma transformação curta; outro pode ter pouca espera e um cálculo dominante. Escolha pelo gargalo relevante, não por um rótulo único para todo o programa.

Para defender uma escolha, descreva: 1) qual trabalho domina a duração; 2) qual suporte a biblioteca oferece; 3) como os dados precisam circular ou ficar isolados; e 4) qual custo pode anular o benefício.

O resultado não é uma promessa de aceleração. É uma estratégia plausível que ainda precisa ser comprovada no contexto real.

Use este mapa para organizar uma justificativa curta e completa.