Como já sabemos, o problema em escrever código para ser rodado paralelamente é grande quando temos acesso a dados compartilhados (shared memory) e existe uma ou mais escritas ocorrendo no mesmo dado.

A abordagem dos monitores do Java (wait/notify) e das pthreads do C estão ligadas a objetos que sinalizam quando podemos e quando não devemos escrever nessa memória compartilhada e, apesar de extremamente poderosa, vem se mostrando difícil de ser trabalhada e mantida pelos desenvolvedores. Tudo isto está conectado com a questão de concorrência preemptiva, onde um escalonador agenda e executa as threads/processos, inclusive em mais de um processador simultaneamente.

Existem duas outras alternativas que ganham força hoje em dia: os atores e processos de linguagens como Erlang e Scala, e as fibers do ruby 1.9.

Em linguagens como Erlang, onde as “variavéis” são imutáveis, não existem efeitos colaterais ao se executar uma função, portanto podemos dizer que a “memória compartilhada” não sofre dos males das outras linguagens, já que não há estado que possa ser alterado. Muitos dizem que o grande problema das linguagens atuais é justo o estado.

Qual a grande vantagem da imutabilidade fazer parte de uma lingaugem? Duas invocações poderiamm ser paralelizadas pelo interpretador/compilador, como o exemplo de pseudo código Java abaixo mostra:

String geraCorpo(Movimentacao[] movimentacoes) {
  String conteudo = "";
  for (Movimentacao m : movimentacoes) {
    conteudo += m.geraConteudo();
  }
  return conteudo;
}

String geraRodape(Informacao[] informacoes) {
  String rodape = "";
  for(Informacao info : informacoes) {
    rodape += info.geraConteudo();
  }
  return rodape;
}

String processaRelatorio (Movimentacao[] movimentacoes,
         Informacao[] informacoes ) {
  return geraCorpo(movimentacoes) + geraRodape(informacoes)
}

Repare que quando invocarmos o processaRelatorio as duas outras funções seriam executadas sequencialmente, mas um compilador/interpretador inteligente poderia executar as duas invocações em paralelo e concatenar o resultados assim que ambos estiverem disponíveis. Ele poderia ir mais além, invocando partes de cada laço em paralelo em processadores diferentes. Isso se tivessemos a garantia de que não haveria efeitos colaterais ao invocarmos cada uma dessas funções, garantia a qual não se da para fazer com o Java.

Funções que não causam efeitos colaterais permitem otimizações impressionantes por parte do interpretador/compilador e são uma ótima alternativa para fazer uso de todos os cores que temos disponibilizados (número que só cresce) evitando o desperdício.

Por outro lado, existem partes do sistema que podem ser manualmente agendados para executarem concorrentemente e – as vezes – até mesmo em paralelo.

Em sites de verificação de rotas de vôo, diversas requisições para diferentes sites podem ser executadas simultaneamente com uma tarefa extra que que concatena todos os resultados. Para que essa tarefa final receba as respostas, precisamos trocar mensagens entre aqueles que processam as diversas requisições e a tarefa que concatena as informações. Alguém responsável por pegar informação de um site seria aquele que recebe o identificador do site que será pesquisado (por exemplo tam, gol etc), os critérios de pesquisa, e quem é responsável pela tarefa final, de concatenar os resultados.

Dada as 3 informações, esse alguém executa uma requisição que é blocante, isto é, segura a sua thread até obter a resposta, executa transformações (parseia) a mesma, e termina notificando o responsável da finalização do processo, como o pseudo-código abaixo:

class Agente {
  def recebe(site, pesquisa, callback) {
    resposta = http.request(site + "?search_for=" + pesquisa)
    resultado = parseia(resposta)
    callback.recebe (resultado)
  }
}

E então alguém responsável por concatenar os resultados:

class TarefaFinal {
  final = []
  def recebe(resultado_parcial) {
    final.add resultado_parcial
  }
  def aguarda_ate_o_fim {
    // aguarda ate o fim de todos os parciais
    // e entao retorna o resultado total
  }
}

A tarefa mãe seria quem dispara diversos agentes que farão as pesquisas e o agente final, que colherá os resultados, ainda com pseudo-código:

class Pesquisador {
  def busca(opcoes) {
    concatenador = new TarefaFinal
    sites = {'www.tam.com.br', 'www.voegol.com.br',
                 'www.aerolinhascaelum.com.br'}
    for site in sites {
      new Agente().envia (site, opcoes, concatenador)
    }
    return concatenador.aguarda_ate_o_fim
  }
}

Em Java, por exemplo, utilizariamos uma thread para cada agente, para que cada requisição blocante não impedisse a execução das outras em paralelo. Com isso, podemos utilizar todos os processadores de uma máquina, mas o peso de gerenciar muitas threads em Java é algo que queremos evitar.

