Вы находитесь на странице: 1из 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

COMUNICAO ENTRE PROCESSOS

NDICE:

1. Introduo 2. Aplicaes Concorrentes 3. Especificao de Concorrncia em Programas 4. Problemas de Compartilhamento de Recursos 5. Excluso Mtua 6. Solues de Hardware 7. Solues de Software 8. Sincronizao Condicional 9. Semforos 10. Monitores 11. Troca de Mensagens 12. Bibliografia 13. Lista de Exerccios

1 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

1.

INTRODUO
Na dcada de 1960, com o surgimento dos sistemas operacionais multiprogramveis, passou a ser possvel estruturar aplicaes de maneira que partes diferentes do cdigo do programa pudessem executar concorrentemente. Este tipo de aplicao, denominado 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 um sistema multiprogramvel com um nico processador, os processos alternam sua execuo segundo critrios de escalonamento estabelecidos pelo sistema operacional. Mesmo no havendo neste tipo de sistema um paralelismo na execuo de instrues, uma aplicao concorrente pode obter melhoras no seu desempenho. Em sistemas com mltiplos processadores, a possibilidade do paralelismo na execuo de instrues somente estende as vantagens que a programao concorrente proporciona. 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 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.

2. APLICAES CONCORRENTES
Muitas vezes, em uma aplicao concorrente, necessrio que processos se comuniquem entre si. Esta comunicao pode ser implementada atravs de diversos mecanismos, como variveis compartilhadas na memria principal ou trocas de mensagens. Nesta situao, necessrio que os processos concorrentes tenham sua execuo sincronizada atravs de mecanismos do sistema operacional. A figura 1 apresenta um exemplo onde dois processos concorrentes compartilham um buffer para trocar informaes atravs de operaes de gravao e leitura. Neste exemplo, um processo s poder gravar dados no buffer caso este no esteja cheio. Da mesma forma, um processo s poder ler dados armazenados do buffer caso exista algum dado para ser lido. Em ambas as situaes, os processos devero aguardar at que o buffer esteja pronto para as operaes, seja de leitura, seja de gravao.

2 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Figura 1: Sincronizao e comunicao entre processos Os mecanismos que garantem a comunicao entre processos concorrentes e o acesso a recursos compartilhados so chamados mecanismos de sincronizao. No projeto de sistemas operacionais multiprogramveis, fundamental a implementao destes mecanismos para garantir a integridade e a confiabilidade na execuo de aplicaes concorrentes.

3. ESPECIFICAO DE CONCORRNCIA EM PROGRAMAS


Existem vrias notaes utilizadas para especificar a concorrncia em programas, ou seja, as partes de um programa que devem ser executadas concorrentemente. A primeira notao para a especificao da concorrncia em um programa foram os comandos FORK e JOIN, introduzidos por Conway (1963) e Dennis e Van Horn (1966). O exemplo a seguir apresenta a implementao da concorrncia em um programa com uma sintaxe simplificada: PROGRAM A . . FORK B; . . JOIN B; . . END PROGRAM B . . . . . END

O programa A comea a ser executado e, ao encontrar o comando FORK, faz com que seja criado um outro processo para a execuo do programa B, concorrentemente ao programa A. O comando JOIN permite que o programa A sincronize-se com B, ou seja, quando o programa A encontrar o comando JOIN, s continuar a ser processado aps o trmino da execuo do programa B. Os comandos FORK e JOIN so bastante poderosos e prticos, sendo utilizados de forma semelhante no sistema operacional Unix.
3 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Uma das implementaes mais claras e simples de expressar concorrncia em um programa a utilizao dos comandos PARBEGIN e PAREND (Dijkstra, 1965). O comando PARBEGIN especifica que a seqncia de comandos seja executada concorrentemente em uma ordem imprevisvel, atravs da criao de um processo (Processo_1, Processo_2, Processo_n) para cada comando (Comando_1, Comando_2, Comando_n). O comando PAREND define um ponto de sincronizao, onde o processamento s continuar quando todos os processos ou threads criados j tiverem terminado suas execues. Os comandos delimitados pelos comandos PARBEGIN e PAREND podem ser comandos simples, como atribuies ou chamadas a procedimentos.

Figura 2: Concorrncia em programas Para exemplificar o funcionamento dos comandos PARBEGIN e PAREND em uma aplicao concorrente, o programa Expressao realiza o clculo do valor da expresso a seguir: X := SQRT (1024) + (35.4 * 0.23) (302 / 7) Os comandos de atribuio situados entre PARBEGIN e PAREND so executados concorrentemente. O clculo final de X s pode ser realizado quando todas as variveis dentro da estrutura tiverem sido calculadas.

4 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

PROGRAM Expressao VAR X, Temp1, Temp2, Temp3 : REAL; BEGIN PARBEGIN Temp1 := SQRT (1024); Temp2 := 35.4 * 0.23; Temp3 := 302 / 7; PAREND; X := Temp1 + Temp2 Temp3; WRITELN ( x = , X); END

4. PROBLEMAS DE COMPARTILHAMENTO DE RECURSOS


Para a compreenso de como a sincronizao entre processos fundamental para a confiabilidade dos sistemas multiprogramveis, so apresentados alguns problemas de compartilhamento de recursos. A primeira situao envolve o compartilhamento de um arquivo em disco; a segunda apresenta uma varivel na memria principal sendo compartilhada por dois processos; e uma terceira envolve um dispositivo de sada. O primeiro problema analisado a partir 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. Neste arquivo so armazenados os saldos de todos os correntistas do banco. O programa l o registro do cliente no arquivo (Reg_Cliente), l o valor a ser depositado ou retirado (Valor_Dep_Ret) e, em seguida, atualiza o saldo no arquivo de contas. 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 que atualizam o saldo de um mesmo cliente simultaneamente, a situao de compartilhamento do recurso pode ser analisada. O processo do primeiro funcionrio (Caixa 1) l o registro do cliente e soma ao campo Saldo o valor do lanamento de dbito. Antes de gravar o novo saldo no arquivo, o processo do segundo funcionrio (Caixa 2) l o registro do mesmo cliente, que est sendo atualizado, para realizar outro lanamento, desta vez de crdito. Independentemente de qual dos processos atualize primeiro o saldo no arquivo, o dado gravado estar inconsistente.
5 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Um segundo, ainda mais simples, onde o problema da concorrncia pode levar a resultados inesperados, a situao onde dois processos (A e B) executam um comando de atribuio. O Processo A soma 1 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;

