Notas da Aula 5 - Fundamentos de Sistemas Operacionais

Transcrição

1 Notas da Aula 5 - Fundamentos de Sistemas Operacionais 1. Operações Atômicas Uma operação é dita atômica quando ela é indivisível no tempo. Em outras palavras, uma vez que a operação tenha sido iniciada, ela não pode ser interrompida. Desta forma, operações atômicas ou são totalmente executadas ou sequer iniciam sua execução. Um exemplo simples de operação atômica são as instruções de máquina. Se o processador identifica uma interrupção, a instrução sequer começar a ser executada. Por outro lado, se a instrução começa seu ciclo de execução, este será concluído antes que uma nova interrupção possa acontecer. A importância do conceito de operação atômica está no fato de que este tipo de operação pode efetivamente resolver o problema de condição de corrida. Se todo o código dentro de uma região crítica puder ser implementado como uma única operação atômica, então condições de corrida não são possíveis. Isso porque, por definição, um processo não poderia ser interrompido no meio de sua seção crítica. No pior caso, o processo seria interrompido imediatamente antes ou imediatamente depois da execução da região crítica. Isso só se aplica, no entanto, a sistemas com um único processador. Em máquinas multiprocessadas, cuidados extras precisam ser tomados. Porém, para o escopo desta disciplina, não iremos considerar o caso com múltiplos processadores. O problema da utilização de operações atômicas como solução para o problema da condição de corrida é que, em geral, as tarefas executadas dentro de uma seção crítica são muito complexas. Ou seja, na maioria dos casos, é inviável pensar em implementar uma única operação atômica (por exemplo, uma única operação de máquina) que faça tudo o que se deseja em uma seção crítica. Há, no entanto, uma maneira relativamente simples de simular a execução atômica do código de uma região crítica. A solução consiste em, imediatamente antes da primeira instrução da seção crítica, desabilitar as interrupções do processador. Em aulas anteriores, foi discutido que a instrução CLI faz exatamente isso. Uma vez desabilitadas as interrupções, o processo poderia executar sua região crítica sem a possibilidade de ser interrompido. Ao final da seção crítica, o processo pode habilitar novamente as interrupções para retornar o sistema ao estado normal. A instrução STI faz justamente isso. Infelizmente, esta solução traz uma série de problemas. Em primeiro lugar, as instruções CLI e STI são privilegiadas. Isso quer dizer que um processo de um usuário executando em modo usuário não poderia executar tais instruções. Ainda que, de alguma forma, o processo fosse capaz de desabilitar as interrupções, sem elas, o processo fica sem qualquer suporte do SO. Isso significa que qualquer operação de E/S efetuada dentro da região crítica precisaria ser completamente implementada pelo próprio código do processo. Há ainda a questão de possíveis falhas ou mesmo tentativas deliberadas de quebra de segurança por parte do

2 processo. O programador pode se esquecer de colocar uma chamada à instrução STI ao final da região crítica, o que faria com que o sistema nunca voltasse ao normal. Isto poderia ser feito também de maneira deliberada, para que o processo assumisse completamente o controle da máquina. Por fim, esta solução não funciona em máquinas multiprocessadas, já que cada processador tem suas próprias interrupções. Embora apresente uma série de desvantagens, o método de desabilitar interrupções é utilizado em alguns sistemas. Em sistemas embarcados, a simplicidade deste método acaba compensando suas desvantagens, especialmente quando se considera o fato de que os processos que rodam em tais sistemas são, em geral, conhecidos e confiáveis. 2. Exclusão Mútua Uma outra maneira de solucionar o problema da condição de corrida é a chamada exclusão mútua. Exclusão mútua é uma propriedade que diz que um determinado recurso (por exemplo, o acesso a uma região crítica) só pode ser concedido a um único processo por vez. Em outras palavras, se um processo A está atualmente dentro de uma região crítica, então um processo B que quer entrar na região terá que esperar que A saia. É importante notar que a exclusão mútua é diferente da operação atômica, no sentido de que um processo dentro da região crítica pode ser interrompido. Por exemplo, o processo A, atualmente dentro da seção crítica, pode ser interrompido e o processador pode ser dado a um processo C, que não tenha recursos compartilhados com A. O processador também pode ser passado para outros processos que compartilhem recursos com A, desde que eles não estejam atualmente tentando acessar a região crítica. Nestes casos, quando o processo A voltar ao processador, ele encontrará o recurso compartilhado exatamente no mesmo estado que havia deixado. Logo, não há condição de corrida. Deseja-se, portanto, criar um mecanismo capaz de prover exclusão mútua no acesso a uma região crítica. Para isso, existem alguns requisitos desejáveis de uma solução: 1. O mecanismo deve prover exclusão mútua. 2. O mecanismo não deve impedir que um processo acesse a região crítica, caso não haja outro processo atualmente nela. 3. O mecanismo não deve postergar indefinidamente a entrada de um processo na região crítica, em favor de outros processos. O primeiro requisito é obvio: o mecanismo deve funcionar corretamente. O segundo diz simplesmente que um processo não deve ficar travado do lado de fora de uma região crítica se não houver outro processo já a acessando. Este requisito tem relação com a eficiência da solução: se o mecanismo não garante esta propriedade, recursos do sistema podem ser desperdiçados em uma espera inútil. O terceiro requisito tem relação com um problema conhecido como starvation (às vezes chamado de esfomeação, em português). Suponha que existam vários processos constantemente tentando acessar a região crítica e que, para escolher um deles, o mecanismo de exclusão mútua simplesmente faça um sorteio.

