SISTEMAS OPERACIONAIS

Sincronizao e Comunicao entre Processos Profa. Luciana Maximiano UNIBAN

UNIBAN

Notas de Aula Sistemas Operacionais

4.0 SINCRONIZAO E COMUNICAO ENTRE PROCESSOS Na dcada de 1960, com o surgimento dos sistemas multiprogramveis, passou a ser possvel estruturar aplicaes de maneira que partes diferentes do cdigo do programa pudessem executar concorrentemente. Este tipo de aplicao, denominada aplicao concorrente, tem como base a execuo cooperativa de mltiplos processos ou threads, que trabalham em uma mesma tarefa na busca de um resultado comum. Em sistemas multiprogramvel com um nico processador, os processos alternam sua execuo segundo critrios de escalonamento estabelecidos pelo Sistema Operacional, mesmo no havendo paralelismo na execuo das instrues, ocorre significativo ganho de desempenho; e em sistemas multiprocessados, as vantagens so ainda maiores. natural que processos de uma aplicao concorrente compartilhem recursos do sistema, como arquivos, registros, dispositivos de E/S e reas de memria. O compartilhamento de recursos entre os processos pode ocasionar situaes indesejveis, capazes at de comprometer a execuo das aplicaes. Para evitar esse tipo de problema, os processos concorrentes devem ter suas execues sincronizadas, a partir de mecanismos oferecidos pelo sistema operacional, com o objetivo de garantir o processamento correto dos programas. 4.1 Aplicaes Concorrentes Muitas vezes, em uma aplicao concorrente, necessrio que processos comuniquem-se entre si, e essa comunicao pode ser implementada de diversos mecanismos, como variveis compartilhadas na memria principal ou troca de mensagens. Nesta situao, necessrio que os processos tenham sua execuo sincronizada pelo sistema operacional.

Figura 1 Sincronizao e comunicao entre processos Profa. Priscila Facciolli Tavares 2

UNIBAN

Notas de Aula Sistemas Operacionais

Na figura acima podemos ver dois processos concorrentes compartilhando um buffer para trocar informaes atravs de operaes de gravao e leitura, onde ambos os processos necessitam aguardar que o buffer esteja pronto para realizar as respectivas operaes, quer seja de leitura, quer seja de gravao. Os mecanismos que garantem a comunicao entre os processos concorrentes e o acesso aos recursos so chamados de mecanismos de sincronizao. 4.2 Problemas de Compartilhamento de Recurso Alguns problemas que podem ocorrer devido falha na sincronizao entre processos concorrentes. Primeiro exemplo o problema do programa Conta_Corrente, que atualiza o saldo bancrio de um cliente aps um lanamento de dbito ou crdito no arquivo de contas-correntes Arq_Contas. Analisemos o trecho do programa abaixo: PROGRAM Conta_Corrente; . . READ (Arq_Contas, Reg_Cliente); READLN (Valor_Dep_Ret); Reg_Cliente.Saldo := Reg_Cliente.Saldo + Valor_Dep_Ret; WRITE (Arq_Contas, Reg_Cliente); . . END. Considerando processos concorrentes pertencentes a dois funcionrios do banco (caixas), que atualizam o saldo de um mesmo cliente simultaneamente, a situao de compartilhamento do recurso pode ser analisada. Supondo que o primeiro caixa ir ler o saldo do cliente e adicionar o valor de um lanamento. Neste mesmo instante outro caixa ir efetuar uma outra operao de atualizao no saldo do mesmo cliente, realizando outro lanamento. Independentemente de qual dos atualize primeiro o saldo no arquivo, o dado gravado estar inconsistente:

Profa. Priscila Facciolli Tavares

UNIBAN Caixa 1 1 1 2 2 2 1 2 Comando READ READLN := READ READLN := WRITE WRITE

Notas de Aula Sistemas Operacionais Saldo Arquivo 1.000 1.000 1.000 1.000 1.000 1.000 800 1.300 Valor Debito/Credito * -200 -200 * +300 +300 -200 +300 Saldo Memria 1.000 1.000 800 1.000 1.000 1.300 800 1.300

Outro exemplo de problema de concorrncia, mais simples para ser analisado, a situao onde dois processos (A e B) executam um comando de atribuio. O Processo A soma 1 a varivel X e o Processo B diminui 1 da mesma varivel que est sendo compartilhada. Inicialmente, a varivel X possui o valor 2. Processo A X: = X + 1; Processo B X: = X 1; Seria razovel pensar que ao final da execuo dos dois processos, o resultado da varivel X continuasse 2, porm isto nem sempre ser verdade. Os comandos de atribuio, em uma linguagem de alto nvel, podem ser decompostos em comandos mais elementares. Processo A A B B A B Comando LOAD X, Ra ADD 1, Ra LOAD X, Rb SUB 1, Rb STORE Ra, X STORE Rb, X X 2 2 2 2 3 1 Ra 2 3 * * 3 * Rb * * 2 1 * 1

