05 SO SincronizacaodeProcessosConcorrentes

Sistemas Operacionais
Sincronização de Processos
1
Sistemas Operacionais - Parte 5
1.Introdução
■ 1.Introdução
■ 2. Comunicação entre processos
■ 3. Problemas clássicos de comunicação entre processos
Sincronização de Processos - versão 1.0 2

2.Comunicação entre processos

■ É comum processos trabalharem juntos compartilhando recursos do sistema,
como arquivos, dispositivos e áreas de memória
■ O compartilhamento pode gerar situações indesejáveis, que podem até comprometer o
sistema
■ Mecanismos de Sincronização
■ São mecanismos que garantem a comunicação entre processos concorrentes e o acesso
a recursos compartilhados, de forma organizada
sincronização
Produtor Consumidor
dados dados
Buffer

■ Especificação de Concorrência em Programas (1)
■ Existe diversas estruturas que permitem a especificação de concorrência em
programas
Program A; Program B
: :
FORK B; :
: END.
JOIN B; repod
2017-01-26 22:20:16
: --------------------------------------------
Ponto de sincronização entre os processos.
END. Apartir do JoinB os 2 programas são
sincronizados e depois disso continua
■ O programa A começa a ser processado o processamento.
■ Ao encontrar o comando FORK, faz com que seja criado outro processo
(subprocesso) para execução do programa B, concorrentemente a A
■ O comando JOIN permite que o programa A sincronize-se com B, ou seja,
quando o programa A encontrar o comando JOIN, só continuará a ser
processado após o término de B


■ Especificação de Concorrência em Programas (2)
■ Outra implementação mais simples de expressar a concorrência é utilizando os
comandos PARBEGIN E PAREND
PARBEGIN
Comando_1
Comando_2
:
Comando_n
PAREND
■ O comando PARBEGIN especifica que a seqüência de comando seja executada
concorrentemente numa ordem imprevisível, através de um subprocesso para
cada comando.
■ O comando PAREND define um ponto de sincronização, onde os
processamento só continuará quando todos os subprocessos já tiverem
terminado sua execução


■ Especificação de Concorrência em Programas
■ O processamento só continuará quando todos os subprocessos já tiverem terminado suas
execuções
Processo
Principal
Processo Processo Processo

1 2 n
Processo
Principal


■ Especificação de Concorrência em Programas
■ O processamento só continuará quando todos os
subprocessos já tiverem terminado suas execuções
X:= SQRT(1024)+ (25.4 * 0.23) + (302/7)
PROGRAM Expressao
Var X, Temp1, Temp2, Temp3:REAL;
BEGIN
PARBEGIN
Temp1:=
SQRT(1024); repod
2017-01-26 22:23:10
Temp2:= 25.4 * 0.23; --------------------------------------------
Ponto de sincronização para o exemplo!
Temp3:= 302/7;
PAREND
X:=
Temp1+Temp2+Temp3;
writeln(´X =´,X);
END.


■ Problemas na Comunicação entre processos
■ Suponha um arquivo de contas bancárias (Arq_Contas), onde cada cliente tem
seu saldo controlado
■ O programa atualiza o saldo de um cliente, após um lançamento.
READ (Arq_Contas, Reg_Cliente); // O programa lê o registro do cliente no arquivo

READLN (Valor_Dep_Ret); // lê o valor a ser depositado ou retirado
Reg_Cliente.Saldo:= Reg_Cliente.Saldo+Valor_Dep_Ret; // faz a operação
WRITE(Arq_Contas,Reg_Cliente); // atualiza o saldo no arquivo de contas


■ Problemas na Comunicação entre processos
■ Imaginem dois caixas diferentes atualizando o saldo de um
mesmo cliente simultaneamente
Saldo Deposito/ Saldo

Caixa Comando
Arquivo Retirada Memória
1 READ 1.000 * 1.000
1 READLN 1.000 -200 1.000
1 := 1.000 -200 800
2 READ 1.000 * 1.000
2 READLN 1.000 +300 1.000
2 := 1.000 +300 1.300

repod
2017-01-26 22:26:52
1 WRITE 800 -200 800 --------------------------------------------
Valor não deveria ser 1300.
2 WRITE 1.300 +300 1.300 Problema de controle de acesso a região
crítica.


■ Solução para os Problemas de Comunicação repod
2017-01-26 22:27:42
--------------------------------------------
Cai em concurso!!
■ Exclusão mútua
■ Consiste em impedir ou mais processos acessem algum dado