Os comandos de atribuio, em uma linguagem de alto nvel, podem ser decompostos em comandos mais elementares, como visto a seguir: Processo A LOAD x, Ra ADD 1, Ra STORE Ra, x Processo B LOAD x, Rb SUB 1, Rb STORE Rb, x

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 sua execuo, carrega o valor de X em Rb e subtrai 1. Dessa vez, o processo B interrompido e 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 valor final da varivel X inconsistente em funo da forma concorrente com que os dois processos executaram. Como terceiro exemplo, vamos analisar um spool de impresso. Quando um processo deseja imprimir um arquivo, ele entra com o nome do arquivo em um diretrio especial de spool. Outro processo, o impressor, verifica periodicamente este diretrio, para ver se h arquivos a serem impressos. Havendo, eles so impressos e seus nomes so retirados do diretrio. Imaginemos que nosso diretrio de spool tenha um grande nmero de entradas, numeradas como 0, 1, 2, ....., cada uma delas capaz de armazenar um nome de arquivo. Consideremos que existam duas variveis compartilhadas: out, que aponta para o nome do prximo arquivo a ser impresso e in, que aponta para a prxima entrada livre do diretrio. Tais variveis devem ser mantidas em duas palavras de memria, acessveis a todos os processos. Suponhamos que em determinado instante, as entradas 0 a 3 estejam vazias e as entradas 4 a 6 estejam ocupadas e que os processos A e B decidam colocar na fila um arquivo para impresso. O processo A l in e armazena o valor lido 7 numa varivel local. Exatamente aps esta operao ter sido concluda, ocorre uma interrupo de tempo, devendo o processo A ceder o processador para o processo B. Este l o valor de in obtendo o valor 7, mesmo valor que A obteve quando realizou a leitura. Desta forma, B guarda o nome do seu arquivo de impresso na entrada 7 do diretrio, e atualiza o valor de in para 8. Aps isto, ele continua seu processamento normalmente.
6 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Em algum momento seguinte, o processo A vai reiniciar seu processamento no exato ponto da interrupo. Ao examinar o valor de sua varivel local encontra 7 armazenado nela e escreve o nome de seu arquivo de impresso na entrada 7 do diretrio, apagando o nome do arquivo escrito anteriormente por B e ainda no impresso. Depois disso, o processo atualiza o valor de in para 8 e continua seu processamento. O diretrio de spool est consistente, de forma que o processo impressor no vai notar nada de errado na estrutura do diretrio. Ocorre que o processo B nunca vai ter sua sada impressa. Analisando os trs 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. Situaes como esta, onde dois ou mais processos esto acessando dados compartilhados, e o resultado final do processamento depende de quem roda quando, so chamadas de condies de corrida. A anlise de programas em que ocorrem condies de corrida no uma tarefa fcil. Os resultados da maioria dos testes so consistentes com a estrutura do programa, mas de vez em quando ocorre algo imprevisto e inexplicvel, em funo do no-determinismo potencial, causado pelas condies de corrida.

5. EXCLUSO MTUA
A soluo mais simples para evitar os problemas de compartilhamento apresentados no item anterior 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 excluso mtua. 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. Se for possvel evitar que dois processos entrem 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 instrues de sua regio crtica, obrigatoriamente dever executar antes um protocolo de entrada nessa regio. Da
7 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

mesma forma, ao sair da regio crtica um protocolo de sada dever ser executado. Os protocolos de entrada e sada garantem a excluso mtua da regio crtica do programa. BEGIN . . Entra_Regiao_Critica; (* Protocolo de Entrada *) Regiao Critica; Sai_Regiao_Critica; (* Protocolo de Saida *) . . END Utilizando o programa Conta_Corrente apresentado anteriormente, a aplicao dos protocolos para os dois processos (A e B) pode ser implementada no compartilhamento do arquivo de contas-correntes. Sempre que o processo A for atualizar o saldo de um cliente, antes de ler o registro o acesso exclusivo ao arquivo deve ser garantido atravs do protocolo de entrada da sua regio crtica. O protocolo indica se j existe ou no algum processo acessando o recurso. Caso o recurso esteja livre, o processo A pode entrar em sua regio crtica para realizar a atualizao. Durante este perodo, caso o processo B tente acessar o arquivo, o protocolo de entrada faz com que esse processo permanea aguardando at que o processo A termine o acesso ao recurso. Quando o processo A terminar a execuo de sua regio crtica, deve sinalizar aos demais processos concorrentes que o acesso ao recurso foi concludo. Isso realizado atravs do protocolo de sada, que informa aos outros processos que o recurso j est livre e pode ser utilizado de maneira exclusiva por um outro processo. Para garantir a implementao da excluso mtua, os processos envolvidos devem fazer acesso aos recursos de forma sincronizada. Diversas solues foram desenvolvidas com esse propsito; porm, alem da garantia da excluso mtua, duas situaes indesejadas tambm devem ser evitadas. A primeira situao indesejada conhecida como starvation ou espera indefinida. Starvation a situao em que um processo nunca consegue executar sua regio crtica e, conseqentemente, acessar o recurso compartilhado. Outra situao indesejada na implementao da excluso mtua aquela em que um processo fora da sua regio crtica impede que outros processos entrem nas suas prprias regies crticas. No caso desta situao ocorrer, um recurso estaria livre, porm alocado a um processo.

6. SOLUES DE HARDWARE
8 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

A excluso mtua pode ser implementada atravs de mecanismos de hardware. Neste item, so apresentadas as solues de desabilitao de interrupes e instrues test-and-set. 6.1. Desabilitao de Interrupes A soluo mais simples para o problema da excluso mtua fazer com que o processo desabilite todas as interrupes antes de entrar em sua regio crtica, e as reabilite aps deixar a regio crtica. Como a mudana de contexto de processos s pode ser realizada atravs de interrupes, o processo que as desabilitou ter acesso exclusivo garantido. Esta soluo, apesar de simples, apresenta algumas limitaes. Primeiramente, a multiprogramao pode ficar comprometida, j que a concorrncia entre processos tem como base o uso das interrupes. Um caso mais grave poderia ocorrer caso um processo desabilitasse as interrupes e no tornasse a habilit-las. Em sistemas com mltiplos processadores, esta soluo torna-se ineficiente devido ao tempo de propagao quando um processador sinaliza aos demais que as interrupes devem ser habilitadas ou desabilitadas. Apesar das limitaes apresentadas, essa soluo pode ser til quando se deseja que a execuo de parte do ncleo do sistema operacional ocorra sem que haja interrupo. Desta forma, o sistema pode garantir que no ocorrero problemas de inconsistncia em suas estruturas de dados durante a execuo de algumas rotinas. 6.2. Instruo Test-and-Set Muitos processadores possuem uma instruo de mquina especial que permite ler uma varivel, armazenar seu contedo em uma outra rea e atribuir um novo valor mesma varivel. Essa instruo especial chamada instruo test-and-set e tem como caracterstica ser executada sem interrupo, ou seja, trata-se de uma instruo indivisvel. Desta forma, garantido que dois processos no manipulem uma varivel compartilhada ao mesmo tempo, possibilitando a implementao da excluso mtua. A instruo test-and-set possui o formato a seguir, e quando executada o valor lgico da varivel Y copiado para X, sendo atribudo varivel Y o valor lgico verdadeiro. Test-and-Set (X,Y); Para coordenar o acesso concorrente a um recurso, a instruo test-and-set utiliza uma varivel lgica global, que no programa Test-and-Set denominada Bloqueio. Quando a varivel Bloqueio for falsa, qualquer processo poder alterar seu valor para verdadeiro atravs da instruo test-and-set e, assim, acessar o recurso de forma exclusiva. Ao terminar o acesso, o processo deve simplesmente retornar o valor da varivel para falso, liberando o acesso ao recurso.
9 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

