Sistemas Operacionais

Apresentação em tema: "Sistemas Operacionais"— Transcrição da apresentação:

1 Sistemas Operacionais
Prof. Edivaldo Serafim Curso: Tecnólogo em Análise e Desenvolvimento de Sistemas IFSP – Campus Capivari

2 Sincronização e comunicação entre processos
03/09/2013

3 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. Prof. Edivaldo Serafim Sistemas Operacionais IFSP 2013

4 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; Prof. Edivaldo Serafim Sistemas Operacionais IFSP 2013

5 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

6 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

7 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

8 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

9 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

10 Condições de corrida Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

11 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

12 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

13 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

14 Condições de corrida Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

15 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

16 Exclusão mútua Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

17 Exclusão mútua 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

18 Outras situações indesejadas
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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

19 Outras situações indesejadas
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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

20 Outras situações indesejadas
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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

21 Implementação de Exclusão mútua
É possível implementar Exclusão Mútua: Por Hardware; Por Software. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

22 Exclusão mútua via Hardware
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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

23 Exclusão mútua via Hardware
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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

24 Exclusão mútua via Hardware
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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

25 Exclusão mútua via Hardware
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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

26 Exclusão mútua via Hardware
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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

27 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

28 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

29 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

30 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

31 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

32 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

33 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

34 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

35 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

36 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

37 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. Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

38 Semáforos Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

39 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

40 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). Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

41 Troca de mensagens Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

42 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; Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

43 Deadlock Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013

44 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) Prof. Edivaldo Serafim - Arquitetura de Computadores - IFSP 2013