3 Neste caso, é possível que um dado processo sempre perca o sorteio e fique eternamente esperando sua oportunidade. Este processo nunca acessará o recurso, sofrendo a condição de starvation. Além destes requisitos, é importante que uma solução não faça suposições sobre a ordem ou a velocidade de execução dos processos. Como discutido na Aula 4, este dois fatores são imprevisíveis. Os primeiros mecanismos criados para prover exclusão mútua foram os chamados Protocolos de Acesso. Estes protocolos nada mais são que pequenos trechos de código colocados antes e depois da região crítica para controlar a entrada dos processos. Uma característica interessante destes protocolos é que eles são totalmente baseados em software, não necessitando de nenhum suporte específico de hardware. O protocolo de acesso mais simples é o chamado Algoritmo de Alternância. Neste algoritmo, existe uma variável compartilhada entre os processos que indica qual processo tem a vez (para entrar na região crítica). O valor desta variável, chamada às vezes de turn, é inicializado para o identificador de um dos processos, arbitrariamente. Quando um processo tenta entrar região na região crítica, ele testa o valor da variável, verificando se ele tem a vez (se o valor da variável é igual ao seu identificador). Se a vez é do processo, ele prossegue para a região crítica. Senão, ele continua testando o valor da variável até que ela passe a conter o seu ID. Esta operação de ficar constantemente testando o valor de uma variável é conhecida como Espera Ocupada. Uma vez que um processo consiga entrar na região crítica, ele executa o código referente à manipulação do recurso da região e, ao final, altera o valor da variável turn, passando-a para outro processo. Embora a variável turn seja compartilhada, não há risco de condição de corrida na sua manipulação, pois um processo só altera seu valor se ele estiver dentro da região crítica. O algoritmo de alternância provê exclusão mútua. Porém, ele deixa de atender aos dois outros requisitos desejáveis. Suponha por exemplo que dois processos, 0 e 1, compartilhem um recurso e utilizem este algoritmo para prover exclusão mútua. Suponha ainda que a variável turn tenha valor inicial 1. Se, por algum motivo, o processo 0 chega à entrada da seção crítica muito antes do processo 1, ele não terá permissão para entrar, precisando esperar que o processo 1 chegue à seção e termine sua execução. Isto claramente infringe o segundo requisito. Além disso, existe a possibilidade do processo 1 jamais chegar à sua seção crítica. Neste caso, 0 ficará eternamente em estado de espera, sofrendo starvation. Um outro protocolo de acesso proposto mais tarde corrigiu estes problemas. Este protocolo, chamado de Algoritmo de Peterson, inseriu uma nova variável que indica a intenção de um processo em utilizar a região crítica. Suponha novamente o caso com dois processos, 0 e 1. O primeiro processo a chegar à entrada da região crítica, digamos o processo 0, irá configurar sua variável de intenção para 1. Em seguida, o processo 0 passará a vez para o processo 1. O próximo passo para o processo 0 é testar se o processo 1 tem a intenção de entrar na região