Outra solução, ainda em Java, é utilizar a api de NIO, permitindo executar tarefas de entrada e saída sem que a thread atual aguarde o resultado final. Por um lado essa alternativa aumentaria a possibilidade de atendermos muito mais requisições, porém há um custo aí de ficar perguntando se o resultado “já está pronto”. É um trade-off entre performance e escalabilidade. Essa abordagem pode ser feita de maneira um pouco mais elegante e transparente através de bibliotecas de dataflow concurrency.

A solução que algumas linguagens apresentam é chamada de processos. Esses processos serão executados concorrentemente, e, como o código é escrito visando minimizar efeitos colaterais, em grande parte ele poderá ser executado em paralelo. Esses processos são mais leves pois não implicam em um overhead de informações devido a troca do estado de memória e de pilha de execução quanto a implementação de threads em Java.

Ainda mais impressionante é a capacidade de executar cada um desses processos em máquinas diferentes da atual. Se o código do agente é facilmente serializável, ou que permita um rápido bootstrap em diversas máquinas remotas, fica muito barato rodar esses processos em diversas máquinas, inclusive efetuando concatenações parciais, até obter o resultado final, se aproximando das idéias do Map Reduce, descrito pelo google em 2004.

Por fim, existe a opção de co-rotinas que voltam a ser abordadas, nesse caso no mundo Ruby, através de Fibers.

O uso de Fibers permite escrever um código onde N processos mantem a comunicação entre si, dizendo uns aos outros quando é o momento de deixar de executar para dar espaço para execução do outro processo. Muitos se lembrarão do método Thread.yield() de Java, que tem um comportamento definido parecido com o mencionado. Mas ele não garante que a thread atual para e deixa outro processo rodar.

Por outro lado, fibers garantem que aquele processo pare momentaneamente para deixar aquele que o invocou continuar sua execução. A grande vantagem está em poder separar, com isso, o código que controla diversos processos (fibers) e o código que executa cada processamento. A desvantagem está em que os processos estão rodando concorrentemente, não em paralelo.

Hoje em dia, outro assunto que está sendo muito discutido é a questão da memória transacional. Uma maneira que, resumidamente, permite criar transações em cima de suas variáveis de memória para que, em casos onde imutabilidade de dados compartilhados não é possível, haja um controle automático.

Mas essa abordagem apresenta certas dificuldades e detalhes importantes de serem estudados, como as dificuldades de se fazer operações de IO durante uma transação dessas – o problema de “como efetuar o rollback do lançamento de um foguete?”. Quem implenta uma possível solução para isso é o haskell, através dos monads.

Só enxergaremos melhor as todas as vantagens e desvantagens de cada uma dessas opções aqui citadas quando elas quando elas forem parte do dia a dia de muitos programadores, um futuro não tão distante.

Agradeço ao Rafael Ferreira e ao Renato Lucindo pelas discussões e revisões.

O Fábio Kung fez no início do ano um acalorado post intitulado 2009 o ano do Ruby on Rails no Brasil, e podemos ir além: diversas linguagens que não fazem faziam parte do mainstream corporativo vem ganhando muita força por todos os lugares.

Martin Fowler fez um trabalho minucioso em suas considerações ao uso de Ruby pela ThoughtWorks (traduzido pelo Fábio Akita aqui). Fowler discorre a respeito das opiniões e sentimentos dos lideres técnicos de cada projeto que optou por Ruby, e poucos deles (5 de 41) disseram que Ruby foi a escolha errada.

Mas será que apenas o Ruby tem ganho toda essa notoriedade e força?

O Rafael Ferreira compartilhou comigo recentemente um excelente artigo que discute os diferentes paradigmas de programação, citando vantagens e desvantagens, culminando na importância do aprendizado de diferentes linguages, em especial para tirar proveito das que facilitam o desenvolvimento de sistemas com muita concorrência.

O Renato Lucindo me mostrou também o quão grande tem sido a repercussão do Scala em grandes ambientes, como é esse caso da Électricité de France Trading que trocou 300 mil linhas de Java por Scala.

Vale também citar a troca de linguagens num dos cursos mais famosos de computação do mundo: o Structure and Interpretation of Computer Programs, curso que inicia os graduandos de ciência da computação e engenharia elétrica do MIT. Este curso foi sempre famoso por ser ministrado em Scheme, e agora depois de uma série de debates e justificativas, foi reformulado usando Python, novamente sem usar uma das linguagens enterprisey.

Pedro Matiello, que trabalha aqui com a gente, é o lider de desenvolvimento da biblioteca python-graph, que implementa diversos algoritmos para grafos em python e possui colaboração dos mais variados países.

Aqui na Caelum, além de usarmos extensivamente Ruby e Rails em projetos e termos estendido o tempo do nosso curso RR-11 para 32 horas ja há algum tempo, há um pedaço de um sistema desenvolvido em Scala e ainda temos o curso de Lógica de Programação é realizado em grande parte com Groovy.