Considere que o Processo A carregue o valor de X no registrador Ra, some 1 e, no momento em que vai armazenar o valor em X, seja interrompido. Nesse instante o Processo B inicia a sua execuo, carrega o valor de X em Rb e subtrai 1. Dessa vez, o Processo B interrompido e o Processo A volta a ser processado, atribuindo o valor 3 varivel X e concluindo sua execuo. Finalmente, o Processo B retorna a execuo, atribui o valor 1 a X, e sobrepe o valor anteriormente gravado pelo Processo A. O

Profa. Priscila Facciolli Tavares

UNIBAN

Notas de Aula Sistemas Operacionais

valor final da varivel X inconsistente em funo da forma concorrente com que os dois processos executaram. Analisando os dois exemplos apresentados, possvel concluir que em qualquer situao, onde dois ou mais processos compartilham um mesmo recurso, devem existir mecanismos de controle para evitar esses tipos de problemas, conhecidos como race conditions (condies de corrida). 4.3 Excluso Mtua A soluo mais simples para evitar os problemas de compartilhamento apresentados impedir que dois ou mais processos acessem um mesmo recurso simultaneamente. Para isso, enquanto um processo estiver acessando determinado recurso, todos os demais processos que queiram acess-lo devero esperar pelo trmino da utilizao do recurso. Essa idia de exclusividade de acesso chamada de excluso mtua (mutual exclusion). A excluso mtua deve afetar apenas os processos concorrentes somente quando um deles estiver fazendo acesso ao recurso compartilhado. A parte do cdigo do programa onde feito o acesso ao recurso compartilhado denominada regio crtica (critical region). Se for possvel evitar que dois processos entre em suas regies crticas ao mesmo tempo, ou seja, se for garantida a execuo mutuamente exclusiva das regies crticas, os problemas decorrentes do compartilhamento sero evitados. Os mecanismos que implementam a excluso mtua utilizam protocolos de acesso regio crtica. Toda vez que um processo desejar executar uma instruo de sua regio crtica, dever obrigatoriamente executar antes um protocolo de entrada nesta regio. Da mesma forma, ao sair da regio crtica um protocolo de sada dever ser executado. Estes protocolos garantem a excluso mtua da regio crtica do programa.

Profa. Priscila Facciolli Tavares

UNIBAN

Notas de Aula Sistemas Operacionais

BEGIN . . Entra_Regiao_Critica; Regiao_Critica; Sai_Regiao_Critica; . . END. Estas solues propostas para o acesso sincronizado devem garantir a excluso mtua e tambm evitar que duas outras situaes indesejadas ocorram. A primeira situao indesejada conhecida como starvation ou espera indefinida. Starvation a situao em que um processo nunca consegue executar sua regio crtica e, consequentemente, acessar o recurso compartilhado. Quando um determinado recurso liberado, o Sistema Operacional ir selecionar qual ser o prximo processo que far uso do mesmo. Este critrio de escolha poder ocasionar starvation, quando for utilizado critrio baseado em escolha aleatria ou em funo da prioridade do processo (processos de baixa prioridade sero prejudicados). A soluo implementar uma fila, atravs do esquema FIFO, garantindo que todos os processos que necessitem do recurso faam seu uso em algum momento. Outra situao indesejvel quando um processo fora de sua regio crtica impede que outros processos entrem em suas prprias regies crticas. Isto ocorre devido ao fato do recurso estar livre, porm ainda alocado a um processo, impedindo que os demais utilizem o recurso. 4.4 Solues de Excluso Mtua Solues de hardware para implementao de excluso mtua: - Desabilitao de Interrupes: faz com que o processo desabilite todas as interrupes antes de entrar em sua regio crtica, e as reabilite aps deixar a regio crtica. Embora seja de fcil implementao, pode comprometer seriamente a multiprogramao. - Instrues de test-and-set: Instruo de mquina especial que permite ler uma varivel, armazenar seu contedo em outra rea e atribuir um novo valor a mesma 6

Profa. Priscila Facciolli Tavares

UNIBAN

Notas de Aula Sistemas Operacionais

