Sistemas Operacionais Bloqueios Perpétuos

Transcrição

1 Sistemas Operacionais loqueios Perpétuos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFM 9 de agosto de Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

2 genda Introdução aos loqueios Perpétuos Tratamento de loqueios Perpétuos Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

3 Introdução aos loqueios Perpétuos Introdução aos loqueios Perpétuos Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 3 / 35

4 Introdução aos loqueios Perpétuos Definições Um conjunto de processos estará em situação de bloqueio perpétuo se todo processo pertencente ao conjunto estiver esperando por um evento que somente um outro processo desse mesmo conjunto poderá fazer acontecer; Estes processos esperam por eventos que jamais ocorrerão; Não está restrito a dispositivos de E/S: pode ocorrer tanto em alocações de recursos tanto de hardware quanto de software (ex: banco de dados: travamento (lock) de registro) ou até mesmo sem envolver recursos diretamente (ex. uso de semáforos); Já a postergação indefinida (ou indefinite postponement starvation) ocorre quando um processo espera por um evento que pode nunca ocorrer. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 4 / 35

5 Introdução aos loqueios Perpétuos Exemplo de loqueio Perpétuo R R Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 5 / 35

6 Introdução aos loqueios Perpétuos Postergação Indefinida Em qualquer sistema que mantém os processos aguardando enquanto decisões sobre escalonamento de processos e recursos são tomadas, permite que um processo seja indefinidamente postergado, enquanto outros processos recebem a atenção do sistema. postergação indefinida pode ser evitada com a poĺıtica de alocação primeiro a chegar, primeiro a ser servido; Em alguns sistemas, aumenta-se a prioridade do processo à medida que ele espera por recursos. Isso é chamado de aging. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 6 / 35

7 Introdução aos loqueios Perpétuos ondições Necessárias para a Ocorrência de loqueio Perpétuo ondição de exclusão mútua: processos requisitam o controle exclusivo dos recursos que estão solicitando; ondição de posse e espera: processos seguram os recursos que já estão alocados a ele enquanto espera por recursos adicionais; 3 ondição de não preempção: os recursos não podem ser removidos dos processos que estão de posse deles enquanto estes recursos não forem utilizados até o fim; 4 ondição de espera circular: existe uma corrente circular de processos na qual cada processo segura um ou mais recursos que são requisitados pelo próximo processo na corrente; Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 7 / 35

8 Introdução aos loqueios Perpétuos Modelando loqueios Perpétuos: Grafo de locação (Holt 97) S D T U R (a) (b) (c) Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 8 / 35

9 Introdução aos loqueios Perpétuos Exemplo de Deadlock Request R Request S Release R Release S (a) Request S Request T Release S Release T (b) Request T Request R Release T Release R (c). requests R. requests S 3. requests T 4. requests S 5. requests T 6. requests R deadlock R S T R S T R S T (d) (e) (f) (g) R S T R S T R S T (h) (i) (j). requests R. requests T 3. requests S 4. requests R 5. releases R 6. releases S no deadlock R S T R S T R S T (k) (l) (m) (n) Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 9 / 35

10 Introdução aos loqueios Perpétuos Tratando loqueios Perpétuos Ignorar o problema; Detectar: permite que o bloqueio ocorra, detecta-o e tentar recuperar o sistema da situação de bloqueio perpétuo; Prevenir: torna o bloqueio perpétuo estruturalmente impossível de ocorrer; Evitar: evita a ocorrência de bloqueio perpétuo através da alocação cuidadosa de recursos. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

11 Tratamento de loqueios Perpétuos Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

12 Ignorando loqueios Perpétuos bordagem favorita de muitos projetistas de SOs; bordagem seguida pelo UNIX e Windows; Pressuposto: a maioria dos usuários preferiria um deadlock ocasional a uma regra que restrinja o uso dos recursos; Se o administrador do sistema notar algo ou algum usuário reclamar ele investigará e resolverá o problema; Usualmente o usuário frustado cancelará o processo e o ciclo será quebrado. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

13 Detecção de loqueios Perpétuos com Um Recurso de ada Tipo aseado na construção do Grafo de locação de Recursos; Um ciclo no grafo indica que há bloqueio perpétuo envolvendo os processos e recursos do mesmo. Quando invocar o algoritmo de detecção? Toda vez que uma requisição para alocação de recurso não puder ser atendida, verifica-se a existência de ciclos no Grafo de locação de Recursos (dispendioso); Em intervalos menos frequentes como uma vez por hora. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 3 / 35

14 Detecção de loqueios Perpétuos com Múltiplos Recursos de ada Tipo Seja m o número de classes de recursos e n a quantidade de processos; E: vetor de recursos existentes; : vetor de recursos disponíveis; : matriz de alocação atual; R: matriz de requisições; Invariante: n ij + j = E j i= Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 4 / 35

