Sumário. Sistemas Operativos: Escalonamento de Processos e Deadlocks. Padrão de Execução dum Processo. Multiprocessamento

Transcrição

1 Sumário Sistemas Operativos: Escalonamento de Processos e Deadlocks Pedro F. Souto (pfs@fe.up.pt) May 18, 2008 Escalonamento de Processos O Problema Algoritmos de Escalonamento de Processos Leitura Adicional Deadlocks O Problema Soluções Leitura Adicional Padrão de Execução dum Processo Multiprocessamento Processos (e threads) alternam: execução de instruções; realização de operações de entrada/saída. De acordo com a duração dos intervalos de execução de instruções, um processo pode ser classificado em CPU-bound (a) ou IO-bound (b) (a) (b) Long CPU burst Short CPU burst Waiting for I/O A generalidade dos SOs é multi-processo: enquanto um, ou mais processos realizam operações de entrada/saída; outro processo pode executar instruções. Obtém-se uma maior utilização dos recursos dum computador. Para o efeito o SO deverá suportar comutação entre processos (process switching), i.e.: retirar o CPU a um processo e atribuí-lo a outro. A parte do SO que faz a comutação de processos designa-se por despacho (dispatcher). Time

2 Comutação de Processos (1/2) Comutação de Processos (2/2) P 0 está no estado RUN e passa para o estado READY : A comutação entre processos inclui: Transferir o estado do processo em execução para a memória (o Process Control Block); Carregar o processador com o estado do processo que passa para o estado de execução; Passar o controlo para o novo processo, possivelmente comutando para user-mode. A comutação entre processos é feita em instantes "oportunos", incluindo: chamadas ao sistema (p.ex., exit(), read()); interrupções: por dispositivos de E/S; pelo relógio. CPU CPU queue head P0 queue head P1 P1 P2 P2 P null P null P0 Escalonamento de Processos Problema: quando há mais de um processo em condições de execução (estado ready), qual o processo a executar? 1 ready running 4 2 waiting Solução: o SO, mais precisamente o scheduler, executa um algoritmo de escalonamento para decidir. I.e., o escalonador determina a que processo deve ser atribuído o CPU. Escalonamento Preemptivo vs. Não-preemptivo Um algoritmo de escalonamento diz-se não-preemptivo, se, uma vez na posse do CPU, um processo executa até o (ao CPU) libertar voluntariamente. Quase todos os algoritmos de escalonamento têm duas versões: uma preemptiva outra não. Algoritmos não-preemptivos têm problemas graves: certas classes de processos executam durante muito tempo até bloquear; um utilizador egoísta pode impedir que o computador execute processos de outros utilizadores. Praticamente todos os sistemas operativos usam algoritmos preemptivos: O SO usa as interrupções do relógio para retirar o CPU ao processo em execução.

3 Critérios para um Bom Algoritmo de Escalonamento Algoritmo Round-Robin Equidade: dar oportunidade a todos os processos para progredir. Equilíbrio: na utilização dos recursos. Satisfação da política escolhida: Sistemas interactivos: tempo de resposta; previsibilidade. Sistemas de tempo-real: cumprir prazos; determinismo. Sistemas não-interactivos: débito; utilização do CPU. Quando um processo passa para o estado de execução, o SO atribui-lhe a posse do CPU por um intervalo de tempo fixo: quantum. A comutação de processos realiza-se: ou quando o processo em execução bloquear; ou quando o quantum expirar. Qual o valor dum quantum? compromisso tempo-de-resposta/utilização-do-cpu: a comutação de processos leva algum tempo; Unix/Linux usa um valor de 100 ms, que se mantém inalterado há mais de 20 anos!!! Algumas vantagens deste algoritmo são: fácil de implementar (como?); equitável (mais uma característica). Escalonamento Baseado em Prioridades Problema por vezes, alguns processos são mais iguais do que os outros. Solução atribuir uma prioridade a cada processo. Quando da comutação de processos, o processo pronto a executar com maior prioridade passa para o estado de execução. As prioridades podem ser atribuídas estática ou dinamicamente. Potencial problema: inanição (starvation): Os processos de mais baixa prioridade podem nunca ser seleccionados para executar. Escalonamento em BSD-Unix Cada processo tem uma prioridade. Processos são agrupados em classes com base na sua prioridade: o escalonamento entre classes é baseado em prioridades; o escalonamento numa classe usa round-robin. q headers prior. 4 prior. prior. 2 prior. 1 Para evitar inanição de processos de prioridade mais baixa: sempre que um processo executa até ao fim do seu quantum, a sua prioridade diminui.

