1 de 14

THREADS
NDICE

1. Introduo
2. Ambiente Monothread
3. Ambiente Multithread
4. Arquitetura e Implementao
5. Modelos de Programao
6. Bibliografia


1. INTRODUO

At o final da dcada de 1970, sistemas operacionais suportavam apenas
processos com um nico thread, ou seja, um processo com apenas um nico
programa fazendo parte do seu contexto. Em 1979, durante o desenvolvimento do
sistema operacional Toth, foi introduzido o conceito de processos lightweight
(peso leve), onde o espao de endereamento de um processo era compartilhado
por vrios programas. Apesar do conceito revolucionrio, a idia no foi utilizada
comercialmente, e somente em meados de 1980, com o desenvolvimento do
sistema operacional Mach na Universidade de Carnegie Mellon, ficou clara a
separao entre o conceito de processo e thread.
A partir do conceito de mltiplos threads possvel projetar e implementar
aplicaes concorrentes de forma eficiente, pois um processo pode ter partes
diferentes do seu cdigo sendo executadas em paralelo, com um menor overhead
do que utilizando mltiplos processos. Como os threads de um mesmo processo
compartilham o mesmo espao de endereamento, a comunicao entre threads
no envolve mecanismos lentos de intercomunicao entre processos,
aumentando o desempenho da aplicao.
2 de 14
O desenvolvimento de programas que exploram benefcios da programao
multithread no simples. A presena do paralelismo introduz um novo conjunto
de problemas como a comunicao e sincronizao de threads. Existem
diferentes modelos de implementao de threads em um sistema operacional,
onde desempenho, flexibilidade e custo devem ser avaliados.
Atualmente o conceito de multithread pode ser encontrado em diversos
sistemas operacionais, como no Sun Solaris e Microsoft Windows 2000. A
utilizao comercial de sistemas operacionais multithread crescente em funo
do aumento da popularidade dos sistemas com mltiplos processadores, do
modelo cliente-servidor e dos sistemas distribudos.


2. AMBIENTE MONOTHREAD

Um programa uma seqncia de instrues, composta por desvios,
repeties e chamadas a procedimentos e funes. Em um ambiente monothread,
um processo suporta apenas um programa no seu espao de endereamento.
Neste ambiente, aplicaes concorrentes so implementadas apenas com o uso
de mltiplos processos independentes ou subprocessos.
A utilizao de processos independentes e subprocessos permite dividir
uma aplicao em partes que podem trabalhar de forma concorrente, como por
exemplo, em um software de gerenciamento de e-mails. Com o uso de mltiplos
processos, cada funcionalidade do software implicaria a criao de um novo
processo para atend-la, aumentando o desempenho da aplicao.

3 de 14

Figura 1: Concorrncia com subprocessos e processos independentes

O problema neste tipo de implementao que o uso de processos do
desenvolvimento de aplicaes concorrentes demanda consumo de diversos
recursos do sistema. Sempre que um novo processo criado, o sistema deve
alocar recursos para cada processo, consumindo tempo de processador neste
trabalho. No caso do trmino do processo, o sistema dispensa tempo para
desalocar recursos previamente alocados.
Outro problema a ser considerado quanto ao compartilhamento do
espao de endereamento. Como cada processo possui seu prprio espao de
endereamento, a comunicao entre processos torna-se difcil e lenta, pois utiliza
mecanismos como pipes, sinais, semforos, memria compartilhada ou troca de
mensagens. Alm disto, o compartilhamento de recursos comuns aos processos
concorrentes, como memria e arquivos abertos, no simples.


Figura 2: Ambiente monothread

So exemplos de sistemas monothread, o Microsoft MS-DOS, as primeiras
verses do MS-Windows, VAX/VMS e Unix.
4 de 14


3. AMBIENTE MULTITHREAD

Em um ambiente multithread, ou seja, com mltiplos threads, no existe a
idia de programas associados a processos, mas, sim, a threads. O processo,
neste ambiente, tem pelo menos um thread de execuo, mas pode compartilhar
o seu espao de endereamento com inmeros outros threads.


Figura 3: Ambiente multithread

De forma simplificada, um thread pode ser definido como uma sub-rotina de
um programa que pode ser executada de forma assncrona, ou seja, executada
paralelamente ao programa chamador. O programador deve especificar os
threads, associando-os s sub-rotinas assncronas. Desta forma, um ambiente
multithread, possibilita a execuo concorrente de sub-rotinas dentro de um
mesmo processo.
Na figura abaixo existe um Programa Principal que realiza a chamada de
duas sub-rotinas assncronas (Sub_2 e Sub_3). Inicialmente, o processo criado
apenas com o Thread_1 para execuo do Programa Principal. Quando o
Programa Principal chama as sub-rotinas Sub_2 eSub_3, so criados os
Thread_2 e Thread_3, respectivamente, e executados independentemente do
programa principal. Neste processo, os trs threads so executados
concorrentemente.
5 de 14