15 Estruturas de Dados Necessárias Resources in existence (E, E, E 3,, E m ) urrent allocation matrix Resources available (,, 3,, m ) Request matrix 3 3 m m R R R R R 3 R 3 R m R m n n n3 nm R n R n R n3 R nm Row n is current allocation to process n Row is what process needs Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 5 / 35

16 lgoritmo para Detecção de loqueios Perpétuos Inicialmente todos os processos estão desmarcados; À medida que o algoritmo prossegue sua execução, os processos são marcados, indicando que estão aptos a completar seus processamentos sem sofrerem deadlock; Quando o algoritmo terminar, todos os processos que ainda permanecerem desmarcados estarão em situação de deadlock. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 6 / 35

17 lgoritmo para Detecção de loqueios Perpétuos Procure por um processo desmarcado, P i, para o qual a i-ésima linha de R seja menor ou igual à correspondente de ; Se esse processo for encontrado, adicione a i-ésima linha de à correspondente de, marque o processo e volte ao passo ; 3 Se não existir esse processo, o algoritmo terminará. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 7 / 35

18 Exemplo do lgoritmo para Detecção de Deadlocks Tape drives E = ( 4 3 ) Plotters Scanners D Roms Tape drives = ( ) Plotters Scanners D Roms urrent allocation matrix Request matrix = R = Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 8 / 35

19 Exemplo do lgoritmo para Detecção de Deadlocks Nem o primeiro nem o segundo processos podem ser satisfeitos, mas o terceiro sim; o final de sua execução ele devolverá todos os recursos, resultando em = (,,,) Neste ponto, o processo pode ser executado, resultando em = (4,,,) gora o processo restante pode ser executado, sem ocorrencia de deadlock; gora suponha que o processo 3 precise de uma unidade de D-ROM além das duas unidades de fita e do plotter deadlock. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 9 / 35

20 Recuperação de loqueios Perpétuos Possíveis abordagens: Matando processos: maneira mais fácil de recuperação; través de pontos de controle: ada processo deve periodicamente realizar um ponto de controle (checkpoint), salvando seu estado em disco; o se detectar um bloqueio perpétuo, o processo que possui um recurso solicitado tem sua execução retornarda um ponto anterior à aquisição do recurso. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

21 Evitando loqueios Perpétuos: Estados Seguros e Inseguros Tendo-se certas informações disponiveis antecipadamente, pode-se evitar deadlocks realizando escolhas certas ao alocarmos recursos aos processos; Um estado é considerado seguro se ele não está em situação de deadlock e se existir uma ordem de escalonamento na qual todo processo possa ser executado até sua conclusão, mesmo se, repentinamente, todos eles requisitem de uma sóv vez o máximo possível de recursos; Se esta ordem de escalonamento não existir, o estado é dito inseguro; Um estado inseguro não gera, necessariamente, uma situação de deadlock; partir de um estado seguro, o sistema pode garantir que todos os processos terminarão, ao passo que a partir de um estado inseguro esta garantia não pode ser dada. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

22 Evitando loqueios Perpétuos: Estados Seguros e Inseguros Has Max Has Max Has Max Has Max Has Max 3 Free: 3 (a) Free: (b) Free: 5 (c) Free: (d) Figura: O sistema em (a) é seguro Free: 7 (e) 9 Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de / 35

23 Evitando loqueios Perpétuos: Estados Seguros e Inseguros Has Max Has Max Has Max Has Max 3 Free: 3 (a) Free: (b) Free: (c) Figura: O sistema em (b) é inseguro Free: 4 (d) 9 7 Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 3 / 35

24 Evitando loqueios Perpétuos: lgoritmo do anqueiro para um Único Recurso Desenvolvido por Dijkstra (965); Extensão do algoritmo de detecção de deadlocks visto anteriormente; Um banqueiro pode negociar com um grupo de clientes para os quais ele libera linhas de crédito; Nem todos os clientes necessitam imediatamente de todas suas linhas de crédito; O banqueiro somente aceita uma requisição de crédito caso possa garantir que poderá satisfazer necessidades futuras de todos seus clientes; Nesta analogia, os clientes são os processos, as unidades de crédito são os recursos e o banqueiro é o sistema operacional. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 4 / 35

25 Evitando loqueios Perpétuos: lgoritmo do anqueiro para um Único Recurso Has Max Has Max Has Max D 7 D 4 7 D 4 7 Free: Free: Free: (a) (b) (c) Figura: (a) Seguro. (b) Seguro. (c) Inseguro. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 5 / 35

