Sistemas
Operacionais
Prof.: Edilberto M. Silva
http://www.edilms.eti.br http://www.edilms.eti.br
Aula 11
Aula 11
Sincronização de Processos
Sincronização de Processos
Sumário
Introdução
Aplicações concorrentes
Especificação de concorrência em programas Problemas de compartilhamento de recursos Exclusão mútua
Sincronização condicional Semáforos
Monitores
Introdução
Os processos concorrentes executando no sistema operacional podem ser:
Independentes: não podem afetar ou serem afetados pelos
outros processos executando no sistema
Cooperativos – podem afetar ou serem afetados por outros
processos em execução no sistema. Compartilham diretamente um espaço de endereçamento lógico (ou seja, código e dados) ou ter permissão para compartilhar dados através de arquivos
Discutiremos os mecanismos para garantir uma execução ordenada de processos ou threads cooperativos para que a consistência dos dados seja mantida.
Aplicações Concorrentes
Sincronização e comunicação entre processos
P r o c e s s o g r a v a d o r P r o c e s s ol e i t o r d a d o S i n c r o n i z a ç ã o l e it u r a g r a v a ç ã o B u f f e r
Especificação de Concorrência em
Programas
Concorrência em programas
P r o c e s s o p r i n c i p a l P r o c e s s o 1 P r o c e s s o 2 P r o c e s s o n P A R B E G I N C o m a n d o _ 1 ; C o m a n d o _ 2 ; . . C o m a n d o _ n ; P A R E N DEspecificação de Concorrência em
Programas
X := SQRT (1024) + (35.4 * 0.23) - (302 / 7) PROGRAM Expressao;
VAR X, Temp1, Temp2, Temp3 : REAL; BEGIN PARBEGIN Temp1 := SQRT (1024); Temp2 := 35.4 * 0.23; Temp3 := 302 / 7; PAREND;
X := Temp1 + Temp2 - Temp3; WRITELN ('x = ', X);
Prob. de Compartilhamento de Recursos
Problema 1: compartilhamento de arquivo
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);
. . END.
Prob. de Compartilhamento de Recursos
Problema 2: compartilhamento de variável dememória
Processo A Processo B X := X + 1; X := X - 1; Processo A Processo B LOAD x,Ra LOAD x,Rb ADD 1,Ra SUB 1,Rb STORE Ra,x STORE Rb,x
Condição de corrida
Condição de corrida
: A situação onde diversos
processos acessam e manipulam recursos
compartilhados de forma concorrente. A situação
final vai depender do último processo que
terminar.
Para prevenir a condição de corrida, processos
concorrentes devem ser
sincronizados
.
Como primeiro método para controlar o acesso a
um recurso compartilhado, declaramos uma seção
de código como sendo
crítica
, em seguida
controlamos o acesso a essa região.
Prob. de Compartilhamento
de Recursos
– Condições de Corrida (Solução): encontrar alguma forma de proibir que mais de um processo acesse o dado compartilhado ao mesmo tempo, isto é,
estabelecer a exclusão mútua de execução.
– Exclusão Mútua:: impedir que dois ou mais processos acessem um mesmo recurso no mesmo instante;
– Região Crítica: parte do código do programa onde é feito o acesso ao recurso compartilhado, ou seja, é a parte do programa cujo processamento pode levar à ocorrência de condições de corrida.
Fundamentos
Acesso concorrente a dados compartilhados pode resultar em inconsistências.
Os processos cooperativos podem compartilhar
diretamente um espaço de endereçamento lógico ( ou seja códigos e dados).
Existem processos que são considerados produtores, pois disponibilizam recursos para outros processos.
Outros são considerados consumidores, pois se utilizam dos recursos dos produtores.
Quando existir mais de um processo consumidor pode haver uma condição de corrida (race condition) entre estes.
As Regiões Críticas
•
N processos todos competindo para utilização dos
mesmos dados compartilhados.
• Cada processo tem um segmento de código,
chamado
região crítica
, no qual os dados
compartilhados são acessados.
•
Problema
– garantir que quando um processo está
executando uma região crítica nenhum outro processo
tem permissão de executar a mesma região.
Solução para o Problema da Região
Crítica
1. Exclusão Mútua. Se um processo Pi está executando uma região crítica, então nenhum outro poderá faze-lo.
2. Progresso. Se nenhuma região crítica está sendo executada e existem processos em espera para entrar em suas regiões críticas, apenas esses processos podem ser selecionados para entrar em suas regiões críticas e essa seleção não pode ser adiada indefinidamente.
3. Espera Limitada. Existe um limite para o número de vezes que outros processos são selecionados para entrar em suas regiões críticas, depois que um processo fez uma requisição para entrar em sua região, e antes que essa requisição seja atendida.
Hardware de sincronização
As características do hardware podem tornar a
tarefa de programação mais fácil e melhorar a
eficiência do sistema.
O problema de seção crítica pode ser resolvido
em um ambiente monoprocessador bastando
desabilitar
a ocorrência de interrupções.
Em algumas máquinas existem
instruções
especiais
que evitam este problema.
Semáforos
As soluções para problemas de seção crítica não
são fáceis de generalizar em problemas complexos.
Para superar esta dificuldade podemos usar
uma ferramenta de sincronização denominada
semáforo.
Um semáforo S é uma
variável inteira
que, além
da inicialização, só é acessada através de duas
operações-padrão:
P
e
V
Estas operações receberam seus nomes dos
termos holandeses
P
de poberen, que significa
Semáforos
Ferramenta de sincronização que não requer espera ocupada (busy waiting).
Semáforo S – variável inteira
Somente pode ser acessada via duas operações indivisíveis (atômicas). P(s) while S = 0 S--; V(s) S++ USO Semaphore S P(s) criticalSection V(s)
Dois tipos de Semáforos
Semáforo Contador
– valor nele
armazenado pode ser qualquer número
inteiro.
Semáforo
Binário
–
valor
nele
armazenado pode variar entre 0 e 1; pode
ser implementado mais simplesmente.
Problemas Clássicos
• Problema dos Leitores e Escritores
• Problema dos Filósofos
Problemas Clássicos de Sincronização
• Problema dos Leitores e Escritores
• Problema dos Filósofos
Problema dos Leitores e Escritores
Suponha que uma banco de dados deva ser
compartilhado entre vários processos concorrentes.
Alguns executando simples leituras e outros
atualizando o banco.
Os primeiros são chamados de
leitores
e os
últimos de
escritores
.
Para evitar o acesso concorrente dos escritores
cada um destes deve ter um acesso exclusivo ao banco
Existem 2 preocupações básicas:
• nenhum leitor deve esperar a menos que um
escritor já tenha obtido permissão para usar o banco de
dados compartilhado.
• o escritor, assim que estiver pronto , faça sua
escrita o mais rápido possível.
Problema dos Filósofos
Considere cinco filósofos que passam suas vidas meditando e comendo. Estes compartilham uma mesa redonda comum cercada por 5 cadeiras, cada qual pertence a um filósofo.
No centro da mesa está uma tigela de arroz, e a mesa está posta com cinco pauzinhos (hashi).
Quando um filósofo medita, não interage com seus colegas. De vez em quando, um dos filósofos fica com fome e tenta pegar os dois hashis mais próximos de si (o da direita e da esquerda).
Um filósofo só pode pegar um hashi de cada vez.
Quando um filósofo está de posse dos dois hashis ele come e libera os mesmos.
Monitores
Construção de sincronização de alto nível que
permite o
compartilhamento seguro de um
tipo de dados
abstrato
entre processos concorrentes.
type monitor-name = monitor
declarações de variáveis
procedure entry P1 :(…);
begin … end;
procedure entry P2(…);
begin … end;
Monitores (Cont.)
Para permitir que um processo espere no monitor, uma variável condicional deve ser declarada, como
var x, y: condition
• Variáveis condicionais somente podem ser usadas com as operações wait e signal.
– A operação x.wait;
indica que o processo que chama esta operação está suspenso até outro processo chamar
x.signal;
– A operação x.signal restaura exatamente um processo
suspenso. Se nenhum processo está suspenso, a operação signal não possui efeito.