Você está na página 1de 39

Sistemas Operacionais

Sistemas
Multiprogramveis
Os sistemas multiprogramveis surgiram na dcada de 60, passou a
ser possvel estruturar aplicaes de maneira que partes diferentes
do cdigo do programa pudessem executar concorrentemente.
Este tipo de aplicao, denominada aplicao concorrente, tem como
base a execuo cooperativa de mltiplos processos ou threads, que
trabalham em uma mesma tarefa na busca de um resultado comum.

Sistemas
Multiprogramveis
Em sistemas multiprogramveis com um nico processador, os processos
alternam sua execuo segundo critrios de escalonamento estabelecidos
pelo Sistema Operacional, mesmo no havendo paralelismo na execuo
das instrues, ocorre significativo ganho de desempenho.

Em sistemas multiprocessados, as vantagens so ainda maiores


graas a possibilidade de paralelismo na execuo das instrues.

Sistemas
Multiprogramveis
natural que processos de uma aplicao concorrente compartilhem
recursos do sistema, como arquivos, registros, dispositivos de E/S e
reas de memria.

O compartilhamento de recursos entre os processos pode


ocasionar situaes indesejveis, capazes at de comprometer
a execuo das aplicaes.

Comunicao e Sincronizao
Muitas vezes, em uma aplicao concorrente, necessrio que
processos comuniquem-se entre si, e essa comunicao pode
ser implementada de diversos mecanismos, como variveis
compartilhadas na memria principal ou troca de mensagens.
Nesta situao, necessrio que os processos tenham sua
execuo
sincronizada pelo sistema operacional
.

Comunicao e Sincronizao
Por exemplo, podemos ter dois processos concorrentes
compartilhando um buffer para trocar informaes atravs de
operaes de gravao e leitura, onde ambos os processos
necessitam aguardar que o buffer esteja pronto.

Comunicao e
Sincronizao
Para cooperar, processos precisam se comunicar e se sincronizar.

Mas cada um dos processos podem ser executados com


velocidades diferentes.

Problemas de Compartilhamento de
Recurso
Alguns problemas que podem ocorrer devido falha na sincronizao
entre processos concorrentes.
Primeiro exemplo o problema do programa Conta_Corrente, que
atualiza o saldo bancrio de um cliente aps um lanamento de dbito
ou crdito noarquivo de contas-correntes Arq_Contas.

Problemas de
Compartilhamento

de Recurs
o

PROGRAM Conta_Corrente;
.
.
READ (Arq_Contas, Reg_Cliente);
READLN
(Valor_Dep_Ret);
Reg_Cliente.Saldo :=
Reg_Cliente.Saldo
WRITE (Arq_Contas, Reg_Cliente);
.
.
END.

+
Valor_Dep_Ret;

Problemas de
Simultaneidade
Considerando processos concorrentes pertencentes a dois funcionrios do banco
(caixas), que atualizam o saldo de um mesmo cliente simultaneamente, a
situao de compartilhamento do recurso pode ser analisada.

Supondo que o primeiro caixa ir ler o saldo do cliente e adicionar o


valor de um lanamento.
Neste mesmo instante outro caixa ir efetuar uma outra operao de
atualizao no saldo do mesmo cliente, realizando outro lanamento.

Independentemente de qual dos atualize primeiro o saldo no arquivo, o


dado gravado estar inconsistente!

Problemas de
Simultaneidade

Condies de
Corrida
Analisando o exemplo apresentado, possvel concluir que em
qualquer situao, onde dois ou mais processos compartilham um mesmo
recurso, devem existir mecanismos de controle para evitar esses tipos de
problemas, conhecidos como condies de corrida (race conditions ).

Ocorre
quando?
Quando processos esto lendo ou escrevendo dados compartilhados e o
resultado final depende de qual processo executa e quando (em que ordem)
este executa.

Excluso
Mtua
A soluo mais simples para evitar os problemas de
compartilhamento apresentados impedir que dois ou mais
processos acessem um mesmo recurso simultaneamente.
Para isso, enquanto um processo estiver acessando determinado
recurso, todos os demais processos que queiram acess-lo devero
esperar pelo trmino da utilizao do recurso.
Essa idia de exclusividade de acesso chamada de excluso mtua
(mutual exclusion).

