AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">
alada dos Gigahertz está nos últimos suspiros. Acabou a facilidade de tornar suas aplicações duas vezes mais rápidas a cada 18 meses, simplesmente instalando uma CPU com freqüência duas vezes maior. Será preciso instalar um número maior de CPUs para continuar ganhando desempenho”. Na época em que escrevi esse texto, CPUs dual-core eram novidade. Hoje temos laptops dual-core de baixo custo, desktops quad-core acessíveis, e no high-end, servidores comerciais disponibilizando até 768 núcleos num único sistema[1]. Em vários artigos falando do assunto, tenho advertido ao leitor da importância desse assunto – e agora o faço de forma mais explícita: fique logo “fera” em concorrência, pois logo isso será tão importante quanto algoritmos, estruturas de dados, OO...
Mas, alto lá! Esse já é um discurso antigo. Mais de três anos já se passaram, desde que Herb Sutter nos avisou que “The Free Lunch is Over”[2]. E agora? O que aconteceu? O que mudou? Como estão as ferramentas, linguagens, desenvolvedores? Vamos fazer um estado da arte da questão do paralelismo no desenvolvimento de software.
Os descontentes
O fato que me motivou a escrever este artigo foi ver um número crescente de artigos, blogs e discussões “do contra”. Nem todo mundo está satisfeito com a necessidade de empregar paralelismo em toda parte. E não me refiro apenas a programadores iniciantes, preguiçosos, ou pouco talentosos.
Veja, por exemplo, o guru da programação Donald Knuth, reclamando do seu “desgosto” com a tendência para arquiteturas multicore: “Me parece que os designers de hardware esgotaram suas idéias, e estão tentando passar o abacaxi para os programadores dando-nos máquinas que só são mais rápidas para uns poucos benchmarks! Eu não ficaria surpreso se toda a idéia de multithreading acabe se revelando um fiasco, pior que o do Itanium. (...) Nos últimos 50 anos eu escrevi mais de mil programas, muitos dos quais com tamanho considerável. Não consigo pensar sequer em cinco desses programas que se beneficiariam muito de paralelismo.”[3] No entanto, Knuth é humilde ao afirmar que prefere focar naquilo que conhece melhor, concluindo: “Outros entendem máquinas paralelas bem melhor do que eu; os programadores devem escutar a eles, não a mim, para conselhos sobre programação concorrente.”
Em outro texto, “Threads considered Harmful”, James Reinders faz um paralelo com o famoso paper “GOTO Statement Considered Harmful” de Edsger Dijkstra, que em 1968 teve enorme influência ao promover a programação estruturada. Reinders é uma das muitas vozes denunciando que os threads são a versão moderna do GOTO: produzem código-espaguete, só que de uma forma diferente – em outra dimensão, a do tempo. O problema, no entanto, não é necessariamente a programação concorrente (PC), e sim a técnica específica de threads. Da mesma forma que Dijkstra não era contrário a todas as estruturas de controle, só ao GOTO por ser muito primitivo e indisciplinado, a reclamação moderna é que threads e locks são uma espécie de programação Assembly da PC. São ferramentas demasiado rudes. Adequadas para cenários de baixo nível, como um sistema operacional, ou o coração de um Application Server que deve atender a milhares de requests simultâneos com uma eficiência extrema. Inadequadas, porém, para aplicações em geral, em cuja balança a facilidade de desenvolvimento e manutenção têm sempre um peso muito alto.
...
