tudo sobre threads

Prévia do material em texto

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 sub-
rotinas 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 threadsdeveria 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.