que dois compartilhado
simultaneamente
■ Região crítica
■ Parte do programa onde é necessária a exclusão mútua, ou seja, onde o dado

compartilhado é acessado


■ Solução para os Problemas de Comunicação
Região Crítica - Protocolo de acesso
repod
■ 2017-01-26 22:29:24
--------------------------------------------
Garantir que apenas um processo pode
BEGIN acessar esta parte do programa em
um dado momento! Não permitir
... múltiplos acessos.
Entra_Região_Crítica; { protocolo de entrada }

Região_Critica; { subrotina }
Sai_Região_Crítica; { protocolo de saída }
...
END.
Quando um processo estiver acessando o dado compartilhado dentro de
sua região crítica, nenhum processo poderá entrar em sua região crítica
correspondente


■ Solução para os Problemas de Comunicação
■ Condições para boa solução do problema
■ 1.Dois ou mais processos não podem estar simultaneamente dentro de suas
regiões críticas correspondentes
■ 2.O número de processadores e o tempo de execução dos processos devem ser
irrelevantes.
■ 3.Nenhum processo que esteja rodando fora de sua região crítica pode bloquear
a execução de outro processo
■ 4.Nenhum processo pode ser obrigado a esperar indefinidamente para entrar na
região crítica
■ Problemas de Sincronização
■ Algumas soluções acarretam novos problemas, denominados problemas de
sincronização, que são tão graves quanto os gerados pela ausência de exclusão
mútua.


■ Velocidade de Execução dos Processos
■ A velocidade de execução dos processos pode interferir em uma boa solução para o
problema de exclusão mútua
■ A possibilidade do processo_B executar a região crítica, fica limitada pela velocidade do
Processo_A
Program Velocidade; Procedure Processo_B; // rápido

Begin
Var Vez: Char; Repeat
While (Vez = ‘A’) do;
Procedure Processo_A; // demorado Região_Critica_B;
Vez := ’A’;
Begin Until False;
Repeat End;
While (Vez = ‘B’) do;
Begin
Região_Critica_A; Vez := ‘A’;
Vez := ’B’; PARBEGIN
Processamento_Longo; Processo_A;
Until False; Processo_B;
End; PAREND;
End.

■ Starvation (Abandono)
■ É a situação onde um processo nunca consegue executar sua região crítica e,
conseqüentemente, não acessar o recurso compartilhado
■ Este problema ocorre quando dois ou mais processos esperam por um recurso
alocado. No momento em que o recurso é liberado o sistema deve determinar
qual processo, dentre os que estão esperando, ganhará o recurso
■ Caso essa escolha seja aleatória, existe a possibilidade de um processo nunca
ser escolhido e sofrer starvation.
■ Caso essa escolha for por prioridades, a baixa prioridade de um processo pode
levar o processo a sofrer starvation.
■ Uma solução para eliminar o problema de starvation seria a criação de filas de
pedidos (FIFO).


■ Sincronização Condicional
■ É quando um recurso compartilhado não está pronto para ser utilizado
pelos processos
■ O processo que deseja acessar o recurso deve ser colocado em estado
de espera, até que o recurso esteja disponível
■ Ocorre em situações onde existem processos
produtores(geram informações) e processos consumidores (usam estas
informações)



■ Sincronização Condicional
PROGRAM Produtor_Consumidor_1; PROCEDURE Consumidor
CONST TamBuf =(*Tamanho qualquer*); BEGIN

REPEAT
TYPE Tipo_Dado = (*tipo qualquer *);
WHILE (Cont=0) DO (*faz nada*);
VAR Buffer: array [1..TamBuf] OF Tipo_Dado;
Lê_Buffer(Dado);
Dado: Tipo_Dado;
Consome_Dado (Dado,Cont);
Cont :0..TamBuf;
UNTIL False;
END;
PROCEDURE Produtor
BEGIN BEGIN
REPEAT Cont:=0;
PARABEGIN
Produz_Dado(
Dado); Produtor;
WHILE (Cont=TamBuf) DO (*faz nada*); Consumidor;

PARAEND;
Grava_Buffer (Dado,Cont);
END.
UNTIL False;
END;

