Starvation

Starvation ocorre quando uma thread fica esperando uma resposta pra prosseguir e essa resposta nunca chega, logo, a thread permanece viva, ocupando recursos, mas não produzindo nada de útil para o software. Uma boa forma de tratar esse problema é sempre trabalhar com timeout e fluxo de exceção, para que caso a resposta não chegue em um determinado tempo seja seguido o fluxo de exceção e a thread possa finalizar o seu trabalho.

Deadlocks

Deadlock ocorre se duas ou mais threads ficam aguardando uma a outra para realizar alguma ação ou liberar algum recurso, por exemplo, a thread A ficar aguardando a thread B liberar algum recurso e B ficar aguardando A terminar alguma ação pra liberar esse recurso, logo, ambas vão permanecer eternamente esperando. Não existe uma solução simples pra resolver esse problema como o timeout para o problema de Starvation, mas se a aplicação não possuir locks explicitos e estados mutáveis então ela estará a salvo de deadlocks, então esse pode ser um bom caminho a se seguir.

Race Conditions

Race Condition ocorre se duas threads concorrem para usar o mesmo recurso ou dado. É um problema bem difícil de tratar pois o comportamento da aplicação se torna imprevisível e uma Race Condition pode ocorrer depois de meses do software em produção. Pra piorar, este problema não ocorre apenas quando duas threads tentam modificar o mesmo dado, ele pode correr quando uma thread tenta gravar um dado e a outra está tentando apenas ler este mesmo dado. Pra piorar ainda mais, existem casos aonde se o código não é otimizado com O JIT(Just In Time) Compiler a Race Condition não aparece, mas se o código é elegível ao JIT e é compilado então a Race Condition surge, basicamente porque a JVM passa a usar cache para acessar algumas variáveis e se outra thread muda o valor da variável, esse valor não é replicado para o cache. Neste caso citado a solução seria usar volatile e/ou synchronized.

Novamente não usar objetos mutáveis evitaria o problema de Race Conditions, por isso que imutabilidade tem sido um tema tão comentado ultimamente, e linguagens que pregam essa técnica tem ganhado cada vez mais força.

Para se aprofundar mais no assunto, inclusive com um código de exemplo que mostra uma Race Condition causada pelo JIT, recomendo a leitura do livro “Programming Concurrency on the JVM”.

Nesta palestra, o Rod tentou mostrar como as principais linguagens que dominam o mercado hoje são burocráticas e chatas de trabalhar. Ele deixa claro que são linguagens robustas e de qualidade, isso é um fato inquestionável, mas elas podiam ser mais amigáveis.

O Rod usou a conhecida do frase do Norvig que diz “patterns are a a demonstration of weakness in a language” para embassar seus argumentos, e também não deixou de mostrar muitos códigos para comprovar o quão verboso é fazer algumas coisas em linguagens como o Java por exemplo. Além disso, também foi falado que o hardware evoluiu muito esses últimos anos, hoje em dia qualquer um tem um computador com dois cores no mínimo, mas nas linguagens de programação tradicionais por assim dizer, não é nada trivial fazer uso deste poder.

Após mostrar todos esses pontos, o Rod expõe quais são os objetivos das linguagens de programação para o futuro. Ou seja, o que precisa ser feito para que elas se tornem melhores, e no final, puxa um pouquinho a sardinha pro lado dele, falando um pouco da Go, a linguagem de programação do Google.

Um fato importante é que para conseguir ver tudo isso que o Rod viu e falou, é preciso pensar fora da caixa como dizem por aí, e aprender novas linguagens de programação. Eu atualmente tenho dado uma olhada mais profunda em duas: Python e Haskell, e não estou me arrependendo. O pessoal pode falar: “Mas aonde você vai usar Haskell profissionalmente?”. Bom, talvez eu nunca use Haskell profissionalmente, mas com certeza seja qual for a linguagem que eu trabalhar, aprender Haskell e programação funcional me tornará um programador melhor.

Enfim, para quem ainda não viu, não deixe de ver essa palestra. E viva a internet, aonde você consegue ter acesso a uma palestra de um evento de fora do país quase que no mesmo dia em que a palestra foi dada.

O primeiro exemplo foi uma situação que passei com um ex-colega de trabalho. Ele tinha que resolver para a faculdade o problema das “Torres de Hanói”, creio que conhecido de todos que frequentam esse blog. O professor queria que fosse desenvolvido um algoritmo para dado uma quantidade de discos, todos inicialmente no pino 1, retornasse quantos movimentos seriam necessários para mover todos os discos para algum outro pino. Meu amigo me pediu para ajudar ele com esse problema. Ele tava fazendo um algoritmo, mas não estava conseguindo….porém, a solução deste problema é totalmente matemática. A formula pow(2, n) – 1 retorna exatamente o resultado esperado. Simples assim.

Outro problema é por exemplo, você quer somar todos os números de 0 a N. Como resolver isso? Simples não? Faz um for até N e vai somando numa variavel. Gauss diria que voce pode resolver isso da seguinte forma:

Soma = N * (N+1) / 2

Quem não gosta de matemática, provavelmente não liga para analise de algoritmos, então acha que dá na mesma. Mas tenta fazer isso com N igual a 1000000 com o for e compara com a solução da expressão.

Um blog que eu gosto muito e sempre acompanho é o DQSoft do Daniel Quadros (http://dqsoft.blogspot.com). O Daniel fez um post falando de um problema recente que ele teve que resolver no “Google Code Jam”. (http://dqsoft.blogspot.com/2008/08/google-code-jam-2008-triangle-areas.html)Reparem como a solução é trivial, dependendo apenas de sacadas matemáticas.

Viram só? Os exemplos não estão relacionados a coisas que usamos no nosso dia-a-dia, mas eu creio que o mais importante disso tudo é a capacidade lógica que a matemática proporciona.

[]‘s

PS: A prova do problema das Torres de Hanói pode ser encontrada no livro “Matematica Concreta”

PS1: A questão da soma foi descoberta por Gauss, que em uma aula do ensino fundamental, recebeu como castigo somar até 100, e rapidamente falou 5050, surpreendendo a todos.