Regies
Crticas
A excluso mtua deve afetar apenas os processos concorrentes somente
quando um deles estiver fazendo acesso ao recurso compartilhado.

A parte do cdigo do programa onde feito o acesso ao recurso


compartilhado denominada regio crtica (critical region).
Se for possvel evitar que dois processos entre em suas regies
crticas ao mesmo tempo, ou seja, se for garantida a execuo
mutuamente exclusiva das regies crticas, os problemas
decorrentes do compartilhamento sero evitados.

Regies
Crticas
Os mecanismos que implementam a excluso mtua utilizam
protocolos de acesso regio crtica.
Toda vez que um processo desejar executar uma instruo de sua
regio crtica, dever obrigatoriamente executar antes um
protocolo de entrada nesta regio.
Da mesma forma, ao sair da regio crtica um protocolo de sada
dever ser executado.
Estes protocolos garantem a excluso mtua da regio crtica do
programa.

Regies Crticas
BEGIN
.
.
Entra_Na_Regiao_Crtica;

/* protocolo de entrada
*/

Regiao_Crtica
;

/* operaes executadas
*/

Sai_Da_Regiao_Crtica;
.
.
END.

/* protocolo de sada
*/

Espera
Indefinida
Estas solues propostas para o acesso sincronizado devem garantir a excluso
mtua e tambm evitar que duas outras situaes indesejadas ocorram.

A primeira situao indesejada conhecida como espera indefinida


(starvation).
Starvation a situao em que um processo nunca consegue executar sua
regio crtica e, consequentemente, acessar o recurso compartilhado.
Quando um determinado recurso liberado, o Sistema Operacional ir
selecionar qual ser o prximo processo que far uso do mesmo.

Espera
Indefinida
Este critrio de escolha poder ocasionar uma espera indefinida, quando for
utilizado critrio baseado em escolha aleatria ou em funo da prioridade do
processo (processos de baixa prioridade sero prejudicados).

A soluo implementar uma fila, atravs do esquema FIFO,


garantindo que todos os processos que necessitem do recurso faam
seu uso em algum momento.
Outra situao indesejvel quando um processo fora de sua regio crtica
impede que outros processos entrem em suas prprias regies crticas.

Isto ocorre devido ao fato do recurso estar livre, porm ainda alocado
a um processo, impedindo que os demais utilizem o recurso.

Mecanismos de
Sincronizao
Sincronizao
Condicional
Entre os mecanismos de sincronizao, a sincronizao condicional uma
situao onde o acesso ao recurso compartilhado exige a sincronizao de
processos vinculada a uma condio de acesso.

Um recurso pode no se encontrar pronto para uso devido a uma


condio especfica.
Nesse caso, o processo que deseja acess-lo dever permanecer
bloqueado at que o recurso fique disponvel.

Mecanismos de
Sincronizao
Um exemplo clssico desse tipo de sincronizao a comunicao entre dois

processos atravs de operaes de gravao e leitura em um buffer,


onde os processos que geram informaes (processos produtores)
utilizadas por outros processos (processos consumidores).

Mecanismos de
Sincronizao
Nessa comunicao, enquanto um processo grava dados em um buffer, o
outro l os dados, concorrentemente.
Os processos envolvidos devem estar sincronizados a uma varivel de
condio, de forma que um processo no tente gravar dados em um buffer
cheio ou realizar uma leitura em um buffer vazio.
Este problema sincronizao conhecido como problema do
produtor / consumidor ou do buffer limitado.

Mecanismos de
Sincronizao
Semforos
O conceito de semforos foi proposto por E. W. Dijkstra em 1965, sendo
apresentado como um mecanismo de sincronizao que permitia implementar,
de forma simples, a excluso mtua e sincronizao condicional entre processos.
De fato, o uso de semforos tornou-se um dos principais mecanismos utilizados em
projetos de sistemas operacionais e em aplicaes concorrentes.

Um semforo uma varivel inteira, no-negativa, que s pode ser


manipulada por duas instrues: DOWN e UP,
Estas instrues so indivisveis, isto , no pode ser
interrompida.

