Arquitetura de Sistemas

Operacionais
Francis Berenger Machado / Luiz Paulo Maia

• Sistemas Operacionais

• Capítulo 6 – Threads

• Professor Luciano Comin Nunes

lcominn@uol.com.br 1
 Processo
▪ Ambiente Monothread
o Um processo suporta apenas um “programa - sequência de instruções”.
o Aplicações concorrentes implementadas com o uso de múltiplos processos
independentes ou subprocessos.
o Assim, pode-se dividir uma aplicação em partes que trabalham
concorrentemente. Ex.: aplicações com interface gráfica em gerenciamento
de e-mails (leitura-envio-recebimento de novas mensagens).

2
 Processo

▪ Ambiente Monothread
o Cada novo processo criado requer recursos do SO.
o Ao término do processo o SO dispensa tempo de desalocação de recursos.
o Cada processo possui seu próprio espaço de endereçamento, requerendo
comunicação entre processos, tornando mais complexo e lento (arquivos,
memória, pipes etc).

3
 Processo
▪ Ambiente Multithread
o Inexiste a ideia de programas associados a processos.
o Pode existir um Thread de execução que compartilha seus recursos com
outros Threads.
▪ Podem compartilhar mesmo contexto de software e espaço de
endereçamento.
▪ Reduz tempo de criação, eliminação, comunicação e troca de contexto
entre processos, economizando recursos do sistema
▪ Um processo pode suportar múltiplas threads, cada qual associada a
uma parte do código.
▪ Um Thread pode ser definido como uma sub-rotina de um programa que
pode ser executada assincronamente, concorrendo com o programa chamador.
4
▪ O desenvolvedor deve especificar cada thread e associá-los às sub-rotinas
assíncronas.
 Processo
▪ Processo e Aplicação Multithread

5
 Processo
▪ Ambiente Multithread
o Cada processo responde a várias solicitações de forma concorrente ou
simultânea, havendo múltiplos processadores.
o Vantágens:
o Minimizar o uso de recursos
o Reduzir o overehead (sobrecarga) na criação, troca e eliminação de
processos.
o Threads compartilham o processador da mesma maneira que Processos.
o Se submetem aos mesmos “estados”: espera, pronto e execução. Ex.:
o Uma operação de E/S leva a um estado de “espera” enquanto outra
thread entra em “execução”.
6
 Processo
▪ Ambiente Multithread
o As trocas de contextos entre os diversos threads são feitas por meio dos
registradores gerais, PC e SP. Cada thread possui seu próprio contexto de
hardware.
o Quando um thread está em “execução”, seu contexto de hardware está
armazenado nos registradores do processador.
o Ao terminar o uso de UCP, as informações da thread são atualizadas no seu
contexto de hardware.
o As implementações das threads são feitas com o uso dos TCBs (Bloco de
Controle do Thread – Thread Control Block).
o No TCB são guardadas: contexto de hardware, prioridade, estado de
execução e bits de estado.
o Threads compartilham o mesmo espaço de endereçamento. Isto requer 7
mecanismos de comunicação e sincronização entre Threads.
 Processo
▪ Ambiente Multithread – Benefícios:
o Maior rapidez na execução de programas (em comparação com múltiplos
processos). Há um menor tempo em criação, troca de contexto e eliminação,
gerando menor overehead.
o Possibilitam compartilhamento de outros recursos, tais como: descritores de
arquivos, temporizadores, sinais, atributos de segurança etc.
o Manuseio de planilhas, edição de textos, desenhos gráficos, imagens etc. são
beneficiadas com o uso de threads.
o Serviços remotos em ambientes cliente-servidor são melhor atendidos, pois
a aplicação continua realizando suas outras funcionalidades.

8
 Processo
▪ Ambiente Multithread – Benefícios:
o O núcleo do SO pode, também utilizar multithreading para executar suas
tarefas como um programa qualquer.

9
 Processo
▪ Ambiente Multithread
o Após criados os três threads, a máquina virtual Java faz o escalonamento a
seu modo.

10
 Processo
▪ Ambiente Multithread – Arquitetura e Implementação
o Modo “Usuário” (TMU) – São eficientes e dispensam o acesso ao núcleo do SO
o Com o uso de bibliotecas, os threads são implementados pela aplicação
do usuário e não pelo SO.
o A aplicação deve gerenciar: criação, eliminação, comunicação e
escalonamento, sincronização de threads.
o Isto facilita o uso de multithreads mesmo em SO que não suportam
esse recurso.

11
 Processo
▪ Ambiente Multithread – Arquitetura e Implementação
o Modo “Usuário” (TMU) – Limitações e cuidados especiais
o No momento em que um thread chama uma rotina do SO, este o coloca no
estado de espera (rotina bloqueante), juntamente com todo o processo e seus
outros threds em estado “pronto”. (usar, pois, rotinas não bloqueantes...)
o Tratamento de sinais enviados para um processo devem ser encaminhados
para cada thread, para o respectivo tratamento. Ex. interrupção de clock.
o Em multiprocessadores não é possível o uso de multithreads de um único
processo, pois o SO seleciona para execução em multiprocessadores somente
“processos” e não threads. Isto limita o uso de paralelismo.

12
 Processo
▪ Ambiente Multithread – Arquitetura e Implementação
o Modo “Kernel” (TMK)
o Implementados diretamente pelo núcleo do SO por meio de rotinas que
gerenciam e sincronizam atividades e uso de recursos.
o O SO sabe da existência de cada thread e os escalona individualmente.
o No caso de multiprocessadores, podem ser executados simultaneamente.

13
 Processo
▪ Ambiente Multithread – Arquitetura e Implementação
o Modo “Kernel” (TMK) – Limitações
o Baixo desempenho nos processos.
o Usam chamadas a rotinas do SO, gerando mudanças de acesso e de estado.

14
 Processo
▪ Ambiente Multithread – Arquitetura e Implementação
o Modo “Híbrido” (TMH)
o Combina as vantagens dos modos TMU e TMK.
o Um TMU pode sere executado em um TMK por um momento e retornar ao
seu próprio modo.
o O desenvolvedor cria a aplicação em termos de TMU e especifica quantos
TMKs estão associados ao processo.

15
 Processo
▪ Ambiente Multithread – Arquitetura e Implementação
o Modo “Híbrido” (TMH) - Limitações
o Apresenta problemas de ambos modos (TMU e TMK)
o Não há comunicação entre os modos.

16
 Processo
▪ Ambiente Multithread - Scheduler Activations
o Troca de informações com a biblioteca de threads
o Busca-se melhor desempenho evitando mudanças de modos (TMU e TMK)
o Chamados do SO, colocando em estado de espera, não é necessário que o
kernel seja ativado, bastando que a próprio biblioteca em TMU escalone
outro thread, por meio cooperativo de kernel-biblioteca.
o Os escalonamentos de threads são realizados de forma independente em
cada camada, mantendo a troca de informações.

17