4 Rate-monotonic Scheduling Mecanismos vs. Políticas Assume n processos periódicos, cada um deles: de período T i igual ao prazo (deadline); com um tempo de execução C i. É de facto um algoritmo de atribuição de prioridades estáticas: quanto mais curto é período maior é a prioridade. Tem propriedades matemáticas que o tornam apropriado para sistemas hard real-time. O algoritmo original (197) impõe sérias restrições, mas desenvolveram-se técnicas que permitem levantar a maioria delas. Observação: Não é possível agradar a gregos e a troianos. : O SO não conhece as necessidades das aplicações suficientemente para tomar as decisões mais apropriadas. Ideia: oferecer os utensílios e permitir que os seus utilizadores os usem da maneira que acharem conveniente. O SO oferece os mecanismos: algoritmos de escalonamento parametrizáveis. Os processos seleccionam as políticas: i.e. o algoritmo e os valores dos seus parâmetros. Escalonamento em POSIX (Linux) (1/2) Escalonamento em POSIX (Linux) (2/2)) POSIX define políticas de escalonamento: SCHED_FIFO preemptivo, baseado em prioridades estáticas; SCHED_RR semelhante a SCHED_FIFO mas com quanta; SCHED_OTHER algoritmo não especificado, i.e. dependente da implementação. O escalonador é baseado em prioridades. A política de escalonamento especifica: quando os processos passam do estado run para o estado ready; onde é que são inseridos na ready-list de processos com a mesma prioridade. SCHED_FIFO e SCHED_RR foram especificados para aplicações de tempo-real. A sua prioridade é sempre superior à de processos com política SCHED_OTHER. Em Linux, SCHED_OTHER é um algoritmo semelhante ao de BSD-Unix, embora os pormenores sejam ligeiramente diferentes. (Para mais informação veja man 2 sched_setscheduler.) Estas políticas de escalonamento podem também ser atribuídas a threads através de funções de libpthread: int pthread_setschedparam(pthread_t tid, int policy, struct sched_param *param);