Figura 4: Aplicao Multithread

No ambiente multithread, cada processo pode responder a vrias
solicitaes concorrentemente ou mesmo simultaneamente, caso haja mais de um
processador. A grande vantagem do uso de threads a possibilidade de
minimizar a alocao de recursos do sistema, alm de diminuir o overhead na
criao, troca e eliminao de processos.
Threads compartilham o processador da mesma maneira que processos e
passam pelas mesmas mudanas de estado. Para permitir a troca de contexto
entre os diversos threads, cada thread possui seu prprio contexto de hardware,
com o contedo dos registradores gerais, PC e SP. Quando um thread est sendo
executado, seu contexto de hardware est armazenado nos registradores do
processador. No momento em que o thread perde a utilizao da CPU, as
informaes so atualizadas no seu contexto de hardware.
Dentro de um mesmo processo, threads compartilham o mesmo contexto
de software e espao de endereamento com os demais threads, porm cada
thread possui seu contexto de hardware individual. Threads so implementados
internamente atravs de uma estrutura de dados denominada bloco de controle
do thread (Thread Control Block TCB). O TCB armazena, alm do contexto de
6 de 14
hardware, mais algumas informaes relacionadas exclusivamente ao thread,
como prioridade, estado de execuo e bits de estado.
Em ambientes monothread, o processo ao mesmo tempo a unidade de
alocao de recursos e a unidade de escalonamento. A independncia entre os
conceitos de processo e thread permite separar a unidade de alocao de
recursos da unidade de escalonamento, que em ambientes monothread esto
fortemente relacionadas. Em um ambiente multithread, a unidade de alocao de
recursos o processo, onde todos os seus threads compartilham o espao de
endereamento, descritores de arquivos e dispositivos de E/S. Por outro lado,
cada thread representa uma unidade de escalonamento independente. Neste
caso, o sistema no seleciona um processo para a execuo, mas sim um de
seus threads.
A grande diferena entre aplicaes monothread e multithread est no uso
do espao de endereamento. Processos independentes e subprocessos
possuem espaos de endereamento individuais e protegidos, enquanto threads
compartilham o espao dentro de um mesmo processo. Esta caracterstica
permite que o compartilhamento de dados entre threads de um mesmo processo
seja mais simples e rpido, se comparado com ambiente monothread.
Como threads de um mesmo processo compartilham o mesmo espao de
endereamento, no existe qualquer proteo no acesso memria, permitindo
que um thread possa alterar facilmente dados de outros. Para que threads
trabalhem de forma cooperativa, fundamental que a aplicao implemente
mecanismos de comunicao e sincronizao entre threads, a fim de garantir o
acesso seguro aos dados compartilhados na memria.
O uso de multithreads proporciona uma srie de benefcios. Programas
concorrentes com mltiplos threads so mais rpidos do que programas
concorrentes implementados com mltiplos processos, pois operaes de criao,
troca de contexto e eliminao dos threads geram menor overhead (ver tabela
abaixo). Como os threads dentro de um processo dividem o mesmo espao de
endereamento, a comunicao entre eles pode ser realizada de forma rpida e
eficiente. Alm disso, threads em um mesmo processo podem compartilhar
facilmente outros recursos, como descritores de arquivos, temporizadores, sinais,
atributos de segurana, etc.

