Post on 17-Apr-2015
Sistemas Operacionais
Prof. Edivaldo Serafim
Curso: Tecnólogo em Análise e Desenvolvimento de Sistemas - 2013
IFSP – Campus Capivari
Sincronização e comunicação entre processos
03/09/2013
Tópicos abordados
• Aplicações concorrentes;• Condições de corrida;• Exclusão mútua;• Implementação de exclusão mútua;• Semáforos;• Monitores;• Troca de mensagens;• Deadlock.
Pro
f. E
div
ald
o S
era
fimS
iste
ma
s O
pe
raci
on
ais
IFS
P 2
01
3
3
Aplicações concorrentes• Em um ambiente multiprocessado geralmente
ocorre a existência de processos concorrentes;• Processos concorrentes podem compartilhar
recursos do sistema como:• Arquivos, dispositivos e áreas de memória.
• Esse compartilhamento pode causar situações em que o sistema pode entrar em colapso;
• Evitar esses problemas é tarefa do SO;• Mecanismos de sincronização:
• Sincronizam a execução de processos;• Garantem a execução correta dos processos
concorrentes;
4
Pro
f. E
div
ald
o S
era
fimS
iste
ma
s O
pe
raci
on
ais
IFS
P 2
01
3
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Aplicações concorrentes
• Um exemplo de aplicações concorrentes:• Dois processos que compartilham um buffer
para troca de informações através de I/O;
5
Processog ravad o r
Processoleito r
d ado
Sin cron ização
leitura
g ra vaçã o
Bu ffer
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Aplicações concorrentes• O processo gravador somente poderá gravar no buffer caso
haja espaço para isso;• O processo leitor somente poderá ler dados caso exista algum
para ser lido;• Ambos processos devem aguardar até que o buffer esteja
pronto para poder acessá-lo.
6
Processog ravad o r
Processoleito r
d ado
Sin cron ização
leitura
g ra vaçã o
Bu ffer
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de Corrida
• São situações onde dois ou mais processos acessam dados compartilhados e o resultado final depende da ordem em que os processos são executados;• Ordem de execução é definida pelo
mecanismo de escalonamento do SO;• Situações de corrida tornam a depuração
difícil.
7
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de Corrida
• Condições de corrida ocorrem quando os processos concorrentes tentam acessar suas regiões críticas;
• Devem ser evitadas através da introdução de mecanismos de exclusão mútua:• A exclusão mútua garante que somente um
processo estará usando os dados compartilhados num dado momento;
• Proíbe que mais de um processo entre em sua Região Crítica.
8
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de corrida
• Exemplo 1:
• Um diretório de spooler com n entradas, cada uma capaz de armazenar um nome de arquivo;
• O servidor de impressão verifica se existem arquivos a serem impressos;
• Caso haja, ele remove os nomes do diretório e envia o arquivo para a impressora;
• Neste contexto, existem variáveis compartilhadas: • Out – aponta para o próximo arquivo a ser
impresso;• In – que aponta para a próxima entrada livre no
diretório.
9
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de corrida
10
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de corrida
• 1 - O Processo A e o Processo B decidem colocar um arquivo no spool de impressão quase ao mesmo tempo;
• 2 - O Processo A lê in, armazena o seu valor (7) na variável local next-free-slot mas é interrompido;
• 3 - O Processo B é escalonado, lê in e coloca o nome do seu arquivo no slot 7, atualizando in para 8.
• 4 - O Processo A retorna a execução e escreve o nome do seu arquivo no slot 7 (valor de next-free-slot), apagando o arquivo colocado pelo Processo B;
• 5 - A variável next-free-slot passa a valer 8;11
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de corrida
• O que ocorrerá?• O servidor não notará nada de errado, pois
para ele o diretório está consistente!• Mas o Processo B nunca terá sua saída
para a impressora.
12
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de corrida
• Exemplo 2:• Considere um banco com dois caixas;• Uma conta corrente de um cliente;• Duas operações simultâneas nessa conta e nesses dois
caixas;• Operações:
• READ – o programa lê o registro do cliente no arquivo;• READLN – lê o valor a ser depositado ou retirado;• := – executa a operação mas não grava no arquivo.• WRITE – atualiza o saldo no arquivo de contas. 13
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Condições de corrida
14
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua
• O que fazer para evitar as condições de corrida?
• Impedir que processos concorrentes acessem suas regiões críticas ao mesmo tempo;
• Isso é possível através da Exclusão Mútua, que pode ser implementada:• Por software;• Por Hardware. 15
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua
16
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua
17
• Mecanismos que implementam a Exclusão Mútua utilizam protocolos de acesso a região crítica;
• Antes de executar instruções da região crítica, o processo precisa executar o protocolo de entrada para essa região;
• Ao terminar a execução dessas instruções, o processo deverá executar o protocolo de saída da região crítica;
• Isso garante a Exclusão Mútua da região crítica de um processo.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Outras situações indesejadas
18
• Além da Exclusão Mútua, outras situações podem ser indesejadas:• Starvation (espera indefinida);• Processos fora da região crítica que
impedem que outros processos entrem na região crítica.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Outras situações indesejadas
19
• Starvation (espera indefinida):• Um processo nunca consegue acessar sua região
crítica;• Dependendo da forma com que o SO seleciona
os processos que acessarão a região compartilhada, pode ocorrer starvation:• Escolha aleatória ou escolha por prioridades.
• Possível solução:• Uso de fila FIFO.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Outras situações indesejadas
20
• Processos fora da região crítica;• Um processo impede que outros processos
entrem em suas regiões críticas;• Mesmo que o processo não utilize essa área,
outros processos não poderão acessá-la;• Se apenas um processo deseja acessar a região
crítica, ele deve conseguir sem maiores custos.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Implementação de Exclusão mútua
21
• É possível implementar Exclusão Mútua:
• Por Hardware;
• Por Software.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Hardware
22
• Desabilitando interrupções:• Consiste em desabilitar as interrupções pelo
processo que necessita acessar a região crítica;• O processo desabilita as interrupções;• Executa o que for necessário;• Reabilita as interrupções após deixar de
utilizar a região crítica;
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Hardware
23
• Desabilitando interrupções:• Desvantagens:
• Compromete a multiprogramação;• O processo pode não habilitar mais as
interrupções novamente;• Sistemas multicore é comprometido com troca de
mensagens entre os cores;• Vantagem:
• Boa solução quando se deseja execução do núcleo do SO sem interrupções;
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Hardware
24
• 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.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Hardware
25
• Test and Set:• Uma variável Global é utilizada para determinar o
acesso ao recurso;• Se um programa precisa acessar a região crítica,
deverá checar se a variável Global é False;• Se for, deverá alterar seu valor para True, acessar a
região crítica e, ao concluir a operação, voltar novamente ao valor de False;
• Se o valor da variável Global for True, o processo deverá esperar até que seja False para acessar a região crítica.
• Todo esse processo ocorre com bloqueio do barramento de memória.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Hardware
26
• Test and Set:• Vantagens:
• Simplicidade na implementação;• Uso em arquiteturas multicore, já que a
execução da rotina Test and Set impede que outros cores acessem a memória.
• Desvantagem:• Possibilidade de starvation, já que a seleção
do processo para o uso do recurso é randômico.
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• 1° Algoritmo:
• Consiste em uma variável de bloqueio comum para apenas dois processos concorrentes;• Quando um processo entra na região
crítica, ele altera a variável para Bloqueada;
• Quando um processo sai da região crítica, ele altera a variável para Liberada;
• Antes de entrar na região crítica, um processo deve checar esta variável.
27
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• 1° Algoritmo:
• Limitações:• O mecanismo só funciona para dois processos
apenas ;• O controle é feito de maneira alternada:
• Se um processo não necessita mais utilizar a região crítica, mesmo assim ele receberá o controle para acessá-la;
• Outro processo mais necessitado fica mais tempo esperando para usar a região crítica.
• A variável pode não ser mais alterada, ficando bloqueada para sempre.
28
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• 2° Algoritmo:
• Consiste em cada processo ter uma variável individual de controle;
• Quando um processo deseja entrar na região crítica, ele testa a variável do outro processo;
• Não existe alternância como no anterior;
29
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• 2° Algoritmo:
• Limitações:• Se houver um problema com o processo antes
de ele alterar a variável para liberado, outros não poderão acessar a região crítica;
• A região ficará bloqueada para sempre;
30
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• 3° Algoritmo:
• Melhora o algoritmo anterior;• Cada processo altera sua variável indicando
entrar na região crítica sem conhecer o estado de outro processo;
• Limitações:• Dois processos podem colocar suas variáveis
como bloqueadas;• Nenhum processo poderá mais acessar a região
crítica; 31
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• 4° Algoritmo:
• Melhora o algoritmo anterior, onde a variável pode ser revertida para desbloqueada;
• Não gera bloqueio simultâneo de processos;• Limitações:
• Ainda sim dois processos podem colocar suas variáveis como bloqueadas por um certo período;
• Nenhum processo poderá mais acessar a região crítica neste tempo; 32
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• Solução de Dekker:
• Consiste em combinar o 1° algoritmo com o 4° algoritmo;
• É uma solução boa porém muito complexa;
• Superada pela solução de Peterson;
33
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• Solução de Peterson:
• Solução semelhante ao 3° algoritmo;• Acrescenta uma nova variável que indica o
desejo de um processo acessar a região crítica;
34
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Exclusão mútua via Software• O grande problema dos algoritmos
analisados:• Todos precisam ficar testando as variáveis de
bloqueio antes de entrar na região crítica;• Isso consome processamento e tempo de CPU;
• Para resolver esse problema:• Criação de mecanismos que colocam o
processo como bloqueado quando não conseguir acessar a região crítica:• Semáforos;• Monitores.
35
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Semáforos• Um semáforo é uma variável inteira, não
negativa, que pode ser manipulado por duas instruções:• DOWN ou P – protocolo para entrar na
região crítica;• UP ou V – protocolo para sair na região
crítica.• São System Calls, e o sistema desabilita
todas as interrupções;36
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Semáforos• O semáforo é associado a um recurso
compartilhado e permite indicar se o recurso está sendo utilizado ou não;
• Se semáforo > 0, nenhum processo está utilizado o recurso senão, recurso está ocupado.
37
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Semáforos
38
Fila de esperad e processos
Processo acessaa reg iã o cr ítica
Processo d eseja en tra rn a reg ião cr ítica
DOW
N (S=
0)
DOW
N (S
>0)
U P (S) - p rocesso sa id a reg ião cr ítica
Libe ra processod a fi la de espe ra
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Monitores
• Ao contrário das soluções anteriores que são implementadas no programa, monitores são implementados por compiladores;
• As regiões críticas são definidas como procedimentos;
• O compilador se encarrega de garantir a exclusão mútua entre os procedimentos;
• A comunicação entre processo e monitor se da através de chamadas de procedimento; 39
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Troca de mensagens
• Utilizado pelo SO para comunicação e sincronização de processos sem uso de variáveis compartilhadas;
• Deve existir um canal de comunicação entre os processos:• Um buffer;• Um link de rede;
• Processos cooperativos trocam mensagem através de duas rotinas:• Send (transmissor);• Receive (receptor).
40
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Troca de mensagens
41
Processotran sm isso r
Processorecep to r
SEN D REC EIV E
C an a l d e co m u nicação
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Deadlock
• Ocorre quando um processo aguarda por um recurso que nunca estará disponível;
• É cada vez mais frequente em sistemas atuais onde o paralelismo é intenso;
42
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
Deadlock
43
Recu rso 2 Recu rso 1
Processo A
Processo B
Processo Aso licita oRecu rso 2
Recu rso 1a loca do aoProcesso A
Recu rso 2a loca do aoProcesso B
Processo Bso licita oRecu rso 1
Pro
f. E
div
ald
o S
era
fim -
Arq
uite
tu
ra d
e C
om
pu
tad
ore
s -
IFS
P 2
01
3
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)
44