5 Escalonamento de Threads Order in which threads run 2. Runtime system picks a thread User-level vs. kernel-level Process A Process B Process A Process B Kernel picks a process 1. Kernel picks a thread Possible: A1, A2, A, A1, A2, A Not possible: A1, B1, A2, B2, A, B (a) Quantum de cada processo de 50 ms. Cada thread executa em bursts de 5 ms. Possible: A1, A2, A, A1, A2, A Also possible: A1, B1, A2, B2, A, B (b) Modos de Partilha do CPU em libpthread libpthread suporta 2 modos da partilha do CPU: PTHREAD_SCOPE_PROCESS threads disputam o CPU apenas com outros threads do processo em execução: user-level threads implica este modo de escalonamento. PTHREAD_SCOPE_SYSTEM threads disputam o CPU com todos os threads no sistema impossível de implementar com user-level threads: SO não conhece todos os threads em execução; modo natural quando se usa kernel-level threads. Note-se que este atributo pode ser configurado por cada thread, usando pthread_attr_setscope(). Linux suporta apenas PTHREAD_SCOPE_SYSTEM. Leitura Adicional Deadlocks Modern Operating Systems, 2nd. Ed. Secção 2.5: Scheduling Secção 10.: Processes in Unix Um zelo excessivo na eliminação de race conditions pode conduzir a um outro problema deadlock: um cenário em que 2 ou mais processos ficam bloqueados indefinidamente. Um exemplo é a seguinte solução do bounded buffer com semáforos: public void remove(object item) { mutex.down(); // keep other threads out empty.down(); // wait for some item que difere da solução correcta na ordem de execução das operações down(): Se o buffer estiver vazio, o consumidor bloqueia sem libertar o mutex, impedindo o produtor de eventualmente introduzir a mensagem no buffer.

6 Recursos O estudo do problema de deadlock tem origem em SOs, no contexto da gestão de recursos dum computador. Um recurso é um objecto usado por um processo. P. ex.: físico: disco, memória, CPU,...; lógico: um socket, um ficheiro, uma secção crítica,...; Num sistema, pode haver mais do que um recurso do mesmo tipo, p.ex. disco. Propriedades importantes de recursos: tipo de acesso certos recursos, p.ex. uma impressora, têm que ser acedidos em exclusão mútua; preemptibilidade recursos podem ser ou não preemptíveis: isto é, podem ser ou não removidos dum processo sem problemas de maior. Por exemplo, uma impressora não é preemptível, mas o CPU é-o. Uso de Recursos por Processos Recursos são geridos por gestores, os quais podem ser ou não componentes do SO. O uso de um recurso por um processo tipicamente envolve a sequência: pedido do recurso; uso do recurso; libertação do recurso. Se o recurso pedido por um processo não estiver disponível, o processo não o pode usar. Neste caso, o processo: ou bloqueia, à espera que o recurso fique disponível; ou prossegue, mas não terá acesso ao recurso pedido. Bloqueio Mútuo (Deadlock) Condições Necessárias para Deadlock Definição um conjunto de processos está mutuamente bloqueado (deadlocked), se cada processo nesse conjunto está à espera dum evento que apenas outro processo nesse conjunto pode causar. Normalmente, o evento pelo qual um processo espera é a libertação dum recurso na posse de outro processo nesse conjunto Numa situação de deadlock, nenhum processo pode: executar; libertar os recursos que detém; ser activado. Bloqueio á espera que o recurso fique disponível (exclusão mútua); Espera com retenção processos não libertam os recursos na sua posse quando bloqueiam à espera de outros recursos; Não-preempção recursos na posse dum processo não lhe podem ser retirados; Espera-circular tem que haver uma cadeia de 2 ou mais processos, cada um dos quais à espera dum recurso na posse do processo seguinte.

7 Estratégias de Ataque ao Problema de Deadlock Algoritmo da Avestruz 1. Ignorar o problema: algoritmo da avestruz (Tanenbaum). 2. Detectar e recuperar.. Evitar (avoidance: solução dinãmica). 4. Prevenir (prevention: solução estática). Ignorar o problema: pretender que não existe. Pode ser aceitável. se a probabilidade de deadlock fôr muito baixa; o custo de qualquer das outras soluções fôr elevado. Unix tenta evitar situações de deadlock, mas não as elimina completamente. É um compromisso entre: correcção; conveniência/eficiência; análogo a muitos em engenharia.... viver é gerir riscos. Detectar e Recuperar Detecção de Deadlock Tem 2 partes: 1. Detectar o deadlock: O algoritmo basicamente testa se há alguma ordem de terminação dos processos. 2. Recuperar da situação: preempção de recursos; roll-back de processos; terminação de processos. Faz uso das seguintes estruturas de dados: Vector dos recursos existentes, E, tem m elementos, i.e. tantos quantos os tipos de recursos. O valor de cada elemento é o número de recursos do tipo correspondente existentes no sistema. Vector de recursos disponíveis, D, com m elementos. Matriz dos recursos atribuídos, A, de dimensão n m, em que n é o número de processos. A linha i é o vector com os recursos atribuídos ao processo P i. Matriz dos pedidos pendentes, P, de dimensão n m. A linha i é o vector com os pedidos pendentes de recursos pelo processo P i.

8 Exemplo de Detecção de Deadlock E = [ ] D = [ ] A = P = Testar se há uma ordem de terminação dos processos. P 1 e P 2 estão bloqueados: os seus pedidos não podem ser satisfeitos. Mas P pode executar e se terminar libertará os seus recursos. Depois os pedidos de P 2 podem ser satisfeitos e P 2 poderá terminar, libertando os seus recursos. Algoritmos de Detecção Os algoritmos de detecção são caros : O(m n 2 ). De facto, a complexidade dum algoritmo não é a história completa: há constantes a considerar e os valores dos parâmetros se m ou n forem pequenos o custo pode ser baixo. Quando devem ser executados? sempre que é feito um pedido; periodicamente; quando a utilização do CPU diminui. Finalmente, os pedidos de P 1 poderão ser satisfeitos e P 1 poderá terminar: não há deadlock. Recuperação de Deadlock (1/2) Recuperação de Deadlock (2/2) Preempção de recursos: depende do recurso em causa: não é sempre aplicável; pode requerer intervenção humana, Rollback de processos: fazer o checkpoint do estado dos processos, periodicamente; em caso de deadlock, identificar um processo que se rolled-back quebrará o deadlock. Terminar um processo no ciclo: de preferência, dever-se-á terminar um processo que possa ser reexecutado de início sem problemas de maior. Em qualquer dos casos, é preciso escolher uma vítima. Alguns critérios: o processo que possui menos recursos; o processo que possui mais recursos; o processo que usou menos o CPU. Pode ainda, usar-se o seguinte critério: o menor conjunto de processos que quebrará o deadlock. Com excepção de roll-back as outras soluções podem deixar o sistema num estado inconsistente. Mesmo com rollback, fazer o checkpointing do estado dos processos pode não ser suficiente: E se o processo rolled-back modificou um ficheiro desde o último checkpoint?

9 Estados Seguros e Não-seguros Deadlock Avoidance (Solução Dinãmica) A B C Admitamos que processos partilham só um tipo de recurso, e que há 10 unidades desse tipo. Has Max Has Max Has Max Has Max Has Max 2 2 Free: (a) A B C 4 2 Free: 1 (b) A B C 0 B 0 2 Free: 5 (c) 9 7 A C 7 Free: 0 (d) 9 7 A B C 0 0 Free: 7 (e) 9 Ideia antes de satisfazer um pedido, averiguar se essa satisfação conduz a um estado não-seguro estratégia pessimista em comparação com detecção & recuperação. Requisito desta técnica: é necessário o conhecimento a priori dos requisitos máximos de cada tipo de recurso por cada processo. Algoritmo para Deadlock Avoidance Faz uso das seguintes estruturas de dados: Vector dos recursos existentes, E, tem m elementos, i.e. tantos quantos os tipos de recursos. O valor de cada elemento é o número de recursos do tipo correspondente existentes no sistema. Vector de recursos disponíveis, D, com m elementos. Matriz dos recursos atribuídos, A, de dimensão n m, em que n é o número de processos. A linha i é o vector com os recursos atribuídos ao processo P i. Matriz dos recursos a atribuir, R, de dimensão n m. A linha i é o vector com os pedidos de recursos que o processo P i ainda poderá fazer: O algoritmo é semelhante ao apresentado para detecção de deadlock, excepto em vez da matriz P usa-se a matriz R. Exemplo de Deadlock Avoidance Seja após a satisfação condicionada dum pedido: E = [ ] D = [ ] A = R = P 4 pode terminar: D = [ ] ; 2. P 1 pode terminar: D = [ ] ;. P 2 pode terminar: D = [ ] ; 4. P pode terminar: D = [ ] ; O pedido pode ser satisfeito: não conduz a deadlock mesmo que os processos usem os recursos ao máximo.

10 Considerações sobre Deadlock Avoidance Prevenir Deadlocks (Solução Estática) Um pedido de recursos só é satisfeito, se os recursos que ficarem disponíveis, permitirem a terminação de todos os processos que detém pelo menos um recurso, assumindo que cada um destes processos usa o número máximo de recursos correspondente. Infelizmente, a utilidade deste algoritmo (Banker s Algorithm, de Dijkstra) é no melhor dos casos limitada: normalmente, os processos não conhecem a priori as suas necessidades máximas. Provavelmente, alguns sistemas de tempo-real serão a única excepção. Ideia garantir que 1 das 4 condições necessárias nunca ocorre: 1. Exclusão mútua; 2. Espera com retenção;. Não-preempção; 4. Espera circular. deadlock avoidance é uma solução dinâmica: o programa executa um algoritmo para determinar se a satisfação do pedido pode conduzir a deadlock. deadlock prevention é uma solução estática: impede-se a ocorrência de deadlock por concepção do programa. Prevenir Deadlocks: Não-exclusividade Exclusão mútua, p.ex., recorrendo a processos auxiliares - printer spooler: nem todos os recursos se prestam a spooling; a contenção no acesso a outros recursos (p.ex. disco, no caso do printer spooler) pode também dar origem a deadlocks. Princípio, em qualquer dos casos, deve-se: atribuir um recurso apenas quando necessário; minimizar o número de processos que partilham um recurso. Prevenir Deadlocks: Espera sem Retenção Espera com retenção de recursos: Pedir todos os recursos necessários antes de iniciar tarefa: sofre do mesmo problema que deadlock avoidance. Alternativamente, um processo deverá libertar todos os recursos que possui, quando o pedido de um recurso conduziria a um bloqueio: quando desbloqueado, o processo terá que readquirir todos os recursos de novo; é uma variante da solução anterior, na qual os recursos necessários são descobertos dinamicamente. Técnica usada por vezes ao nível do kernel do SO.

11 Prevenir Deadlocks: Preempção e Não-circularidade Mais sobre Gestão de Recursos Na prática, usa-se uma combinação destas técnicas. Preempção dos recursos: retirar recursos a um processo (sem a sua cooperação) é inviável na maioria dos casos. Espera circular pode ser evitada por vezes. Por exemplo: definindo uma ordem total para todos os tipos de recursos; impondo que o pedido dos recursos respeite essa ordem. Infelizmente, nem sempre é viável. Inanição (starvation) de processos pode ocorrer também associada à gestão de recursos: quando o número de recursos disponível é inferior ao número de recursos pedido, o sistema tem que decidir a que processos atribuir os recursos disponíveis; se o algoritmo usado favorecer alguns processos em relação a outros, estes últimos poderão ser continuamente preteridos no acesso aos recursos e assim impossibilitados de fazer qualquer progresso. O escalonamento de processos é um problema de gestão dum recurso particular: o CPU. Leitura Adicional Modern Operating Systems, 2nd. Ed. Secção.1: Resources Secção.2: Introduction to Deadlocks Secção.: The Ostrich Algorithm Secção.4: Deadlock Detection and Recovery Secção.5: Deadlock Avoidance Secção.6: Deadlock Prevention Subsecção.7.2: Nonresource Deadlocks Subsecção.7.2: Starvation