Mecanismos de
Sincronizao
Semforos so classificados em dois tipos:
- Semforos binrios: chamados de mutexes (mutual
exclusion semaphores), s podem assumir valores 0 e 1.

Permitem a implementao da excluso mtua e so utilizados nos casos


onde a sincronizao condicional exigida.

- Semforos contadores: podem assumir qualquer valor inteiro


positivo, alm do 0.

Semforos contadores so teis quando aplicados em problemas de


sincronizao condicional onde existem processo concorrentes alocando
recursos do mesmo tipo.

Mecanismos de
Sincronizao

Monitores

Mecanismos de
Sincronizao

So mecanismos de sincronizao de alto nvel que tornam mais simples


o

desenvolvimento de aplicaes concorrentes.

O conceito de monitores foi proposto , como um mecanismo de sincronizao


estruturado, ao contrrio dos semforos, que so considerados no-estruturados.

Estes mecanismos so alto nvel e estruturados em funo de serem


implementados pelo compilador, possibilitando que o desenvolvimento de
programas concorrentes fique mais fcil e com chances menores de erros.
O monitor formado por procedimentos e variveis encapsulados dentro
de um mdulo, implementando de forma automtica a excluso mtua
entre os procedimentos declarados.

Mecanismos de Sincronizao
Toda vez que algum processo faz uma chamada a um procedimento, o
monitor verifica se j existe outro processo executando algum
procedimento do monitor.
Caso exista, o processo ficar aguardando a sua vez em uma fila de
entrada.
A implementao da excluso mtua via monitores no implementada
diretamente pelo programador, assim como no caso do uso dos
semforos, o prprio compilador encarrega-se de garantir a excluso
mtua entre os procedimentos previamente definidos.

Mecanismos de
Sincronizao

Mecanismos de Sincronizao
Troca de Mensagens
Tambm um mecanismo de comunicao e sincronizao entre
processos.
O sistema operacional possui um subsistema de mensagens que suporta esse
mecanismo sem que haja a necessidade do uso de variveis compartilhadas.

Para que ocorra a comunicao entre os processos, deve existir um


canal de comunicao, podendo esse meio ser um buffer ou um link
de uma rede de computadores.

Mecanismos de Sincronizao
Os processos cooperativos podem fazer uso de um buffer para trocar mensagens atravs de duas rotinas: SEND (transmissor, mensagem) e RECEIVE (receptor,
mensagem).

A rotina SEND permite o envio de uma mensagem para um processo


receptor, enquanto a rotina RECEIVE possibilita o recebimento de mensagem
enviada por um processo transmissor.

Mecanismos de Sincronizao
O mecanismo de troca de mensagens exige que os processos envolvidos na comunicao tenham suas execues sincronizadas

A troca de mensagens entre os processos pode ser implementada de duas maneiras distintas: comunicao direta e comunicao indireta.

Comunicao direta entre dois processos exige que, ao enviar ou receber


uma mensagem, o processo enderece explicitamente o nome do processo
receptor ou transmissor.
Uma caracterstica deste tipo de comunicao s permitir a troca de
mensagem entre dois processos.

Mecanismos de Sincronizao
A comunicao indireta entre processos utiliza uma rea compartilhada, onde as mensagens podem ser colocadas pelo processo transmissor e
retiradas pelo receptor.
Esse tipo de buffer conhecido como mailbox ou port, e suas caractersticas, como identificao e capacidade de armazenamento de mensagens,
so definidas no momento de criao.

Na comunicao indireta, vrios processos podem estar associados a mailbox, e


os parmetros dos procedimentos SEND e RECEIVE passam a ser nomes de
mailboxes e no mais nomes de processos.

Deadlock
Deadlock ( espera circular ) a situao em que um processo aguarda por um recurso que nunca estar disponvel ou um evento que nunca
ocorrer.
Essa situao consequncia, na maioria das vezes, do compartilhamento de recursos, como dispositivos, arquivos e registros, entre processos
recorrentes onde a excluso mtua exigida.

Deadlock
Para que ocorra a situao de deadlock, 4 condies so necessrias simultaneamente:

1 Excluso mtua: cada recurso s pode estar alocado a um nico


processo em um determinado instante;
2 Espera por recurso: um processo, alm dos recursos j alocados, pode
estar esperando por outros recursos;
3 No-preempo: um recurso no pode ser liberado de um
processo s porque outros processos desejam o mesmo recurso;
4 Espera circular: um processo pode ter de esperar por um recurso
alocado a outro processo e vice-versa.
Problemas de deadlock existem em qualquer sistema multiprogramvel e as solues
implementadas devem considerar o tipo do sistema e o impacto em seu desempenho.

Deadlock - Preveno
Como vimos, para que um deadlock ocorra, todas as quatro condies listadas
devem ocorrer simultaneamente.
Isto quer dizer que se garantirmos que somente uma delas no possa ocorrer,
estaremos prevenindo a ocorrncia de deadlocks em um determinado sistema.

Deadlock - Preveno
Examinemos as quatro condies separadamente:
1 - Negando a Condio de Excluso
Mtua
Conforme j foi visto, a condio de excluso mtua no deve ser negada,
pois dois processos acessando um recurso simultaneamente poderiam levar
o sistema a uma situao de caos.
Imagine o exemplo de dois processos acessandouma mesma impressora ao
mesmo tempo!
Uma soluo utilizar um sistema de spool, onde um nico processo de spool
acessa a impressora diretamente, e no acessa nenhum outro recurso. Uma vez
que os processos no imprimem diretamente, e o processo de spool acessa
somente o recurso impressora, deadlocks no podem ocorrer.
O problema que nem todos os recursos podem ser alocados via
spooling.

Deadlock - Preveno
2

- Negando a Condio Esperar por Recurso (Hold and


Wait)

A primeira estratgia requer que todos os recursos que um processo precise


devem ser requisitados de uma s vez.
O sistema deve liberar os recursos segundo uma poltica tudo ou nada. Se todos
os recursos que o processo requisitou esto disponveis, ento o sistema pode aloclos todos de uma vez ao processo, que poder prosseguir.
Se, por outro lado, nem todos os recursos requisitados esto disponveis, ento o
processo deve esperar at que todos eles estejam disponveis. Enquanto o processo
espera, entretanto, ele no deve deter nenhum recurso.
Esta soluo parece ser boa, mas pode levar a um srio desperdcio de recursos.
Outro problema a possibilidade de um processo requisitando todos os
seus recursos de uma s vez ficar indefinidamente esperando.

Deadlock - Preveno
3

- Negando a Condio No-Preempo (No Preemption)

Negar a condio de no-preempo uma estratgia ainda pior do que a


anterior.
Para vrios recursos, como uma impressora, no interessante que um processo
os perca durante seu uso.

Deadlock - Preveno
4

- Negando a Condio Espera Circular (Circular


Wait)

A condio circular wait pode ser eliminada de vrias formas.


Uma maneira simplesmente estabelecer uma regra que diga que um processo
s pode alocar um nico recurso em um dado momento. Se ele precisa de um
segundo recurso, deve liberar o primeiro.
Para um processo que necessita copiar um arquivo muito grande para uma
impressora (o processo de spooling, por exemplo), isto inaceitvel.
Uma estratgia melhor seria que todos os recursos devem ser numerados em
ordem crescente.
Assim, processos podem requisitar recursos sempre que quiserem, mas
todas as requisies devem ser em ordem crescente de numerao.

Deadlock - Preveno
4

- Negando a Condio Espera Circular (Circular Wait)

A condio circular wait pode ser eliminada de vrias formas.


Uma maneira simplesmente estabelecer uma regra que diga que um processo
s pode alocar um nico recurso em um dado momento. Se ele precisa de um
segundo recurso, deve liberar oprimeiro.
Para um processo que necessita copiar um arquivo muito grande para uma
impressora (o processo de spooling, por exemplo), isto inaceitvel.
Uma estratgia melhor seria que todos os recursos devem ser numerados em
ordem crescente.
Assim, processos podem requisitar recursos sempre que quiserem, mas
todas as requisies devem ser em ordem crescente de numerao.

Você também pode gostar