Sistemas Operacionais Prof. Edivaldo Serafim Curso: Tecnólogo em Análise e Desenvolvimento de...

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


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


• 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


• 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


• 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


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


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


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


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


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


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


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


• 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


• 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


• 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


• 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


• 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

Sistemas Operacionais Prof. Edivaldo Serafim Curso: Tecnólogo em Análise e Desenvolvimento de...

Documents

Transcript of Sistemas Operacionais Prof. Edivaldo Serafim Curso: Tecnólogo em Análise e Desenvolvimento de...