Sistemas Operacionais. Prof. André Y. Kusumoto

Transcrição

1 Sistemas Operacionais Prof. André Y. Kusumoto

2 Fundamentos Paradigma do produtor-consumidor Sincronização de Processos Produtor while (count == BUFFER_SIZE) ; //no-op //adiciona um item no buffer ++count; buffer[in] = item; in = (in + 1) % BUFFER_SIZE; Consumidor while (count == 0) ; //no-op --count; item = buffer[out]; out = (out + 1) % BUFFER_SIZE; As rotinas produtor e consumidor podem não funcionar corretamente quando forem executadas ao mesmo tempo. Porque os threads compartilham a mesma variável count (contador de itens no buffer) Ex. O valor atual da variável count seja 5, e que os threads produtor e consumidor executem as instruções ++count e -count de forma concorrente. Após a execução dessas duas intruções, o valor da variável count pode ser 4, 5 ou 6. 2/14

3 Sincronização de Processos O problema da seção crítica Como primeiro método para controlar o acesso a um recurso compartilhado, declaramos uma seção de código como sendo crítica; em seguida, controlamos o acesso a essa região. Considere um sistema que consista em n threads {T0, T1,..., Tn-1}. Cada thread tem um segmento de código, chamado região crítica, no qual o thread pode estar alterando variáveis comuns, atualizando uma tabela, gravando um arquivo, etc. Quando um thread estiver executando em sua região crítica, nenhum outro thread terá permissão de executar em sua seção crítica. Assim, a execução das seções críticas pelos threads é mutuamente exclusiva no tempo. 3/14

4 Sincronização de Processos Uma solução ao problema da seção crítica deve satisfazer os três requisitos seguintes: Exclusão mútua: se o thread Ti estiver executando em sua seção crítica, nenhum outro thread poderá estar executando em sua respectiva seção crítica. Progresso: nenhum processo executando fora da sua seção crítica pode impedir que outro processo entre na sua seção crítica. Espera limitada: nenhum processo pode esperar eternamente para entrar na sua seção crítica. Isso evita a starvation de qualquer thread único. 4/14

5 Semáforos Sincronização de Processos Um semáforo é uma estrutura de dados que consiste em um número inteiro e em uma fila Seu objetivo é coordenar o acesso a uma região crítica Um semáforo S é uma variável inteiro positiva sobre a qual os processos podem fazer duas operações primitivas (indivisíveis) - P(S) e V(S). P e V têm sua origem das palavras parsen (passar) e e vrygeren (liberar)). Cada semáforo tem uma fila associada a ele, onde processos bloqueados nele esperam. Quando um processo executa a operação P em um semáforo, o seu valor inteiro é decrementado. Caso o novo valor do semáforo seja negativo, o processo é bloqueado e ele vai pro fim da fila. Quando um processo executa a operação V, o seu valor inteiro é incrementado. Caso exista algum processo bloqueado na fila desse semáforo, o primeiro processo da fila é liberado. 5/14

6 Semáforos Sincronização de Processos Observe o funcionamento através do semáforo S: P(S): S.valor = S.valor - 1; Se S.valor < 0 V(S): Então bloqueia o processo, insere em S.fila S.valor = S.valor + 1; Se S.fila não está vazia Então retira processo P de S.fila, acorda P Operações P e V devem ser atômicas Para cada estrutura de dados compartilhada, deve ser criado um semáforo S inicializado com o valor 1. Todo processo, antes de acessar essa estrutura, deve executar um P(S). Ao sair da seção crítica, o processo executa V(S). 6/14

7 Sincronização de Processos Variações muito comuns de semáforos são as construções mutex ou semáforo binário. valores 0 e 1, livre e ocupado, lock e unlock. lock(x): Se x está livre Então -> marca x como ocupado Senão -> insere processo no fim da fila x unlock(x): Se fila x está vazia Então -> marca x como livre Senão -> libera processo do início da fila x 7/14

8 Problemas clássicos de sincronização Problema dos leitores-escritores Um banco de dados deve ser compartilhado entre vários threads concorrentes. Alguns desses threads talvez queiram apenas ler o banco de dados, enquanto outros talvez queiram atualiza-lo (ou seja, ler e gravar dados). Fazemos a distinção entre esses dois tipos de threads chamando os primeiros de leitores e os últimos de escritores. Obviamente, se dois leitores acessarem os dados compartilhados ao mesmo tempono entanto, se um escritor e algum outro thread (leitor ou escritor) acessar o banco de dados ao mesmo tempo, poderá haver confusão. Para evitar esse tipo de problema, os escritores deverão ter acesso exclusivo ao banco de dados compartilhado. Esse requisito leva ao problema dos leitores-escritores. 8/14

