Aula 6_7 - Threads

(1)

Sistemas Operacionais

Threads

https://sites.google.com/site/thiagoaalves/

thiago.augusto2@anhanguera.com

(2)

6 – Thread

 Ambiente Monothread

o Concorrência implementada apenas com o uso de processos independentes e subprocessos

 Permite dividir uma aplicação em partes que podem trabalhar de forma concorrente

o Problemas:

 Consumo maior de recursos do sistema

 Espaço de endereçamento não é compartilhado

o Comunicação entre processos mais difícil e lenta o Compartilhamento de recursos é mais

(3)

 Ambiente Monothread

Subprocessos Processos Independentes

(4)

 Ambiente Monothread

o Processos monothread possuem, cada um, seu

próprio contexto de hardware, de software e espaço de

endereçamento

o Exemplos de SO’s monothread:

 MS-DOS, primeiras versões do MS-Windows

 Primeiros sistemas UNIX

Thread Thread Thread

(5)

 Ambiente Multithread

Contexto de hardware Contexto de hardware Contexto de hardware Espaço de endereçamento C o n te x to d e so ft w a re Thread 3 Thread 2 Thread 1

6 – Thread

(6)

 Ambiente Multithread

o Programas são associados a threads, não a procesos

 Cada programa tem pelo menos uma thread de execução  Pode compartilhar espaço de endereçamento com outras threads criadas pelo programa

o Thread corresponde a uma sub-rotina que pode ser executada de forma assíncrona (paralela) das demais

 Sub-rotinas concorrentes dentro de um mesmo processo  Threads criadas dinamicamente, sob demanda

(7)

 Aplicação Multithread

6 – Thread

Espaço de endereçamento Processo Programa Principal C o n te x to d e H a rd w a re C o n te x to d e H a rd w a re C o n te x to d e H a rd w a re Call Sub_1 Call Sub_2 Thread_1 Thread_2 Thread_3 PC SP PC SP PC SP Fim Sub_2 Variáveis Ret Sub_1 Ret

..

.

..

.

(8)

 Aplicação Multithread

o Minimiza a alocação de recursos do sistema

o Mais rápidos p/ criação, término e troca de contexto

o Compartilham processador da mesma forma que processos independentes

 Mudança de estados entre wait, ready e running  Cada thread com contexto próprio de hardware

o Threads de um mesmo processo compartilham contexto de

software e espaço de endereçamento (comunicação mais rápida

e eficiente)

o Implementadas por estrutura chamada Thread Control Block (TCB)

(9)

oTCB armazena contexto de hardware e informações exclusivas da thread (prioridade, estado)

o Unidade de alocação de recursos é o processo

 Threads criadas compartilham recursos do processo o Unidade de escalonamento é a thread

 SO não escalona o processo para execução, mas sim uma de suas threads

o Compartilhamento de espaço de endereçamento inibe mecanismos de proteção no acesso a este espaço

(aplicação deve cuidar disto)

(10)

 Aplicação Multithread

o Threads de um mesmo processo pode facilmente

compartilhar recursos como descritores de arquivos,

sinais, temporizadores, etc

o Uso de periféricos pode ser realizado de forma

concorrente entre as threads

o Melhora desempenho de algumas aplicações onde

tarefas podem ser executadas em background

durantes operações de E/S

 Exs: editores de texto, planilhas, aplicações

gráficas, processamento de imagens

(11)

 Aplicação Multithread

o Thread principal solicita

operações de E/S

o Threads específicas

executam as operações de

E/S

Th r e a d d e e n tr a d a Th r e a d d e g r a v a çã o Th r e a d d e e xi b i çã o Bu f f e r

6 – Thread

(12)

o Essenciais para arquiteturas cliente-servidor

 Thread no cliente p/ solicitar e aguardar o serviço enquanto thread principal continua executando em background

o Evita que processo cliente pare aguardando serviço pedido

 Processo servidor dispara threads para atender cada solicitação que chega de maneira simultânea

o Evita que uma solicitação precise aguardar o término do atendimento das solicitações anteriores

o Úteis para núcleo de arquiteturas microkernel

(13)

 Aplicação Multithread

Solicitações Processo servidor Thread Thread Processo cliente

Processo cliente Processo cliente Thread

