Sistemas Operacionais

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
*
		Sistemas Operacionais
*
*
Sistemas Multiprogramáveis
Os sistemas multiprogramáveis surgiram na década de 60, passou a ser possível estruturar aplicações de maneira que partes diferentes do código do programa pudessem executar concorrentemente.
Este tipo de aplicação, denominada aplicação concorrente, tem como base a execução cooperativa de múltiplos processos ou threads, que trabalham em uma mesma tarefa na busca de um resultado comum.
*
*
Sistemas Multiprogramáveis
Em sistemas multiprogramáveis com um único processador, os processos alternam sua execução segundo critérios de escalonamento estabelecidos pelo Sistema Operacional, mesmo não havendo paralelismo na execução das instruções, ocorre significativo ganho de desempenho.
Em sistemas multiprocessados, as vantagens são ainda maiores graças a possibilidade de paralelismo na execução das instruções.
*
*
Sistemas Multiprogramáveis
É natural que processos de uma aplicação concorrente compartilhem
recursos do sistema, como arquivos, registros, dispositivos de E/S e áreas de memória.
O compartilhamento de recursos entre os processos pode ocasionar situações indesejáveis, capazes até de comprometer a execução das aplicações.
*
*
Comunicação e Sincronização
Muitas vezes, em uma aplicação concorrente, é necessário que processos comuniquem-se entre si, e essa comunicação pode ser implementada de diversos mecanismos, como variáveis compartilhadas na memória principal ou troca de mensagens.
Nesta situação, é necessário que os processos tenham sua execução
sincronizada pelo sistema
operacional.
*
*
Comunicação e Sincronização
Por exemplo, podemos ter dois processos concorrentes compartilhando um buffer para trocar informações através de operações de gravação e leitura, onde ambos os processos necessitam aguardar que o buffer esteja pronto.
*
*
Comunicação e Sincronização
Para cooperar, processos precisam se comunicar e se sincronizar. Mas cada um dos processos podem ser executados com velocidades diferentes.
*
*
Problemas de Compartilhamento de Recurso
Alguns problemas que podem ocorrer devido à falha na sincronização entre processos concorrentes.
Primeiro exemplo é o problema do programa Conta_Corrente, que atualiza o saldo bancário de um cliente após um lançamento de débito ou crédito noarquivo de contas-correntes Arq_Contas.
*
*
Problemas de Compartilhamento
de
Recurso
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.
*
*
Problemas de Simultaneidade
Considerando processos concorrentes pertencentes a dois funcionários do banco (caixas), que atualizam o saldo de um mesmo cliente simultaneamente, a situação de compartilhamento do recurso pode ser analisada.
Supondo que o primeiro caixa irá ler o saldo do cliente e adicionar o valor de um lançamento.
Neste mesmo instante outro caixa irá efetuar uma outra operação de atualização no saldo do mesmo cliente, realizando outro lançamento.
Independentemente de qual dos atualize primeiro o saldo no arquivo, o dado gravado estará inconsistente!
*
*
Problemas de Simultaneidade
*
*
Condições de Corrida
Analisando o exemplo apresentado, é possível concluir que em
qualquer situação, onde dois ou mais processos compartilham um mesmo recurso, devem existir mecanismos de controle para evitar esses tipos de problemas, conhecidos como condições de corrida (race conditions ).
Ocorre quando?
Quando processos estão lendo ou escrevendo dados compartilhados e o
resultado final depende de qual processo executa e quando (em que ordem)
este executa.
*
*
Exclusão Mútua
A solução mais simples para evitar os problemas de compartilhamento apresentados é impedir que dois ou mais processos acessem um mesmo recurso simultaneamente.
Para isso, enquanto um processo estiver acessando determinado recurso, todos os demais processos que queiram acessá-lo deverão esperar pelo término da utilização do recurso.
Essa idéia de exclusividade de acesso é chamada de exclusão mútua (mutual exclusion).
*
*
Regiões Críticas
A exclusão mútua deve afetar apenas os processos concorrentes somente quando um deles estiver fazendo acesso ao recurso compartilhado.
A parte do código do programa onde é feito o acesso ao recurso compartilhado é denominada região crítica (critical region).
Se for possível evitar que dois processos entre em suas regiões críticas ao mesmo tempo, ou seja, se for garantida a execução mutuamente exclusiva das regiões críticas, os problemas decorrentes do compartilhamento serão evitados.
*
*
Regiões Críticas
Os mecanismos que implementam a exclusão mútua utilizam protocolos de acesso à região crítica.
Toda vez que um processo desejar executar uma instrução de sua região crítica, deverá obrigatoriamente executar antes um protocolo de entrada nesta região.
Da mesma forma, ao sair da região crítica um protocolo de saída deverá ser executado.
Estes protocolos garantem a exclusão mútua da região crítica do programa.
*
*
Regiões
Críticas
BEGIN
.
.
Entra_Na_Regiao_Crítica;
/*
protocolo de entrada */
Regiao_Crítica;
/* operações executadas */
Sai_Da_Regiao_Crítica;
.
.
END.
/* protocolo de saída */
*
*
Espera Indefinida
Estas soluções propostas para o acesso sincronizado devem garantir a exclusão mútua e também evitar que duas outras situações indesejadas ocorram.
A primeira situação indesejada é conhecida como espera indefinida (starvation).
Starvation é a situação em que um processo nunca consegue executar sua região crítica e, consequentemente, acessar o recurso compartilhado.
Quando um determinado recurso é liberado, o Sistema Operacional irá selecionar qual será o próximo processo que fará uso do mesmo.
*
*
Espera Indefinida
Este critério de escolha poderá ocasionar uma espera indefinida, quando for utilizado critério baseado em escolha aleatória ou em função da prioridade do processo (processos de baixa prioridade serão prejudicados).
A solução é implementar uma fila, através do esquema FIFO, garantindo que todos os processos que necessitem do recurso façam seu uso em algum momento.
Outra situação indesejável é quando um processo fora de sua região crítica impede que outros processos entrem em suas próprias regiões críticas.
Isto ocorre devido ao fato do recurso estar livre, porém ainda alocado a um processo, impedindo que os demais utilizem o recurso.
*
*
Mecanismos de Sincronização
Sincronização Condicional
Entre os mecanismos de sincronização, a sincronização condicional é uma situação onde o acesso ao recurso compartilhado exige a sincronização de processos vinculada a uma condição de acesso.
Um recurso pode não se encontrar pronto para uso devido a uma condição específica.
Nesse caso, o processo que deseja acessá-lo deverá permanecer bloqueado até que o recurso fique disponível.
*
*
Mecanismos de Sincronização
Um exemplo clássico desse tipo de sincronização é a comunicação entre dois processos através de operações de gravação e leitura em um buffer, onde os processos que geram informações (processos produtores) utilizadas por outros processos (processos consumidores).
*
*
Mecanismos de Sincronização
Nessa comunicação, enquanto um processo grava dados em um buffer, o outro lê os dados, concorrentemente.
Os processos envolvidos devem estar sincronizados a uma variável de condição, de forma que um processo não tente gravar dados em um buffer cheio ou realizar uma leitura em um buffer vazio.
Este problema sincronização é conhecido como problema do produtor / consumidor ou do buffer limitado.
*
*
Mecanismos de Sincronização
Semáforos
O conceito de semáforos foi proposto por E. W. Dijkstra em 1965, sendo
apresentado como um mecanismo de sincronização que permitia implementar, de forma simples, a exclusão mútua e sincronização
condicional entre processos.
De fato, o uso de semáforos tornou-se um dos principais mecanismos utilizados em projetos de sistemas operacionais e em aplicações concorrentes.
Um semáforo é uma variável inteira, não-negativa, que só pode ser manipulada por duas instruções: DOWN e UP,
Estas instruções são indivisíveis, isto é, não pode ser interrompida.
*
*
Mecanismos de Sincronização
Semáforos são classificados em dois tipos:
- Semáforos binários: chamados de mutexes (mutual exclusion semaphores), só podem assumir valores 0 e 1.
Permitem a implementação da exclusão mútua e são utilizados nos casos onde a sincronização condicional é exigida.
- Semáforos contadores: podem assumir qualquer valor inteiro positivo, além do 0.
Semáforos contadores são úteis quando aplicados em problemas de sincronização condicional onde existem processo concorrentes alocando recursos do mesmo tipo.
*
*
Mecanismos de Sincronização
*
*
Mecanismos de Sincronização
Monitores
São mecanismos de sincronização de alto nível que tornam mais simples desenvolvimento de aplicações concorrentes.
o
O conceito de monitores foi proposto , como um mecanismo de sincronização estruturado, ao contrário dos semáforos, que são considerados não-estruturados.
Estes mecanismos são alto nível e estruturados em função de serem implementados pelo compilador, possibilitando que o desenvolvimento de programas concorrentes fique mais fácil e com chances menores de erros.
O monitor é formado por procedimentos e variáveis encapsulados dentro de um módulo, implementando de forma automática a exclusão mútua entre os procedimentos declarados.
*
*
Mecanismos de Sincronização
Toda vez que algum processo faz uma chamada a um procedimento, o monitor verifica se já existe outro processo executando algum procedimento do monitor.
Caso exista, o processo ficará aguardando a sua vez em uma fila de entrada.
A implementação da exclusão mútua via monitores não é implementada
diretamente pelo programador, assim como no caso do uso dos semáforos, o próprio compilador encarrega-se de garantir a exclusão mútua entre os procedimentos previamente definidos.
*
*
Mecanismos de Sincronização
*
*
Mecanismos de Sincronização
Troca de Mensagens
Também é um mecanismo de comunicação e sincronização entre processos.
O sistema operacional possui um subsistema de mensagens que suporta esse mecanismo sem que haja a necessidade do uso de variáveis compartilhadas.
Para que ocorra a comunicação entre os processos, deve existir um canal de comunicação, podendo esse meio ser um buffer ou um link de uma rede de computadores.
*
*
Mecanismos de Sincronização
Os processos cooperativos podem fazer uso de um buffer para trocar mensagens através de duas rotinas: SEND (transmissor, mensagem) e RECEIVE (receptor, 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.
*
*
Mecanismos de Sincronização
.
O mecanismo de troca de mensagens exige que os processos envolvidos na comunicação tenham suas execuções sincronizadas
A troca de mensagens entre os processos pode ser implementada de duas maneiras distintas: comunicação direta e comunicação indireta.
Comunicação direta entre dois processos exige que, ao enviar ou receber uma mensagem, o processo enderece explicitamente o nome do processo receptor ou transmissor.
Uma característica deste tipo de comunicação é só permitir a troca de mensagem entre dois processos.
*
*
Mecanismos de Sincronização
A comunicação 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 características, como identificação e capacidade de armazenamento de mensagens, são definidas no momento de criação.
Na comunicação indireta, vários processos podem estar associados a mailbox, e os parâmetros dos procedimentos SEND e RECEIVE passam a ser nomes de mailboxes e não mais nomes de processos.
*
*
Deadlock
Deadlock ( espera circular )é a situação em que um processo aguarda por um recurso que nunca estará disponível ou um evento que nunca ocorrerá.
Essa situação é consequência, na maioria das vezes, do compartilhamento de recursos, como dispositivos, arquivos e registros, entre processos recorrentes onde a exclusão mútua é exigida.
*
*
Deadlock
Para que ocorra a situação de deadlock, 4 condições são necessárias simultaneamente:
1 – Exclusão mútua: cada recurso só pode estar alocado a um único processo em um determinado instante;
2 – Espera por recurso: um processo, além dos recursos já alocados, pode estar esperando por outros recursos;
3 – Não-preempção: um recurso não pode ser liberado de um processo só porque outros processos desejam o mesmo recurso;
4 – Espera circular: um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa.
Problemas de deadlock existem em qualquer sistema multiprogramável e as soluções implementadas devem considerar o tipo do sistema e o impacto em seu desempenho.
*
*
Deadlock - Prevenção
Como vimos, para que um deadlock ocorra, todas as quatro condições listadas devem ocorrer simultaneamente.
Isto quer dizer que se garantirmos que somente uma delas não possa ocorrer, estaremos prevenindo a ocorrência de deadlocks em um determinado sistema.
*
*
Deadlock - Prevenção
Examinemos as quatro condições separadamente:
1 - Negando a Condição de Exclusão Mútua
Conforme já foi visto, a condição de exclusão mútua não deve ser negada, pois dois processos acessando um recurso simultaneamente poderiam levar o sistema a uma situação de caos.
Imagine o exemplo de dois processos acessandouma mesma impressora ao mesmo tempo!
Uma solução é utilizar um sistema de spool, onde um único processo de spool acessa a impressora diretamente, e não acessa nenhum outro recurso. Uma vez que os processos não imprimem diretamente, e o processo de spool acessa somente o recurso impressora, deadlocks não podem ocorrer.
O problema é que nem todos os recursos podem ser alocados via spooling.
*
*
Deadlock - Prevenção
2
- Negando a Condição “Esperar por Recurso (Hold and Wait)
A primeira estratégia requer que todos os recursos que um processo precise devem ser requisitados de uma só vez.
O sistema deve liberar os recursos segundo uma política “tudo ou nada”. Se todos os recursos que o processo requisitou estão disponíveis, então o sistema pode alocá-los todos de uma vez ao processo, que poderá prosseguir.
Se, por outro lado, nem todos os recursos requisitados estão disponíveis, então o processo deve esperar até que todos eles estejam disponíveis. Enquanto o processo espera, entretanto, ele não deve deter nenhum recurso.
Esta solução parece ser boa, mas pode levar a um sério desperdício de recursos.
Outro problema é a possibilidade de um processo requisitando todos os seus recursos de uma só vez ficar indefinidamente esperando.
*
*
Deadlock - Prevenção
3
- Negando a Condição “Não-Preempção” (No Preemption)
Negar a condição de “não-preempção” é uma estratégia ainda pior do que a anterior.
Para vários recursos, como uma impressora, não é interessante que um processo os perca durante seu uso.
*
*
Deadlock - Prevenção
4
- Negando a Condição “Espera Circular” (Circular Wait)
A condição “circular wait” pode ser eliminada de várias formas.
Uma maneira é simplesmente estabelecer uma regra que diga que um processo só pode alocar um único recurso em um dado momento. Se ele precisa de um segundo recurso, deve liberar o primeiro.
Para um processo que necessita copiar um arquivo muito grande para uma impressora (o processo de spooling, por exemplo), isto é inaceitável.
Uma estratégia melhor seria que todos os recursos devem ser numerados em ordem crescente.
Assim, processos
podem requisitar recursos sempre que quiserem, mas todas as requisições devem ser em ordem crescente de numeração.
*
*
Deadlock - Prevenção
4
- Negando a Condição “Espera Circular” (Circular Wait)
A condição “circular wait” pode ser eliminada de várias formas.
Uma maneira é simplesmente estabelecer uma regra que diga que um processo só pode alocar um único recurso em um dado momento. Se ele precisa de um segundo recurso, deve liberar oprimeiro.
Para um processo que necessita copiar um arquivo muito grande para uma impressora (o processo de spooling, por exemplo), isto é inaceitável.
Uma estratégia melhor seria que todos os recursos devem ser numerados em ordem crescente.
Assim, processos podem requisitar recursos sempre que quiserem, mas todas as requisições devem ser em ordem crescente de numeração.