Arquitetura de
Sistemas
Operacionais
Professor Sandro Teixeira Pinto
E-mail: sandro.pinto@unifil.br
Thread
6.1
• Um outro mecanismo para execução de tarefas concorrentes ;
• Linhas de controle de um mesmo processo;
• Independentes;
• Podem ser executadas concorrentemente;
• Compartilham o mesmo espaço de endereçamento;
Thread
6.1
•
Por definição uma THREAD são
várias linhas de execução DENTRO
de um mesmo processo;
Monothread
6.2
•
Em um ambiente monothread, um
processo suporta apenas um programa
no seu espaço de endereçamento.
•
Neste ambiente, aplicações concorrentes
são implementadas apenas com o uso de
múltiplos processos independentes ou
Monothread
Monothread
6.2
Na utilização de processos independentes
e subprocessos permite dividir uma
aplicação em partes que podem trabalhar
de forma concorrente.
EX: gerenciamento de e-mails.
Neste ambiente podemos estar lendo
mensagens antigas e ao mesmo tempo
enviando e recebendo novas mensagens.
Monothread
6.2
Com o uso de múltiplos processos, cada
funcionalidade do software implicaria a
criação de um novo processo para
atendê-la, aumentando o desempenho da
aplicação.
Monothread
6.2
Um problema neste tipo de implementação é que o uso de processos no desenvolvimento de
aplicações concorrentes demanda consumo de diversos recursos do sistema.
Outro problema é quanto ao compartilhamento de espaço de endereçamento. Como cada processo possui seu próprio espaço de endereçamento a comunicação entre processos fica difícil e lenta.
Monothread
6.2
Nesta figura existem três processos
monothreads cada um com seu próprio
contexto de hardware, software e espaço
de endereçamento.
Ambiente Multithread
6.3
Em ambiente multithread, não existe a idéia de
programas associados a processos, mas a
threads.A figura mostra um processo com 3
threads em execução
compartilhando o mesmo espaço de
Ambiente Multithread
6.3
Um Thread pode ser definido como uma
sub-rotina de um programa que pode ser
executada de forma assíncrona, ou seja,
executada concorrentemente ao
programa chamador.
No ambiente multithread, cada processo
pode responder a várias solicitações
concorrentemente, caso haja mais de um
processador.
Ambiente Multithread
6.3
Existe sempre um programa principal que
realiza a chamada de duas sub-rotinas
assíncronas( Sub_1 e Sub_2).
Inicialmente, o processo é criado apenas
com o Thread_1, quando o programa
principal chama as sub-rotinas são
criados novos threads.
Ambiente Multithread
Ambiente Multithread
Threads compartilham o processador da
mesma maneira que processos e passam
pelas mesmas mudanças de estado
(execução, espera e pronto).
Ex: quando um thread espera por uma
operação de E/S, o outro pode ser
executado.
Ambiente Multithread
Threads são implementados internamente através de uma estrutura de dados denominada BLOCO DE CONTROLE DO THREAD( thread control block- TCB ).
O TCB armazena, além do contexto de hardware, mais algumas informações relacionadas
exclusivamente ao thread, como:
• Prioridade;
• Estado de execução;
• Bits do estado;
Ambiente Multithread
A utilização do processador, discos e outros periféricos pode ser feita de forma concorrente pelos diversos threads.Em algumas aplicações a utilização de threads pode melhorar o desempenho da aplicação apenas executando tarefas em
Background(sem usuário), enquanto operações de E/S estão sendo
processadas.
Ex: editores de texto, planilhas, gráficos, etc.
Ambiente Multithread
Em ambientes cliente-servidor, os threads são
essenciais para solicitações de serviços
remotos.
Em ambiente multithread, um thread pode
solicitar o serviço remoto, enquanto a
aplicação pode continuar realizando outras
atividades, permitindo que diversos pedidos
sejam atendidos simultaneamente.
Ambiente Multithread
Programação Multithread
O conjunto de rotinas disponíveis para que uma
aplicação utilize as facilidades dos threads é
chamada de pacotes de Threads.
O escalonamento dos threads é realizada pelo
sistema operacional, independentemente da
ordem que foram criados.
Ver programa na página 94 e 95.
Programação Multithread
Um fator importante em aplicações multithread é o número total de threads e a forma como são criados e eliminados.
Se a aplicação cria um número excessivo de threads poderá ocorrer um overhead no sistema,
ocasionando uma queda no desempenho.
Dependendo da implementação, a definição do
número de threads pode ser dinâmica ou estática.Em dinâmica os Threads são criados e eliminados
conforme a demanda, já em estáticos, o número de threads é definido na criação do processo.
Arquitetura e Implementação
A arquitetura dos threads podem ser oferecidos
das seguintes formas:
•
Biblioteca de rotinas fora do núcleo do
sistema operacional ( modo usuário );
•
Núcleo do sistema ( modo Kernel );
•
Combinação de ambos ( modo Híbrido );
•
Modelo conhecido como Scheduler
Activations.
Arquitetura e Implementação
Arquitetura e Implementação
Threads em modo Usuário
Threads em modo usuário(TMU) são
implementados pela aplicação e não pelo
sistema operacional.
Existe uma biblioteca de rotinas que possibilite
à aplicação realizar tarefas como criação e
eliminação de threads, troca de mensagens
entre threads e uma política de
escalonamento.
Arquitetura e Implementação
Threads em modo Usuário
A vantagem deste modelo é a possibilidade de
implementar aplicações multithreads mesmo
em sistemas operacionais que não suportam
threads.
Utilizando de biblioteca, múltiplos threads
podem ser criados, compartilhando o mesmo
espaço de endereçamento do processo, além
de outros recursos.
TMU são rápidos e eficientes por dispensarem
acessos ao kernel do SO.
Arquitetura e Implementação
Threads em modo Usuário
Arquitetura e Implementação
Threads em modo Usuário
TMU possui uma grande limitação, 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, todo o processo é colocado em estado de espera, mesmo havendo outros threads prontos para execução.
Para contornar esta limitação, a biblioteca tem que possuir rotinas que substituam as rotinas
bloqueantes.
Arquitetura e Implementação
Threads em modo Kernel
Threads em modo Kernel (TMK) são implementados diretamente pelo núcleo do sistema operacional, através de chamadas de rotinas do sistema que oferecem todas as funções de gerenciamento e sincronização.
O sistema operacional sabe da existência de cada thread e pode escaloná-los
individualmente.
Arquitetura e Implementação
Threads em modo Kernel
Neste pacote em modo Kernel existe um grande problema: seu baixo desempenho.
Enquanto nos pacotes em modo usuário é feito sem 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 de rotinas do sistema, com várias mudanças do modo de acesso.
Arquitetura e Implementação
Threads em modo Híbrido
A arquitetura de Threads em modo Híbrido combina as vantagens de threads implementados em modo usuário(TMU) e modo Kernel(TMK).
Arquitetura e Implementação
Scheduler Activations
6.5.4
O modelo ideal deveria utilizar as facilidades do pacote em modo Kernel com o desempenho e a flexibilidade do modo usuário.
Este pacote combina o melhor das duas arquiteturas, mas ao contrário de dividir os threads em modo usuário entre os de modo Kernel o núcleo do sistema troca informações com a biblioteca de threads.
Arquitetura e Implementação
Scheduler Activations
6.5.4
O modelo ideal deveria utilizar as facilidades do pacote em modo Kernel com o desempenho e a flexibilidade do modo usuário.
Este pacote combina o melhor das duas arquiteturas, mas ao contrário de dividir os threads em modo usuário entre os de modo Kernel o núcleo do sistema troca informações com a biblioteca de threads.
