1 / 44

Sistemas Operacionais

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;

enan
Download Presentation

Sistemas Operacionais

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Sistemas Operacionais Prof. Edivaldo Serafim Curso: Tecnólogo em Análise e Desenvolvimento de Sistemas - 2013 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 OperacionaisIFSP 2013

  4. Aplicações concorrentes • Em um ambiente multiprocessado geralmente ocorre a existência de processos concorrentes; • Processos concorrentes podem compartilhar recursos do sistemacomo: • 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 OperacionaisIFSP 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 slot7, 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

More Related