■ Soluções de Hardware
■ As soluções de hardware criam mecanismos que permitem a implementação
das soluções de software
■ Desabilitação de Interrupções
■ A solução mais simples para o problema de exclusão mútua é fazer com que o
processo, antes de entrar em sua região crítica desabilite todas as interrupções
externas, e as reabilite após deixar a região crítica.
■ Como a mudança de contexto só pode ser realizada através de interrupções, o
processo que as desabilitou terá acesso garantido
BEGIN
.
Desabilita_Interrupções;
Região_Crítica;
Habilita_Interrupções
.
End

■ Desabilitação de Interrupções
■ Este mecanismo é inconveniente pois o processo que desabilitou
as interrupções, pode não habilitá-la novamente.
■ O funcionamento do sistema será comprometido.
■ Entretanto, o SO pode utilizar este recurso para a manipulação
de estruturas de dados compartilhados, como lista de processos.

■ Dessa forma, o SO garante que não ocorrerão problemas de
inconsistência em seus dados


■ Instrução Test-and-Set
■ Muitos processadores possuem uma instrução especial, que permite ler uma
variável, armazenar seu conteúdo em outra área e atribuir um novo valor a essa
variável.
■ A sua execução é sem interrupção, ou seja, é uma instrução indivisível.
■ Exemplo
■ Quando a variável Y for falsa, qualquer processo pode alterar o seu
valor para verdadeiro, através da instrução test-and-set e, assim,
acessar ao recurso de forma exclusiva
■ Test_and_Set(X,Y) =O valor lógico da variável Y é copiado para X, e é
atribuído o valor Verdadeiro para Y.
■ Ao terminar o acesso, o processo deve simplesmente retornar o valor da
variável para falso, liberando o acesso ao recurso


PROCEDURE Processo_B;
■ Soluções de Hardware VAR Pode_B:BOOLEAN;
■ Instrução Test-and-Set BEGIN
PROGRAM Programa_Test_and_Set; REPEAT Bloqueio =True
VAR Bloqueio:BOOLEAN; Pode_B:=True;
PROCEDURE Processo_A; WHILE (Pode_B) DO
Test_and_Set (Pode_B,Bloqueio);
VAR Pode_A:BOOLEAN;
Região_Crítica_B;
BEGIN
Bloqueio:=False;
REPEAT
UNTIL True;
Pode_A:=True; Bloqueio =True END;
WHILE (Pode_A) DO
BEGIN
Test_and_Set (Pode_A,Bloqueio);
Bloqueio:=False;
Região_Crítica_A;
PARABEGIN
Bloqueio:=False; Processo_A;
UNTIL True; Processo_B;
END; PARAEND;
END.


■ Instrução Test-and-Set
Processo_A Pode_A Pode_B Bloqueio

Processo_B
---------------------------------------------------------------------------------------------
Repeat (1) Repeat (2) * * False
Pode_A:=True (3) Pode_B:=True (4) True True False
WHILE (Pode_A) (5) WHILE(Pode_B) (6) True True False
Test_and_Set (6) True False True
Test_and_Set (7) Região_Crítica_B (8) True
True False
While (Pode_A) (10) Bloqueio:=False (9) True False False
Test_and_Set (12) Pode_B:=True (11) False True True
Região_Crítica_A (13) While (Pode_B) (14) False True True
()- passos da execução


■ Solução de Software
■ Semáforos
■ Um semáforo é uma variável inteira, não negativa, que pode ser manipulado por
duas instruções DOWN/P (protocolo para entrar na região crítica) e UP/V
(protocolo para sair na região crítica)
■ São System Calls, com o sistema desabilitando todas as interrupções
■ O semáforo é associado a um recurso compartilhado e permite, indicando se o
recurso está sendo utilizado ou não
■ Se semáforo > 0, nenhum processo está utilizado o recurso
■ Senão, recurso está ocupado


■ Solução de Software Se o processo deseja entrar na
■ Semáforos sua região crítica
Executa um DOWN
Fila de
espera de Libera processo Se S>0
processos da fila de S= S –1
DOWN (S=0) espera Região Critica UP
(S=S+1)
Processo Senão (S=0)
deseja Processo
entrar na sai da
região Estado de Espera
região
crítica crítica
S=S-1 S=S+1
DOWN (S>0)
Processo
UP Inicialmente
acessa
a região
S=1
crítica
Mecanismo de utilização de semáforo


■ Semáforo S
TYPE Semaforo = RECORD
Valor:Integer
Fila_espera: (Lista de processos pendentes*)
END;
PROCEDURE DOWN (var S: Semaforo);