PROGRAM Test-and-Set; VAR Bloqueio : BOOLEAN; PROCEDURE Processo_A; VAR Pode_A : BOOLEAN; BEGIN REPEAT Pode_A :=True; WHILE (Pode_A) DO Test-and-Set (Pode_A, Bloqueio); Regiao_Critica_A; Bloqueio := False; UNTIL True; END; PROCEDURE Processo_B; VAR Pode_B : BOOLEAN; BEGIN REPEAT Pode_B :=True; WHILE (Pode_B) DO Test-and-Set (Pode_B, Bloqueio); Regiao_Critica_B; Bloqueio := False; UNTIL True; END; BEGIN Bloqueio := False; PARBEGIN Processo_A; Processo_B; PAREND; END. O uso de uma instruo especial de mquina oferece algumas vantagens, como a simplicidade de implementao da excluso mtua entre mltiplas regies crticas e o uso da soluo em arquiteturas com mltiplos processadores. A principal desvantagem a possibilidade do starvation, pois a seleo do processo para o acesso ao recurso arbitrria.

7. SOLUES DE SOFTWARE
Diversos algoritmos foram propostos na tentativa de implementar a excluso mtua atravs da soluo de software. As primeiras solues tratavam apenas da excluso mtua para dois processos e, inicialmente, apresentavam alguns problemas. A seguir apresentado de forma evolutiva como foi o desenvolvimento de uma soluo definitiva para a excluso mtua entre N processos. 7.1. Primeiro Algoritmo
10 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Este algoritmo apresenta uma soluo para excluso mtua entre dois processos, onde um mecanismo de controle alterna a execuo das regies crticas. Cada processo (A e B) representado por um procedimento que possui um loop infinito (REPEAT/UNTIL), onde feito o acesso a um recurso por diversas vezes. A seqncia de comandos, dentro do loop, formada por um protocolo de entrada, uma regio crtica e um protocolo de sada. A regio crtica representada por uma rotina, onde o acesso ao recurso realmente acontece. Aps o acesso regio crtica, tanto o processo A quanto o processo B realizam processamentos individuais. O algoritmo utiliza uma varivel de bloqueio, indicando qual processo pode ter acesso regio crtica. Inicialmente, a varivel global Vez igual a A, indicando que o processo A pode executar em sua regio crtica. O processo B, por sua vez, fica esperando enquanto Vez for igual a A. O processo B s executar sua regio crtica quando o processo A atribuir o valor B varivel de bloqueio Vez. Desta forma, estar garantida a excluso mtua entre os dois processos. PROGRAM Algoritmo_1; VAR Vez : CHAR; PROCEDURE Processo_A; BEGIN REPEAT WHILE (Vez = B) DO Regiao_Critica_A; Vez := B; Processamento_A; UNTIL False; END; PROCEDURE Processo_B; BEGIN REPEAT WHILE (Vez = A) DO Regiao_Critica_B; Vez := A; Processamento_B; UNTIL False; END; BEGIN Vez := A; PARBEGIN Processo_A; Processo_B; PAREND; END.

(* Nao faz nada *);

(* Nao faz nada *);

Este algoritmo, apesar de implementar a excluso mtua, apresenta duas limitaes, das quais a primeira surge do prprio mecanismo de controle utilizado. O acesso ao recurso compartilhado s pode ser realizado por dois processos e sempre de maneira alternada. Com isso, um processo que necessite utilizar o recurso mais vezes do que outro permanecer grande parte do tempo bloqueado. No algoritmo apresentado, caso o processo
11 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

A permanea muito tempo na rotina Processamento_A, possvel que o processo B queira executar sua regio crtica e no consiga, mesmo que o processo A no esteja utilizando o recurso. Como o processo B pode executar seu loop mais rapidamente que o processo A, a possibilidade de executar sua regio crtica fica limitada pela velocidade de processamento do processo A. Outro problema existente nesta soluo que, no caso da ocorrncia de algum problema com um dos processos, de forma que a varivel de bloqueio no seja alterada, o outro processo permanecer indefinidamente bloqueado, aguardando o acesso ao recurso.

7.2.

Segundo Algoritmo O problema principal do primeiro algoritmo que ambos os processos trabalham com

uma mesma varivel global, cujo contedo indica qual processo tem direito de entrar na regio crtica. Para evitar esta situao, o segundo algoritmo introduz uma varivel para cada processo (CA e CB) que indica se o processo est ou no em sua regio crtica. Neste caso, toda vez que um processo deseja entrar em sua regio crtica, a varivel do outro processo testada para verificar se o recurso est livre para uso. PROGRAM Algoritmo_2; VAR CA, CB : BOOLEAN; PROCEDURE Processo_A; BEGIN REPEAT WHILE (CB) DO CA := true; Regiao_Critica_A; CA := false; Processamento_A; UNTIL False; END; PROCEDURE Processo_B; BEGIN REPEAT WHILE (CA) DO CB := true; Regiao_Critica_B; CB := false; Processamento_B; UNTIL False; END; BEGIN CA := false; CB := false; PARBEGIN Processo_A; Processo_B; PAREND; END.

(* Nao faz nada *);

(* Nao faz nada *);

12 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Neste segundo algoritmo, o uso do recurso no realizado necessariamente alternado. Caso ocorra algum problema fora da regio crtica, o outro processo no ficar bloqueado, o que, porm, no resolve por completo o problema. Caso um processo tenha um problema dentro da sua regio crtica ou antes de alterar a varivel, o outro processo permanecer indefinidamente bloqueado. Mais grave que o problema do bloqueio que esta soluo, na prtica, pior do que o primeiro algoritmo apresentado, pois nem sempre a excluso mtua garantida quando cada processo executa cada instruo alternadamente. 7.3. Terceiro Algoritmo O terceiro algoritmo tenta solucionar o problema apresentado no segundo, colocando a instruo de atribuio das variveis CA e CB antes do loop de teste. PROGRAM Algoritmo_3; VAR CA, CB : BOOLEAN; PROCEDURE Processo_A; BEGIN REPEAT CA := true; WHILE (CB) DO (* Nao faz nada *); Regiao_Critica_A; CA := false; Processamento_A; UNTIL False; END; PROCEDURE Processo_B; BEGIN REPEAT CB := true; WHILE (CA) DO (* Nao faz nada *); Regiao_Critica_B; CB := false; Processamento_B; UNTIL False; END. Esta alterao resulta na garantia da excluso mtua, porm introduz um novo problema, que a possibilidade de bloqueio indefinido de ambos os processos. Caso os dois processos alterem as variveis CA e CB antes da execuo da instruo WHILE, ambos os processos podero entrar em suas regies crticas, como se o recurso j estivesse alocado. 7.4. Quarto Algoritmo No terceiro algoritmo, cada processo altera o estado da sua varivel indicando que ir entrar na regio crtica sem conhecer o estado do outro processo, o que acaba resultando no problema apresentado. O quarto algoritmo apresenta uma implementao onde o processo, da mesma forma, altera o estado da varivel antes de entrar na sua regio crtica, porm existe a possibilidade de esta alterao ser revertida.
13 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

PROGRAM Algoritmo_4; VAR CA, CB : BOOLEAN; PROCEDURE Processo_A; BEGIN REPEAT CA := true; WHILE (CB) DO BEGIN CA := false; { pequeno intervalo de tempo aleatrio } CA := true; END; Regiao_Critica_A; CA := false; UNTIL False; END; PROCEDURE Processo_B; BEGIN REPEAT CB := true; WHILE (CA) DO BEGIN CB := false; { pequeno intervalo de tempo aleatrio } CB := true; END; Regiao_Critica_B; CB := false; UNTIL False; END; BEGIN CA := false; CB := false; PARBEGIN Processo_A; Processo_B; PAREND; END. Apesar de esta soluo garantir a excluso mtua e no gerar bloqueio simultneo dos processos, uma nova situao indesejada pode ocorrer eventualmente. No caso de os tempos aleatrios serem prximos e a concorrncia gerar uma situao onde nenhuns dos dois processos alterem as variveis CA e CB para falso antes do trmino do loop, nenhum dos dois conseguir executar sua regio crtica. Mesmo com esta situao no sendo permanente, pode gerar algum problema. 7.5. Algoritmo de Dekker A primeira soluo de software que garantiu a excluso mtua entre dois processos sem a incorrncia de outros problemas foi proposta pelo matemtico holands T. Dekker com base no primeiro e quarto algoritmos. O algoritmo de Dekker possui uma lgica

