Agora o problema todo não se a resume a green-threads são naturalmente ruim, eu até já falei anteriormente sobre isso, mas a questão é garantir que todas threads executem apenas código gerenciado ou código nativo. Essa garantia é suficiente para permitir um sistema escalável é livre dos problemas habituais. Tudo bem que a interface nativa fica muito mais complicada, não é mais um wrapper para o código externo e sim um protocolo de IPC.

Espero pelo menos que esse tipo de discussão sirva para alertar do fato que threading é um mecanismo complicado demais para ser efetivamente utilizado, enquanto troca de mensagens entre processos leves é um paradigma igualmente poderoso com garantias de segurança muito maiores. Quando não existe memória compartilhada e necessidade de locking, concorrência é um problema resolvido localmente por cada processo/ator envolvido. Protocolos são criados e definidos que representam de maneira muito mais clara e lógica o que seria de outra maneira representada por uma estrutura de dados compartilhada e seus monitores.

Enfim, enquanto se discutir o assunto, ainda existe esperança, mesmo que decisões muito erradas sejam tomadas. Não é uma questão simplesmente de nos preparar para um futuro com sistemas com muitos núcleos, mas sim facilitar a construção de software muito mais seguro e confiável. As provas e evidencias estão por toda parte, ao alcance de todos dispostos a abrir os olhos para o futuro.

O grande problema é o modelo que as linguagens que usamos, tais como Java, C ou Ruby, tem essa coisa horrivel que é memória compartilhada entre as várias linhas de execução, nossas queridas threads. O Joe Armstrong, um guru nesta área argumenta sobre isso neste artigo e defende o porque de ser um problema muito bem.

O Joe também fala que apenas usando múltiplos procesos e passagem de mensagens entre eles é possivel conseguir o mesmo resultado, só que de forma muito mais facil e confiavel, ele ainda sugere usar Erlang. A um tempo escrevi um artigo falando um pouco sobre como Erlang funciona e ainda continuo firme que o seu modelo de execução é muito superior ao que temos nas linguagens mainstream – mas peca por ser uma linguagem dificil de usar.

Mas quais são as característica que tornam Erlang tão interessantes? Primeiro, seu suporte a processos super leves, manter um milhão deles executando em paralelo é perfeitamente possivel, já que para criar um basta pouco mais de 1kb de memória e o tempo de alocá-la – compare isso com o tempo e o uso de memória para subir uma JVM. Depois temos uma sintaxe especial para troca de mensagens assíncronas entre processos – que é uniforme em relação a localização de cada um. Cada processo possui sua área propria de memória, se um processo fizer muita meleca e morrer, nada interfere no funcionamento dos demais. Essa resiliência torna Erlang uma linguagem muito mais segura e confiavel que as demais.

Por isso que eu acredito que o próximo Java vai ser a linguagem que suportar um ambiente de execução semelhante ao do Erlang. Esse me parece ser o avanço técnológico que justificaria uma adoção em massa, e para entender isso bastar olharmos para tras. Gerenciamento manual de memória é facil de explicar e fazer um estagiário entender, ele vai saber que quando terminar de usar um pedaço de memória, ele deve ser liberado – apesar disso excelentes desenvolvedores gastam muito tempo caçando memory-leaks em código C/C++. Programação concorrente com memória compartilhada é dificil achar plenos/seniors que são capazes de entender direito. Java introduziu gerenciamento automático de memória para as massas, agora precisamos uma linguagem que faça o mesmo com processos leves e passagem de mensagens.