BEGIN
IF (S=0) THEN
Coloca_Processo_na_Fila_de_Espera
ELSE
S := S - 1;
end;
PROCEDURE UP (var S: SEMAFORO);

begin
S := S + 1;
IF (tem_Processo_Esperando) Then
Tira_da_Fila_de_Espera;
end;


■ Problema de exclusão mútua entre dois processos utilizando Semáforos
■ Inicialmente o semáforo está com valor 1
■ Indicando que nenhum processo está executando a região crítica
■ O Processo_A executa a instrução DOWN
■ Faz com que o semáforo seja decrementado de 1, passando ter o valor 0
■ O Processo_A ganha acesso a sua região crítica
■ O Processo_B também executa a instrução DOWN
■ Mas, como seu valor é igual a 0, ficará aguardando até que o Processo_A
execute a instrução UP, ou seja, volte o valor do semáforo para 1
■ Semáforos aplicados ao problema da exclusão mútua são chamados mutexes
(mutual exclusion semaphores) ou binários, por apenas assumirem, os
valores 0 ou 1


■ Problema de exclusão mútua entre dois processos utilizando Semáforos
PROGRAM Semáforo_1;
VAR s:Semáforo:=1; (inicialização) PARBEGIN
PROCEDURE Processo_A; Processo_A;
REPEAT
DOWN(s); Processo_B;
Região_Crítica_A; PAREND.
UP(s); Processo_A Processo_B S Pendente
UNTIL False; REPEAT REPEAT 1 *
END; DOWN(s) REPEAT 0 *
PROCEDURE Processo_B; Região_Crítica_A DOWN(s) 0 Processo_B
REPEAT UP(s) DOWN(s) 1 Processo_B
DOWN(s); REPEAT Região_Crítica_B 0 *
Região_Crítica_B;
UP(s);
UNTIL False;
END;


Solução de Software
■ Monitores
■ É um conjunto de procedimentos, variáveis e estruturas de dados, todas
agrupadas juntas em um módulo especial
■ Sua característica mais importante é a implementação automática da
exclusão mútua
■ Somente um processo pode estar executando um dos
procedimentos do monitor em um determinado instante
■ Toda vez que algum processo chama um dos procedimentos, o
monitor verifica se já existe outro processo executando algum
procedimento do monitor
■ Caso exista, o processo ficará aguardando a sua vez até que tenha
permissão para executar

■ Monitores
■ As variáveis globais ao monitor são visíveis apenas a ele e a seu procedimentos
■ O bloco de comandos do monitor é responsável por inicializar essas
variáveis, sendo executado apenas uma vez, na ativação do programa
Variáveis globais
Fila de espera
procedimentos
código de inicialização
Estrutura do monitor
Solução de Software
■ Monitores
■ Toda implementação da exclusão mútua nos monitores é realizada
pelo compilador, e não mais pelo programador, como no caso de uso
de semáforos
■ Para isto, basta colocar todas as regiões críticas em forma de
procedimentos no monitor e o compilador se encarregará de
garantir a exclusão mútua desses procedimentos
■ Assim, o desenvolvimento de programas concorrentes fica mais
fácil, e as chances de erros são menores


repod
2017-01-26 23:00:58
--------------------------------------------
Prova até aqui!!!
■ Monitores
• O monitor não pode ser executado como
PROGRAM Exemplo; uma subrotina comum.
MONITOR Região_Crítica;
VAR X: INTEGER; • A comunicação do processo com
PROCEDURE Soma;
o
monitor é feita unicamente através de
BEGIN
X:=X+1;
END;
chamadas a seus procedimentos e dos
PROCEDURE Diminui; parâmetros passados para eles
BEGIN
X:=X-1; • A inicialização da variável compartilhada
END;
BEGIN X com o valor zero só acontecerá uma
x:=0;
PARABEGIN
vez
Região_Critica.Soma; • No momento da primeira ativação do
Região_Crítica.Diminui;
PARAEND; monitor Região_Crítica.
END.
• No exemplo o valor final de X será 0


■ Troca de mensagens
■ É um mecanismo de comunicação e sincronização entre processos, implementado pelo SO,
através de duas rotinas do sistema
■ SEND (Receptor, Mensagem)
■ RECEIVE(Transmissor, Mensagem)
■ Mesmo não sendo suas execuções mutuamente exclusivas, permitem tanto a
comunicação entre processos como a sincronização entre eles
■ A comunicação ocorre porque um processo, ao receber uma mensagem,
obtém dados enviados de outro processo
■ A sincronização é obtida porque uma mensagem somente pode ser lida
após ter sido enviada, restringindo dessa forma, a ordem na qual os dois
eventos devem ocorrer