14 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

bastante complexa. Posteriormente, G. L. Peterson props outra soluo mais simples para o mesmo problema. 7.6. Algoritmo de Peterson O algoritmo proposto por G. L. Peterson apresenta uma soluo para o problema da excluso mtua entre dois processos que pode ser facilmente generalizada para o caso de N processos. Similar ao terceiro algoritmo, esta soluo, alm das variveis de condio (CA e CB) que indicam o desejo de cada processo entrar em sua regio crtica, introduz a varivel Vez para resolver os conflitos gerados pela concorrncia. Antes de acessar a regio crtica, o processo sinaliza esse desejo atravs da varivel de condio, porm o processo cede o uso do recurso ao outro processo, indicado pela varivel Vez. Em seguida, o processo executa o comando WHILE como protocolo de entrada da regio crtica. Neste caso, alm da garantia da excluso mtua, o bloqueio indefinido de um dos processos no loop nunca ocorrer, j que a varivel Vez sempre permitir a continuidade da execuo de um dos processos. PROGRAM Algoritmo_Peterson; VAR CA, CB : BOOLEAN; Vez : CAHR; PROCEDURE Processo_A; BEGIN REPEAT CA := true; Vez := B; WHILE (CB and Vez = B) DO Regiao_Critica_A; CA := false; Processamento_A; UNTIL False; END; PROCEDURE Processo_B; BEGIN REPEAT CB := true; Vez := A; WHILE (CA and Vez = A) DO Regiao_Critica_B; CB := false; Processamento_B; UNTIL False; END; BEGIN CA := false; CB := false; PARBEGIN Processo_A; Processo_B; PAREND; END.

(* Nao faz nada *);

(* Nao faz nada *);

15 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

7.7.

Algoritmo para Excluso Mtua entre N Processos O algoritmo de Dekker e a verso inicial do algoritmo de Peterson garantem a

excluso mtua de dois processos. Posteriormente, o algoritmo de Peterson foi generalizado para o caso de N processos. Apesar de todas as solues at ento apresentadas implementarem a excluso mtua, todas possuam uma deficincia conhecida como espera ocupada. Na espera ocupada, toda vez que um processo no consegue entrar em sua regio crtica, por j existir outro processo acessando o recurso, o processo permanece em looping, testando uma condio, at que lhe seja permitido o acesso. Dessa forma, o processo em looping consome tempo do processador desnecessariamente, podendo ocasionar problemas ao desempenho do sistema. A soluo para a espera ocupada foi a introduo de mecanismos de sincronizao que permitiram que um processo, quando no pudesse entrar em sua regio crtica, fosse colocado no estado de espera.

8. 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, conforme visto na figura 1, onde processos 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. O programa a seguir exemplifica o problema da sincronizao condicional, tambm conhecido como problema do produtor/consumidor ou do buffer limitado. O recurso compartilhado um buffer, definido no algoritmo com o tamanho TamBuf e sendo controlado por uma varivel Cont. Sempre que a varivel Cont for igual a 0, significa que o buffer est vazio e o processo Consumidor deve permanecer aguardando at que se grava um dado. Da mesma forma, quando a varivel Cont for igual a TamBuf, significa que o buffer est cheio e o processo Produtor deve aguardar a leitura de um novo dado. Nessa soluo, a tarefa de colocar e retirar os dados no buffer realizada, respectivamente, pelos procedimentos Grava_Buffer e Le_Buffer, executados de forma mutuamente exclusiva. No
16 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

est sendo considerada a implementao da excluso mtua na varivel compartilhada Cont. PROGRAM Produtor_Consumidor_1; CONST TamBuf = (* Tamanho qualquer *); TYPE Tipo_dado = (* Tipo qualquer *); VAR Buffer : ARRAY [1..TamBuf] OF Tipo_Dado; Dado_1 : Tipo_Dado; Dado_2 : Tipo_Dado; Cont : 0..TamBuf; PROCEDURE Produtor; BEGIN REPEAT Produz_Dado (Dado_1); WHILE (Cont = TamBuf) DO (* Nao faz nada *); Grava_Buffer (Dado_1, Buffer); Cont := Cont + 1; UNTIL False; END; PROCEDURE Consumidor; BEGIN REPEAT WHILE (Cont = 0) DO (* Nao faz nada *); Consome_Dado (Dado_2); Cont := Cont_1; UNTIL False; END; BEGIN Cont := 0; PARBEGIN Produtor; Consumidor; PAREND; END. Apesar do algoritmo apresentado resolver a questo da sincronizao condicional, o problema da espera ocupada tambm se faz presente, sendo somente solucionado pelos mecanismos de sincronizao semforos e monitores.

9. 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. Atualmente, a maioria das linguagens de programao disponibiliza rotinas para o uso de semforos.

17 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Um semforo uma varivel inteira, no-negativa, que s pode ser manipulada por duas instrues: DOWN e UP. As instrues DOWN e UP so indivisveis (aes atmicas), ou seja, a execuo destas instrues no pode ser interrompida. A instruo UP incrementa uma unidade ao valor do semforo, enquanto a instruo DOWN decrementa a varivel. Como, por definio, valores negativos no podem ser atribudos a um semforo, a instruo DOWN executada em um semforo com valor 0, faz com que o processo entre no estado de espera. Em geral, essas instrues so implementadas no hardware do processador, que deve garantir todas essas condies. Os semforos podem ser classificados como binrios ou contadores. Os semforos binrios, tambm chamados de mutexes (mutual exclusion semaphores), s podem assumir valores 0 e 1, enquanto que os semforos contadores podem assumir qualquer valor inteiro positivo, alm do 0.

9.1.

Excluso Mtua Utilizando Semforos A excluso mtua pode ser implementada atravs de um semforo binrio associado

ao recurso compartilhado. A principal vantagem desta soluo em relao aos algoritmos anteriormente apresentados a no ocorrncia da espera ocupada. As instrues DOWN e UP funcionam como protocolos de entrada e sada, respectivamente, para que um processo possa entrar e sair da sua regio crtica. O semforo fica associado a um recurso compartilhado, indicando quando o recurso est sendo acessado por um dos processos concorrentes. O valor do semforo igual a 1 indica que nenhum processo est utilizando o recurso, enquanto que o valor 0 indica que o recurso est em uso. Sempre que deseja entrar na sua regio crtica, um processo executa uma instruo DOWN. Se o semforo for igual a 1, este valor decrementado, e o processo que solicitou a operao pode executar as instrues da sua regio crtica. De outra forma, se uma instruo DOWN executada em um semforo com valor igual a 0, o processo fica impedido do acesso, permanecendo em estado de espera e, conseqentemente, no gerando overhead no processador. O processo que est acessando o recurso, ao sair de sua regio crtica, executa uma instruo UP, incrementando o valor do semforo e liberando o acesso ao recurso. Se um ou mais processos estiverem esperando pelo uso do recurso, o sistema selecionar um processo na fila de espera associada ao recurso e alterar o seu estado para pronto.