varivel, tudo isto em uma nica instruo de mquina, indivisvel. Com isto torna-se impossvel que dois processos manipulem uma varivel compartilhada ao mesmo tempo. Tambm existem vrias propostas de solues via software, na qual algoritmos foram desenvolvidos na tentativa de implementar a excluso mtua. No analisaremos estes algoritmos em nosso curso. 4.5 Sincronizao Condicional Sincronizao condicional uma situao onde o acesso ao recurso compartilhado exige a sincronizao de processos vinculada a uma condio de acesso. Um recurso pode no se encontrar pronto para uso devido a uma condio especfica. Nesse caso, o processo que deseja acess-lo dever permanecer bloqueado at que o recurso fique disponvel. Um exemplo clssico desse tipo de sincronizao a comunicao entre dois processos atravs de operaes de gravao e leitura em um buffer, como foi visto na figura 1, onde os processos que geram informaes (processos produtores) utilizadas por outros processos (processos consumidores). Nessa comunicao, enquanto um processo grava dados em um buffer, o outro l os dados, concorrentemente. Os processos envolvidos devem estar sincronizados a uma varivel de condio, de forma que um processo no tente gravar dados em um buffer cheio ou realizar uma leitura em um buffer vazio. Este problema sincronizao conhecido como problema do produtor/consumidor ou do buffer limitado. 4.6 Semforos O conceito de semforos foi proposto por E. W. Dijkstra em 1965, sendo apresentado como um mecanismo de sincronizao que permitia implementar, de forma simples, a excluso mtua e sincronizao condicional entre processos. De fato, o uso de semforos tornou-se um dos principais mecanismos utilizados em projetos de sistemas operacionais e em aplicaes concorrentes. Um semforo uma varivel inteira, no-negativa, que s pode ser manipulada por duas instrues: DOWN e UP, tambm chamadas originalmente como instrues P (proberen, teste em holands) e V (verhogen, incremento em holands). Estas instrues so indivisveis, isto , no pode ser interrompida. 7

Profa. Priscila Facciolli Tavares

UNIBAN

Notas de Aula Sistemas Operacionais

Semforos so classificados em dois tipos: - Semforos binrios: chamados de mutexes (mutual exclusion semaphores), s podem assumir valores 0 e 1. - Semforos contadores: podem assumir qualquer valor inteiro positivo, alm do 0.

Figura 2 - Utilizao do semforo binrio na excluso mtua 4.7 Monitores So mecanismos de sincronizao de alto nvel que tornam mais simples o desenvolvimento de aplicaes concorrentes. O conceito de monitores foi proposto por Brinch Hansen em 1972, e desenvolvido por C.A.R. Hoare em 1974, como um mecanismo de sincronizao estruturado, ao contrrio dos semforos, que so considerados no-estruturados. Estes mecanismos so alto nvel e estruturados em funo de serem implementados pelo compilador, possibilitando que o desenvolvimento de programas concorrentes fique mais fcil e com chances menores de erros. O monitor formado por procedimentos e variveis encapsulados dentro de um mdulo, implementando de forma automtica a excluso mtua entre os procedimentos declarados. Toda vez que algum processo faz uma chamada a um procedimento, o monitor verifica se j existe outro processo executando algum procedimento do monitor. Caso exista, o processo ficar aguardando a sua vez em uma fila de entrada. A implementao da excluso mtua via monitores no implementada diretamente pelo programador, assim como no caso do uso dos semforos; o prprio Profa. Priscila Facciolli Tavares 8

UNIBAN

Notas de Aula Sistemas Operacionais

compilador encarrega-se de garantir a excluso mtua entre os procedimentos previamente definidos.

Figura 3 - Estrutura do monitor 4.8 Troca de Mensagens Tambm um mecanismo de comunicao e sincronizao entre processos. O sistema operacional possui um subsistema de mensagens que suporta esse mecanismo sem que haja a necessidade do uso de variveis compartilhadas. Para que ocorra a comunicao entre os processos, deve existir um canal de comunicao, podendo esse meio ser um buffer ou um link de uma rede de computadores. Os processos cooperativos podem fazer uso de um buffer para trocar mensagens atravs de duas rotinas: SEND (receptor, mensagem) e RECEIVE (transmissor, mensagem). A rotina SEND permite o envio de uma mensagem para um processo receptor, enquanto a rotina RECEIVE possibilita o recebimento de mensagem enviada por um processo transmissor.

Figura 4 Transmisso de Mensagem Profa. Priscila Facciolli Tavares 9

UNIBAN

Notas de Aula Sistemas Operacionais

