Http vs Sftp

Upload do mesmo ficheiro binário não-comprimível, primeiro por HTTP e depois por SFTP.

… como diria alguém conhecido, é por isso que “uma coisa é uma coisa e outra coisa é outra coisa”.

Remember Yesterday… Porto Cidade Linux

As coisas em que uma pessoa tropeça quando tenta reconstituir o passado…

Porto: Cidade Linux, Cidade Tecnológica

e cá está a prova de que estive lá…

Jobs++

Foram agora mesmo publicadas mais duas vagas para outro departamento cá da casa:

http://groups.google.com/group/ptjug-emprego/msg/55aba884f854c500

Jobs

Um post fora de tema só para dizer que acabei de colocar online duas ofertas de emprego, ambas para a zona do Porto.

http://blogs.fe.up.pt/mpadilha/jobs/

Thread-safe singleton?

Uma das piores coisas que se pode encontrar quando se pretende migrar uma aplicação single-threaded para multi-threaded é um Singleton que nunca o deveria ter sido, um daqueles que guarda informação de estado por todo o lado e que é usado em múltiplos sítios da aplicação ao longo de todo o ciclo de vida.

O que é se faz a uma coisa destas? A solução parece óbvia: “alteras o método instance() para devolver sempre um objecto novo”, efectivamente desfazendo o comportamento de singleton. Ok, funciona, mas e se o impacto em termos de performance for demasiado elevado? O que fazer quando se pretende manter o comportamento de singleton, mas ao nível do Thread, em vez de ser ao nível da JVM?

A resposta é substituir as variáveis existentes que guardam informação de estado por outras do tipo ThreadLocal<T>.

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

Ok, perfeito, não é?

Hmm… quase. Funciona bem se a criação dos threads for feita exclusivamente “antes” da primeira utilização da classe. Dessa forma cada thread inicializa a sua própria cópia uma só vez e trabalha com ela daí para a frente.

Mas e se forem necessários vários níveis de multi-threading, alguns dos quais “depois” da primeira utilização da classe? De acordo com a forma de funcionamento das variáveis ThreadLocal, cada thread filho teria uma instância nova, o que pode corresponder a esforço desnecessário e, dependendo dos casos, ter um impacto significativo no desempenho.

O nome diz tudo:  InheritableThreadLocal<T> é uma subclasse de ThreadLocal<T> que permite herdar a instância do thread pai se ela existir.

 This class extends ThreadLocal to provide inheritance of values from parent thread to child thread: when a child thread is created, the child receives initial values for all inheritable thread-local variables for which the parent has values. Normally the child’s values will be identical to the parent’s; however, the child’s value can be made an arbitrary function of the parent’s by overriding the childValue method in this class.

Agora sim, perfeito.