Embora os encadeamentos pareçam ser um pequeno passo em relação à computação sequencial, na verdade, eles representam um grande passo. Eles descartam as propriedades mais essenciais e atraentes da computação seqüencial: compreensibilidade, previsibilidade e determinismo. Os threads, como modelo de computação, são extremamente não-determinísticos, e o trabalho do programador passa a podar esse não-determinismo.
- O problema com os threads (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).
Embora haja algumas vantagens de desempenho que podem ser obtidas com o uso de encadeamentos em que você pode distribuir o trabalho em vários núcleos, eles geralmente têm um ótimo preço.
Uma das desvantagens do uso de encadeamentos ainda não mencionados aqui é a perda de compartimentação de recursos obtida com espaços de processo encadeados únicos. Por exemplo, digamos que você encontre o caso de um segfault. Em alguns casos, é possível recuperar isso em um aplicativo com vários processos, pois você simplesmente deixa a criança com falha morrer e reaparece uma nova. É o caso do backend pré-fork do Apache. Quando uma instância httpd falha, o pior caso é que a solicitação HTTP específica pode ser descartada para esse processo, mas o Apache gera um novo filho e, muitas vezes, a solicitação, se apenas for reenviado e atendido. O resultado final é que o Apache como um todo não é eliminado com o encadeamento defeituoso.
Outra consideração nesse cenário são vazamentos de memória. Existem alguns casos em que você pode lidar com um encadeamento de falhas de encadeamento (no UNIX, a recuperação de alguns sinais específicos - até segfault / fpviolation - é possível), mas mesmo nesse caso, você pode ter vazado toda a memória alocada por esse encadeamento (malloc, novo etc.). Assim, enquanto o processo pode permanecer, ele vaza mais e mais memória ao longo do tempo a cada falha / recuperação. Novamente, existem maneiras de minimizar isso, como o uso de conjuntos de memória do Apache. Mas isso ainda não protege contra a memória que pode ter sido alocada por bibliotecas de terceiros que o encadeamento pode estar usando.
E, como algumas pessoas apontaram, entender as primitivas de sincronização é talvez a coisa mais difícil de se acertar. Esse problema por si só - apenas acertar a lógica geral para todo o seu código - pode ser uma enorme dor de cabeça. Os deadlocks misteriosos tendem a acontecer nos momentos mais estranhos e, às vezes, até o programa estar em produção, o que torna a depuração ainda mais difícil. Adicione a isso o fato de que as primitivas de sincronização geralmente variam amplamente com a plataforma (Windows vs. POSIX), e a depuração pode ser mais difícil, além da possibilidade de condições de corrida a qualquer momento (inicialização / inicialização, tempo de execução e desligamento), programar com threads realmente tem pouca piedade para iniciantes. E mesmo para especialistas, ainda há pouca misericórdia apenas porque o conhecimento do encadeamento em si não minimiza a complexidade em geral. Às vezes, cada linha de código encadeado parece exponencialmente aumentar a complexidade geral do programa, além de aumentar a probabilidade de surgir um impasse oculto ou uma condição estranha de corrida a qualquer momento. Também pode ser muito difícil escrever casos de teste para descobrir essas coisas.
É por isso que alguns projetos como o Apache e o PostgreSQL são, em grande parte, baseados em processos. O PostgreSQL executa todos os threads de back-end em um processo separado. É claro que isso ainda não alivia o problema das condições de sincronização e corrida, mas adiciona bastante proteção e, de certa forma, simplifica as coisas.
Vários processos, cada um executando um único encadeamento de execução, podem ser muito melhores do que vários encadeamentos executados em um único processo. E com o advento de grande parte do novo código ponto a ponto como AMQP (RabbitMQ, Qpid etc.) e ZeroMQ, é muito mais fácil dividir threads em diferentes espaços de processo e até máquinas e redes, simplificando bastante as coisas. Mas ainda assim, não é uma bala de prata. Ainda há complexidade para lidar. Você acabou de mover algumas de suas variáveis do espaço do processo para a rede.
A conclusão é que a decisão de entrar no domínio dos threads não é clara. Depois de entrar nesse território, quase instantaneamente tudo se torna mais complexo e novas raças de problemas entram em sua vida. Pode ser divertido e legal, mas é como energia nuclear - quando as coisas dão errado, elas podem ir mal e rápido. Lembro-me de fazer uma aula de treinamento de crítica há muitos anos e eles mostraram fotos de alguns cientistas de Los Alamos que brincavam com plutônio nos laboratórios da Segunda Guerra Mundial. Muitos tomaram poucas ou nenhuma precaução contra o evento de uma exposição e, num piscar de olhos - em um único flash brilhante e indolor, tudo acabaria para eles. Dias depois eles estavam mortos. Richard Feynman mais tarde se referiu a isso como " fazendo cócegas na cauda do dragão. "É o tipo de brincadeira com tópicos (pelo menos para mim, pelo menos). Parece bastante inócuo no começo, e quando você é mordido, você está coçando a cabeça com a rapidez com que as coisas azedaram. Mas pelo menos os tópicos venceram te matar.