O mecanismo de troca de mensagens exige que os processos envolvidos na comunicao tenham suas execues sincronizadas. A troca de mensagens entre os processos pode ser implementada de duas maneiras distintas: comunicao direta e comunicao indireta. Comunicao direta entre dois processos exige que, ao enviar ou receber uma mensagem, o processo enderece explicitamente o nome do processo receptor ou transmissor. Uma caracterstica deste tipo de comunicao s permitir a troca de mensagem entre dois processos.

Figura 5 - Comunicao Direta A comunicao indireta entre processos utiliza uma rea compartilhada, onde as mensagens podem ser colocadas pelo processo transmissor e retiradas pelo receptor. Esse tipo de buffer conhecido como mailbox ou port, e suas caractersticas, como identificao e capacidade de armazenamento de mensagens, so definidas no momento de criao. Na comunicao indireta, vrios processos podem estar associados a mailbox, e os parmetros dos procedimentos SEND e RECEIVE passam a ser nomes de mailboxes e no mais nomes de processos.

Figura 6 - Comunicao Indireta Independente do mecanismo de comunicao adotado, processos que esto trocando mensagens devem ter suas execues sincronizadas em funo do fluxo de

Profa. Priscila Facciolli Tavares

10

UNIBAN

Notas de Aula Sistemas Operacionais

mensagens. Um processo no pode tratar uma mensagem at que esta tenha sido enviada por outro processo, ou ento receber uma mesma mensagem mais de uma vez. 4.9 Deadlock Deadlock a situao em que um processo aguarda por um recurso que nunca estar disponvel ou um evento que no ocorrer. Essa situao conseqncia, na maioria das vezes, do compartilhamento de recursos, como dispositivos, arquivos e registros, entre processos recorrentes onde a excluso mtua exigida.

Figura 7 Espera Circular Para que ocorra a situao de deadlock, 4 condies so necessrias simultaneamente (Coffman, Elphick e Shoshani, 1971) : 1 Excluso mtua: cada recurso s pode estar alocado a um nico processo em um determinado instante; 2 Espera por recurso: um processo, alm dos recursos j alocados, pode estar esperando por outros recursos; 3 No-preempo: um recurso no pode ser liberado de um processo s porque outros processos desejam o mesmo recurso; 4 Espera circular: um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa. Problemas de deadlock existem em qualquer sistema multiprogramvel; no entanto, as solues implementadas devem considerar o tipo do sistema e o impacto em seu desempenho. Profa. Priscila Facciolli Tavares 11

UNIBAN 4.10 - Preveno de Deadlocks

Notas de Aula Sistemas Operacionais

Como vimos, para que um deadlock ocorra, todas as quatro condies listas devem ocorrer simultaneamente. Isto quer dizer que se garantirmos que somente uma delas no possa ocorrer, estaremos prevenindo a ocorrncia de deadlocks em um determinado sistema. Examinemos as quatro condies separadamente: 4.10.1 - Negando a Condio Mutual Exclusion Conforme j foi visto, a condio de excluso mtua (mutual exclusion) no deve ser negada, pois dois processos acessando um recurso simultaneamente poderiam levar o sistema a uma situao de caos. Imagine o exemplo de dois processos acessando uma mesma impressora ao mesmo tempo! Uma soluo utilizar um sistema de spool, onde um nico processo de spool acessa a impressora diretamente, e no acessa nenhum outro recurso. Uma vez que os processos no imprimem diretamente, e o processo de spool acessa somente o recurso impressora, deadlocks no podem ocorrer. O problema que nem todos os recursos podem ser alocados via spooling. 4.10.2 - Negando a Condio Esperar por Recurso (Hold and Wait) A primeira estratgia de Havender requer que todos os recursos que um processo precise devem ser requisitados de uma s vez. O sistema deve liberar os recursos segundo uma poltica tudo ou nada. Se todos os recursos que o processo requisitou esto disponveis, ento o sistema pode aloc-los todos de uma vez ao processo, que poder prosseguir. Se, por outro lado, nem todos os recursos requisitados esto disponveis, ento o processo deve esperar at que todos eles estejam disponveis. Enquanto o processo espera, entretanto, ele no deve deter nenhum recurso. Assim a condio hold and wait negada e deadlocks simplesmente no podem ocorrer. Esta soluo parece ser boa, mas pode levar a um srio desperdcio de recursos. Por exemplo, suponha um programa que l dados de uma unidade de fita, processa-os por uma hora, e em seguida imprime alguns grficos em um plotter. Uma vez que ambas a unidade de fita e o plotter estejam disponveis, o programa pode prosseguir. O desperdcio ocorre porque o plotter ficar alocado ao processo durante uma hora antes de ser efetivamente utilizado. Outro problema a possibilidade de um processo requisitando todos os seus recursos de uma s vez ficar indefinidamente esperando, se outros processos estiverem