26 Evitando loqueios Perpétuos: lgoritmo do anqueiro para Múltiplos Recursos D E Process Tape drives 3 Plotters Resources assigned Scanners D ROMs D E 3 Process Tape drives Plotters Scanners D ROMs Resources still needed E = (634) P = (53) = () Figura: Estruturas de Dados Utilizadas Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 6 / 35

27 Evitando loqueios Perpétuos: lgoritmo do anqueiro para Múltiplos Recursos Procure uma linha R cujas necessidades de recursos sejam todas inferiores ou iguais a. Se não existir, o sistema poderá entrar em deadlock. onsidere que o processo da linha escolhida requisita todos os recursos de que precisa e termina. Marque esse processo como terminado e adicione ao vetor todos os recursos que lhe pertenciam. 3 Repita os passos e até que todos os processos sejam marcados como terminados, o que é o caso seguro, ou até ocorrer um deadlock, que é o caso inseguro. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 7 / 35

28 Evitando loqueios Perpétuos: lgoritmo do anqueiro para Múltiplos Recursos O estado do sistema mostrado na figura anterior é seguro; Suponha que requisite um scanner. requisição pode ser atendida (processo D pode terminar e, depois, ou E, seguido dos demais); Suponha que após a alocação de um dos dois scanners restantes por, E queira o último scanner, reduzindo o vetor de recursos disponíveis a (,,,). Isso levaria a um deadlock. Neste caso, a solicitação deve ser negada. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 8 / 35

29 Evitando loqueios Perpétuos: lgoritmo do anqueiro Na prática este algoritmo não é utilizado: Raramente os processos sabem antecipadamente a quantidade máxima de cada recursos que irão utilizar; O número de processos não é fixo, variando dinamicamente à medida que usuários entram e saem. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 9 / 35

30 Prevenção de loqueio perpétuos Havender sugeriu as seguintes estratégias para quebrar estas condições necessárias para a ocorrência de bloqueios perpétuos: cada processo deve solicitar todos os recursos de uma só vez e não pode prosseguir até que todos estes recursos estejam a ele alocados. se a um processo for negado novos recursos, ele deve liberar os recursos já alocados a ele e, se necessário, solicitar todos os recursos novamente juntamente com os recursos adicionais. 3 Impor uma ordenação linear dos recursos para os processos. Isto é, se um processo possui recursos a ele alocado, só poderá requisitar aqueles recursos com numeração maior. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 3 / 35

31 nalisando a Primeira Estratégia Pode levar a um sério desperdício de recursos. Exemplo: um programa que requisita dez unidades de fita, necessitando de apenas uma unidade de fita para iniciar a sua execução; Eventualmente o programa poderia ser dividido em vários passos que executam de forma relativamente independente das demais. Isto pode reduzir o desperdício mas envolve uma sobrecarga no projeto das aplicações do sistema bem como na sua execução; Pode causar a postergação indefinida já que pode ocorrer de nem sempre todos os recursos estarem disponíveis de uma vez. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 3 / 35

32 nalisando a Segunda Estratégia Quando um processo libera os recursos pode ser que ele perca todo o seu trabalho até este ponto. Isto parece um preço muito alto a se pagar, mas a questão real é: qual a freqüência que este preço vai ser pago? Esta estratégia pode causar a postergação indefinida já que um processo pode ficar preso indefinidamente se ele tiver que repetidamente requisitar e liberar os mesmos recursos. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 3 / 35

33 nalisando a Terceira Estratégia Os recursos são numerados e os processos devem requisitar os recursos de uma forma linear ascendente. Isto impede que uma corrente circular seja criada. Por exemplo, pode-se definir: impressora plotter 3 unidade de fita 4 unidade de DROM Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 33 / 35

34 nalisando a Terceira Estratégia Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 34 / 35

35 nalisando a Terceira Estratégia Se um processo tiver alocado o recurso i e o recurso j teríamos um bloqueio perpétuo caso requisitasse j e requisitasse i. No entanto, isto é impossível já que se i > j então não pode requisitar j. Se i < j então não pode requisitar i. Desta forma, o bloqueio perpétuo jamais ocorrerá. mesma lógica pode ser aplicada a vários processos; Desvantagens: Pode ser impossível encontrar uma ordem para os recursos que satisfaça todas as aplicações; Os números dos recursos são definidos pela instalação e devem permanecer os mesmos por um longo período. Se novos recursos são adicionados, pode ser necessário re-escrever os sistemas e programas existentes; Os usuários deveriam poder desenvolver suas aplicações sem se preocupar com restrições de hardware e software. Francisco Silva (UFM/LSD) Sistemas Operacionais 9 de agosto de 35 / 35