(14)

 Arquitetura e Implementação

o Sistemas Operacionais disponibilizam pacotes de threads para serem usados pelas aplicações

o Abordagem usada no pacote influenciará o desempenho, a concorrência e a modularidade das aplicações multithread o Podem ser oferecidas de quatro formas:

 Biblioteca de rotinas em modo usuário (fora do núcleo do SO)

 Rotinas em modo kernel (do núcleo do SO)  Modo híbrido (modos kernel + usuário)

 Modelo de Scheduler Activations

(15)

 Arquitetura e Implementação

o Ex. de SO’s de acordo com a arquitetura de thread:  Modo usuário

o Open VMS versão 6  Modo kernel

o Windows 2000, Open VMS versão 7, Compaq UNIX  Modo híbrido

o Sun Solaris versão 2

 Modelo de Scheduler Activations

o FastThreads (University of Washington)

(16)

 Threads em Modo Usuário

o Threads em modo usuário (TMU) são implementadas pela aplicação, e não pelo SO, através de uma biblioteca de rotinas

 Criação, eliminação, troca de mensagens, política de escalonamento

o SO não gerencia nem sincroniza as múltiplas thread, é responsabilidade da aplicação

o Vantagem é poder implementar aplicações multithreads em SO’s que não suportam threads

o TMU’s são mais rápidas por dispensarem acessos ao kernel

do SO, porém mais limitadas

(17)

 Threads em Modo Usuário

o SO gerencia TMU’s como se fosse uma única thread

 Caso uma thread entre em estado de espera, todo o processo fica em estado espera

 Biblioteca deve possuir rotinas que substituam as rotinas bloqueantes por outras não-bloqueantes

o Sinais são enviados para o processo, não para a thread  Processo deve reconhecer os sinais e encaminhá-los para as threads de direito

 O mesmo para interrupções de clock objetivando

time-sharing

(18)

 Threads em Modo Usuário

o Caso hajam múltiplos processadores, TMU’s não

poderão rodar nos diferentes processadores

 Como o SO só enxerga o processo, todas as

TMU’s rodarão no mesmo processador

 Limitação extrema para o paralelismo da

aplicação

Modo usuário Modo kernel Kernel Biblioteca T h re a d 0 T h re a d 4 T h re a d 3 T h re a d 2 T h re a d 1

6 – Thread

(19)

 Threads em Modo Kernel

o Threads em modo kernel (TMK) são implementadas

diretamente pelo núcleo do SO através de system calls que fazem o gerenciamento e a sincronização

 SO escalona as threads individualmente

 Utiliza capacidade de múltiplos processadores

o Baixo desempenho devido às mudanças de modo de acesso usuário-kernel-usuário (10 a 30x, +/-) Modo usuário Modo kernel Kernel T h re a d 0 T h re a d 4 T h re a d 3 T h re a d 2 T h re a d 1

6 – Thread

(20)

 Threads em Modo Híbrido

o Threads em modo híbrido (TMH) combinam vantagens das TMU’s e das TMK’s

 Processo pode ter várias TMK’s e as TMK’s podem ter várias TMU’s

 TMK’s escalonadas individualmente pelo SO

 Uma TMU pode ser executada por qualquer TMK o Apesar da flexibilidade, apresenta desvantagens

 Quando TMK faz uma operação bloquante, todas as TMU’s associadas à TMK ficam bloqueadas

 TMU’s que precisem rodar em diferentes processadores

precisam estar em TMK’s distintas

(21)

 Threads em Modo Híbrido

Modo usuário Modo kernel Kernel TMK 0 TMK 1 TMK 2 TMK 3 Biblioteca T M U 0 T M U 4 T M U 5 T M U 3 T M U 2 T M U 1

6 – Thread

(22)

 Threads no Modelo Scheduler Activations

o Problemas das TMH’s em muito se devem à falta de comunicação entre TMU’s e TMK’s

o O ideal é combinar o que há de melhor nas TMU’s e nas TMK’s sem precisar repetir os modelos

o Modelo de scheduler activations

 Introduzido na década de 1990 na Universidade de Washington

 Núcleo do SO troca informações com biblioteca de threads através de estrutura chamada scheduler activations

 Evita mudanças desnecessárias de modos de acesso