4 crítica e se tem também a vez. Caso ambas as condições sejam verdadeiras, o processo 0 realiza uma espera ocupada até que o processo 1 termine a seção crítica e reconfigure sua intenção para 0. A chave para o funcionamento correto do Algoritmo de Peterson está no fato dos processos que querem entrar na região crítica abdicarem da preferência, passando a vez para os outros processos. Uma demonstração formal de que este algoritmo não sofre de condição de corrida nas suas próprias variáveis de controle é razoavelmente complexa e está fora do escopo desta disciplina. Mas é importante notar que, ao contrário do Algoritmo de Alternância, no Algoritmo de Peterson um processo não fica travado, tentando entrar na região crítica se os demais processos não manifestaram interesse em usá-la. Logo, o algoritmo atende ao segundo requisito. Além disso, este sistema de abdicar da preferência em favor dos demais processos, se implementado corretamente, impede a ocorrência de starvation. Embora o Algoritmo de Peterson (e outros protocolos de acesso) resolva o problema da exclusão mútua atendendo aos requisitos desejáveis, ele é bastante complexo, especialmente quando se trabalha com mais de dois processos. Os protocolos de acesso também apresentam uma ineficiência, por conta de realizarem espera ocupada, aguardando que as condições para entrada na região crítica se tornem verdadeiras. Por esta razão, novas soluções foram criadas para o problema da exclusão mútua. 3. Soluções com Suporte do Hardware Para tornar mais eficientes e simples os mecanismos de exclusão mútua, foram criados alguns recursos de hardware. O mecanismo mais simples a utilizar tais recursos são os Spin-locks. Um spin-lock, intuitivamente, é uma variável compartilhada, chamada lock, que diz se a região crítica está trancada (pois já há um processo dentro dela) ou aberta (pois não há nenhum processo lá). Quando um processo deseja entrar na região crítica, ele realiza uma espera ocupada, aguardando que a variável de lock se torne 0 (ou seja, a região crítica está aberta). Uma vez que isso ocorra, o processo configura a variável lock para 1, indicando que agora a seção crítica está fechada e prossegue com a execução do código da seção. Ao final da seção crítica, o processo coloca de novo o valor da variável de lock para 0, permitindo o acesso de outros processos. Embora simples, esta ideia apresenta um defeito fundamental. A própria variável lock, compartilhada pelos vários processos, pode sofrer condição de corrida. Isso ocorre porque a operação de testar o valor de lock e configurar este valor para 1 (caso lock anteriomente seja 0) pode ser interrompida. Esta operação, em assembly, é traduzida para algo como: 1: MOV acc, lock ; Traz o valor de lock da memória para um registrador. 2: TST acc ; Verifica se lock (agora no acumulador) é 0. 3: JNZ 1 ; Volta ao início, se não for. 4: MOV lock, 1 ; Escreve 1 na posição de memória de lock.

5 Suponha que, em um dado momento, lock seja 0. Um processo A, então, começa a execução das instruções acima. No entanto, logo após a execução da primeira instrução (que traz o valor de lock para um registrador), o processo A é retirado do processador. Em seu lugar, entra o processo B que também deseja entrar na região crítica. Quando o processo B executa a instrução 1, o valor trazido da memória para o acumulador é 0, pois o processo A não teve a oportunidade de alterar o valor de lock. Portanto, B verifica que a região crítica está aberta, altera o valor de lock para 1 e entra na região. Suponha que no meio do seu processamento dentro da região, o processo B é retirado do processador e substituído pelo processo A. O processo A continua sua execução do exato ponto no qual havia parado e com exatamente os mesmos valores de registradores (lembre-se que ao retirar um processo do processador, o SO salva o contexto do processo, incluindo valores de todos os registradores, para posterior recuperação). Logo, quando o processo A executar a segunda instrução, o valor do acumulador será 0 (valor antigo de lock). Com isso, o processo A entenderá que a seção crítica está aberta, quando na verdade não está. Este problema ocorre porque, entre a instrução 1, que traz o valor de lock para o acumulador, e a instrução 4, que altera o valor de lock, o processo pode ser interrompido e substituído por outro que também tenta acessar a seção crítica. Se houvesse uma maneira de impedir que isso aconteça, a variável lock funcionaria. Para solucionar este problema, os processadores mais modernos passaram a contar com uma ou mais instruções que deram esta capacidade aos programadores. Existem vários nomes para este tipo de instrução, como Test-and-Set-Lock, Swap e Compare-on-Store. Todas elas, no entanto, podem ser utilizadas para a implementação dos spin-locks. Vamos considerar, então, a instrução Swap (SWP). Esta instrução recebe dois argumentos: um endereço de memória (da variável lock) e um registrador. Quando esta instrução é executada, ela troca os valores do registrador e da posição de memória. Em outras palavras, o registrador passa a conter o valor da variável, enquanto a variável passa a conter o valor do registrador. Como se trata de uma única instrução de máquina, esta operação é atômica. Ou seja, não pode ser interrompida. Com esta instrução disponível, a implementação de um spin-lock se torna simples: // Tentar entrar na seção crítica. do { reg = 1; swap(reg, lock); } while(reg == 1); // Início da Seção Crítica... // Fim da Seção Crítica. lock = 0;