■ Permite a troca de mensagem entre máquinas diferentes
■ As mensagens podem ser perdidas na rede
■ O receptor envia de volta uma msg de acknowledgement
■ O receptor deve saber distinguir uma msg nova/velha
■ Cada msg deve ser um identificador (seqüencial,time-stamp)
■ Autenticação
■ Será que o servidor é o real ou um impostor ? (criptografia)
■ O desempenho atende os requisitos ?


PROGRAM Produdor_Consumidro;
PROCEDURE Produdor;
PROCEDURE Consumidor;
VAR Msg: Tipo_Msg;
VAR Msg: Tipo_Msg;
BEGIN
REPEAT BEGIN
Produz_Mensagem(Msg) REPEAT
SEND(Msg) RECEIVE(Msg);
UNTIL False; Consome_Mensagem(Msg)
END;
UNTIL False;
END;
BEGIN
PARABEGIN
Produtor;
Consumidor;
PARAEND;
END;
END.


■ Deadlock
■ Um processo é dito em deadlock, quando está esperando por um evento que
nunca ocorrerá
■ Exemplo de Deadlock
■ Processo_A e Processo_B estão executando
■ Processo_A aloca Recurso_1 e Processo_B aloca Recurso_2
■ Processo_A requisita Recurso_2 e Processo_B requisita Recurso_1
■ Cada processo fica esperando que o outro libere o recurso alocado

3. Problemas Clássicos de Comunicação entre Processos
■ O Problema dos Filósofos Glutões

■ Considere cinco filósofos que passam suas vidas meditando e comendo
■ Compartilham uma mesa redonda comum cercada por cinco cadeiras, cada qual
pertencente a um filósofo
■ No centro da mesa está uma tigela de arroz, e a mesa está posta com cinco
garfos
■ 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 dois garfos
mais próximos de si
■ Os garfos que estão entre ele e seus colegas da esquerda e direita
■ Um filósofo só pode pegar um garfo de cada vez
■ Não pode pegar um que já esteja na mão de um colega
■ Quando o filósofo com fome está de posse dos dois garfos, ao mesmo tempo,
ele poderá comer sem soltá-los
■ Quando terminar de comer, o filósofo solta os garfos e volta meditar


■ Problema clássico de sincronização
■ É uma representação simples da necessidade de alocar vários recursos entre
vários processos, sem incorrer em deadlocks ou starvation


■ Solução 1 (pode gerar deadlock) – errada !!!!!!
■ O procedimento pegar_garfo espera até que o garfo especificado esteja livre, e então aloca-o ao filósofo
■ Se os cincos filósofos resolverem comer ao mesmo tempo e se conseguirem o garfo a esquerda, quando
forem pegar o garfo a direita acarretará uma situação de deadlock
■ Solução 2 (pode gerar starvation) – errada !!!!!!
■ Antes de pegar o garfo da esquerda, verificamos se o garfo da direita está livre. Se não estiver, ele deve
liberar o garfo da esquerda, esperar um tempo e repetir todo o processo
■ Se todos os filósofos começarem a mesmo tempo, e notarem que o garfo a direita está ocupado,
esperarão e retornarão o processo, e assim sucessivamente (starvation)
■ Solução 3 (livre de deadlock e starvation)
■ Utiliza-se um semáforo DOWN/UP, para proteger os cincos comandos que seguem o
comando pensar
■ Antes de iniciar a aquisição dos garfos o filósofo precisa executar um DOWN
■ Após a devolução de um garfo, o filósofo deve executar um UP
■ Do ponto de vista teórico é adequada, mas tem um bug, somente um filósofo pode comer
por vez

■ O Problema dos Leitores e Escritores

■ Modela o acesso a base de dados
■ É aceitável que haja mais de um processo lendo a base de dados ao mesmo
tempo
■ Se um processo estiver escrevendo na base, nenhum outro processo, nem
mesmo os leitores, poderão ter acesso a ela enquanto o escritor não terminar
■ Solução
■ Quando o primeiro leitor ter acesso à base ele executa um DOWN no semáforo
do banco.
■ Subsequente, os leitores só incrementam o contador
■ Cada leitor que deixar a base decrementa o contador
■ O último que sair executa um UP
■ Permitindo que o escritor bloqueado, se houver algum, tenha acesso a base
■ Em algumas soluções os Escritores tem maior prioridade do que o Leitores,
assim eles não ficam em starvation