São muitos meus amigos e colegas de trabalho estudando LISP, Erlang, OCaml, Scala e outras linguagens, sem contar Ruby/Rails e Python/Django. Todas essas linguagens podem de certa forma rodar sobre a JVM. É um lugar-comum (e é uma das dicas do excelente Pragmatic Programmer) dizer que devemos aprender mais linguanges de programação para ampliar nossa visão e formas de ataque a um problema. Já disse Peter Norvig que é necessário 10 anos para que adquiramos fluência numa linguagem de programação, mas sempre há o momento de começar.

E você? Como está seu contato com essas linguagens? Sua empresa está usando algo “novo” em seus projetos?

Essa nova edição está estendida e revista, para cobrir as grandes mudanças do Java 5. Esse, juntamente com outros dois livros (e atualmente incluiríamos também o The Mythical Man-month), são de extrema importância para todo desenvolvedor na nossa opinião.

O Fernando Boaglio tem um resumo em seu blog, sobre todos os itens dessa nova versão. A Vanessa Sabino publicou anos atrás um resumo completo sobre a primeira edição, que você pode conferir na coluna da direita do seu blog.

O Fernando também postou no GUJ um link para uma excelente entrevista do Joshua Bloch, onde ele tenta resumir as más práticas, o java inefetivo: otimização prematura, e escrever o próprio código quando bibliotecas boas já existem. Além disso, Joshua Bloch é categório sobre a grande importância dos testes unitários: “Unit testing is key. And writing your tests first is a great thing.”

Lendo essa nova edição e relembrando muito da edição anterior, escolhi aqui quatro itens que considero vitais, e vou falar sucintamente sobre cada um deles. Curiosamente todos os selecionados aqui já existiam na edição anterior, e estão mais relacionados a design que a idiomismos da linguagem, mas isso não tira a importância dos outros aqui não citados. Esses itens são muito debatidos no capítulo de Tópicos em Orientação a Objetos no nosso trienamento de Design e Arquitetura de projetos Java. Vamos a eles:

Item 15: Minimize mutabilidade

Classes imutáveis possuem uma série de vantagens: fáceis de manter, não possuem efeitos colaterais e acima de tudo são thread safe. Uma classe deve ser imutável a não ser que você tenha muito bons motivos para isso. Mesmo se não for possível tornar sua classe imutável, minimize a quantidade de métodos que alteram o estado do objeto. Um objeto previsível é muito mais simples de manter. Joshua Bloch cita String, BigInteger e diz que java.util.Date e java.awt.Point deveriam ter sido criadas imutáveis! Muitas APIs novas abusam da imutabilidade, como a Joda Time, classes wrapper, Money and Time do Eric Evans, etc. Aliás, é com o slogan da imutabilidade que linguagens como clojure e erlang tem chamado tanta atenção. Leia também essa citação no blog do Renato Lucindo.

Item 16: Favoreça composição em vez de herança

Esse é um tópico que já foi discutido anteriormente nesse post. O fato é o seguinte: é muito fácil usar herança de maneira errada, como é o caso de Stack extends Vector e Properties extends Hashtable. Mesmo quando usada corretamente, herança pode causar efeitos colaterais com muita facilidade, sendo que utilizar interfaces e composição pode substitui-la por completo, com o pequeno acréscimo de algumas linhas de delegação. Esse item também é citado no livro Design Patterns como um dos dois princípios básicos do bom design orientado a objetos.

Item 47: Conheça e use as bibliotecas!

Você conhece a ArrayDeque do java 6? Sabia que a java.util.Scanner pode ler facilmente arquivos com formatos caseiros, e já trazer para você doubles, Strings e até mesmo BigDecimals? Que JAXB e JAXWS podem agora ser usados apenas com Java SE? Sabia que a Collections possui hoje métodos para calcular a frequência de um elemento e inverter a ordem de um Comparator?. Conhecer bem a biblioteca padrão do Java pode te salvar de escrever muito código já existente, testado e de qualidade. java.io, java.lang e java.util são APIs que funcionam como base para todo desenvolvedor e merecem um estudo aprofundado.

Item 52: Refira a objetos pelas suas interfaces
Sem dúvida uma boa prática mais que necessária. Através dela conseguimos diminuir muito o acoplamento entre classes, deixando apenas uma fina camada entre elas: as interfaces. Sempre usar InputStream em vez de se acoplar em FileInputStream, sempre usar List em vez de se acoplar a ArrayList. Muitas vezes podemos ir mais longe, nesse último caso Collection pode ser o suficiente, ou até mesmo Iterable! Algumas pessoas levam isso tão a sério que nunca criam uma única classe concreta que não implemente uma interface. Esse item também é citado no livro Design Patterns, e é o outro princípio básico do bom design orientado a objetos desta forma: “Programe voltado a interface, e não a implementação“.

Ainda existem itens fundamentais sobre Enums, Exceptions, Concorrência e Generics. Esse livro é realmente importante na sua cabeceira. Boa leitura!