Senhores,
gostaria de saber se alguém já enfrentou uma situação onde um aplicativo feito em Java (Desktop) roda perfeitamente em uma máquina com processador convencional e quando este mesmo aplicativo é executado em uma máquina com processador HT (Hyper Threading da Intel) acaba travando logo no início do carregamento.
Obs.: O aplicativo usa multi-threading e o travamento é gerado devido ao disparo de uma exceção (criada especificamente para o aplicativo em questão).
:? :? :?
Faz todo sentido, se a aplicação possuir bugs relativos a multi-threading eles são muito mais evidentes em máquinas HT que nas sem esse recurso.
poe a stacktrace pra gente ver… as vezes é a wrap de alguma outra bem conhecida.
OK. Vou levar alguns dias - estou de folga - para pegar estas informações onde trabalho - Metrô São Paulo. Obrigado por enquanto.
Ai está …
Exception in thread “Thread-317” Exception in thread “Thread-316” java.lang.Null PointerException
at gerenciador.DinamicSequence.consumeEvent(DinamicSequence.java:38)
at gerenciador.ConsumerEvent.run(ConsumerEvent.java:17)
java.lang.NullPointerException
at gerenciador.DinamicSequence.consumeEvent(DinamicSequence.java:38)
at gerenciador.ConsumerEvent.run(ConsumerEvent.java:17)
O DinamicSequence representa um gerenciador de eventos do simulador.
Senhores,
apenas para registrar: quando desabilitado o “recurso” HT, as exceções não ocorreram !
Então você já sabe que o seu programa não é thread-safe. Agora é só corrigir.
Hahahahaha… ai ai…
Acho que nem programas thread-safe são thread-safe. 
[quote=Giuliano Mega][quote]
Então você já sabe que o seu programa não é thread-safe. Agora é só corrigir.
[/quote]
Hahahahaha… ai ai…
Acho que nem programas thread-safe são thread-safe. ;)[/quote]
A sim, provar que um programa é thread-safe deve ser tão dificil quanto provar que P=NP. Mas felizmente a nós basta fazer um programa ser suficientemente bom para que ninguém ache os bugs deles e não totalmente livre deles.
Eu tenho processador HT em casa
E tenho uma lista de programas que travam, logo de cara quando subo eles, incluindo o mozilla firefox e thunderbird.
Esse HT é um lixo.
É isso aí, paralelismo é um lixo. :mrgreen:
E viva os branch mispredictions em pipelines de duzentos mil níveis e as CPUs com consumo de aquecedor de parede.
Cara, se HT é um lixo, um dual core vai parecer 10x pior.
Achava que essa discussao (ainda nao muito popular, acho) sobre modelos de programacao que suportem melhor paralelismo/concorrencia (ie: nao dependa tanto da capacidade do programador mediano) era coisa para o futuro. Parece que a coisa eh mais urgente do que parece.
Sera que isso dara visibilidade para outras linguagens que adotam estrategias diferentes? Sera que vao trazer isso pro Java, como estao tentando fazer com linguagens dinamicas, ou vao martelar que isso deve ser corrigido com ferramentas de grandes fornecedores como o “IBM Concurrent Thread Verificator Tabajara”?
Marcio Kuchma
Achava que essa discussao (ainda nao muito popular, acho) sobre modelos de programacao que suportem melhor paralelismo/concorrencia (ie: nao dependa tanto da capacidade do programador mediano) era coisa para o futuro. Parece que a coisa eh mais urgente do que parece.
Sera que isso dara visibilidade para outras linguagens que adotam estrategias diferentes? Sera que vao trazer isso pro Java, como estao tentando fazer com linguagens dinamicas, ou vao martelar que isso deve ser corrigido com ferramentas de grandes fornecedores como o “IBM Concurrent Thread Verificator Tabajara”?
Marcio Kuchma[/quote]
Java, Ruby, C/C++, C# (.net), Python e quase todas linguagens que estamos acostumados estão terrivelmente mal preparadas para nos permitir escrever programas paralelos facilmente.
Sim, esses assuntos estão explodindo em projetos de pesquisa, existem muitas coisas a serem feitas ainda nessa área, considerando que quando você quer paralelismo em ambiente muito distribuído é ainda mais complicado.
Escrever até que é fácil. O duro é testar e depurar.
Abraços,
[quote=Giuliano Mega][quote]
Java, Ruby, C/C++, C# (.net), Python e quase todas linguagens que estamos acostumados estão terrivelmente mal preparadas para nos permitir escrever programas paralelos facilmente.
[/quote]
Escrever até que é fácil. O duro é testar e depurar.
Abraços,[/quote]
Até que não, usando breakpoints condicionais e AOP até que fica razoavel. O dificil ainda é conseguir paralelismo de forma segura.
Mas é justamente essa a questão. É muito difícil afirmar, num programa multithreaded (ou distribuído), que um caso de teste “testa” alguma coisa. Você teria que rodar o caso de teste de maneira a gerar todas as possíveis dependências entre threads (exponencial no número de threads) prá poder afirmar algo. Fora que é muito difícil coletar as dependências entre threads, envolve rastrear acessos à memória. Além de “lentificar” o programa, esse tipo de overhead pode ser não-uniforme e causar mudanças na execução do programa.
Isso me leva ao segundo problema. Como você debuga um programa que não é determinístico? Como você debuga um programa que muda de comportamento na presença do debugger?
Eu acho que estamos muito longe de termos técnicas eficazes de teste e depuração para sistemas multithreaded.
Abraços,
Olá
Me lembro que lá pelo fim da década de 80, se não me engano, começou este papo de paralelismo. Acho que as linguagens não tinham nada a ver com o assunto. Todos os artigos que li referiam-se a algoritmos. Na COPPE eles chegaram a construir um computador com vários processadores (acho que i860). Um dos aplicativos que usavam algoritmos paralelos servia para resolver enormes sistemas de equações usando Fortran.
[]s
Luca
[quote=Giuliano Mega][quote]
O dificil ainda é conseguir paralelismo de forma segura.
[/quote]
Isso me leva ao segundo problema. Como você debuga um programa que não é determinístico? Como você debuga um programa que muda de comportamento na presença do debugger?
Eu acho que estamos muito longe de termos técnicas eficazes de teste e depuração para sistemas multithreaded.
Abraços,
[/quote]
Por isso que falei que essas linguagens são muito mal preparadas para programação paralela. Já existem mecanismos mais modernos como sistemas baseados em processos (Erlang) e memória transacional - existem protótipos tanto de STM e HTM.