Previsibilidade e concorrência: rodar em paralelo

Várias tarefas ao mesmo tempo

Computadores modernos têm vários núcleos, e usar todos ao mesmo tempo faz o trabalho render. Isso é concorrência: em vez de uma fila única de passos, várias tarefas avançam em paralelo. O ganho é real, mas vem com um perigo específico. Quando duas tarefas mexem no mesmo dado mutável ao mesmo tempo, o resultado passa a depender de quem chegou primeiro, e essa ordem é imprevisível. É como duas pessoas editando a mesma frase de um caderno na mesma hora: o que sobra na página vira sorte. Esse é o bug conhecido como condição de corrida, e ele é dos mais odiados porque muda a cada execução e some quando você tenta observá-lo.

O exemplo canônico é um simples contador compartilhado. Duas tarefas leem o valor, somam um e escrevem de volta. Se ambas leem o mesmo número antes de qualquer uma escrever, as duas gravam o mesmo resultado, e uma das somas se perde. O contador que deveria ir de dez para doze para em onze. Ninguém escreveu código errado; o erro nasce da ordem em que os acessos ao dado compartilhado se cruzaram. Reproduzir isso é penoso, porque depende de um encontro exato no tempo. Quanto mais dado mutável compartilhado, mais oportunidades para essas colisões.

Pureza e imutabilidade abrem a porta

Aqui as duas ideias do módulo se encontram e mostram para que serviam. A condição de corrida precisa de dois ingredientes: dado compartilhado e mutação. Tire qualquer um dos dois e o bug não tem como nascer. Dado imutável não pode ser alterado no meio da disputa, então várias tarefas podem lê-lo à vontade, ao mesmo tempo, sem risco: ninguém muda o que o outro está lendo. Função pura não mexe em nada por fora, então rodar mil funções puras em paralelo é seguro, porque nenhuma delas pisa no dado da outra. A previsibilidade que parecia só elegância vira uma vantagem concreta: código puro e imutável é fácil de paralelizar porque não há nada compartilhado para disputar.

// Risco: contador MUTÁVEL compartilhado entre tarefas concorrentes
contador <- 10
// tarefa A e tarefa B, ao mesmo tempo:
//   leem 10, somam 1, escrevem 11  -> uma soma se perde

// Seguro: cada tarefa trabalha uma CÓPIA IMUTÁVEL e devolve seu resultado
parcialA <- processar(loteA)   // não toca em dado de B
parcialB <- processar(loteB)   // não toca em dado de A
total <- parcialA + parcialB   // combina no fim, sem disputa

Sem dado mutável compartilhado, as tarefas rodam em paralelo e só juntam os resultados no fim.

O fio que liga o módulo

Vale amarrar as pontas. Começamos escolhendo entre mudar um dado no lugar ou gerar uma cópia, e vimos que dado imutável evita mudanças por acidente à distância. Depois abrimos a função pura, que só depende dos argumentos e não toca o mundo, o que a torna previsível e trivial de testar. Em seguida, aceitamos que efeitos são necessários e aprendemos a isolá-los na borda, guardando um miolo puro. Agora fechamos mostrando o prêmio maior: essa previsibilidade toda é o que permite rodar em paralelo com segurança. O fio comum é um só, previsibilidade. Código previsível é mais fácil de entender, testar, mudar e paralelizar. Não é enfeite acadêmico; é o que faz um programa durar sem virar um campo minado a cada alteração.