(23)

 Threads no Modelo Scheduler Activations

o Caso uma thread faça uma chamada bloqueante, biblioteca em modo usuário escalona outra thread em cooperação com modo kernel

 Cada camada implementa seu escalonamento de forma independente, trocando informações quando necessário

Modo usuário Modo kernel Kernel Biblioteca T h re a d 0 T h re a d 4 T h re a d 3 T h re a d 2 T h re a d 1

6 – Thread

(24)

 Modelos de Programação

o Desenvolvimento de aplicações multithread exige

sincronismo na comunicação e compartilhamento de recursos entre as threads

 Deve-se evitar problemas de inconsistência e deadlocks o Procedimento de depuração torna-se mais complicado

o Fator importante para desempenho do programa é sua

política de criação e eliminação de threads, o que implicará no número total de threads coexistindo

o Uma boa estratégia de modularização do programa e conseqüente divisão em threads é fundamental

(25)

 Problema do Barbeiro

o Na barbearia há um barbeiro, uma cadeira de

barbeiro e 5 para espera

o Se um cliente chega e o barbeiro está

trabalhando, ele senta se houver cadeira vaga,

senão vai embora

o Se não há nenhum cliente para atender, barbeiro

(26)

Problema



Qual o maior erro encontrado na

problema da Barbearia?



Agora se pensarmos em recursos

computacionais qual o maior problema

que podemos ter?

(27)

7 – Sincronização e Comunicação entre Processos

 Sincronização e Comunicação

o Numa aplicação concorrente, é natural que processos

precisem comunicar entre si

 Implementação através de mecanismos como variáveis

compartilhadas ou trocas de mensagens

 Processos precisam ter sua execução sincronizada

através de mecanismos do SO

o Exemplo com buffer de comunicação:

 Processo só poderá gravar os dados se buffer estiver

liberado

 Processo só poderá ler os dados quando estes

(28)

 Sincronização e Comunicação

Processo gravador Processo leitor dado Sincronização leitu ra gra va çã_o Buffer

(29)

 Sincronização e Comunicação

o Mecanismos de sincronização:

 Garantem a comunicação entre processos

concorrentes

 Garantem o acesso a recursos

compartilhados

 Garantem a integridade e a confiabilidade na

(30)

7 – Sincronização e Comunicação entre Processos  Concorrência em Programas

o Cada linguagem tem sua notação para especificar as

partes do programa que devem ser executadas concorrentemente

 Fork e Join (Conway, Dennis e Van Horn, 1963/66) o Fork <X> – dispara o processo X

o Join <X> – interrompe execução até que

processo X termine (sincroniza processos)

 ParBegin/CoBegin e ParEnd/CoEnd (Dijkstra, 1965) o Cada comando executado concorrentemente

(31)

 Concorrência em Programas

Processo principal Processo principal

Processo 1 Processo 2 Processo n PARBEGIN Comando_1; Comando_2; . . Comando_n; PAREND

(32)

7 – Sincronização e Comunicação entre Processos  Compartilhamento de Recursos

o Arquivos compartilhados

 Ex: atualizações em um mesmo saldo bancário

 Caso o processo não “trave” o arquivo com

saldo, poderá haver inconsistência

o Variáveis compartilhadas

 Um processo só poderá operar com a variável

após processo anterior completar sua operação

 Análogo ao caso de arquivos compartilhados o Estes problemas são chamados de race conditions

(33)

Compartilhamento de Recursos

PROGRAM Conta_Corrente; .

.

READ (Arq_Contas, Reg_Cliente); READLN (Valor_Dep_Ret);

Reg_Cliente.Saldo := Reg_Cliente.Saldo + Valor_Dep_Ret; WRITE (Arq_Contas, Reg_Cliente);

. .

(34)

 Exclusão Mútua

o Solução mais simples

o Impede que dois ou mais processos acessem

simultaneamente um mesmo recurso

 Quando um processo estiver acessando o

recurso, demais processos que desejam

acessá-los devem ficar em espera

 Parte do código que faz acesso ao recurso é

denominada região crítica

o Uma vez garantida a execução mutuamente

exclusiva das regiões críticas, resolve-se

problemas de compartilhamento

(35)

7 – Sincronização e Comunicação entre Processos  Exclusão Mútua