■ O Problema do Barbeiro Dorminhoco
■ Existe um barbeiro, uma cadeira de barbeiro e diversos lugares onde os clientes
que estiverem esperando, se houver, poderão sentar
■ Se não houver nenhum cliente, o barbeiro senta em sua cadeira e cai no sono
■ Se um freguês chegar e o barbeiro estiver cortando o cabelo do outro, este deve
sentar, se houver cadeira vazia, ou ir embora, se não houver nenhuma cadeira
disponível


■ Solução
■ Três semáforos
■ Clientes - conta os clientes que estão esperando

■ Excluindo aquele que está na cadeira
■ Barbeiros – o número de barbeiros livres esperando por

clientes (0 ou 1)
■ Mutex – garante a exclusão mútua
■ Variável
■ Esperando – conta os clientes que estão
aguardando o serviço


■ Solução
■ Quando chega o primeiro freguês, este executa cliente
■ Executa um DOWN sobre mutex
■ Garantindo que se outro cliente chegar imediatamente após ele não estará
habilitado a fazer nada, até que o primeiro execute um UP sobre mutex
■ O cliente verifica se tem há alguma cadeira livre
■ Comparando o número de clientes que esperam com o número de cadeiras
disponíveis
■ Se não houver, ele libera mutex e vai embora
■ Havendo, o cliente incrementa a variável Esperando e dá um UP no
semáforo Clientes, ficando a espera do barbeiro. Neste momento, o cliente
e o barbeiro estão acordados. Então, quando o cliente liberar o mutex, o
barbeiro apodera-se dele, e inicia o corte.
■ Quando o corte termina, o cliente completa a execução do procedimento e
deixa a barbearia

05 SO SincronizacaodeProcessosConcorrentes

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

05 SO SincronizacaodeProcessosConcorrentes

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas Operacionais

■ 2. Comunicação entre processos

■ 3. Problemas clássicos de comunicação entre processos

Sincronização de Processos - versão 1.0 2

2.Comunicação entre processos

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 4

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 5

2.Comunicação entre processos

Processo Processo Processo

Sincronização de Processos - versão 1.0 6

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 7

2.Comunicação entre processos

READ (Arq_Contas, Reg_Cliente); // O programa lê o registro do cliente no arquivo

Sincronização de Processos - versão 1.0 8

2.Comunicação entre processos

Saldo Deposito/ Saldo

1 READLN 1.000 -200 1.000

1 := 1.000 -200 800

2 READ 1.000 * 1.000

2 READLN 1.000 +300 1.000

2 := 1.000 +300 1.300

Sincronização de Processos - versão 1.0 9

2.Comunicação entre processos

■ Consiste em impedir ou mais processos acessem algum dado

■ Parte do programa onde é necessária a exclusão mútua, ou seja, onde o dado

Sincronização de Processos - versão 1.0 10

2.Comunicação entre processos

Entra_Região_Crítica; { protocolo de entrada }

Sincronização de Processos - versão 1.0 11

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 12

2.Comunicação entre processos

Program Velocidade; Procedure Processo_B; // rápido

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 14

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 15

Sincronização de Processos - versão 1.0 16

2.Comunicação entre processos

CONST TamBuf =(*Tamanho qualquer*); BEGIN

WHILE (Cont=TamBuf) DO (*faz nada*); Consumidor;

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 18

2.Comunicação entre processos

as interrupções, pode não habilitá-la novamente.

■ O funcionamento do sistema será comprometido.

■ Entretanto, o SO pode utilizar este recurso para a manipulação

de estruturas de dados compartilhados, como lista de processos.

inconsistência em seus dados

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 20

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 21

2.Comunicação entre processos

Processo_A Pode_A Pode_B Bloqueio

Sincronização de Processos - versão 1.0 22

2.Comunicação entre processos

Sincronização de Processos - versão 1.0 23

2.Comunicação entre processos

Mecanismo de utilização de semáforo

2.Comunicação entre processos

CONST TamBuf =(Tamanho qualquer); BEGIN

WHILE (Cont=TamBuf) DO (faz nada); Consumidor;