Principe de la méthode

Como pode ser observado, foi definido um método main do Java para que seja pos- sível inicializar toda a plataforma de execução. A primitiva init definida no Launcher é então invocada para se iniciar o middleware. O argumento passado (N_WORKERS) indica que existirá uma pool de threads partilhada pelas localidades com N_WORKERS threads dis- poníveis. Após a inicialização do middleware, as localidades presentes na computação são instanciadas e são adicionadas ao middleware com recurso à primitiva addPlace também definida no Launcher. A implementação do addPlace adiciona a localidade e verifica se a localidade passada como argumento é uma localidade ativa. Se for, ele invoca a pri- mitiva main de forma a ativar a localidade. A primitiva stop é invocada para encerrar toda a plataforma de execução.

Gestão de Tarefas

Como foi referido na Subsecção 3.3.1.1, o processo de submissão de trabalho pode re- sultar na invocação de uma operação específica dessa localidade ou pode ser explícito, no qual o programador cria e submete uma tarefa para ser executada em paralelo. Em qualquer dos casos, o objeto passado para o gestor tem que implementar a interface TaskInterface. A interface TaskInterface estende a interface Callable do pacote java.util.concurrente portanto herda o método call definido pelo Callable.

Na invocação de uma operação, é gerado um handler que representa a descrição da invocação do método pretendido, no qual se incluí o nome do método e os respetivos argumentos. Para a sua concretização é utilizada uma classe Handler que implementa

4. IMPLEMENTAÇÃO 4.2. Middleware

a interface TaskInterface<R>, onde o tipo abstrato R representa o tipo de retorno da operação. A implementação do R call() recorre ao pacote Reflection API [Mic] ofere- cido pelo Java. Este pacote torna possível, por meio da sua interface, a inspeção a classes, interfaces, campos e métodos em tempo de execução sem conhecimento prévio destes em tempo de compilação. Também torna possível instanciar novos objetos, invocar mé- todos e modificar campos de classes, tudo em tempo de execução. A implementação do call, com o recurso à Reflection API e com a descrição do método a invocar, torna pos- sível a invocação desejada na interface da localidade, retornando o resultado obtido pela invocação.

Na submissão explicita de trabalho, o programador submete um objeto que é uma extensão da classe abstrata ConcurrentTask e que implementa o método call(). Esta classe abstrata comporta uma implementação base da tarefa e implementa a interface TaskInterfacee portanto o call é herdado dessa interface.

Atualmente apenas existe uma fila de tarefas que está associada à pool, onde as tarefas são retiradas da fila para serem executadas por um thread disponível presente na pool. Portanto, a vida de um thread presente na pool é: 1) Obter uma tarefa da fila. Caso a fila esteja vazia, ele adormece até a fila conter tarefas; 2) Executar a tarefa; 3) Voltar a 1).

O recurso ao padrão pool de threads (Figura 4.2) tem vantagens em relação à criação de um novo thread para a execução cada nova tarefa submetida. O re-uso de threads em vez da criação de novos threads traz ganhos no desempenho pois não existirá o overhead associado à criação e destruição de threads à medida que surge uma tarefa para executar. É ainda mais grave, se a tarefa for de granularidade fina, pois o overhead influenciará em grande medida o tempo total de execução da tarefa. Para além do problema do overhead, se um grande número de tarefas for submetido para execução, o grande número de thre-

adscriado numa única JVM pode causar graves falhas no sistema devido ao thrashing de

recursos. O número de threads da pool é fixo e é definido aquando da sua construção po- dendo assim prevenir o thrashing de recursos. Quando não existirem threads disponíveis na pool, as tarefas são colocadas numa fila para serem executadas posteriormente.

Thread Thread Thread Thread Pool de threads Tarefa A Tarefa B Tarefa C Tarefa D ... Fila de Tarefas

Figura 4.2: Pool de threads.

do pacote java.util.concurrent. Na inicialização do módulo, o número de threads da pool requerido é criado e será sempre o mesmo, ou seja não existe dinamismo na cria- ção de novos threads mesmo que a fila fique cheia. Os objetos submetidos para o executor têm que implementar a interface Callable e por essa razão a interface TaskInterface estende essa interface.

Apesar da escolha da pool de threads ter as vantagens já referidas em relação ao de- sempenho global do sistema, a escolha do tipo de fila e respetiva disciplina é também importante para manter o bom desempenho. A escolha da fila residiu numa fila limi- tada pois garante uma gestão mais estável dos recursos. As filas ilimitadas têm como desvantagem o facto de, se a taxa de chegadas de novas tarefas for superior à taxa de tarefas completadas existirá uma degradação de desempenho progressiva até que deixe de haver memória suficiente para guardar as tarefas. Usando uma fila limitada e com uma taxa de chegadas de tarefas superior à taxa de tarefas completadas, a fila ficará cheia em determinada altura, e portanto será necessário tratar das tarefas que não caibam na fila. Para resolver este problema foi utilizada uma política em que uma nova tarefa que não possa ser adicionada na fila será executada pelo fluxo invocador. A implementação utilizada da pool de threads permite adicionar essa política. Para tal, no seu construtor foi indicada essa política através de uma instância da classe CallerRunsPolicy.

Paralelismo Recursivo A primitiva freeThreads permite saber se existem fluxos de

execução disponíveis. A sua utilização é vantajosa quando uma computação recorre ao paralelismo recursivo. O paralelismo recursivo segue o mesmo principio das invocações recursivas, mas onde estas são realizadas de forma assíncrona. O exemplo do cálculo do número de Fibonacci apresentado na Listagem 3.2 é um exemplo de paralelismo recur- sivo. A implementação da tarefa realiza duas invocações assíncronas da mesma tarefa, mas com argumento diferente, ficando à espera do seu resultado antes de realizar a ope- ração de adição. Cada uma destas execuções irá ocupar um fluxo de execução e este ao ficar bloqueado à espera dos resultados faz com que não possa realizar trabalho útil. Portanto, uma maneira de contornar este problema é perguntar à localidade se existem fluxos de execução disponíveis para a execução de cada nova computação. Se não exis- tirem, então a tarefa deve invocar a versão sequencial do método e assim é possível ter vários fluxos de execução a realizar trabalho útil. A desvantagem desta abordagem é que o programador, para além de criar a tarefa e submete-la para execução, tem também que criar a versão sequencial do método. Para tornar mais clara a explicação, considere o exemplo da Listagem 4.3 que alterou o código apresentado na Listagem 3.2.

Como pode ser observado, antes de serem submetidas as tarefas nas linhas 11 e 16, nas linhas 8 e 13 a primitiva é invocada de forma a saber se existem fluxos de execu- ção disponíveis naquele momento. Caso não existam, a versão sequencial do método é invocada nas linhas 9 e 14, assumindo a existência do método dentro da classe FibTask.

4. IMPLEMENTAÇÃO 4.2. Middleware

1 public Integer call() 2 { 3 int x = 0, y = 0; 4 Future<Integer> f1 = null; 5 Future<Integer> f2 = null; 6 //... 7 8 if(!place.freeThreads()) 9 x = seqFib(n-1); 10 else 11 f1 = place.spawn(new FibTask(n-1)); 12 13 if(!place.freeThreads()) 14 y = seqFib(n-2); 15 else 16 f2 = place.spawn(new FibTask(n-2)); 17 //... 18 }