o Mecanismos que implementam exclusão mútua se

valem de protocolos de acesso à região crítica

 Sempre que um processo desejar executar

instruções de uma região crítica, ele deverá executar um protocolo de entrada nesta região

 Sempre que o processo desejar sair da região

crítica, ele deverá executar um protocolo de saída desta região

o Protocolo de entrada indica que há processo

executando instruções na região crítica

o Protocolo de saída sinaliza a liberação da região

(36)

o Duas situações indesejadas devem ser evitadas:  Starvation ou espera indefinida

o Processo nunca consegue entrar na região

crítica, ficando eternamente em espera

o Pode ocorrer devido a critérios do SO para

seleção do processo que vai entrar numa RC que tenha sido liberada

 Critérios baseados em prioridade ou em

aleatoriedade

 Sistema FIFO, por exemplo, resolve o

(37)

 Exclusão Mútua

o Outra situação indesejada que deve ser evitada:

 Processo fora da RC impede que outros

processos entrem na RC

o Recurso está livre, mas alocado a um

determinado processo

o Reduz grau de compartilhamento

o Para implementar a exclusão mútua, são usadas

(38)

o Soluções de hardware:

 Desabilitar de interrupções

o Processo desabilita todas as interrupções

antes de entrar na RC, reabilitando-as após deixá-la

o Não há mudança de contexto enquanto na RC o Solução simples mas com limitações:

 Multiprogramação fica comprometida

 Ineficiente com múltiplos processadores  Interessante para o kernel do SO

(39)

 Exclusão Mútua

o Soluções de hardware:

 Instrução Test-and-Set

o

Instrução “de máquina” que permite ler

uma variável, armazená-la em outra área e

atribuir novo valor à variável

o Indivisível, executada sem interrupção

o Garante que dois ou mais processos não

manipulem uma variável compartilhada

simultaneamente

o Usa variável lógica global chamada

(40)

(41)

o Soluções de software:

 Diversos algoritmos para implementar exclusão

mútua através de software

 Primeiras soluções abrangiam apenas dois

processos e apresentavam problemas, posteriormente sanados

o Algoritmo de Peterson, inicialmente aplicado

a dois processos, evoluído para N processos

 Problema da solução por software: o Espera ocupada! (busy wait)

(42)

 Exclusão Mútua

o Soluções de software:

 Primeiro algoritmo

o Usa variável global para sincronizar

processos

o Só funciona para dois processos

o Processos são sempre alternados

 Um processo fica bloqueado se o outro

não entrar na RC

o Se um processo travar, o outro fica

(43)

o Soluções de software:  Segundo algoritmo

o Funciona somente com dois processos o Usa variável de condição para cada

processo, informando se processo está ou não na RC

o Processos não necessitam ser alternados o Se um processo travar antes de alterar

variável, o outro fica bloqueado aguardando entrar na RC

(44)

 Exclusão Mútua

o Soluções de software:

 Terceiro algoritmo

o Funciona somente com dois processos

o Atribuição da variável de condição é feita

antes do loop de teste

o Processos não necessitam ser alternados

o Se um processo travar antes de alterar

variável, o outro fica bloqueado

o Garante exclusão mútua, mas ambos

(45)

o Soluções de software:  Quarto algoritmo

o Funciona somente com dois processos

o Como o terceiro, mas introduz tempo aleatório

para setar váriável de condição

o Processos não necessitam ser alternados o Se um processo travar antes de alterar

variável, o outro fica bloqueado

o Garante exclusão mútua, mas ambos

processos podem ficar bloqueados durante algum tempo

(46)

o Soluções de software:

 Algoritmo de Peterson

o Solução para problemas anteriores, foi

generalizado para N processos (Hofri, 1990)

o Além das variáveis de condição, usa variável

“Vez” para resolver conflitos

 Antes de acessar a RC, sinaliza este desejo

mas cede a vez para outro processo, depois fica em loop aguardando sua vez

 Para N processos, também há o algoritmo do

(47)

7 – Sincronização e Comunicação entre Processos  Sincronização Condicional

o Situação onde o acesso à RC exige sincronização

vinculada a uma condição de acesso

 Recurso disponível se condição satisfeita,

processos bloqueados enquanto isso

 Ex: comunicação via leitura/escrita em buffer

