DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 
DevWare  
Novidade: DevMedia lança o DevWare - Saiba mais!


  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Artigo Java Magazine 59 - Quick Update: A Crise dos Threads

Artigo da Revista Java Magazine Edição 59.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você gostaria de comentar o que não lhe agradou?

Esse artigo faz parte da revista Java Magazine edição 59. Clique aqui para ler todos os artigos desta edição

Quick Update: A Crise dos Threads

Paralelizar ou não paralelizar... Há escolha? E como?

Muitos estão insatisfeitos com a guinada da indústria em direção às arquiteturas multi-core, exigindo processamento concorrente. Precisamos de melhores ferramentas, e elas estão vindo

Na Edição 31 (“Novas Fronteiras na Evolução do Java”), escrevi: “a escalada 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."

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.
O que você achou deste post?

    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!
Cursos relacionados
Publicidade
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03