Pra quem esta interessado em STM:
http://kskky.info/wiki/STM.NETInFramework4

Com callbacks, thread pools e selectors o lance fica flexível mesmo. Já cobre a maioria esmagadora dos casos.

Obrigado pela explicação.

O Selector do java.nio vai fazer isso pra voce, e voce pode esperar algo por callback pelo PooledExecutor se quiser. Mas nao sei comparar com esses frameworks que voce postou, ja ta bem longe do meu conhecimento. Dizem que o java.nio é bem flexivel tambem comparado com as outras linguagens, e que a proposta do nio2 vai mais longe ainda.

Paulo

Uma outra forma de async IO talvez mais interessante é por callbacks e eventos.

Frameworks como Twisted (python), Boost.ASIO (c++) e a API aio_* do Linux 2.6 fazem async IOs muito mais robustas e flexíveis.

Pra que fazer polling se eu posso receber uma mensagem quando minha tarefa estiver pronta?

Att.

Obviamente o objetivo não era ser abrangente, mas achei que pecaram em não citar I/O Assíncrona. Esse conceito é muito importante porque livra a mente do programador de achar que tudo se resolve com threads. Na prática quase nunca thread é a solução ideal. Quase nunca precisamos de concorrência _real_, i.e., execução simultânea em cores/processadores diferentes. O que normalmente precisamos é orquestrar tarefas, e permitir mais de um fluxo de execução. Isso não implica em concorrência real.

Abraço

Uma alternativa para concorrência Java baseada em troca de mensagens é a biblioteca Jetlang:

http://code.google.com/p/jetlang

Para ser franco, acho ela um tanto ruidosa. Quando fiz alguns estudos sobre concorrência e paralelismo tempos atrás, conheci a GParallelizer (em Groovy) que você citou, e fiquei bem inspirado a fazer algo bem próximo disso em Java. Tive algum sucesso no design da API, mas a implementação ainda está um tanto pobre.

Mais uma vez, ótimo post!

Abraço,