o Conhecido como problema produtor/consumidor ou

buffer limitado

o Mantém-se o problema da espera ocupada o Obs: algoritmo apresentado não considera

(48)

7 – Sincronização e Comunicação entre Processos  Semáforos

o Proposto por Dijkstra em 1965

 Mecanismo de sincronização para implementar

exclusão mútua e sincronização condicional

 Principal mecanismo usado em aplicações

concorrentes

o Composto por uma variável inteira não negativa

manipulada somente pelas instruções UP e DOWN

 UP incrementa de 1, DOWN decrementa de 1  UP e DOWN são instruções indivisíveis

o Executar DOWN num semáforo com valor 0 coloca o

(49)

 Semáforos

o Classificados como binários ou contadores

 Semáforos binários (MUTEX, de MUTual

EXclusion) só podem assumir 0 ou 1

 Semáforos contadores podem assumir

qualquer valor inteiro não negativo

o Exclusão mútua implementada por um MUTEX

associado ao recurso compartilhado

 Vantagem: ausência de espera ocupada

 DOWN e UP funcionam como protocolos de

entrada e saída na RC, respectivamente

(50)

 Utilização do Semáforo Binário na Exclusão

Mútua

Fila de espera de processos Processo acessa

a região crítica

Processo deseja entrar na região crítica D O W N (S₌ 0) DO WN (S> 0) UP (S) - processo sai da região crítica Libera processo da fila de espera

(51)

 Semáforos

o Sincronização condicional para operação de E/S

 Semáforo iniciado com 0

 Pedido de operação via DOWN

 Completada a operação, rotina faz UP

o Para o problema produtor/consumidor

 Usa 3 semáforos:

o Um MUTEX, para fazer exclusão mútua,

iniciado com 1

o Dois contadores, para sincronização

(52)

7 – Sincronização e Comunicação entre Processos  Semáforos

o Problema produtor/consumidor:

 Mutex usado para a RC que permite gravação e

leitura (logo, mutuamente exclusivas)

 Semáforos contadores representam posições

livres (“Vazio”) para serem gravadas, e posições ocupadas (“Cheio”) para serem lidas

o Vazio = 0, processo produtor em espera

o Cheio = 0, processo consumidor em espera

 “Vazio” iniciado com tamanho do buffer

(53)

 Semáforos

o Semáforos contadores são úteis para

problemas de sincronização condicional com

processos concorrentes disputando pool de

recursos

 Semáforo iniciado com número total de

recursos do pool

 Processo que deseja alocar recurso faz

DOWN

 Processo que libera recurso faz UP

 Semáforo em 0 indica que não há mais

recursos disponíveis no pool e coloca

processos que fizeram DOWN em espera

(54)

 Problema dos Filósofos

o Exemplo clássico de sincronização de

processos

o

Também chamado de “Dining Philosophers”

 Mesa com 5 pratos e 5 garfos

 Filósofos podem sentar, comer e pensar

 Quando filósofo para de pensar e deseja

comer, precisa usar dois garfos, à direita e à

esquerda

 Se todos os filósofos estiverem segurando

um garfo cada, nenhum deles come

(Deadlock!)

(55)

 Problema dos Filósofos

o Existem várias soluções, dentre elas:

 Permitir que apenas 4 filósofos sentem à

mesa simultaneamente

 Permitir que um filósofo um garfo apenas

quando o outro estiver disponível

 Permitir que um filósofo ímpar pegue

primeiro o seu garfo da esquerda e depois o

da direita, enquanto um filósofo par pegue

primeiro o garfo da direita e depois o da

esquerda

(56)

 Monitores

o Mecanismos de sincronização de alto nível

o Formado por procedimentos e variáveis

encapsuladas dentro de um módulo

o Diferenças entre monitores e semáforos:

 Semáforos são mecanismos não

estruturados implementados pelo

desenvolvedor

 Monitores são mecanismos estruturados

(57)

 Monitores

o Um monitor é definido especificando-se um

nome, declarando-se variáveis locais, um

conjunto de procedimentos e um código de

inicialização

o Um processo que deseje acessar determinada

RC através de um monitor fará chamada a um

dos procedimentos do monitor

 Caso outro processo já esteja executando

qualquer um dos procedimentos, ele