6 A repetição antes da seção crítica inicialmente configura o valor de um registrador para 1. Em seguida, a instrução SWP é chamada, trocando os valores do registrador e da variável lock. Finalmente, o valor do registrador (valor que estava no variável lock) é testado. Repare que o código sempre escreve 1 na variável lock (através da instrução swap). Existem, portanto, dois casos: 1. A variável lock continha o valor A variável lock continha o valor 1. Se o valor de lock antes da instrução Swap era 1, seu valor continua sendo 1, assim como o registrador reg. Eventualmente, o processo testará o valor do registrador e irá verificar que a seção está fechada. Se o valor de lock era 0, seu valor passa a ser 1. Ou seja, em uma única instrução de máquina, o processo está trazendo o valor de lock para um registrador (que não pode ser alterado por outros processos) e está fechando a seção crítica para outros processos. Eventualmente, o valor de reg será testado e o processo perceberá que pode entrar na seção crítica. É interessante notar que, neste caso, o processo fecha a seção crítica antes mesmo de saber que ela pode ser utilizada. Embora os spin-locks garantam exclusão mútua, eles não atendem ao terceiro requisito desejável. Dependendo da ordem de execução dos processos, é possível que um processo seja indefinidamente preterido (sempre que um processo sai da região crítica, o SO coloca outro processo antes, que ganha acesso à região primeiro). Ou seja, os spin-locks podem resultar em starvation. Além disso, os spin-locks também utilizam espera ocupada, o que é um desperdício de tempo do processador. Diante destas limitações dos spin-locks, surgiu o conceito de Semáforo. Um semáforo é um tipo especial de dados, composto por um valor inteiro e uma fila de processos. Este tipo de dados aceita duas operações básicas: 1. P(S), também conhecida como down(s): decrementa o valor inteiro do semáforo S e verifica se o resultado é menor que 0. Caso seja, o processo é bloqueado e colocado na fila de processos de S. 2. V(S), também conhecida como up(s): incrementa o valor inteiro do semáforo S e verifica se há processos bloqueados na fila de S. Se houver, desbloqueia o primeiro semáforo da fila. Ambas as operações são implementadas pelo SO. No caso da operação P(S), por exemplo, se o valor inteiro do semáforo é negativo, o SO remove o processo atual do processador, coloca este processo no estado bloqueado e insere uma referência para este processo na fila de processos de S. Dadas as funcionalidades de um semáforo, a exclusão mútua é facilmente obtida. Supondo que um semáforo S tenha sido inicializado com 1 (no caso, seu valor inteiro), basta que, antes de

