Blog

Arquitetura e Implementação O conjunto de chamadas (primitivas) disponíveis para que uma aplicação utilize as facilidades dos threads é chamado de pacote de threads (threads package). Existem diferentes abordagens na implementação deste pacote em um sistema operacional, o que influenciará o desempenho, concorrência e modularidade das aplicações multithread. Threads podem ser oferecidos pelo próprio núcleo do sistema operacional (thread em modo kernel), por uma biblioteca de rotinas fora do núcle uma combinação de de scheduler activati processadores multit arquiteturas para dif

OF6 bo g Swipe nentp ou a modo usuário), novo modelo Itetura de umariza as diversas lonals. Threads em Modo Usuário Threads em modo usuário são implementas por chamadas a uma biblioteca de rotinas que são linkadas e carregadas em tempo de execução (run-time) no mesmo espaço de endereçamento do processo e executadas em modo usuário . O sistema operacional não sabe da existência de múltiplos threads, sendo responsabilidade da biblioteca gerenciar e sincronizar os diversos threads existentes.

Threads em modo usuário e eficientes, por dispensar acesso ao kernel do sistema para criação, eliminação, sincronização e troca de contexto das threads. A biblioteca oferece todo o suporte necessário em modo usuário, sem a necessidade de chamadas ao sistema (system calls). O sistema operacional desconhece a existência dos threads, sendo responsabilidade da biblioteca particionar o tempo de UCP do processo (time-slice) entre os diversos threads existentes. Como cada aplicação possui sua cópia da biblioteca, é possível implementar uma politica de escalonamento diferente, em função da sua necessidade.

