Rodrigo Kumpera Weblog

Esses dias estava estudando como funcionam actors em Scala, baseado no artigo Actors that Unify Threads and Events, resolvi fazer o equivalente em Java, utilizando o commons-javaflow para ter continuations. Fiquei feliz de ter um protótipo funcional, porém assim como a solução em Scala, deixou muito a desejar.

O maior problema é que Java não é a plataforma ideal para se implementar Actors da maneira ideal. Você é obrigado a assumir vários trade-off para chegar em uma solução escalavel. Primeiro que utilizar uma thread por actor não vinga, dificilmente um sistema suportaria mais de 3mil deles. Um programa erlang pode ter milhares de micro-processos sem nenhum problema.

Outro problema que eu encontrei é o fato de se usar cooperative multi-tasking, ou seja, a troca do actor em execução somente ocorre quando alguma primitiva de I/O ou troca de mensagens acontece. Isso não deve se mostrar um grande entrave se utilizarmos múltiplos escalonadores com work-stealing, além do fato que a maioria dos actors faz um processamento simples com cada mensagem. Mas não deixa de ser uma preocupação, pois perdemos a garantia de fairness que tinhamos usando apenas threads.

Finalmente tem o problema que apenar de usar um modelo de troca de mensagens que não precisa de memória compartilhada, não podemos nos dar o luxo de ter actors que simplesmente abortam na presença de erro. Com memória compartilhada, temos sempre que nos preocupar de manter o estado global em um estado consistente.

Pessoamente acredito que a primeira empresa que distribuir uma linguagem que funda o modelo de programação concorrente do erlang, com uma linguagem com notação parecia ao C/Java, vai fazer muita grana na próxima década. Afinal, muito em breve teremos servidores baratos com dúzias de cores. Hoje é muito dificil explorar isso de maneira efetiva em linguagens como Java, imagine daqui meia década, quando vamos ter mais núcleos de processamento que requisições simultâneas.