18 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Figura 3: Utilizao do semforo binrio na excluso mtua

As instrues DOWN e UP, aplicadas a um semforo S, podem ser representadas pelas definies a seguir, em uma sintaxe Pascal no convencional: TYPE Semaforo = RECORD Valor : INTEGER; Fila_Espera : (* Lista de processos pendentes *); END; PROCEDURE DOWN (VAR S : Semaforo); BEGIN IF (S = 0) THEN Coloca_Processo_na_Fila_de_Espera ELSE S := S - 1; END; PROCEDURE UP (VAR S : Semaforo); BEGIN S := S + 1; IF (Tem_Processo_Esperando) THEN Retira_da_Fila_de_Espera; END; O programa Semaforo_1 apresenta uma soluo para o problema da excluso mtua entre dois processos utilizando semforos. O semforo inicializado com o valor 1, indicando que nenhum processo est executando sua regio crtica. PROGRAM Semaforo_1; VAR s Semaforo := 1; PROCEDURE Processo_A; BEGIN REPEAT DOWN (s); Regiao_Critica_A; UP (s); UNTIL False; END; PROCEDURE Processo_B; BEGIN REPEAT (* inicializacao do semaforo *)

19 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

DOWN (s); Regiao_Critica_B; UP (s); UNTIL False; END; BEGIN PARBEGIN Processo_A; Processo_B; PAREND; END.

9.2.

Sincronizao Condicional Utilizando Semforos Alm de permitir a implementao da excluso mtua, os semforos podem ser

utilizados nos casos onde a sincronizao condicional exigida. Um exemplo desse tipo de sincronizao ocorre quando um processo solicita uma operao de E/S. O pedido faz com que o processo execute uma instruo DOWN no semforo associado ao evento e fique no estado de espera, at que a operao seja completada. Quando a operao termina, a rotina de tratamento da interrupo executa um UP no semforo, liberando o processo do estado de espera. Uma soluo para esse problema apresentada no programa Semaforo_2. Neste algoritmo, o semforo inicializado com o valor 0, o que garante que o processo Solicita_Leitura permanea no estado de espera at que o processo Le_Dados o libere. PROGRAM Semaforo_2; VAR Evento : Semaforo := 0; PROCEDURE Solicita_leitura; BEGIN DOWN (Evento); END; PROCEDURE Le_Dados; BEGIN UP (Evento); END; BEGIN PARBEGIN Solicita_Leitura; Le_Dados; PAREND; END.

20 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

O problema do produtor/consumidor j apresentado um outro exemplo de como a excluso mtua e a sincronizao condicional podem ser implementadas com o uso de semforos. O programa Produtor_Consumidor_2 apresenta uma soluo para esse problema, utilizando um buffer de apenas duas posies. O programa utiliza trs semforos, sendo um do tipo binrio, utilizado para implementar a excluso mtua, e dois semforos contadores para a sincronizao condicional. O semforo binrio Mutex permite a execuo das regies crticas Grava_Buffer e Le_Buffer de forma mutuamente exclusiva. Os semforos contadores Vazio e Cheio representam, respectivamente, se h posies livres no buffer para serem gravadas e posies ocupadas a serem lidas. Quando o semforo Vazio for igual a 0, significa que o buffer est cheio e o processo produtor dever aguardar at que o consumidor leia algum dado. Da mesma forma, quando o semforo Cheio for igual a 0, significa que o buffer est vazio e o consumidor dever aguardar at que o produtor grave algum dado. Em ambas as situaes, o semforo sinaliza a impossibilidade de acesso ao recurso. PROGRAM Produtor_Consumidor_2; CONST TamBuf = 2; TYPE Tipo_Dado = (* tipo qualquer *); VAR Vazio : Semaforo := TamBuf; Cheio : Semaforo := 0; Mutex : Semaforo := 1; Buffer : ARRAY [1..TamBuf] OF Tipo_Dado; Dado_1 : Tipo_Dado; Dado_2 : Tipo_Dado; PROCEDURE Produtor; BEGIN REPEAT Produz_Dado (Dado_1); DOWN (Vazio); DOWN (Mutex); Grava_Buffer (Dado_1, Buffer); UP (Mutex); UP (Cheio); UNTIL False; END; PROCEDURE Consumidor; BEGIN REPEAT DOWN (Cheio); DOWN (Mutex); Le_Buffer (Dado_2, Buffer); UP (Mutex); UP (Vazio); UNTIL False; END; BEGIN PARBEGIN Produtor; Consumidor; PAREND; END.
21 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Semforos contadores so bastante teis quando aplicados em problemas de sincronizao condicional onde existem processos concorrentes alocando recursos do mesmo tipo (pool de recursos). O semforo inicializado com o nmero total de recursos do pool, e, sempre que um processo deseja alocar um recurso, executa um DOWN, subtraindo 1 do nmero de recursos disponveis. Da mesma forma, sempre que o processo libera um recurso para o pool, executa um UP. Se o semforo contador ficar com o valor igual a 0, isso significa que no existem mais recursos a serem utilizados, e o processo que solicita um recurso permanece em estado de espera, at que outro processo libere algum recurso para o pool.

9.3.

Problema dos Filsofos O problema dos filsofos um exemplo clssico de sincronizao de processos

proposto por Dijkstra. Nesse problema, h uma mesa com cinco pratos e cinco garfos, onde os filsofos podem sentar, comer e pensar.

A vida de um filsofo consiste em perodos nos quais ele alternadamente come e pensa. Quando um filsofo sente fome, ele tenta tomar posse dos garfos sua direita e sua esquerda, um por vez, em qualquer ordem. Se ele tiver sucesso nesta empreitada, come um pouco do macarro, libera os garfos e continua a pensar. A questo a ser respondida : podemos escrever um programa para simular a ao de cada filsofo que nunca leve a situaes de deadlock? Existem vrias solues para resolver o problema dos filsofos sem a ocorrncia do deadlock, como as apresentadas a seguir: (a) Permitir que apenas quatro filsofos sentem na mesa simultaneamente;

22 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

(b) Permitir que um filsofo pegue um garfo apenas se o outro estiver disponvel;