7 acessar a região crítica, o processo execute um P(S). Se este for o primeiro processo a chegar à região crítica, o valor do semáforo passará a ser 0 e o processo não será bloqueado. A partir deste momento, outros procesos que cheguem à seção executarão P(S) e ficarão bloqueados. Quando o primeiro processo terminar a execução da sua seção crítica, ele deve executar um V(S), incrementando o semáforo e liberando o primeiro processo da fila de S. Note que o valor inteiro de um semáforo representa (em módulo) a quantidade de processos bloqueados na fila. Quando eventualmente todos os processos conseguem acessar a região crítica, o valor inteiro do semáforo passa a ser novamente o valor inicial 1. Semáforos podem também ser usados para sincronização entre processos. Suponha que, em um determinado programa concorrente, um processo A só pode executar uma certa parte do código após um processo B ter terminado um certo trecho da sua execução. Isso pode ocorrer, por exemplo, se A depende do resultado de uma computação de B para realizar a sua própria tarefa. Neste caso, pode-se inicializar um semáforo S com o valor 0. Quando o processo A chega ao ponto do código no qual deve esperar por B, ele executa P(S). Se o valor do semáforo ainda é 0, A será bloqueado. Quando eventualmente B termina o trecho de código do qual A depende, ele executa V(S), liberando A. Note que, se por algum motivo, o processo B executa V(S) antes do processo A executar P(S), o valor do semáforo passará a ser 1, fazendo com que P(S) não bloqueie A. O semáforo discutido até aqui é chamado de Semáforo Contador, por causa da capacidade de contagem do seu valor inteiro. Alguns sistemas, no entanto, fornecem um tipo ligeiramente diferente de semáforo, chamado Semáforo Mutex. A diferença de um mutex para um contador está no fato de que o valor inteiro de um mutex só pode assumir dois valores, 0 ou 1. Quando um processo faz um P(S) em um semáforo S cujo contador está em 0, o processo é bloqueado, mas o valor do semáforo não é decrementado. De forma análoga, quando um processo executa um V(S) em um semáforo S cujo contador está em 1, a operação não tem efeito algum (o valor não pode ser incrementado e não há processos na fila). Semáforos do tipo mutex podem ser mais simples de implementar e são suficientes para as duas funcionalidades vistas até aqui: exclusão mútua e sincronização. Entretanto, semáforos contadores são capazes de uma funcionalidade específica impossível para os semáforos mutex. Suponha uma implementação do problema do Produtor-Consumidor na qual o buffer circular tem capacidade para armazenar 10 dados. Um produtor não pode tentar inserir um dado no buffer, caso não haja posições disponíveis. Um consumidor, por outro lado, não pode tentar ler dados do buffer caso este esteja vazio. Esta coordenação pode ser feita através de dois semáforos contadores. Um dos semáforos, chamado vagas, é inicalizado com 10, representando que há inicialmente 10 posições vagas no buffer circular. Toda vez que um processo produtor tenta inserir um valor no buffer, ele primeiramente tenta realizar um P(vagas). Se ainda há vagas no buffer, o processo não será bloqueado e fará a inserção. Caso contrário, o valor inteiro do semáforo vagas será menor ou igual a 0, e o processo será bloqueado e colocado na fila de espera.

8 De forma análoga, existe um segundo semáforo chamado dados, inicialmente com o valor 0, representando que não há dados a serem consumidos no momento. Quando um consumidor tenta ler um dado do buffer, ele inicialmente executa um P(dados). Se o valor inteiro do semáforo dados é 0, o processo consumidor ficará bloqueado. Caso contrário, o processo seguirá em frente, realizando a remoção do próximo dado do buffer, e decrementando o valor do semáforo dados. Quando um produtor termina de inserir um dado no buffer, ele executa um V(dados), que incrementa o valor do semáforo dados e desbloqueia processos consumidores que estejam esperando. Da mesma forma, quando um consumidor remove um dado do buffer, ele executa um V(vagas), indicando aos produtores que há uma nova vaga livre no buffer. Note que o acesso efetivo a estrutura de dados do buffer ainda precisa ser protegido por um semáforo para exclusão mútua. Este terceiro semáforo pode ser um simples semáforo mutex. Os semáforos são soluções superiores às demais citadas, pois eles garantem todos os requisitos desejáveis. Não é possível haver starvation pois a fila de processos de um semáforo garante que a ordem de chegada é sempre respeitada. Os semáforos são também muito mais eficientes, pois não há espera ocupada: quando um processo fica preso após um P(S), ele é colocado imediatamente no estado bloqueado pelo SO, sem gastar tempo de uso do processador. Os semáforos podem ainda ser usados para outras funcionalidades além da exclusão mútua. Um detalhe sobre os semáforos, no entanto, é a maneira como eles são implementados. A variável que armazena a estrutura de dados de um semáforo precisa ser compartilhada entre os vários processos que desejam utilizá-lo. Como visto em relação aos spin-locks, isso pode fazer com que haja condição de corrida na própria manipulação dos semáforos. Desta forma, é preciso existir algum mecanismo para a implementação segura de semáforos. A implementação dos semáforos, em geral, é feita com spin-locks (por isso, semáforos, indiretamente, precisam de suporte do hardware). No entanto, nada impede que qualquer outro método de exclusão mútua seja utilizado para implementar as operações P e V. A pergunta, portanto, é: qual a vantagem dos semáforos, se eles acabam sendo implementados utilizando algum dos outros métodos de exclusão mútua, todos falhos? A resposta é que semáforos são implementados pelo SO e suas operações, P e V, são rápidas. Isso significa que os problemas enfrentados pelos outros métodos, como a espera ocupada e a possibilidade de starvation, são minimizados.