1 8 Threads 8.1 Introdução Uma thread, também chamada de tarefa, pode ser definida como uma parte ou rotina de um processo em execução que compartilha o mesmo espaço de endereçamento, mas tem seu próprio contexto de hardware e de software. Um processo pode ter várias threads, podendo estas tarefas serem executadas em paralelo. Até o final da década de 1970, os sistemas operacionais suportavam apenas processos com um único thread (monothread), ou seja, um processo com um único programa fazendo parte do seu contexto. Em 1979, foi introduzido o conceito de processo lightweight (peso leve), onde o espaço de endereçamento de um processo é compartilhado por vários programas. A partir do conceito de múltiplos threads (multithread), um processo pode ter diferentes partes do seu código sendo executado em paralelo. Como os threads de um mesmo processo compartilham o mesmo espaço de endereçamento, a comunicação entre os threads é mais rápida, visto que não envolve os mecanismos de comunicação entre processos. Atualmente, o conceito de multithread pode ser encontrado em diversos sistemas operacionais, entre eles o Microsoft Windows, Linux, Mac OS e o Solaris, da Sun Microsystems. 8.2 Ambiente Monothread Um ambiente monothread suporta apenas um programa no seu espaço de endereçamento. Neste tipo de ambiente, aplicações concorrentes são implementadas apenas com o uso de múltiplos processos independentes ou subprocessos. Com o uso de múltiplos processos, cada funcionalidade do software implicaria na criação de um novo processo para atender a essa funcionalidade.
2 Outro problema é quanto ao compartilhamento do espaço de endereçamento. Como cada processo possui o próprio espaço de endereçamento isto comprometeria o desempenho da aplicação. 8.3 Ambiente Multithread Em um ambiente multithread, não existe a ideia de programas associados a processos e sim a threads. O processo neste tipo de ambiente tem pelo menos uma thread em execução, mas pode compartilhar o espaço de endereçamento com outros inúmeros threads. Uma thread pode ser definida como uma sub-rotina de um programa que pode ser executada de forma assíncrona, ou seja, executada paralelamente ao programa. Um ambiente multithread possibilita a execução concorrente de subrotinas dentro de um mesmo processo. A grande vantagem do uso de threads é a possibilidade de minimizar a alocação de recursos do sistema, além de diminuir o overhead na criação, troca e eliminação de processos. Threads compartilham o processador da mesma maneira que os processos e passam pelas mesmas mudanças de estado. Dentro de um mesmo processo, threads compartilham o mesmo espaço de endereçamento, mas cada thread possui seu próprio contexto de hardware e contexto de software. Threads são implementados por uma estrutura de dados chamada Bloco de Controle de Thread(Thread Control Block TCB). Esta estrutura armazena o contexto de hardware do thread e mais algumas informações como prioridade e estado de execução. Em um ambiente multithread, a unidade de alocação de recursos é o processo, onde todos os seus threads compartilham o espaço de endereçamento. Por outro lado, cada thread representa uma unidade de escalonamento, sendo assim, o sistema não seleciona o processo para ser executado, mas sim uma de suas threads. A grande diferença de aplicações monothreads e multithreads está no uso do espaço de endereçamento. Como os threads de um mesmo processo compartilham o mesmo espaço de endereçamento, não existe qualquer
3 proteção no acesso à memória, permitindo que um thread possa alterar facilmente os dados de outros e vice-versa. Programa concorrentes com múltiplos threads são mais rápidos que programas concorrentes implementados com múltiplos processos. Como os threads de um mesmo processo dividem o mesmo espaço de endereçamento, a comunicação entre eles é realizada de forma mais rápida e eficiente. Tabela 8.1 - Comparação entre Processo e Threads A utilização dos recursos do sistema computacional pode ser feita de forma concorrente pelos diversos threads, por exemplo, enquanto algumas aplicações realizam algumas tarefas em background, outras threads vão realizando operações de Entrada/Saída. 8.4 Arquitetura e Implementação As threads podem ser oferecidas por meio de uma biblioteca de rotinas fora do kernel do sistema operacional (modo usuário), pelo próprio kernel (modo kernel), pela combinação dos dois modos (modo híbrido) ou por um modelo conhecido como scheduler activations ou ativações do escalonador. 8.4.1 Threads em Modo Usuário Threads em modo usuário são implementadas pela própria aplicação e não pelo sistema operacional. Para isso, deve existir uma biblioteca que permita à aplicação realizar tarefas como a criação/eliminação de threads, troca de mensagens, escalonamento, etc. Neste modo o sistema operacional não sabe da existência dos threads, sendo a aplicação a única responsável por gerenciar essas threads.
4 Figura 8.1 Threads em modo usuário Uma vantagem deste modo é a rapidez e eficiência, pois o sistema operacional não sabe da existência das threads, isso evita a mudança do modo de acesso. Uma desvantagem é que o sistema operacional gerencia cada processo como se o mesmo tivesse apenas uma única thread. Quando o processo em estado de execução vai para o estado de espera, todas as suas threads também são colocadas em estado de espera, mesmo estando no estado de pronto. Neste caso, é preciso criar rotinas que permitam a essas threads serem executadas. Esse controle é transparente para o usuário e para o sistema operacional. Um dos maiores problemas na implementação de threads em modo usuário é o tratamento individual de sinais. Como o sistema operacional reconhece apenas os processos e não threads, os sinais são enviados para o processo, que devem ser reconhecidos e encaminhados a thread responsável para o devido tratamento. 8.4.2 Threads em Modo Kernel Threads em modo kernel são implementados diretamente pelo núcleo do sistema operacional, através de chamadas a rotinas do sistema que oferecem todas as funções de gerenciamento. Neste modo, o sistema operacional sabe da existência de cada thread e pode escaloná-los individualmente.
5 Figura 8.2 Threads em modo kernel O grande problema deste modo é que threads em modo kernel utilizam system calls e, consequentemente, há várias mudanças de modo de acesso, enquanto que as threads em modo usuário fazem todo o tratamento sem a intervenção do sistema operacional. 8.4.3 Threads em Modo Híbrido A arquitetura de threads em modo híbrido combina as vantagens de threads implementados em modo usuário com as dos threads em modo kernel. Um processo pode ter vários Threads em Modo Kernel e, este, por sua vez, ter vários threads em modo usuário. O núcleo do sistema operacional reconhece os threads em modo kernel e pode escaloná-los individualmente. Um thread em modo usuário pode ser executado por em thread em modo kernel em um determinado momento, e no instante seguinte, ser executado em outro.
6 Figura 8.3 Threads em modo híbdrido O modo híbrido é mais flexível, pois implementa os dois modos em conjunto, mas também herda os problemas provenientes de ambos. Quando um thread em modo kernel realiza uma chamada bloqueante, todos os threads em modo usuário são colocados no estado de espera. Threads que utilizam vários processadores devem utilizar diferentes threads em modo kernel, uma para cada processador, o que influi no desempenho. 8.4.4 Scheduler Activations (Ativações do Escalonador) O modelo ideal de implementação de threads deveria unir e utilizar as facilidades das threads em modo kernel com o desempenho e flexibilidade do modo usuário. Nesta arquitetura, ao invés de dividir as threads em modo usuário e modo kernel, como é feito no modelo híbrido, o kernel do sistema operacional troca informações com a biblioteca de threads utilizando uma estrutura de dados chamada scheduler activation.
7 Figura 8.4 Scheduler Activations A maneira de alcançar um melhor desempenho é evitar as mudanças de modos de acesso. Caso uma thread utilize uma chamada ao sistema que a coloque em estado de espera, a própria biblioteca em modo usuário escalona outra thread. 8.5 Modelos de Programação Um fator importante é a forma como as threads são criadas e eliminadas. Se uma aplicação cria um número excessivo de threads, poderá ocorrer uma sobrecarga no sistema, ocasionando uma queda de desempenho. Dependendo da aplicação, a definição do número de threads pode ser dinâmica ou estática. Quando a criação/eliminação é dinâmica, os threads são criados/eliminados de acordo com a demanda da aplicação, permitindo assim uma maior flexibilidade. Já em ambientes estáticos, o número de threads é definido na criação do processo onde a aplicação será executada. Para obter os benefícios do uso de threads, uma aplicação deve permitir que partes diferentes de seu código sejam executados em paralelo, de forma independente. Sistemas gerenciadores de banco de dados (SGBD), servidores de aplicações, servidores de arquivos ou impressão são exemplos onde o uso de múltiplos threads proporciona vantagens e benefícios.