(c) Permitir que um filsofo mpar pegue primeiro o seu garfo da esquerda e depois o
da direita, enquanto um filsofo par pegue primeiramente o garfo da direita e, em seguida, o da esquerda. A soluo correta, que permite o mximo de paralelismo para um nmero arbitrrio de filsofos est mostrada abaixo. Ela utiliza uma matriz, state, para controlar se um filsofo est comendo, pensando ou com fome. Um filsofo s pode passar para o estado comendo se nenhum vizinho estiver comendo. Os vizinhos do filsofo i so definidos pelas macros LEFT e RIGHT. Em outras palavras, se i vale 2, LEFT vale 1 e RIGHT vale 3. O programa usa arrays de semforos, um para cada filsofo, de forma que os filsofos com fome possam ser bloqueados se os garfos necessrios para que ele coma estiverem ocupados. Cada processo roda o procedimento philosopher como seu cdigo principal. Os demais procedimentos, take_forks, put_forks e test so procedimentos comuns e no processos separados. #include prototypes.h #define N #define LEFT #define RIGHT #define THINKING #define HUNGRY #define EATING typedef int semaphore; int state (N); semaphore mutex = 1; semaphore s ( N ); void philosopher ( int i ) { while (TRUE) { think ( ); take_forks ( i ); eat ( ); put_forks ( i ); } } void take_forks ( int i ) { down ( &mutex ); state ( i ) = HUNGRY; test ( i ); up ( &mutex ); down ( &s [ i ] ); } void put_forks ( int i ) { /* numero de filsofos /* numero de vizinhos a esquerda de i /* numero de vizinhos a direita de i /* filosofo pensando /* filosofo tentando pegar garfos /* filosofo comendo /* semaforos sao tipos especiais inteiros /* vetor para controlar estado dos filosofos /* excluso mutua para regiao critica /* um semforo por filosofo /* i: identificacao do filosofo ( de 1 ate N) /* loop /* filosofo pensando /* adquire dois garfos ou fica bloqueado /* come o macarro /* devolve ambos os garfos de volta a mesa /* i: numero de filosofo (de 1 ate N) /* entra na regiao critica /* lembra do fato de que o filosofo i esta com fome /* tenta adquirir dois garfos /* sai da regiao critica /* fica bloqueado se nao conseguir pegar dois garfos /* i: numero de filosofo (de 1 ate N)
23 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

down ( &mutex ); state ( i ) = THINKING; test (LEFT); test (RIGHT);

