Escalonamento de Processos - Critérios. justiça : cada processo tem sua parte justa de tempo de cpu;. eficiência : cpu ocupada 100% do tempo;. tempo de resposta : minimizar tempo de resposta para processos interativos;. turnaround : minimizar o tempo que usuários batch esperam pelas saídas de seus programas;
. rendimento : maximizar número de jobs por hora. - Alguns desses objetivos podem ser contraditórios (interativo X batch) - cada processo é único e imprevisível (na maioria dos casos) - CPU-bound X I/O-bound - Quando escalonar? - Fork: Pai ou Filho? - Quando processo termina - Quando processo bloqueia (motivo do bloqueio pode ser importante: acesso região crítica) - Quando ocorre interrupção de I/O: pode ter desbloqueado algum processo; que processo executará?
- relógio ---> interrupção de clock (gerenciar tempo do processador) -estratégias :. Não-preemptivo : processo escolhido executa até bloquear, ou voluntariamente liberar a CPU. Não exige decisões durante interrupções de clock. Quando terminará.preemtivo : executado por um tempo máximo fixo; se ainda está executando no final do intervalo de tempo (interrupções de clock), ele é suspenso e outro processo é escolhido. Pode levar a condições de corrida.
Round-robin
Escalonamento Round Robin - cada processo tem um quantum - processo interrompido ( preemptado ) e contexto salvo - chaveamento de contexto ou processo - fácil de implementar - qual deve ser o tamanho do quantum? ex : 20 ms e chaveamento 5 ms (20 % de overhead) 500 ms e chaveamento 5 ms (+/- 1 % de overhead) com 10 processos o último só será executado em 5 s!!
Escalonamento com Prioridades - usuários em diferentes níveis de prioridade - Pode-se alocar um número de quanta e chavear - Para evitar monopólio, pode-se diminuir a prioridade a cada interrupção de clock (se prioridade cair abaixo da próxima prioridade mais alta, processo é chaveado) - prioridades designadas estáticamente - prioridades designadas dinâmicamente. processos CPU bound e I/O bound. ex : prioridade = 1/f (f = fração do último quantum que o processo usou) - classes de prioridade
Classes de Prioridade
Filas Múltiplas - memória pequena --> um processo apenas na memória; - processo CPU bound --> mais eficiente um quantum grande, de vez em quando, que pequenos quanta frequentemente (reduzindo swapping) - dá a todos processos grande quantum significa pequeno tempo de resposta - Solução: Classe de prioridade com compromisso entre uso do quantum e prioridade
-classes de prioridade :. processos na classe de prioridade mais alta são executados por um quantum;. processos na classe de prioridade seguinte são executados por dois quanta;. processos na classe de prioridade seguinte a anterior são executados por quatro quanta, e assim por diante;. quando um processo usa todo o quanta alocado para ele, ele é movido para classe imediatamente inferior.
ex : processo necessita de 100 quanta 1 quantum, 2 quanta, 4 quanta, 8 quanta, 16 quanta, 32 quanta, 64 quanta (apenas 37) 7 chaveamentos (round robin seriam 100!)
Estruturação do Software de E/S - estruturar o software em camadas : 1. Tratadores de Interrupções 2. Device Drivers 3. Software do Sistema Operacional Independente de Dispositivo 4. Software a Nível de Usuário
Tratadores de Interrupções - interrupção é uma coisa chata! - esconder interrupções :. um process (device driver) bloqueado sempre que um comando de E/S for feito;. ao chegar a interrupção, a rotina de de tratamento daquela interrupção faz o que quer que seja para desbloqueiar o device driver - uso de semáforos (UP), variáveis de condição em um monitor (SIGNAL) para acordar device driver, SEND
processo (fazendo E/S) 11 22 bloqueado 33 interrupção (UP s, SIGNALS, SENDS) pronto
Device Drivers (DD) - contém todo código dependende de dispositivo; - cada device driver manipula um tipo de dispositivo, ou uma classe de dispositivos estreitamente relacionados;
-device drivers enviam comandos para os controladores (programa-os). - ex : disk driver é a única parte do S.O que sabe quantos registros o tem o controlador de disco; só ele conhece setores, trilhas, cilindros, cabeças de gravação/ leitura, movimento do braço, fatores de interleaving, drives de motores, etc - device driver aceita pedidos abstratos do software independente de dispositivo e toma providências para eles sejam executados pelo hardware
ex : disco- pedido - lê bloco n. driver ocioso? -> executa driver ocupado? -> fila de espera. tradução do pedido abstrato : onde está o bloco? motor está funcionando? determinar se braço está sobre o cilindro. envia comandos para o controlador. device driver espera até o controlador fazer o trabalho (bloqueia até uma interrupção o desbloquear) operação é feita sem demora (não precisa bloquear; ex : rolagem de tela em terminais). checagem de erros e informação de status é enviada
Software de E/S Independente de Dispositivo (SID) -função : executar funções de E/S comum a todos os dispositivos, fornecendo uma interface uniforme ao usuário (software á nível de usuário) - maioria das funções E/S não depende de dispositivo (fronteira com device drivers é tênue) - muitas funções feitas nos drivers por questão de eficiência
-funções típicamente feitas no SID a) interfaceamento uniforme para DD b) nomeamento de dispositivos mapear nomes simbólicos nos drivers apropriados (ex : unix) c) proteção de dispositivos d) fornecer um tamanho de bloco independente do dispositivo ex :discos podem ter diferentes tamanhos de setores -> bloco lógico de tamanho fixo
e) buferização. blocos físicos e lógicos podem ter tamanhos diferentes (hardware ler blocos, mas usuário pode ler apenas partes de tamanho arbitrário). velocidade (ex: dispositivos orientados a caracter) f) alocação de espaço em dispositivos ex: alocação de novos blocos para um arquivo orientado a bloco
g) alocação/liberação de dispositivos dedicados alguns dispositivos só podem ser usados por um processo de cada vez h) comunicação de erros grande parte dos erros são muito dependente de dispositivos (checagem feita pelos drivers) detecção : baixo nível tratamento : nível mais alto
Exemplo de caracterização de tarefas: Periódicas: ti = ti (Ci,Fi,Ti,Di) t1 = t1 (2,5,10,10) t2 = t2 (3,10,20,20) Esporádicas: Semelhante às periódicas mas com miti em vez de Ti e Fi não é habitualmente usado (poderia significar um tempo mínimo até à primeira activação). ti = ti (Ci,miti,Di) t1 = t1 (2,5,5) t2 = t2 (3,10,7)
Deadlocks - motivação : - problema do spooling. todo o arquivo a ser impresso tem que ser escrito no disco antes que a saída possa ser realizada (caso contrário, se o processo que gera o arquivo demorasse 2 horas!?). um arquivo pode ser tão grande que não comporte no disco! saída : não usar spooling e dá acesso exclusivo -> deadlock
Problema com recursos exclusivos Impressora D1 Disco D2 Processo A Processo B Request D1 Request D2 Request D2 Request D1 DEADLOCK!
Usando um semáforo para proteger recursos: importância da ordem de alocação de recursos typedef int semaphore; typedef intsemaphore semaphore resource_1; semaphore resource_1; semaphore resource_2; void process_a(void) { void process_a(void) { down(&resource _1); down(&resource _1); use_resource_1( ); down(&resource _2); up(&resource _1); use both_resources( ); { up(&resource _2); } up(&resource _1); } Protegendo um recurso Protegendo dois recursos
typedef int semaphore; semaphore resource_1; semaphore resource_1; semaphore resource_2; semaphore resource_2; void process_a(void) { void process_a(void) { down(&resource _1); down(&resource _1); down(&resource _2); down(&resource _2); use_both_resources( ); use_both_resources( ); up(&resource _2); up(&resource _2); up(&resource _1); up(&resource _1); } } Código sem deadlock em potencial void process_b(void) { void process_b(void) { down(&resource _1); down(&resource _2); down(&resource _2); down(&resource _1); use_both_resources( ); use_both_resources( ); up(&resource _2); up(&resource _1); up(&resource _1); up(&resource _2); } } Código com deadlock em potencial
Recursos - recursos : hardware ou software - instâncias de recursos - eventos em operações com recursos : 1. solicitar recurso (request) 2. usar recurso (use) 3. liberar recurso (release) - se recurso não disponível : processo bloqueia
Modelando Deadlocks - deadlock : um conjunto de processos estão em deadlock se cada processo no conjunto estiver esperando por um evento que somente um outro processo no conjunto pode provocar. Condições que devem ocorrer para haver deadlock (Coffman, 1971)
1. Condição de exclusão mútua (Mutual Exclusion). Cada recurso ou está correntemente alocado para exatamente um processo, ou ele está disponível; 2. Condição Reter e Esperar ( Hold and Wait). Processos correntement retendo recursos concedidos anteriormente, podem solicitar novos recursos; 3. Condição de Exclusão de Preempção ( No Preemption ). Recursos concedidos anteriormente não podem ser tomados de um processo, que devem liberá-los de forma explícita; 4. Condição Espera Circular ( Circular Wait). Deve existir uma cadeia de dois ou mais processos, cada um dos quais está esperando por um recurso mantido pelo próximo membro da cadeia.
Uso de Grafos (Holt, 1972). processos : círculos. recursos : quadrados. operações : flexas R A Recurso R alocado para processo A
R A Recurso R alocado para processo A R A Processo A esperando por recurso R
B R SS A DEADLOCK A R B S
Exemplo : Processos A, B, C Recursos R, S, T
Considerações:.S.O livre para executar em qualquer ordem;. execução sem concorrência não leva a deadlock (executa A até o fim, executa B até o fim, executa C até fim); mas não é o ótimo (E/S);. se nenhum processo faz E/S, algoritmo do Menor Job Primeiro melhor que round robin e execução sequencial éo melhor modo;. dependendo do modo de execução o sistema pode ou não deadlocar.
A Requests R Requests S Releases R Releases S B Requests S Requests T Releases S Releases T C Requests T Requests R Releases T Releases R 1. A requests R 2. B requests S 3. C requests T 4. A requests S 5. B requests T 6. C requests R deadlock! 1. A requests R 2. C requests T 3. A requests S 4. C requests R 5. A releases R 6. A releases S sem deadlock!
1. A requests R 2. C requests T 3. A requests S 4. C requests R 5. A releases R 6. A releases S no deadlock
Estratégias para Lidar com Deadlock 1. Ignorar (avestruz) 2. Detecção e Recuperação 3. Prevenção(negar uma das 4 condições) 4. Evitar (dinâmicamente), através de cuidadosa alocação de recursos
Algoritmo do Avestruz (Ignorar) - outros tipos de falhas levam o sistema a falhar com mais frequência que deadlock o faz - vale a pena investir recursos para resolver o problema? - exemplo : 100 entradas na tabela de processos (unix), 10 processos e cada deseja criar outros 12 (fork)
Detecção e Recuperação - a cada pedido de recurso é feita uma checagem no grafo para verificar existência de possíveis wait circulares; se positivo, elimina-se processos, até o círculo se romper (restaurar qualquer arquivo modificado para o estado original) - outra opção : não checar por círculos; timeout para processos bloqueados - em alguns sistemas é inaceitável se eliminar processos
Prevenção de Deadlock (negar uma das quatro condições) a) Negar Exclusão Mútua - permitir dois processos acessarem uma impressora ao mesmo tempo seria um caos! - spooling seria solução? somente o daemon realmente acessa a impressora. - nem a todos dispositivos se pode aplicar a técnica de spooling - competição por espaço em disco (necessário no spooling) pode levara deadlock!
-ex :. dois processos ocupam, cada, metade do espaço em disco disponível usado para spooling e nenhum tenha acabado. se daemon começa a imprimir antes que tod arquivo esteja na área de spooling e processo que gera o arquivo demora a enviaro resto, a impressora ficaria bloqueada. assim : normalmente daemons são programados para só imprimir quando toda a saída do arquivoestiver disponível. conclusão : nenhum processo iria terminar -> deadlock!
b) Negar Condição Reter e Esperar ( Hold and Wait ) - evitar que processos que detêm recursos de esperar por mais recursos - todos processos devem solicitar seus recursos antes de iniciar; se todos estiverem disponíveis, o processo é executado -problemas :. nem todos processos sabem quantos e quais recursos necessitarão;. recursos não serão usados de maneira ótima (ex :processo que lê dado de fita, analiza por 1 hora e escreve na impressora) - variação : a cada novo recurso solicitado, todos retidos devem sem liberados; se todos disponíveis, ele continua
c) Negar Condição de Exclusão de Preempção ( No Preemption ) - se a impressora é retirada de um processo no meio de uma impressão seria uma confusão geral!
d) Negar Espera Circular ( Circular Wait ) - opção 1 : um processo só tem direito a um único recurso em um dado momento (ex : copy!) - numeração de recursos : processos só podem solicitar recursos na ordem numérica
A ii B jj 1. Disco 1 2. Fita 3. Impressora 4. Disco 2 deadlock só pode ocorrer se : A solicita j B solicita i (i diferente de j) Se i > j => A não pode pedir j i < j => B não pode pedir i
-múltiplos recursos - variação : nenhum processo pode pedir recurso de número inferior ao que detém - problema : como numerar inúmeros recursos?
Resumo Condição Procedimento Exclusão Mútua spool tudo Reter e Esperar solicita todos os recursos inicialmente Exclusão de retira recursos Preempção Espera Circular ordenar recursos numéricamente
Evitar Deadlock - existe um algoritmo que possa evitar sempre deadlock através de uma escolha correta (de processos)?
Evitando Deadlock Análise de trajetórias: permite modelar o tratamento com dois processos e dois recursos
Algoritmo dos Banqueiros para um Único Recurso (Dijkstra, 1965)
Nome Usado Máximo André 0 6 Isabel 0 5 João 0 4 Mariana 0 7 Disponível = 10
Disponível = 2 Estado Seguro
Disponível = 1 Estado Não Seguro
Algoritmo dos Banqueiros para Múltiplos Recursos - Duas matrizes :. quantas instâncias de cada recurso estão correntemente alocadas. quantas instâncias de cada recurso cada processo ainda precisa para completar sua execução. Vetor A (x,y,..z) recursos disponíveis
Suponha B solicite um Scanner - estado ainda seguro D, A, E... Suponha B solicitar um Scanner, E solicite o outro Scanner (1 0 0 0)
1. Procure uma linha R cujo os recursos não satisfeitos são menores que A. Se tal linha não existir, o sistema está em deadlock; 2. Suponha que o processo da linha escolhida solicite todos os recursos que ele necessite e termine. Marque o processo como terminado e adicione seus recursos ao vetor A; 3. Repita os passos 1 e 2 até todos os processos serem marcados como terminados (nesse caso o estado inicial era seguro), ou até que um deadlock tenha ocorrido (nesse caso o estado inicial era inseguro)
Recursos ainda necessários Processos Disks Plotters Printers Tapes A B C D E 1 1 0 0 0 1 1 2 3 1 0 0 0 0 1 0 2 1 1 0 E - recursos existentes P - recursos possuídos A - recursos disponíveis E = (6 3 4 2) P = (5 3 2 2) A = (1 0 2 0) -situações : -. estado da figura é seguro: se processo B solicita impressora, o pedido pode ser garantido porque o estado resultante é seguro (processo D pode terminar, depois processos A ou E, seguidos pelo resto).. Se após ser dado uma das duas impressoras restantes para B, E for dado a última impressora, isto reduziria o vetor A = (1 0 0 0), implicando em um deadlock. Pedido de E deve ser negado por enquanto.
- Processos raramente sabem suas necessidades com antecedência!!
Processos Disks Plotters Printers Tapes A B C D E 3 0 1 1 0 1 0 0 1 1 1 0 1 1 0 1 0 0 0 0 Recursos Alocados
Algoritmo dos Banqueiros para um Único Recurso (Dijkstra, 1965) a é seguro - b não é seguro