Você usa java.util.concurrent?

Estou escrevendo um artigo sobre o assunto e gostaria de saber das experiências do pessoal do fórum na utilização do de conconcorrência do Java5.

Quem aqui utiliza dessas classes? Ou prefere utilizar um dos backports (versões reescritas p/ funcionar com o java 1.4)? Ou ainda está usando o util.concurrent do Doug Lea?

Falo da minha experiência, eu utilizo muito o pacote do Doug Lea porque considero ele o mais estavel dentre todas opções e não posso utilizar java5 nos meus atuais projetos.

Eu utilizo basicamente variaveis atômicas, o framework de executors (thread pool) quase sempre e as collections muito pouco.

Uso o util.concurrent onde o Java é 1.4. Passei a usar o java.util.concurrent em projetos mais recences onde posso usar o Java 5. A transição foi tranquila para o caso dos pools de execução e outras primitivas, o que não é exatamente de se espantar, já que a java.util.concurrent foi criada em cima da do Doug Lea.

Achei meio besta o introdução do TimeUnit. Criou uma complexidade desnecessária para a maioria dos cenários, onde o uso de um long com milissegundos resolve bem o problema. Cenários "hard real-time", com tempos de resposta de microsegundos não poderiam usar esta abordagem, mas quando a coisa chega neste nível, provavelmente java já não faz mais parte da paisagem...

Olá

Bem, eu uso a do Java 5. A API do Doug Lea usei para estudar o livro dele (que agora recentemente estava relendo ao iniciar a leitura do livro do Goetz).

Acho esta API absolutamente fundamental para quem quer trabalhar com concorrência com um pouco mais de controle sobre o que está fazendo. Relendo o livro do Doug vi que ele continua atual e que os conceitos são excelentes. O livro poderia ser mais fácil de ler mas mesmo assim é um dos raros livros antigos que ainda valem a pena comprar.

A propósito deste assunto hoje saiu um artigo, que ainda não acabei de ler, mas que faço questão de compartilhar o link até para seguir chamando a atenção sobre a importância de conhecer esta API.

Discover the Elegant Simplicity of JSR 166

[]s
Luca

Olá,

Em um dos projetos que to usamos a API do Doug Lea. Particularmente eu trabalhei pouco com ela.
Em um outro projeto que estou desenvolvendo estou usando a java.util.concurrent, principalmente a classe ThreadPoolExecutor.

Luca, 5 estrelas pelo link. Muito bom, obrigado.

]['s

Falando de concorrência, sugiro a quem tiver interesse no assunto uma olhada neste site:

http://www.wotug.org/occam/

A linguagem está por aí a uns 15 anos, e possui construções nativas para implementação de aplicações multi-thread e sincronização que são as mais elegantes que já vi.

Existe uma biblioteca que implementa os conceitos em java:

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Tenho a impressão que, com a popularização de processadores multicore, aplicações multithreaded passarão a ser mais comuns, porém o desenvolvimento deste tipo de aplicação requer alguma experiência e é bem mais difícil de se testar.

Olá

Só um testemunho rápido mais com intuito de enfatizar que programação paralela é diferente de programação concorrente com threads que a gente faz com Java. Para aproveitar de verdade a capacidade de processamento paralelo, pode ser que seja preciso mudar completamente o algoritmo utilizado e até mesmo o modo de programar.

Lá pelos idos do início dos anos 90 a computação paralela era a grande promessa para resolver grandes sistemas de equações. Na COPPE/Eng. estruturas montaram uma máquina com vários processadores Intel i860 para testar os algoritmos. O meu amigo professor Nelson Ebecken (meu colega dos tempos de COPPE), montou uma equipe e teve a oportunidade de provar conceitos muito interessantes.

Como solução de grandes sistemas de equações já foi meu ganha pão, ouvi com interesse suas explicações e percebi que na verdade todo o sistema foi reescrito para aproveitar o paralelismo. Nada do meu cinto de utilidades servia naquele caso.

O PhD Nelson formou-se engenheiro estrutural pela UFF. Ele foi um dos responsáveis pelo desenvolvimento dos métodos computacionais que permitiram à Petrobrás construir estruturas para explorar águas profundas. Depois se tornou um guru em Data Mining com trabalhos apresentados em todo o mundo. Hoje sua equipe alia Data Mining com paralelismo mas não sei em que pé andam as pesquisas.

[]s
Luca

Luca wrote:
Lá pelos idos do início dos anos 90 a computação paralela era a grande promessa para resolver grandes sistemas de equações. Na COPPE/Eng. estruturas montaram uma máquina com vários processadores Intel i860 para testar os algoritmos. O meu amigo professor Nelson Ebecken (meu colega dos tempos de COPPE), montou uma equipe e teve a oportunidade de provar conceitos muito interessantes.

Putz, isto me fez reativar umas sinapses já a muito desativadas...
MIMD/SIMD e outras siglas voltaram junto.

O meu projeto de formatura foi em cima dos transputers, justamente para explorar algumas possibilidades abertas para o tipo de arquitetura em que estas CPUs únicas no gênero permitiam.

Como os chips eram raros (e caros), montamos um protótipo em cima dos respeitáveis 68020, com 4 módulos com dois canais cada. Para demonstrar a escalabilidade, elegemos um algorítmo de geração de fractais. Acho que tínhamos como meta ter algo de ray-tracing, mas nao lembro agora se chegamos a implementar.

Luca, dá para comentar um pouco sobre como o livro do Goetz se compara com o do Lea?

Thanks.

Olá

AllMighty wrote:Luca, dá para comentar um pouco sobre como o livro do Goetz se compara com o do Lea?

O livro do Goetz é absolutamente fundamental. Estou gostando muito. Não vou dizer que é melhor do que o CJP do Lea porque na verdade ele é de outro tipo. O Lea é como se fosse um livro de referência enquanto o do Goetz é de regras práticas. A vantagem do Goetz é ser mais novo, poder citar o Lea e usar o Java 5.

E para quem quer rever Threads com Java 5, um bom livro que comprei meio assim só por comprar mas que achei muito bom é a nova edição do Java Threads do Scott Oaks.

[]s
Luca

Notícias, artigos e o maior fórum brasileiro sobre Java