up ( &mutex ); } void test ( int i ) /* i: numero de filosofo (de 1 ate N) { if (state [i] = HUNGRY && state [LEFT] ! = EATING && state [RIGHT] ! = EATING) { state [I] = EATING; up ( &s [I] ); } } 9.4. Problema do Barbeiro

/* entra na regiao critica /* filosofo acabou de comer /* verifica se vizinho a esquerda pode comer agora /* verifica se vizinho a direita pode comer agora /* sai da regiao critica

O problema do barbeiro outro exemplo clssico de sincronizao de processos. Neste problema, um barbeiro recebe clientes para cortar o cabelo. Na barbearia h uma cadeira de barbeiro e apenas cinco cadeiras para clientes esperarem. Quando um cliente chega, caso o barbeiro esteja trabalhando, ele senta se houver cadeira vazia ou vai embora se todas as cadeiras estiverem ocupadas. No caso de o barbeiro no ter nenhum cliente para atender, ele senta na cadeira e dorme at que um novo cliente aparea. A soluo proposta mostrada abaixo:
#include prototypes.h #define CHAIRS 5 typedef int semaphore; semaphore customers = 0; semaphore barbers = 0; semaphore mutex = 1; int waiting = 0; void barber ( void ) { while (TRUE) { down (customers); down (mutex); waiting = waiting - 1; up (barbers); up (mutex); cut_hair ( ); } } void customer (void) { down (mutex); if (waiting < CHAIRS) { waiting = waiting + 1; up (customers); up (mutex); down (barbers); get_haircut ( ); /* # de cadeiras para clientes esperando /* # de clientes esperando por servico /* # de barbeiros esperando por clientes /* controla ao acesso a regiao critica /* clientes esto esperando

/* loop /* vai dormir se # de clientes 0 /* obtem acesso a waiting /* decrementa contador de clientes esperando /* um barbeiro esta pronto para cortar cabelos /* libera acesso a waiting /* corta o cabelo (fora da regiao critica)

/* entra na regiao critica /* vai embora se nao houver nenhuma cadeira vazia /* incrementa contador de clientes esperando /* acorda o barbeiro se necessario /* libera acesso a wating /* vai dormir se # de barbeiros livre 0 /* senta na cadeira e corta o cabelo
24 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

} else { up (mutex); } }

/* barbearia muito cheia, no espere

Quando chega o primeiro fregus, este executa customer, iniciando tal execuo com um DOWN sobre mutex, garantindo que se outro cliente chegar imediatamente aps ele no estar habilitado a fazer nada, at que o primeiro execute um UP sobre mutex. O cliente ento verifica se h alguma cadeira livre, comparando o nmero de clientes que esperam com o nmero de cadeiras disponveis. Se no houver, ele libera mutex e vai embora. Havendo pelo menos uma cadeira disponvel, o cliente incrementa a varivel inteira waiting. Ento d um UP no semforo customers, ficando espera do barbeiro. Neste momento, tanto o cliente quanto o barbeiro esto acordados. Ento, quando o cliente libera mutex, o barbeiro apodera-se dele, d uma arrumadinha no salo e inicia o corte. Quando o corte termina, o cliente completa a execuo do procedimento e deixa a barbearia. Em contraposio aos exemplos anteriores, no h loop para o processo cliente, porque cortar o cabelo uma operao idempotente. J o barbeiro deve estar num loop tentando pegar o prximo cliente. Se houver algum presente, um novo corte iniciado. Se no houver, o barbeiro vai dormir.

10. MONITORES
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. Hoare em 1974, como um mecanismo de sincronizao estruturado, ao contrrio dos semforos, que so considerados noestruturados. O uso de semforos exige do desenvolvedor bastante cuidado, pois qualquer engano pode levar a problemas de sincronizao imprevisveis e difceis de serem reproduzidos devido execuo concorrente dos processos. Monitores so considerados mecanismos de alto nvel e estruturados em funo de serem implementados pelo compilador. Assim, o desenvolvimento de programas concorrentes fica mais fcil e as chances de erro so menores. Atualmente, a maioria das linguagens de programao disponibiliza rotinas para uso de monitores. O monitor formado por procedimentos e variveis encapsulados dentro de um mdulo. Sua caracterstica mais importante a implementao automtica da excluso
25 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

mtua entre os procedimentos declarados, ou seja, somente um processo pode estar executando um dos procedimentos do monitor em um determinado instante. Toda vez que um processo faz uma chamada a um desses procedimentos, 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. As variveis globais de um monitor so visveis apenas aos procedimentos da sua estrutura, sendo inacessveis fora do contexto do monitor. Toda a inicializao das variveis realizada por um bloco de comando do monitor, sendo executado apenas uma vez, na ativao do programa onde est declarado o monitor.

Figura 4: Estrutura do monitor Um monitor definido especificando-se um nome, declarando-se variveis locais, procedimentos e um cdigo de inicializao. A estrutura de um monitor mostrada a seguir, utilizando uma sintaxe Pascal no convencional: MONITOR Exclusao_Mutua; (* Declaracao das variaveis do monitor *); PROCEDURE Regiao_Critica_1; BEGIN . . END; PROCEDURE Regiao_Critica_2; BEGIN . . END; PROCEDURE Regiao_Critica_3; BEGIN . . END; BEGIN (* Codigo de inicializacao *) END.
26 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

10.1.

Excluso Mtua Utilizando Monitores A implementao da excluso mtua utilizando monitores no realizada

diretamente pelo programador, como no caso do uso de semforos. As regies crticas devem ser definidas como procedimentos no monitor, e o compilador se encarregar de garantir a excluso mtua entre esses procedimentos. A comunicao do processo com o monitor feita unicamente atravs de chamadas a seus procedimentos e dos parmetros passados. O programa Monitor_1 apresenta a soluo para o problema anteriormente apresentado, onde dois processos somam e diminuem, concorrentemente, o valor 1 da varivel compartilhada X. PROGRAM Monitor_1; MONITOR Regiao_Critica; VAR X : INTEGER; PROCEDURE Soma; BEGIN X = X + 1; END; PROCEDURE Diminui; BEGIN X = X 1; END; BEGIN X := 0; END; BEGIN PARBEGIN Regiao_Critica.Soma; Regiao_Critica.Diminui; PAREND; END. A inicializao da varivel X com o valor 0 s acontecer uma vez, no momento da inicializao do monitor Regiao_Critica. Neste exemplo, podemos garantir que o valor de X ao final da execuo concorrente de Soma e Diminui ser igual a 0, porque, como os procedimentos esto definidos dentro do monitor, estar garantida a execuo mutuamente exclusiva.

10.2.

Sincronizao Condicional Utilizando Monitores Monitores tambm podem ser utilizados na implementao da sincronizao

condicional. Atravs de variveis especiais de condio, possvel associar a execuo de um procedimento que faz parte do monitor a uma determinada condio, garantindo a sincronizao condicional.

27 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

As variveis especiais de condio so manipuladas por intermdio de duas instrues, conhecidas como WAIT e SIGNAL. A instruo WAIT faz com que o processo seja colocado no estado de espera, at que algum outro processo sinalize com a instruo SIGNAL que a condio de espera foi satisfeita. Caso a instruo SIGNAL seja executada e no haja processo aguardando a condio, nenhum efeito surtir. possvel que vrios processos estejam com suas execues suspensas, aguardando a sinalizao de diversas condies. Para isso, o monitor organiza os processos em espera, utilizando filas associadas s condies de sincronizao. A execuo da instruo SIGNAL libera apenas um nico processo da fila de espera da condio associada. Um processo pode executar um procedimento de um monitor, mesmo quando um ou mais processos esto na fila de espera de condies.

Figura 5: Estrutura do monitor com variveis de condio O problema do produtor/consumidor mais uma vez apresentado, desta vez com o uso dos monitores para a soluo. O monitor Condicional estruturado com duas variveis especiais de condio (Cheio e Vazio) e dois procedimentos (Produz e Consome). MONITOR Condicional; VAR Cheio, Vazio : (* Variaveis especiais de condicao *); PROCEDURE Produz; BEGIN IF (Cont = TamBuf) THEN WAIT (Cheio); . . IF (Cont = 1) THEN SIGNAL (Vazio); END; PROCEDURE Consome; BEGIN IF (Cont = 0) THEN WAIT (Vazio); . . IF (Cont = TamBuf 1) THEN SIGNAL (Cheio); END; BEGIN END;
28 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

END. Sempre que o processo produtor desejar gravar um dado no buffer, dever faz-lo atravs de uma chamada ao procedimento Produz do monitor (Condicional. Produz). Neste procedimento, deve ser testado se o nmero de posies ocupadas no buffer igual ao seu tamanho, ou seja, se o buffer est cheio. Caso o teste seja verdadeiro, o processo deve executar um WAIT em Cheio, indicando que a continuidade da sua execuo depende dessa condio, e permanece aguardando em uma fila de espera associada varivel Cheio. O processo bloqueado s poder prosseguir sua execuo quando um processo consumidor executar um SIGNAL na varivel Cheio, indicando que um elemento do buffer foi consumido. No caso do processo consumidor, sempre que desejar ler um dado do buffer, dever faz-lo atravs de uma chamada ao procedimento Consome do monitor (Condicional.Consome). Sua condio de execuo existir ao menos um elemento no buffer. Caso o buffer esteja vazio, o processo deve executar um WAIT em Vazio, indicando que a continuidade da sua execuo depende dessa condio, e permanece aguardando em uma fila de espera associada varivel Vazio. O processo produtor que inserir o primeiro elemento no buffer dever sinalizar esta condio atravs do comando SIGNAL na varivel Vazio, liberando o consumidor. O programa Produtor_Consumidor_3 descreve a soluo completa com o uso do monitor Condicional apresentado. Os procedimentos Produz_Dado e Consome_Dado servem, respectivamente, como entrada e sada de dados para o programa. Os procedimentos Grava_Dado e Le_Dado so responsveis, respectivamente, pela transferncia e recuperao do dado no buffer. PROGRAM Produtor_Consumidor_3; CONST TamBuf = (* Tamanho qualquer *); TYPE Tipo_Dado = (* Tipo qualquer *); VAR Buffer : ARRAY [1..TamBuf] OF Tipo_Dado Dado : Tipo_Dado; MONITOR Condicional; VAR Vazio, Cheio : (* Variaveis de condicao *); Cont : INTEGER; PROCEDURE Produz; BEGIN IF (Cont = TamBuf) THEN WAIT (Cheio); Grava_Dado (Dado, Buffer); Cont = Cont + 1; IF (Cont = 1) THEN SIGNAL (Vazio); END; PROCEDURE Consome; BEGIN IF (Cont = 0) THEN WAIT (Vazio); Le_Dado (Dado, Buffer); Cont := Cont 1; IF (Cont = TamBuf 1) THEN SIGNAL (Cheio);
29 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

END; BEGIN Cont := 0; END; PROCEDURE Produtor; BEGIN REPEAT Produz_Dado (Dado); Condicional.Produz; UNTIL False; END; PROCEDURE Consumidor; BEGIN REPEAT Condicional.Consome; Consome.Dado (Dado); UNTIL False; END; BEGIN PARBEGIN Produtor; Consumidor; PAREND; END.

11.

TROCA DE MENSAGENS
Troca de Mensagens um mecanismo de comunicao e sincronizao entre

processos. O sistema operacional possui um subsistema de mensagem que suporta esse mecanismo sem que haja necessidade do uso de variveis compartilhadas. Para que haja 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 6: Transmisso de mensagem


30 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

O mecanismo de troca de mensagens exige que os processos envolvidos na comunicao tenham suas execues sincronizadas. A sincronizao necessria, j que uma mensagem somente pode ser tratada por um processo aps ter sido recebida, ou o envio de mensagem pode ser uma condio para a continuidade de execuo de um processo. A troca de mensagens entre processos pode ser implementada de duas maneiras distintas, comunicao direta ou comunicao indireta. A 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. O principal problema da comunicao direta a necessidade da especificao do nome dos processos envolvidos na troca de mensagens. No caso de mudana na identificao dos processos, o cdigo do programa deve ser alterado e recompilado.

Figura 7: 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 8: Comunicao indireta

31 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

Independente do mecanismo de comunicao utilizado, processos que esto trocando mensagens devem ter suas execues sincronizadas em funo do fluxo de mensagens. Um processo no pode tratar uma mensagem at que esta tenha sido enviada por outro processo, ou um processo no pode receber uma mesma mensagem mais de uma vez. Existem trs diferentes esquemas de implementar a sincronizao entre processos que trocam mensagens. O primeiro esquema de sincronizao garantir que um processo, ao enviar uma mensagem, permanea esperando at que o processo receptor a leia. Na mesma condio, um processo, ao tentar receber uma mensagem ainda no enviada, deve permanecer aguardando at que o processo transmissor faa o envio. Esse tipo de comunicao implementa uma forma sncrona de comunicao entre os processos que conhecida como rendezvous. O problema desta implementao que a execuo dos processos fica limitada ao tempo de processamento no tratamento das mensagens. Uma variao mais eficiente do rendezvous permitir que o processo transmissor no permanea bloqueado aguardando a leitura da mensagem pelo processo receptor. Neste caso, possvel a um processo enviar mensagens para diversos destinatrios to logo seja possvel. O terceiro esquema implementa uma forma assncrona de comunicao, onde tanto o processo receptor quanto o processo transmissor no permanecem aguardando o envio e o recebimento de mensagens. Nesse caso, alm da necessidade de buffers para armazenar as mensagens, deve haver outros mecanismos de sincronizao que permitam ao processo identificar se uma mensagem j foi enviada ou recebida. A grande vantagem deste mecanismo aumentar a eficincia de aplicaes concorrentes. Uma soluo para o problema do produtor/consumidor apresentada utilizando a troca de mensagens. PROGRAM Produtor_Consumidor_4; PROCEDURE Produtor; VAR Msg : Tipo_Msg; BEGIN REPEAT Produz_Mensagem (Msg); Send (MSG); UNTIL False; END; PROCEDURE Consumidor VAR Msg : Tipo_Msg; BEGIN REPEAT RECEIVE (Msg); Consome_Mensagem (Msg); UNTIL False;
32 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

END; BEGIN PARBEGIN Produtor; Consumidor; PAREND; END.

Um problema envolvendo os sistemas de troca de mensagens a questo envolvendo a autenticao das mensagens: como um processo sabe que est se comunicando com um servidor de arquivos real e no com um impostor? Como um servidor de arquivos sabe qual o processo que requisitou acesso a um arquivo? A criptografia das mensagens, com uma chave conhecida somente por usurio autorizado, pode ser muito til neste caso. No outro extremo do espectro deve haver questes que so importantes quando o transmissor e o receptor esto rodando na mesma mquina. Uma de tais questes diz respeito performance. Copiar mensagens de um processo para outro demora muito mais do que fazer uma operao sobre um semforo, ou uma chamada a monitor. Cheriton (1984) sugeriu, por exemplo, limitar o tamanho das mensagens de forma que elas possam ser armazenadas nos registradores da mquina, realizando a troca de mensagens usando os registradores.

12.

BIBLIOGRAFIA

MACHADO, F. B., MAIA, L. P., Arquitetura de Sistemas Operacionais, 3a edio, Ed. LTC, 2002, Rio de Janeiro TANENBAUM, A., Sistemas Operacionais Modernos, 5a edio, Ed. Makron Books, 1999, Rio de Janeiro

33 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

13.

LISTA DE EXERCCIOS 1. 2.
Defina o que uma aplicao concorrente e d um exemplo de sua utilizao. Considere uma aplicao que utilize uma matriz na memria principal para a comunicao entre vrios processos concorrentes. Que tipo de problema pode ocorrer quando dois ou mais processos acessam uma mesma posio da matriz?

3. 4.

O que excluso mtua e como implementada? Como seria possvel resolver os problemas decorrentes do compartilhamento da matriz, apresentada anteriormente, utilizando o conceito de excluso mtua?

5. 6.

O que starvation e como podemos solucionar esse problema? Qual o problema com a soluo que desabilita as interrupes para implementar a excluso mtua?

7. 8.

O que espera ocupada e qual o seu problema? Explique o que sincronizao condicional e d um exemplo de sua utilizao?

9.

Explique o que so semforos e d dois exemplos de sua utilizao: um para a soluo da excluso mtua e outro para a sincronizao condicional.

10.

Explique o que so monitores e d dois exemplos de sua utilizao: um para a soluo da excluso mtua e outro para a sincronizao condicional.

11.

Qual a vantagem da trocas de mensagens assncronas e como pode estar implementada?

12.

Em uma aplicao concorrente que controla saldo bancrio em contascorrentes, dois processos compartilham uma regio de memria onde esto armazenados os saldos dos clientes A e B. Os processos executam concorrentemente os seguintes passos: Processo 1 (Cliente A) /* saque em A */ 1a. x := saldo_do_cliente_A; 1b. x := x 200; 1c. saldo_do_cliente_A := x; /* deposito em B */ Processo 2 (Cliente B) /* saque em A */ 2a. y := saldo_do_cliente_A; 2b. y := y 100; 2c. saldo_do_cliente_A := y; /* deposito em B */
34 de 36

