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; • Implementação de exclusão mútua; • Semáforos; • Monitores; • Troca de mensagens; • Deadlock. Prof. Edivaldo Serafim Sistemas OperacionaisIFSP 2013

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sistemas Operacionais