9 Problemas clássicos de sincronização Problema dos leitores-escritores Um sistema de reserva de passagens aéreas é um bom exemplo. Os leitores são aqueles que apenas lêem as informações, sem alterá-las Os escritores são aqueles que desejam reservar um lugar em determinado vôo. O sistema não poder permitir que alguém escreva enquanto outra pessoa esteja lendo (ou escrevendo). Portanto, é preciso implementar uma política de exclusão mútua. Uma solução trivial para esse problema consistiria em proteger o acesso à área compartilhada com um semáforo inicializado em 1 Essa solução deixa a desejar em termos de desempenho, porque restringe desnecessariamente o acesso dos leitores à área compartilhada. A utilização de priorização de leitores pode resultar no abandono dos escritores, quanto que a priorização de escritores pode resultar no abandono dos leitores. 9/14

10 Problemas clássicos de sincronização Procurando evitar esse tipo de ocorrência, foi proposta uma combinação de prioridades. Assim que um escritor termina, todos os leitores em espera recebem permissão para execução. Em seguida, assim que o grupo de leitores termina, o escritor que está esperando pode começar, e nenhum dos novos leitores que chegaram poderá começar até que o escritor termine. 10/14

11 Problemas clássicos de sincronização Problema do Jantar dos Filósofos Considere cinco filósofos que passam suas vidas meditando e comendo. Os filósofos compartilham uma mesa redonda comum cercada por cinco cadeiras, cada qual pertence a um filósofo. No centro da mesa, está uma tigela de arroz, e a mesa está posta com cinco pauzinhos (hashi). Quando um filósofo medita, não interage com seus colegas. De vez em quando, um dos filósofos fica com fome e tenta pegar os dois pauzinhos mais próximos de si (os pauzinhos que estão entre ele e seus colegas da esquerda e da direita). Um filósofo só pode pegar um pauzinho de cada vez. Obviamente, não poderá pegar um que já esteja na mão de um colega. Quando o filósofo com fome está de posse dos dois pauzinhos ao mesmo tempo, ele poderá comer sem soltá-los. Quando termina de comer, o filósofo solta os pauzinhos e volta a meditar. O problema do jantar dos filósofos é considerado um problema clássico de sincronização. 11/14

12 Problemas clássicos de sincronização Uma solução simples consiste em representar cada pauzinho por um semáforo. Um filósofo tenta agarrar o pauzinho executando uma operação P naquele semáforo; o filósofo solta o pauzinho executando a operação V. Essa solução deve ser rejeitada porque tem a possibilidade de criar um deadlock - todos os cinco filósofos fiquem com fome ao mesmo tempo, e cada um pegue o pauzinho à sua esquerda. Quando um filósofo tentar pegar o pauzinho a sua direita, ficará esperando para sempre. Várias soluções possíveis para o impasse são listadas a seguir. Essas soluções evitam o deadlock, impondo restrições aos filósofos: Permitir a presença de no máximo quatro filósofos ao mesmo tempo na mesa. Permitir que um filósofo pegue o seu pauzinho apenas se os dois pauzinhos estiverem disponíveis. Usar uma solução assimétrica; por exemplo, um filósofo impar pega primeiro o pauzinho a sua esquerda e depois o da sua direita, enquanto um filósofo par pega o da direita e depois o da esquerda. Qualquer solução satisfatória ao problema do jantar dos filósofos deverá evitar a possibilidade de um dos filósofos morrer de fome (starvation). 12/14

13 Sincronização de Processos Monitores Estruturas de sincronização de alto nível. Parecidos com classes Um monitor é um conjunto de procedimentos, variáveis e estruturas de dados, todas agrupadas juntas em um módulo especial. As implementações existentes de monitores fazem parte de algumas linguagens de programação. monitor Regiao_Critica; integer i; PROCEDURE produtor(x);.. end; PROCEDURE consumidor(x);.. end; end monitor; 13/14

14 Sincronização de Processos Os monitores têm uma propriedade muito importante que os torna úteis na implementação da exclusão mútua: somente um processo pode estar ativo dentro do monitor em um dado instante de tempo. Quando um procedimento chama um procedimento de um monitor, as primeiras instruções verificam se algum outro processo está ativo dentro dele. Se isto for verdade, o processo que chamou o procedimento do monitor será suspenso até que o outro processo deixe o monitor. Se não houver nenhum processo ativo dentro do monitor, o processo que chamou o procedimento do monitor poderá entrar e executar o procedimento chamado. 14/14