SISTEMAS OPERACIONAIS NOTAS DE AULA

1d. x := saldo_do_cliente_B; 2d. y := saldo_do_cliente_B; 1e. x := x + 100; 2e. y := y + 200; 1f. saldo_do_cliente_B := x; 2f. saldo_do_cliente_B := y; Supondo que os valores dos saldos de A e B sejam, respectivamente, 500 e 900, antes de os processos executarem pede-se:
a.

Quais os valores corretos esperados para os saldos dos clientes A e B aps o trmino da execuo dos processos? Quais os valores finais dos saldos dos clientes se a seqncia temporal de execuo das operaes for: 1a, 2a, 1b, 2b, 1c, 2c, 1d, 2d, 1e, 2e, 1f, 2f? Utilizando semforos, proponha uma soluo que garanta a integridade dos saldos e permita o maior compartilhamento possvel dos recursos entre os processos, no esquecendo a especificao da inicializao dos semforos.

b.

c.

13.

O problema dos leitores/escritores, apresentado a seguir, consiste em sincronizar processos que consultam/atualizam dados em uma base comum. Pode haver mais de um leitor lendo ao mesmo tempo; no entanto, enquanto um escritor est atualizando a base, nenhum outro processo pode ter acesso a ela. VAR Acesso: Semaforo := 1; Excluso: Semforo := 1; Nleitores: integer := 0; PROCEDURE Escritor; BEGIN ProduzDado; DOWN (Acesso); Escreve; UP (Acesso); END; PROCEDURE Leitor; BEGIN DOWN (Excluso); Nleitores := Nleitores + 1; IF (Nleitores = 1) THEN DOWN (Acesso); UP (Exclusao); Leitura; DOWN (Exclusa); Nleitores := Nleitores 1; IF (Nleitores = 0) THEN UP (Acesso); UP (Exclusao); ProcessaDado; END;
a.

Suponha que exista apenas um leitor fazendo acesso base. Enquanto esse processo realiza a leitura, quais os valores das trs variveis? Chega um escritor enquanto o leitor ainda est lendo. Quais os valores das trs variveis aps o bloqueio do escritor? Sobre qual(is) semforo(s) se d o bloqueio?
35 de 36

b.

SISTEMAS OPERACIONAIS NOTAS DE AULA

c.

Chega mais um leitor enquanto o primeiro ainda no acabou de ler e o escritor est bloqueado. Descreva os valores das trs variveis quando o segundo leitor inicia a leitura.

d.

Os dois leitores terminam simultaneamente a leitura. possvel haver problemas quanto integridade do valor da varivel Nleitores? Justifique. Descreva o que acontece com o escritor quando os dois leitores terminam suas leituras. Descreva os valores das trs variveis quando o escritor inicia a escrita. Enquanto o escritor est atualizando a base, chegam mais um escritor e mais um leitor. Sobre qual(is) semforo(s) eles ficam bloqueados? Descreva os valores das trs variveis aps o bloqueio dos recm-chegados.

e.

f.

g.

Quando o escritor houver terminado a atualizao, possvel prever qual dos processos bloqueados (leitor ou escritor) ter acesso primeiro base? Descreva uma situao onde os escritores sofram starvation.

h.

36 de 36