aguarda sua vez na fila

(58)

 Estrutura do Monitor

Declaração de variáveis globais Procedimentos Fila de entrada Inicialização de variáveis Proc. 1 Proc. 2 Proc. n M o n it o r

(59)

7 – Sincronização e Comunicação entre Processos  Monitores

o O uso de monitores facilita o desenvolvimento de

aplicações concorrentes

 Exclusão mútua é implementada de forma

automática

o Somente um processo pode estar

executando qualquer um dos procedimentos do monitor

 Variáveis globais do monitor são visíveis apenas

aos procedimentos de sua estrutura, inacessíveis externamente

 Inicialização das variáveis por código no

(60)

 Exclusão Mútua com Monitores

o Regiões críticas definidas como

procedimentos no monitor, exclusão mútua entre

eles por conta do compilador

o Comunicação com o monitor unicamente

através da chamada de seus procedimentos e

dos parâmetros passados

(61)

7 – Sincronização e Comunicação entre Processos  Sincronização Condicional com Monitores

o Se vale de variáveis especiais de condição para

associar a execução dos procedimentos do monitor

o Variáveis de condição são manipuladas por

intermédio das funções WAIT e SIGNAL

 Instrução WAIT faz com que o processo seja

colocado na respectiva fila de espera e aguarde que a condição seja satisfeita

 Processo sai da fila de espera quando outro

processo usar a instrução SIGNAL para sinalizar que a condição de espera foi satisfeita

 Se SIGNAL for executado e não houver processo

(62)

 Estrutura do Monitor com Variáveis de

Condição

Declaração de variáveis globais Procedimentos Fila de entrada Inicialização de variáveis Proc. 1 Proc. 2 Proc. n M on ito r Filas de espera Condição C1 Condição C2 Condição Cn

(63)

 Transmissão de Mensagem

Processo transmissor Processo receptor SEND RECEIVE Canal de comunicação

(64)

 Comunicação Direta e Indireta

Processo A Processo B

Mailbox ou Port

(65)

 Troca de Mensagens

o Forma síncrona:

 Processo transmissor fica esperando que o

processo receptor leia a mensagem

 Processo receptor fica aguardando que

processo transmissor mande a mensagem

o Forma assíncrona:

 Processos não ficam bloqueados à espera

de mensagem

(66)

 Deadlock

o Situação onde um processo aguarda

indefinidamente por um recurso que nunca estará

disponível ou aguarda por um evento que nunca

irá ocorrer

o Pode ser representado por ciclos num diagrama

de grafo

 Nós simbolizam processos e recursos

 Aresta que sai do processo X e chega ao

recurso Y indica que X solicita Y

 Aresta que sai do recurso Y e chega no

(67)

 Deadlock

– Espera Circular

Recurso 2 Recurso 1 Processo A Processo B Processo A solicita o Recurso 2 Recurso 1 alocado ao Processo A Recurso 2 alocado ao Processo B Processo B solicita o Recurso 1

(68)

7 – Sincronização e Comunicação entre Processos  Deadlock

o Condições simultâneas para ocorrer deadlock:  Exclusão mutua: Cada recurso só pode estar

alocado a um único processo por vez

 Espera por recurso: Um processo, apesar dos

recursos alocados, pode estar esperando por novo recurso

 Não-preempção: recurso não é liberado de um

processo devido à solicitação do mesmo por outro processo

 Espera circular: processo pode ter que esperar

por um recurso alocado a outro processo e vice-versa

(69)

 Deadlock

o Prevenção de deadlock:

 Evitar que as condições para deadlock

ocorram simultaneamente

 Evitar que pelo menos uma das condições

para deadlock ocorra

o Forçar o processo a ter apenas um

recurso por vez (evita a espera circular)

o Permitir preempção

o Processos que possuem recurso não

podem solicitar outro recurso

(70)

 Deadlock

o Detecção de deadlock:

 Se dá através da verificação de espera

circular

o Correção de deadlocks:

 Eliminação de todos os processos envolvidos

no deadlock

 Eliminação de apenas um dos processos

envolvidos no deadlock

 Liberação de apenas alguns recursos

(71)

- MACHADO, Francis Berenger e MAIA, Luiz Paulo. Arquitetura de Sistemas Operacionais,