Apesar das vantagens, threads em modo usuários são difíceis de implementar. Um grande problema surge quando um thread utiliza uma chamada ao sistema que a coloca em estado de espera (chamada bloqueante ou síncrona), como, por exemplo, uma operação de entrada/sa[da. Neste caso, como o sistema operacional encara o processo com apenas um thread, o sistema coloca todo o processo em estado de espera, mesmo havendo outros threads prontos para a execução. Para contornar o problema das chamadas síncronas, a biblioteca tem que implementar todas as chamadas que possam causar o bloqueio de um thread.

Sempre que uma chamada ao sistema é realizada, a biblioteca verifica a possibilidade de bloqueios e ntervém, utilizando uma chamada assincrona própria. Todo este controle é transparente para o usuário e para o sistema operacional. Outro problema do pacote em modo usuário está no compartilhamento de variáveis da biblioteca multithread sem a devida sincronização. Bibliotecas que apresentam este tipo de problema são ditas não reentrante ou thr problema são ditas não reentrante ou thread-safe (segura).

Para contorna-lo, a biblioteca deve fornecer para cada thread um conjunto individual de variáveis ou o programador deve intervir para a garantir a Integridade das variáveis. Não apenas a iblioteca multithread deve ser thread-safe, mas também todas as bibliotecas oferecidas pelo sistema operacional utilizadas pela aplicação. Talvez um dos maiores problemas na implementação de threads em modo usuário, seja o tratamento de sinais por cada thread individualmente. Como o sistema reconhece apenas processos e não threads, os sinais enviados para um processo devem ser reconhecidos pela biblioteca e encaminhado ao thread correspondente.

Um problema crítico no tratamento de sinais é o recebimento de interrupções de clock, fundamental para a implementação do time-slice. Logo, para oferecer escalonamento preemptivo, a biblioteca deve receber sinais de temporização, interromper o thread em execução e realizar a troca de contexto. Outro grande problema relacionado ao escalonamento é a incapacidade de múltiplos threads em um processo serem executados por processadores diferentes simultaneamente, em ambientes com múltiplos processadores.

Esta restrição limita drasticamente o grau de paralelismo da aplicação, ja que os threads de um mesmo processo podem ser executados em somente um processador de cada vez. Threads em modo kernel são implementadas diretamente pelo ucleo do sistema, por chamadas ao sistema (system calls) que oferecem todas as funções de gerenciamento e sincronização (Fig. 6) 3 sistema (system calls) que oferecem todas as funções de gerenciamento e sincronização (Fig. 6). O sistema operacional (escalonador) sabe da existência de cada thread e pode escalona- los individualmente.

No caso de múltiplos processadores, os threads de um mesmo processo podem ser executados simultaneamente. Threads em modo kernel Os problemas apresentados para a implementação de pacotes em modo usuário não são encontrados neste modelo, como ompartilhamento de variáveis, tratamento de sinais, chamadas síncronas, escalonamento em múltiplos processadores etc. O grande problema para pacotes em modo kernel é o seu desempenho, sendo da ordem de dez vezes mais lento que o modo usuário.

Enquanto que pacotes em modo usuário todo tratamento é feito sem a ajuda do sistema operacional, ou seja, sem a mudança do modo de acesso (usuário-kernel-usuário), pacotes em modo kernel utilizam chamadas ao sistema e conseqüente mudança de modo de acesso. 4. 3 Threads em Modo Hibrido Nesta arquitetura existe a idéia de combinar as vantagens de hreads implementados em modo usuário e modo kernel. Para facilitar a explicação deste modelo, chamaremos os threads em modo kernel de TMKs e os de modo usuário de TMCJs. Um processo pode ter vários TMKs e, por sua vez, um TMK pode ter vários TMIJs.

O núcleo do sistema reconhece os TMKs e pode escaloná-los individualmente. Um TMIJ pode ser executado em um TMK, em um determinado momento, e no instante seguinte ser executado em outro. programador desenvolve a aplicação em termos de TMIJs e especifica quantos TMKs estão associados ao processo. Os TMIJ são mapeados em TMK enquanto o processo está sendo xecutado. O programador pode utilizar apenas TMKs, TMIJs ou uma combinação de ambos, como mostra a Fig. 7. O pacote hibrido, apesar da maior flexibilidade, também apresenta problemas herdados de ambas as implementações.

Por exemplo, quando um TMK realiza uma chamada bloqueante, todos os TMIJs são colocados no estado de espera. TMCJs que desejam utilizar vários processadores devem utilizar diferentes TMKs, o que influenciará no desempenho. Scheduler Activations Os problemas apresentados no pacote de threads hibrido existem devido a falta de comunicação entre os threads em modo usuário e modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em modo kernel com o desempenho e flexibilidade do modo usuário.

Introduzido no início da década de 90, na Universidade de Washington, este pacote combina o melhor do dois mundos, mas ao contrário de multiplexar os threads em modo usuário entre os de modo kernel, o núcleo do sistema troca informações com a biblioteca de threads utilizando uma estrutura de dados chamada scheduler activation (Fig. 8). A maneira de alcançar um melhor desempenho é evitar a mudanças de acessos (usuário-kernel-usuário) desnecessárias. Caso um thread utilize uma chamada ao sistema que o coloque no estado de espera, não é necessário que o kernel seja ativado.

Basta que a própria biblioteca em modo usuário possa escalonar outro thread. Isto é possível or ue a biblioteca em modo usuário e ok S escalonar outro thread. Isto é possível porque a biblioteca em modo usuário e o kernel se comunicam e trabalham de forma cooperativa. Cada camada implementa seu escalonamento de forma independente, porém trocando informações quando necessario. Processadores Multithread O conceito de thread reduziu significativamente o tempo asto na troca de contexto entre processos, mas para algumas aplicações este tempo continua alto.

Para reduzir o tempo de troca e, assim, aumentar a concorrência, uma nova arquitetura de processadores esta sendo oferecida. Em uma arquitetura de processador multithread, a troca de contexto dos threads é feita por hardware, diretamente no processador, quase eliminado a latência da troca de contexto. Este tipo de arquitetura começou a ser estudada na década de 50, mas foi apenas na década de 70 que o primeiro sistema multithread foi comercializado, o Heterogeneous Element Processor (HEP) da Denelcor.

Atualmente, o MTA da Tera Computer vem sendo comercializado com base nesta nova tecnologia Em uma arquitetura multithread, os threads são mapeados em contextos de hardware, que incluem registradores, bits de estado e contador de intruções (PC). Cada contexto representa um thread que pode ser executado, aguardando apenas uma chance de ser executado. Por limitações de hardware, nem todos os threads estarão mapeados em um contexto de hardware. Apesar da grande melhoria de desempenho, arquiteturas multithread são mais caras e complexas que as arquiteturas tradicionais de alto desempenho.