Profa. Priscila Facciolli Tavares

12

UNIBAN

Notas de Aula Sistemas Operacionais

usando os recursos que ele deseja com bastante freqncia. De qualquer forma, esta abordagem evita deadlocks. 4.10.3 - Negando a Condio No-Preempo (No Preemption) Negar a condio de no-preempo uma estratgia ainda pior do que a anterior. Para vrios recursos, como uma impressora, no interessante que um processo os perca durante seu uso. 4.10.4 - Negando a Condio Espera Circular (Circular Wait) A condio circular wait pode ser eliminada de vrias formas. Uma maneira simplesmente estabelecer uma regra que diga que um processo s pode alocar um nico recurso em um dado momento. Se ele precisa de um segundo recurso, deve liberar o primeiro. Para um processo que necessita copiar um arquivo muito grande para uma impressora (o processo de spooling, por exemplo), isto inaceitvel. Uma estratgia melhor seria utilizar a terceira estratgia de Havender, que determina que todos os recursos devem ser numerados em ordem crescente. Assim, processos podem requisitar recursos sempre que quiserem, mas todas as requisies devem ser em ordem crescente de numerao. 4.11 - Deteco e Recuperao: Alguns sistemas esto desenhados para permitir que a alocao de recursos prossiga sem grandes intervenes, em vez disso, o sistema verifica periodicamente se existe a possibilidade de surgir um Deadlock, quer periodicamente, quer sempre que certos eventos ocorram. Um aspecto negativo acerca desta abordagem reside em determinar quando o algoritmo de deteco deve ser executado. Isto deve-se ao fato de que se executado muitas vezes, simplesmente torna o sistema demasiado lento, mas se no executado vezes suficientes os processos em Deadlock e os recursos do sistema ficam entrelaados de uma maneira no produtiva at que o sistema seja recuperado. Este problema surge devido presena de um Deadlock resultar da no ocorrncia de eventos em vez de executar algum evento excepcional que possa disparar a execuo do algoritmo de deteco. Na estratgia do algoritmo de deteco surgem duas fases, a deteco, que verifica se ocorre uma situao de Deadlock, e a segunda fase, recuperao, que surge aps o Deadlock se ter verificado e que resulta no desbloqueio dos recursos, por 13

Profa. Priscila Facciolli Tavares

UNIBAN

Notas de Aula Sistemas Operacionais

destruio dos processos que os bloqueavam. Esta a estratgia mais utilizada para tratar uma situao de Deadlock. 4.12 - Gerenciamento Manual do Deadlock Muitos dos sistemas atuais deixam para o usurio a funo de detectar um Deadlock, que atravs da utilizao rotineira o usurio apercebe-se devido ao tempo que se acha necessrio, para que o processo seja executado, j ter sido largamente ultrapassado, ficando a descrio do usurio achar se os processos entraram em Deadlock, e tentar resolver a situao recorrendo a ferramentas dos sistemas ou que a mquina fornecem, como por exemplo, e utilizado em ltima instncia, a reinicializao do sistema. O padro em que os recursos so requisitados, adquiridos e ficam em Deadlock determina quando o sistema entra em Deadlock. Um processo bloqueado incapaz de mudar o estado de um sistema, pois ele no consegue causar qualquer transio para alm do estado corrente.

Profa. Priscila Facciolli Tavares

14

UNIBAN

Notas de Aula Sistemas Operacionais EXERCCIOS PARA FIXAO

1 Defina o que uma aplicao concorrente e d um exemplo de sua utilizao. 2 O que excluso mtua e como implementada? 3 Explique o que sincronizao condicional e d um exemplo de sua utilizao. 4 Diferencie Semforos e Monitores. 5 Quais os tipos possveis de Semforos? 6 O que deadlock, qual a condio para obt-lo e quais as possveis solues? 7 - O que o mecanismo de troca de mensagens e como ele pode ser implementado? 8 Independente do mecanismo de comunicao adotado, processos que esto trocando mensagens devem ter suas execues sincronizadas. Esta afirmao est correta? Justifique sua resposta. 9 O que uma regio crtica em um programa? 10 Liste ao menos uma soluo para a excluso mtua.

Profa. Priscila Facciolli Tavares

15