Implementao Tempo de criao ( 6 Tempo de sincronizao ( V
7 de 14
Processo 1700 200
Processo lightweight 390 390
Thread 52 66

A utilizao do processador, dos discos e de outros perifricos pode ser
feita de forma concorrente pelos diversos threads, significando melhor utilizao
dos recursos computacionais disponveis. Em algumas aplicaes, a utilizao de
threads pode melhorar o desempenho da aplicao apenas executando tarefas
em background enquanto operaes de E/S esto sendo processadas.

Figura 5: Aplicao multithread

Em ambientes cliente-servidor, threads so essenciais para solicitaes de
servios remotos. Em um ambiente monothread, se uma aplicao solicita um
servio remoto, ela pode ficar esperando indefinidamente, enquanto aguarda pelo
resultado. Em um ambiente multithread, um thread pode solicitar o servio remoto,
enquanto a aplicao pode continuar realizando outras atividades. J para o
processo que atende a solicitao, mltiplos threads permitem que diversos
pedidos sejam atendidos simultaneamente.

8 de 14

Figura 6: Aplicao multithread

No apenas aplicaes tradicionais podem fazer uso dos benefcios do
multithreading. O ncleo do sistema operacional tambm pode ser implementado
com o uso desta tcnica de forma vantajosa, como na arquitetura microkernel.


4. ARQUITETURA E IMPLEMENTAO

O conjunto de rotinas disponveis para que uma aplicao utilize as
facilidades dos threads chamado de pacote de threads. Existem diferentes
abordagens na implementao deste pacote em um sistema operacional, o que
influenciar no desempenho, na concorrncia e na modularidade das aplicaes
multithread.
Threads podem ser oferecidos por uma biblioteca de rotinas fora do ncleo
do sistema operacional (modo usurio), pelo prprio ncleo do sistema (modo
kernel), por uma combinao de ambos (modo hbrido) ou por um modelo
conhecido como scheduler activations. A tabela abaixo mostra as diversas
arquiteturas para diferentes ambientes operacionais:
9 de 14

Ambientes Arquitetura
Distributed Computing Environment Modo usurio
Compaq OpenVMS verso 6 Modo usurio
Microsoft Windows 2000 Modo kernel
Compaq Unix Modo kernel
Compaq OpenVMS verso 7 Modo kernel
Sun Solaris verso 2 Modo hbrido
University of Washington Fast Threads Scheduler activations

Uma das grandes dificuldades para a utilizao de threads foi a ausncia
de um padro. Em 1995, o padro POSIX P1003.1c foi aprovado e posteriormente
atualizado para a verso P1003.4a. Com este padro, tambm conhecido como
Pthreads, aplicaes comerciais multithreading tornaram-se mais simples e de
fcil implementao. O padro Pthreads largamente utilizado em ambientes
Unix, como o Sun Solaris Pthreads e o DECthreads para Digital OSF/1.

4.1. Threads em Modo Usurio
Threads em modo usurio (TMU) so implementados pela aplicao e no
pelo sistema operacional. Para isso, deve existir uma biblioteca de rotinas que
possibilite aplicao realizar tarefas como criao/eliminao de threads,
troca de mensagens entre threads e uma poltica de escalonamento. Neste
modo, o sistema operacional no sabe da existncia de mltiplos threads,
sendo responsabilidade exclusiva da aplicao gerenciar e sincronizar os
diversos threads existentes.
A vantagem deste modelo a possibilidade de implementar aplicaes
multithreads mesmo em sistemas operacionais que no suportam threads.
Utilizando a biblioteca, mltiplos threads podem ser criados, compartilhando o
mesmo espao de endereamento do processo, alm de outros recursos. TMU
so rpidos e eficientes por dispensarem acessos ao kernel do sistema
operacional, evitando assim a mudana do modo de acesso.

10 de 14

Figura 7: Threads em modo usurio

TMU possuem uma grande limitao, pois o sistema operacional gerencia
cada processo como se existisse apenas um nico thread. No momento em
que um thread chama uma rotina do sistema que o coloca em estado de
espera (rotina bloqueante), todo o processo colocado no estado de espera,
mesmo havendo outros threads prontos para execuo. Para contornar esta
limitao, a biblioteca tem que possuir rotinas que substituam as rotinas
bloqueantes por outras que no possam causar o bloqueio de um thread. Todo
este controle transparente para o usurio e para o sistema operacional.
Talvez um dos maiores problemas na implementao de TMU seja o
tratamento individual de sinais. Como o sistema reconhece apenas processos
e no threads, os sinais enviados para um processo devem ser reconhecidos e
encaminhados a cada thread para tratamento. No caso do recebimento de
interrupes de clock, fundamental para implementao do tempo
compartilhado, esta limitao crtica. Neste caso, os sinais de temporizao
devem ser interceptados, para que se possa interromper o thread em
execuo e realizar a troca de contexto.
Em relao ao escalonamento em ambientes com mltiplos processadores,
no possvel que mltiplos threads de um processo possam ser executados
em diferentes CPUs simultaneamente, pois o sistema seleciona apenas
processos para execuo e no threads. Esta restrio limita drasticamente o
grau de paralelismo da aplicao, j que os threads de um mesmo processo
podem ser executados em somente um processador de cada vez.

4.2. Threads em Modo KerneI
Threads em modo kernel (TMK) so implementados diretamente pelo
ncleo do sistema operacional, atravs de chamadas a rotinas do sistema que
11 de 14
oferecem todas as funes de gerenciamento e sincronizao. O sistema
operacional sabe da existncia de cada thread e pode escalon-los
individualmente. No caso de mltiplos processadores, os threads de um
mesmo processo podem ser executados simultaneamente.


Figura 8: Threads em modo kernel

O grande problema para pacotes em modo kernel o seu baixo
desempenho. Enquanto nos pacotes em modo usurio todo tratamento feito
sem a ajuda do sistema operacional, ou seja, sem a mudana do modo de
acesso, pacotes em modo kernel utilizam chamadas a rotinas do sistema e,
conseqentemente, vrias mudanas no modo de acesso. A tabela abaixo
compara o desempenho de duas operaes distintas envolvendo a criao,
escalonamento, execuo e eliminao de um processo/thread:
Implementao Operao 1 6 Operao 2 ( V
Subprocessos 11.300 1.840
Threads em modo kernel 948 441
Threads em modo usurio 34 37

4.3. Threads em Modo Hbrido
A arquitetura de threads em modo hbrido combina as vantagens de
threads implementados em modo usurio e threads em modo kernel. Um
processo pode ter vrios TMK e, por sua vez, um TMK pode ter vrios TMU. O
ncleo do sistema reconhece os TMK e pode escalon-los individualmente.
Um TMU pode ser executado em um TMK, em um determinado momento, e no
instante seguinte pode ser executado em outro.
O programador desenvolve a aplicao em termos de TMU e especifica
quantos TMK esto associados ao processo. Os TMU so mapeados em TMK
enquanto o processo est sendo executado. O programador pode utilizar
apenas TMK, TMU ou uma combinao de ambos.
12 de 14

Figura 9: Threads em modo hbrido

O modo hbrido, apesar da maior flexibilidade, apresenta problemas
herdados de ambas as implementaes. Por exemplo, quando uma TMK
realiza uma chamada bloqueante, todos os TMU so colocados no estado de
espera. TMU que desejam utilizar vrios processadores devem utilizar
diferentes TMK, o que influenciar no desempenho.

4.4. ScheduIer Activations
Os problemas apresentados no pacote de threads em modo hbrido
existem devido falta de comunicao entre os threads em modo usurio e
em modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em
modo kernel com o desempenho e flexibilidade do modo usurio.
Introduzido no incio da dcada de 1990 na Universidade de Washington,
este pacote combina o melhor das duas arquiteturas, mas em vez de dividir os
threads em modo usurio entre os de modo kernel, o ncleo do sistema troca
informaes com a biblioteca de threads utilizando uma estrutura de dados
chamada scheduler activations.

Figura10: Scheduler Activations
13 de 14

A maneira de alcanar um melhor desempenho evitar as mudanas de
modos de acesso desnecessrias. Caso um thread utilize uma chamada ao
sistema que o coloque no estado de espera, no necessrio que o kernel
seja ativado, bastando que a prpria biblioteca em modo usurio escalone
outro thread. Isto possvel porque a biblioteca em modo usurio e o kernel se
comunicam e trabalham de forma cooperativa. Cada camada implementa seu
escalonamento de forma independente, porm trocando informaes quando
necessrio.


5. MODELOS DE PROGRAMAO

O desenvolvimento de aplicaes multithread no simples, pois exige que
a comunicao e o compartilhamento de recursos entre os diversos threads seja
feita de forma sincronizada para evitar problemas de inconsistncias e deadlock.
Alm das dificuldades naturais no desenvolvimento de aplicaes concorrentes, o
procedimento de depurao bastante complexo.
Um fator importante em aplicaes multithread o nmero total de threads
e a forma como so criados e eliminados. Se uma aplicao cria um nmero
excessivo de threads, poder ocorrer um overhead no sistema, ocasionando uma
queda de desempenho.
Dependendo da implementao, a definio do nmero de threads pode
ser dinmica ou esttica. Quando a criao/eliminao dinmica, os threads so
criados/eliminados conforme a demanda da aplicao, oferecendo grande
flexibilidade. J em ambientes estticos, o nmero de threads definido na
criao do processo onde a aplicao ser executada.
Para obter os benefcios do uso de threads, uma aplicao deve permitir
que partes diferentes do seu cdigo sejam executadas em paralelo de forma
independente. Se um aplicativo realiza vrias operaes de E/S e trata eventos
assncronos, a programao multithread aumenta seu desempenho at mesmo
em ambientes com um nico processador. Sistemas gerenciadores de banco de
dados (SGBDs), servidores de arquivos ou impresso so exemplos onde o uso
de mltiplos threads proporciona grandes vantagens e benefcios.

14 de 14
6. BIBLIOGRAFIA

MACHADO, F. B., MAIA, L. P., Arquitetura de Sistemas Operacionais, 3
a
edio, Ed.
LTC, 2002, Rio de Janeiro

TANENBAUM, A., Sistemas Operacionais Modernos, 5
a
edio, Ed. Makron Books,
1999, Rio de Janeiro