Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Faculdade de Computao
Captulo 5
Escalonamento de Processos
Trabalho referente disciplina Sistemas Operacionais 2, ministrada pelo Prof.: Lus F. Faina
Introduo
Processos
O conceito de processo , certamente, o conceito mais importante no estudo de sistemas operacionais. Para facilitar o entendimento deste conceito, considere-se um computador funcionando em multiprogramao (isto , tendo vrios programas simultaneamente ativos na memria). Alm das instrues e dados, cada programa em execuo possui uma rea de memria correspondente para armazenar os valores dos registradores da UCP, quando o programa, por algum motivo, no estiver sendo executado. Essa rea de memria conhecida como registro descritor. Assim, em um determinado sistema, cada programa em execuo constitui um processo. Portanto, podemos definir processo como sendo um programa em execuo, o qual constitudo por uma seqncia de instrues, um conjunto de dados e um registro descritor. Num ambiente de multiprogramao, quando existe apenas um processador na instalao, cada processo executado um pouco de cada vez, de forma intercalada. Um processo aps receber a UCP, s perde o controle da execuo quando ocorre uma interrupo ou quando ele executa um trap, requerendo algum servio do sistema operacional. As interrupes so transparentes aos processos, pois o efeitos das mesmas apenas parar, temporariamente, a execuo de um processo, o qual continuar sendo executado, mais tarde, como se nada tivesse acontecido. Quando um processo est realmente usando a UCP, diz-se que o mesmo est no estado executando (running). Quando est esperando pelo trmino de um servio que requereu, diz-se que est no estado bloqueado (blocked). Quando o processo tem todas as condies para ser executado e s no est em execuo porque a UCP est alocada para outro processo, diz-se que o mesmo est no estado pronto (ready). O sistema operacional mantm uma lista (fila) dos processos que esto prontos, a chamada lista de processos prontos (ready list ou ready queue). O diagrama da figura 2.1 mostra como os estados de um processo podem mudar durante a execuo. O componente do sistema operacional que, aps o atendimento de uma interrupo ou trap, escolhe o prximo processo a ser executado denominado escalonador de processos (scheduler) ou despachador de processos (dispatcher). Quando dois ou mais processos tm condies de rodar, o escalonador que decide qual ser o prximo a receber tempo de CPU. Esta deciso baseada em um algoritmo de escalonamento.
trap
bloqueado
Figura 2.1 - Estados sucessivos de um processo no sistema Relgio ("clock"): fornece interrupes peridicas (~60 Hz). As decises de escalonamento podem ocorrer a cada k-sima interrupo de relgio (k>=1):
5 Escalonamento de Processos
5.1 Breve apresentao
Como memrias e terminais, a CPU um recurso dividido para cada processo no sistema. O escalonador o componente do sistema operacional que determina qual processo vai rodar num dado tempo e quanto tempo vai rodar. Sistema de partilha de tempo - permite que diversos processos funcionem simultaneamente. Em um sistema monoprocessado cria uma iluso de execuo simultnea, intercalando processos em uma base da partilha de tempo. O escalonador entrega a CPU a cada processo por um pequeno perodo de tempo, antes de trocar por outro processo. Este perodo chamado de quantum do tempo ou fatia do tempo. Dois aspectos do escalonador: Poltica As regras usadas para decidir qual processo vai rodar e quando ele ser trocado por outro. Implementao As estruturas de dados e algoritmos usados para cumprir tais polticas. Objetivos da poltica de escalonamento:
o o o
Tempo de resposta rpido para aplicaes interativas. Throughput elevado para trabalhos rodando em background. Execuo da poltica eficientemente e com despesas gerais mnimas.
Mudana de contexto - o escalonador arranja para o processador trocar de um processo para outro. O kernel salva o contexto da execuo do processo atual em seu bloco de controle do processo (PWB). (parte da rea de u do processo) O contexto uma cpia dos valores de propsito geral, gerenciamento de memria e outros registradores especiais do processo.
O kernel carrega os registradores com o contexto do processo seguinte a ser rodado, obtido do PWB do processo seguinte. A CPU comea a executar o processo seguinte. Mudana de contexto - Uma operao cara. Alm de salvar uma cpia dos registradores do processo o kernel deve executar outras tarefas do especfico da arquitetura - limpar os dados, instrues, ou tradues de endereos de cache para evitar acessos incorretos memria pelo novo processo. Nas arquiteturas pipelined (por exemplo RISC), o kernel deve limpar as instrues de pipeline Prvias para mudar o contexto. Estes fatores podem influenciar no s a implementao, mas tambm a poltica de escalonamento. O clock crtico na operao de escalonamento, porque o escalonador geralmente quer preemptar processos executando quando sua fatia de tempo expira.
Em lote: sistemas no-interativos. Preemptivo ou no preemptivo com longos intervalos de tempo para cada processo. Interativo: preempo essencial. Em tempo-real: executam somente processos que visam o progresso da aplicao (e no, genericamente, qualquer processo, como no caso interativo).
Eis alguns algoritmos: Round Robin: Cada processo executado por um intervalo de tempo (quantum). No final desse tempo, se o processo estiver executando, ser suspenso e a CPU, alocada a outro processo. Se o processo terminar, ou for bloqueado, antes do final do quantum, a CPU tambm passada para outro processo. Com Prioridades: Uma prioridade associada a cada processo, e processos com prioridade superior devem ser executados primeiro. O escalonador pode diminuir a prioridade dos processos, para prevenir que os de maior prioridade executem indefinidamente, com o aumento do seu respectivo tempo de execuo. Mltiplas Filas: Define classes com prioridades, permitindo que processos que esto na classe de menor prioridade executem por 1 quantum; na classe seguinte, por 2 quanta; na prxima , por 4 quanta; e assim por diante. Quando um processo interrompido por exceder esse tempo, a prioridade de sua classe diminuda. Tarefas Pequenas Primeiro: Designado para aplicaes no interativas, em que o tempo mdio de execuo conhecido a priori. Como o prprio nome diz, esse algoritmo define que tarefas menores devem ser executadas primeiro. Policy-Driven: Particiona a CPU de forma equnime entre os usurios (no entre processos) e define que, para n usurios ligados ao sistema, cada usurio dever receber 1/n do poder da CPU.
Toda mquina UNIX tem um clock que interrompe o sistema em intervalos fixos do tempo. Algumas mquinas requerem que o sistema operacional prepare o clock depois de cada interrupo; em outros, o clock se rearma sozinho. O perodo de tempo entre interrupes sucessivas de clock chamado de tick da CPU, tick de clock, ou simplesmente, um tick. UNIX ajusta tipicamente tick da CPU em 10 milissegundos (100 hertz). Definido geralmente no arquivo param.h. Funes do kernel geralmente medem o tempo em nmero de ticks, ao invs de em segundos ou milisegundos. O tratador de interrupo de clock funciona em resposta interrupo do pulso de disparo da ferragem, cuja prioridade cuja prioridade s perde para a interrupo por falha de energia. O tratador deve ser to rpido quanto possvel.
Ele executa as seguintes tarefas: Rearma o clock se necessrio. Atualiza as estatsticas de uso da CPU para o processo corrente. Executa funes relacionadas ao escalonador, tais como recomputao prioritria e tratador de expirao de fatia de tempo. Envia um sinal SIGXCPU para o processo corrente se ele excedeu sua quota de uso da CPU. Atualiza o clock da hora do dia e outros clocks relacionados. Por exemplo, SVR4 mantm uma varivel chamada lbolt para armazenar o nmero de ticks que se passou desde que o sistema foi iniciado. Tratamento de callouts. Acorda os processos de sistema tais como swapper e pagedaemon quando apropriado. Tratamento de alarmes.
Algumas dessas tarefas no precisam ser executadas em todo tick. A maioria dos sistemas UNIX definem uma noo de tick principal, o qual ocorre uma vez a cada n ticks de clock, onde n depende de uma varivel especfica UNIX. O escalonador executa algumas de suas tarefas somente nos ticks principais. Por exemplo, 4.3BSD executa uma recomputao prioritria a cada 4 ticks, enquanto SVR4 tratador de alarmes acorda os processos do sistema uma vez por segundo, se necessrio.
5.2.1 Callouts
Um callout guarda uma funo que o kernel deve invocar um tempo mais tarde. Em SVR4, por exemplo, algum subsistema kernel deve registrar um callout pela chamada. int to_ID = timeout (void (*fn)(), caddr_t arg, long delta); onde fn() a funo do kernel invoca, arg um argumento para passar para fn(), e delta o intervalo de tempo no tick da CPU, depois cada funo deve ser invocada. O kernel invoca a funo callout no contexto do sistema.
O valor de retorno to_ID deve ser usado para cancelar o callout, usando: void untimeout (int to_ID);
Callouts podem ser usados para vrias tarefas peridicas, tais como: Retransmisso de pacotes de rede; Certos escalonadores e funes de gerenciamento de memria; Monitoramento de dispositivos para evitar perder interrupes. Dispositivos que no atendem interrupes.
Callouts so considerados operaes normais de kernel e no devem executar uma interrupo prioritria. Entretanto, o tratador de interrupes do clock no invoca diretamente callouts. Em cada tick, o tratador do clock checa se algum callout est aguardado. Se sim, ele seta uma flag indicando que o tratador de callouts deve rodar. O sistema checa esta flag quando ele retorna para a base de interrupo prioritria e, se setada, invoca o tratador de callout. O tratador invocar cada callout que aguardado. Portanto, uma vez aguardado, o callout rodar to logo seja possvel, mas apenas depois de todas as interrupes pendentes terem sido tratadas. O kernel mantm uma lista de callouts pendentes. A organizao desta lista afeta a performance do sistema como podem existir vrios callouts pendentes. Uma vez que a lista checada em todo tick da CPU com interrupo de alta prioridade. O tempo requerido para inserir um novo callout na lista menos crtico, uma vez que as inseres tipicamente ocorrem numa prioridade mais baixa e muito menos freqente do que uma vez por tick.
Implementao do Time-to-fire Um mtodo usado no 4.3BSD ordena a lista em ordem de time to fire. Cada entrada armazena a diferena entre seu time to fire e o do callout anterior. O kernel decrementa o tempo da primeira entrada em cada tick de clock e retira o callout se o tempo chegar a zero. Outro callout aguardado na mesma hora tambm retirado.
5.2.2 Alarmes
Um processo pode requerer que o kernel envie a ele um sinal depois de um perodo especfico de tempo, tal como um alarme de relgio. H 3 tipos de alarmes tempo real, profiling e tempo virtual: o Alarme tempo real - relata o atual tempo decorrido, e notifica o processo por um sinal SIGALARM. o Profiling alarme - mede o tanto de tempo que o processo tem estado executando e usa o sinal SIGPROF para notificao. o Alarme tempo virtual - mede somente o tempo gasto pelo processo em modo usurio; emite o sinal de SIGVTALRM.
SVR4 - Usa a chamada do sistema alarm para um alarme tempo real em segundos. Usa a chamada do sistema hrtsys - interface de alta resoluo do timer, para resoluo em microsegundos. A alta resoluo dos alarmes tempo real no implicam em alta preciso. Quando um alarme tempo real programado, o kernel entrega prontamente o sinal SIGALRM ao processo da chamada. O processo no ver e no responder ao sinal at que esteja escalonado para funcionar - poderia ser um substancial atraso se o sistema for carregado pesadamente e se o processo da chamada tiver uma prioridade relativamente baixa. Os temporizadores de alta resoluo so os mais teis quando usados por processos de alta prioridade (e ainda o atraso pode ser significativo se o alarme for entregue quando o processo atual executar em modo kernel e no alcanar rapidamente um ponto de preempo).
O escalonador deve distribuir o tempo da CPU a todos os processos no sistema. Conforme a carga no sistema aumenta, cada processo recebe uma parte menor do tempo da CPU. Um sistema tpico roda vrias aplicaes concorrentemente. Estas aplicaes podem ser largamente categorizadas nas seguintes classes, baseadas em seus requisitos de escalonamento e expectativas de performance:
o
Interativo - As aplicaes com interface de usurio, que constantemente interagem com usurios, gastam muito tempo esperando por entrada do usurio. O sistema necessita reduzir o tempo e a variao mdios entre a ao do usurio e a resposta da aplicao (atraso aceitvel de aproximadamente 50-150 milissegundos). Grupo - No requer a interao do usurio; a medida de eficincia de escalonamento o tempo de concluso da tarefa na presena de outra atividade, quando comparada ao tempo requerido em um sistema inativo. Tempo Real - Geralmente aplicaes de tempo crtico; Precisam predizer o comportamento do escalonador com limites garantidos no tempo de resposta.
Uma estao de trabalho tpica roda todos os trs tipos de aplicaes. O escalonador deve balanar suas exigncias, e assegurar-se de que as funes do kernel executem tambm prontamente (por exemplo, paginao, tratamentos de interrupo, gerenciamento de processos). Em um sistema em bom funcionamento todas as aplicaes devem progredir (nenhum starvation).
SVR3 e 4.3 BSD Os sistemas so targeted em tempo dividido, ambientes interativos com usurios mltiplos; as aplicaes so uma mistura de programas interativos e de grupo. Escalonar baseado em prioridades - cada processo tem uma prioridade de escalonamento que mude com tempo. O escalonador seleciona sempre o processo em estado de pronto de prioridade mais elevada. O escalonador usa a preempo por time-slicing para escalonar processos de prioridade igual, e varia dinamicamente as prioridades do processo baseadas em seus exemplos de uso da CPU. Se um processo de prioridade elevada se tornar pronto para funcionar, o escalonador preempta o processo atual mesmo que ele no tenha terminado sua fatia ou quantum do tempo. Kernel tradicional - estritamente no-preemptivo (se um processo estiver executando cdigo kernel, devido a uma chamada do sistema ou a uma interrupo, ele no pode ser forado a deixar a CPU para um processo de mais alta prioridade (o processo pode ser preemptado se ele bloqueia um recurso, ou quando retornar ao modo usurio). Kernel no-preemptivo - resolve muitos problemas da sincronizao.
O kernel associa uma prioridade sleep com um evento ou um recurso em que um processo pode bloquear (entre 0 e 49). A prioridade sleep para o terminal de entrada 28, para o E/S de disco 20. Quando um processo em uma chamada de sistema desbloqueia, desde que um recurso se torna disponvel, seu p_pri ajustado prioridade sleep do recurso, de modo que o processo seja escalonado para rodar mais logo. Depois que o processo retorna ao modo usurio, sua prioridade ser retornada ao valor salvo no p_usrpri. A prioridade em modo usurio depende de dois fatores - o valor agradvel e o uso recente da CPU. O valor agradvel um nmero entre 0 e 39 com um default de 20. Aumentando o valor agradvel diminui a prioridade. Somente o superusurio pode diminuir o valor agradvel de um processo, aumentando desse modo sua prioridade. O campo do p_cpu uma medida do uso recente da CPU pelo processo. inicializado em zero quando um processo criado. Em cada tick, o tratador do clock incrementa o valor do p_cpu para o processo atual, a um mximo de 127. Em cada segundo, o clock invoca uma rotina chamada schedcpu() escalonada por um callout, que reduz o valor do p_cpu de cada processo por um fator de deteriorao. SVR3 usa 1/2 como o fator de deteriorao; 4.3 BSD usa uma frmula: decay = (2 * load_average) / (2 * load_average + 1); onde load_average o nmero de processos terminados no ltimo segundo, a rotina schedcpu( ) tambm recomputa a prioridade de usurio de todos os processos usando a frmula: p_usrpri = PUSER + (p_cpu / 4) + ( 2 * p_nice); onde PUSER a base de prioridade 50.
Quando um processo roda muito, seu fator de p_cpu aumenta, e seus valor do p_usrpri aumenta - sua prioridade torna-se mais baixa. Quanto mais tempo um processo espera antes de ser escalonado, mais o fator de deteriorao abaixa seu p_cpu e sua prioridade aumenta. o Impede starvation de um processo de prioridade mais baixa. o Favorece processos I/O bound sobre processos CPU-bound. Frmula SVR3 - quando a carga de sistema for muito elevada, o uso da CPU no tem muito impacto na prioridade, e os processos que comearam com uma prioridade mais baixa morrem desproporcionalmente. O 4.3 BSD fora o fator de decremento a depender da carga do sistema. Carga elevada - os processos que recebem ciclos da CPU tero sua prioridade diminuda rapidamente.
Uma varivel global whichqs contm um bitmask com um bit para cada fila - o bit setado se houver um processo nessa fila. Somente os processos em estado de pronto so mantidos nestas filas de escalonadores.
O processo de prioridade a mais elevada funciona sempre, a menos que o processo atual estiver executando em modo kernel. A todo processo atribudo um quantum fixo do tempo (por exemplo ms 100 em 4.3 BSD) isto afeta somente o escalonamento de mltiplos processos na mesma fila de execuo. A cada 100ms, o kernel invoca atravs de um callout uma rotina chamada roundrobin() para escalonar o processo seguinte da mesma fila. Se um processo de mais alta prioridade estiver pronto, ele seria preferencialmente escalonado sem esperar por roundrobin( ). Se todos os processos da fila de pronto estiverem na fila de mais baixa prioridade, o processo corrente continua a rodar mesmo que seu quantum tenha expirado. A rotina schedcpu() recomputa a prioridade de cada processo uma vez cada segundo. Se todos os processos restantes estiverem em estado de pronto restantes estiverem em umas filas mais baixas de uma prioridade, o processo atual continua a funcionar mesmo que seu quantum expire. O tratador de interrupo do clock recomputa a prioridade do processo corrente a cada 4 ticks. H 3 situaes, onde uma mudana de contexto indicada:
o o
Os blocos processo atual em um recurso ou em sadas - uma mudana voluntria do contexto (swtch() da chamada do sleep() ou do exit() ) O procedimento de recomputao da prioridade resulta na prioridade de um outro processo tornar-se maior do que aquele do atual (ajuste a varivel runrun, indicando a necessidade para a mudana do contexto). O processo corrente ou um tratador de interrupo acorda um processo de mais alta prioridade (ajusta a varivel runrun, indicando a necessidade para a mudana de contexto).
Cada vez que um processo retorna ao modo usurio o kernel verifica a flag do runrun e se setada chama a rotina swtch() para iniciar uma mudana de contexto.
5.4.4 Anlise
No escala bem ineficiente ao recomputar todas as prioridades a cada segundo, se o nmero dos processos for muito grande. No h nenhuma maneira garantir uma parcela de recursos da CPU a um processo especfico ou o grupo dos processos As aplicaes tm pouco controle sobre suas prioridades (o mecanismo do valor agradvel simples e inadequado).
Inverso da prioridade devido no preempo do kernel (os processos de uma prioridade mais elevada podem ter que esperar uma quantidade de tempo significativa mesmo aps estar em estado de pronto).
Necessite mais suporte em tempo real para as aplicaes que requerem o comportamento mais previsvel e tempos de resposta limitados.
Suporte uma escala de aplicaes diversa (por exemplo tempo real) Separao da poltica de escalonamento do mecanismo de implementao. Fornece um controle maior da aplicao sobre sua prioridade e escalonamento. Define uma estrutura de escalonamento com uma relao bem orientada ao kernel. Permite que as novas polticas de escalonamento sejam adicionadas em uma maneira modular, incluindo o carregamento dinmico de execues do escalonador. Limita a latncia de trmino para aplicaes de tempo crtico;
Nova Abstrao fundamental - classe de escalonamento, a qual define a poltica de escalonamento para todos os processos que pertencem classe. Por default classes time-sharing e realtime. O escalonador prov um conjunto de rotinas independentes de classes para servios comuns, como a mudana de contexto, manipulao da fila de prontos, preempo. Define uma relao procedural para funes dependentes de classes tais como a computao da prioridade e a herana. (por exemplo a classe realtime usa prioridades fixas; a classe time-sharing varia dinamicamente as prioridades do processo). Metodologia orientada a objetos - o escalonador representa uma classe de base abstrata, e cada classe de escalonamento age como uma subclasse (classe derivada).
A camada classe-independente responsvel pela troca de contexto, a gerncia de fila de pronto e a preempo. O processo de mais alta prioridade sempre roda (exceto para processamento em kernel no-preemptivo). O nmero das prioridades foi aumentado para 160, e h uma fila separada para cada prioridade. Numericamente os valores maiores de prioridade correspondem a prioridades mais elevadas. A atribuio e a recomputao de prioridades , entretanto, so executados pela camada classe-dependente. Manipulao da fila -- setfrontdq(), setbackdq(), dispdeq().
Tipicamente, um processo recentemente executado colocado na cauda de sua fila de pronto, enquanto um processo que foi preemptado antes que seu quantum expirasse retornado para a cabea da fila. Limitao principal para o uso em aplicaes realtime -- o kernel nopreemptivo. Os processos tempo-real precisam ter uma baixa latncia de trmino, a qual a diferena entre o tempo onde se torna pronto para rodar e o tempo em que realmente ele comea realmente a rodar. Com kernels no-preemptivos, se um processo realtime se tornar pronto quando o processo atual executa uma chamada de sistema, pode haver um significativo atraso antes que a mudana de contexto possa ocorrer. SVR4 dirige-se edio introduzindo diversos pontos do preempto - lugares no cdigo do kernel, onde todas as estruturas de dados do kernel esto em um estado estvel, e no kernel esto a ponto de embarcar em uma computao longa. Quando um ponto de preempo alcanado, o kernel verifica se um processo realtime est pronto para funcionar, e se sim preempta o processo atual.
Implementao
A estrutura classfuncs um vetor de ponteiros para as funes que implementam a interface classe-dependente para qualquer classe. Uma tabela global de classe contm uma entrada para cada classe. Esta entrada composta do nome da classe, de um ponteiro a uma funo de iniciao, e de um ponteiro para o vetor da classfuncs para essa classe. Quando um processo criado primeiramente herda a classe da prioridade de seu pai. Ele pode subseqentemente ser movido para uma classe diferente atravs da chamada de sistema priocntl. A estrutura do proc tem trs campos que so usados pelas classes de escalonamento: o p_cid -- classID -- um ndice na tabela global da classe. o p_clfuncs -- ponteiro para o vetor classfuncs para a classe a que o processo pertence o p_clproc -- ponteiro a uma estrutura classe-dependente de estrutura de dados private.
Um conjunto de macros resolve chamadas s funes genricas da relao e invoca as funes classe-dependentes corretas, por exemplo. #define CL_SLEEP(procp, clprocp, ...) \ (*(procp)->p_clfuncs->cl_sleep)(clprocp, ...)
A classe de escalonamento decide as polticas para a computao da prioridade e escalonamento dos processos que lhe pertencem. A classe de escalonamento determina a escala das prioridades para seus processos, e sob que circunstncias a prioridade do processo pode mudar. A classe de escalonamento decide o tamanho da fatia do tempo cada vez que um processo roda. A fatia do tempo pode ser a mesma para todos os processos ou pode variar de acordo com a prioridade - de um tick ao infinito, por exemplo para as aplicaes realtime que devem rodar at completar. Diferentes classes de escalonamento podem implementar diferentes interfaces de comportamento, por exemplo: CL_TICK - chamada do tratador do tratador de interrupo do clock.
No escalonador padro - a prioridade recomputada a cada quarto ticks; na classe realtime -- usa prioridades fixas e conseqentemente no faz a recomputao das prioridades. O cdigo da Classe-dependente decide quando o quantum do tempo expirou.
A classe time-sharing a classe default para um processo. Muda prioridades do processo dinamicamente e usa o round-robin para escalonar processos com a mesma prioridade. A classe time-sharing usa uma tabela de parmetro esttica para controlar as prioridades e fatias de tempo do processo. A fatia do tempo dada a um processo depende de sua prioridade de escalonamento. Pelo default Quanto mais baixa a prioridade do processo, maior sua fatia do tempo. A classe time-sharing usa escalonamento dirigida a eventos (no precisa recomputar as prioridades de todos os processos a cada segundo). Exemplo de eventos relacionados a prioridade:
o o o
Penalizar o processo cada vez que ele usa sua fatia do tempo. Credita ao processo se ele bloqueia um evento ou em um recurso Credita ao processo se ele levar muito tempo para usar seu quantum
Os eventos afetam geralmente somente 1 processo -- rpida.recomputao. A tabela de encerramento define como os vrios eventos mudam a prioridade de um processo. A classe time-sharing usa a estrutura tsproc para armazenar dados classedependente.
o o o o o
ts_timeleft -- tempo restante no quantum ts_cpupri -- parte da prioridade do sistema. ts_upri -- parte da prioridade do usurio (valor agradvel) ts_umdpri -- prioridade do modo usurio (ts_cpupri + ts_upri, mas < 59) ts_dispwait -- nmero dos segundos de tempo de clock desde o comeo do quantum
O valor agradvel (ts_upri) est entre -20 e +19, com o valor default 0. (somente o superusurio pode aumentar o valor com priocntl).
o ts_cpupri ajustado de acordo com a tabela de parmetro do relatrio A tabela de parmetro contem uma entrada para cada prioridade na classe. A tabela time-sharing contem as seguintes entradas:
o o o o o o
ts_globpri -- prioridade global para esta entrada ts_quantum -- quantum do tempo para esta prioridade ts_tqexp -- ts_cpupri novo a ajustar-se quando o quantum expirar ts_slpret -- ts_cpupri novo a ajustar-se ao retornar ao modo usurio aps dormir. ts_maxwait -- nmero dos segundos para esperar a expirao do quantum antes de usar o ts_lwait ts_lwait -- uso em vez do ts_tqexp se o processo levar mais tempo do que o ts_maxwait para usar seu quantum.
A classe realtime usa prioridades na escala 100-159. Estas prioridades so mais elevadas do que todo o processo time-sharing, mesmo aqueles em modo kernel, o que significa que um processo realtime ser escalonado antes de qualquer processo do kernel. Os processos realtime so escalonados quando o kernel alcana um ponto de preempo, se o processo atual roda em modo kernel, ou quando o processo atual roda em modo usurio. Os processos realtime so caracterizados por um quantum e uma prioriade fixa.
Os processos realtime requerem a latncia limitada . to bem quanto o tempo de resposta limitado.
Latncia da trmino - o tempo entre quando o processo se tornar pronto para executar e quando comear a rodar. Tempo de resposta - o tempo entre a ocorrncia de um evento que requeira uma resposta do processo e a resposta do mesmo. Necessidade de ambas as vezes ter um limite superior bem definido que esteja dentro de um limite razovel. O tempo de resposta a soma do tempo requerido pelo tratador de interrupo para processar o evento, a latncia de trmino, e o tempo levado pelo processo realtime para responder aos eventos. A latncia de trmino de interesse grande para o kernel. Em kernels no-preemptivos - a latncia de trmino pode ser muito elevada. Introduo de pontos do preempo - reduz significativamente a latncia de trmino, limitada pelo caminho mximo do cdigo entre dois pontos do preempo.
Todos os processos no sistema Todos os processos em um grupo ou em uma sesso de processos Todos os processos em uma classe de escalonamento. Todos os processos possudos por um usurio particular Todos os processos que tm o mesmo pai
5.5.6 Anlise
Um projeto muito melhor. Mais escalvel e flexvel. Os sistemas realtime requerem um kernel totalmente preemptvel. Extremamente difcil de ajustar o sistema para um conjunto misturado de aplicaes.
Solaris um sistema multithreaded, sistema operacional multiprocessado. O escalonador realado. Latncia de trmino mais baixa suporta melhor processamento em tempo real.
Kernel inteiramente preemptivo Garante um bom tempo de resposta. A maioria de estruturas de dados globais do kernel devem ser protegidas por objetos apropriados da sincronizao, tais como excluso mtua(mutexes) ou semaforos. As interrupes so executadas usando as threads especiais do kernel que podem usar as primitivas padro de sincronizao do kernel e bloquear recursos se necessrio. Portanto, o Solaris raramente precisa aumentar o nvel de interrupo para proteger regies crticas, e tem somente alguns segmentos de cdigo nopreemptivos. Um processo de prioridade mais alta pode ser escalonado assim que estiver pronto. As threads de interrupo funcionam sempre na prioridade mais alta do sistema.
Os processadores podem comunicar-se com cada outro emitindo interrupes do cross-processor. Uma thread de baixa prioridade pode bloquear uma thread de prioridade mais alta durante um longo perodo do tempo, causado geralmente por escalonamento escondido ou por inverso de prioridade. (o Solaris trata estes efeitos).
O kernel executa frequentemente algum trabalho assincronamente em favor das threads. O kernel escalona esta tarefa sem considerar a prioridade da thread pela qual est fazendo a tarefa. Isto chamado escalonar escondido. Por exemplo, rotinas de STREAMS e callouts SVR4 trata STREAMS em modo kernel, imediatamente antes que algum processo retorne ao modo usurio, com a prioridade do modo corrente (A requisio do STREAM atual deve ter sido iniciada por um processo de mais baixa prioridade) Solaris faz o processamento de STREAMS em threads do kernel, que funcionam em uma prioridade mais baixa do que qualquer thread tempo real. (Novo problema - como tratar as requisies de STREAMS iniciadas por threads tempo real) Os callouts em SVR4 so tratados por interrupes de mais baixa prioridade, que ainda assim so mais elevadas do que qualquer prioridade tempo real. Solaris trata os callouts por uma thread de callout, que roda na prioridade mxima do sistema, que mais baixa do que toda a prioridade realtime. Os callouts requisitados por processos tempo real so mantidos separados e invocados no nvel mais baixo de interrupo.
O problema da inverso da prioridade consiste numa situao onde um processo de mais baixa prioridade retm um recurso necessrio a um processo de prioridade mais alta, obstruindo desse modo processos de prioridade mais alta. Este problema pode ser resolvido com uma tcnica chamada herana da prioridade ou emprstimo de prioridade. Quando uma thread de prioridade mais alta bloqueia um recurso, ele temporariamente transferirem sua prioridade para a thread de mais baixa prioridade que possui o recurso. A herana de prioridade deve ser transitiva. O kernel deve poder atravessar todos os objetos e threads bloqueadas na sincronizao comeando de qualquer objeto dado.
Cada thread tem duas prioridades - uma prioridade global que determinada pela sua classe de escalonamento e uma prioridade herdada que depende de sua interao com objetos da sincronizao. A prioridade herdada normalmente zero a menos que a thread tenha se beneficiado da herana de prioridade. A prioridade de escalonamento da thread a mais elevada de suas prioridades, herdadas e globais. Quando uma thread deve bloquear um recurso, ela chama uma funo (pi_willto() ) para passar sua prioridade para todas as threads que esto diretamente ou indiretamente bloqueadas por ela.
A herana de prioridade s pode ser implementada em situaes onde ns sabemos que a thread vai liberar o recurso. Isto possvel quando o recurso mantido por uma nica thread conhecida. Solaris fornece quatro tipos de objetos de sincronizao -- mutexes, semforos, variveis de condio e bloqueios de leitores/escritores. Com mutexes, o dono sempre conhecido. Para semforos e variveis da condio o dono geralmente indeterminado, e a herana de prioridade no usada. Com bloqueio de leitor-escritor Mltiplos bloqueios de leitura podem manter o bloqueio simultaneamente, e ento o bloqueio ter mltiplos donos. impraticvel para o kernel manter um ponteiro para todos os donos, ento o Solaris define owner-of-record para ser a primeira thread que obtm o bloqueio de leitura. A primeira thread de leitura herdar a prioridade de um escritor de mais alta prioridade, mas quando terminar, as outras threads de leitura que estavam bloqueadas no mesmo bloqueui no podem herdar a prioridade do escritor - a inverso de prioridade pode acontecer. Soluo til em a maioria de casos. O atraso do pior caso ainda muito maior do que o aceitvel para muitas aplicaes tempo real. A corrente de bloqueio pode crescer arbitrariamente.
5.6.7 Turnstiles
O kernel contm centenas dos objetos da sincronizao, um para cada estrutura de dados que deve ser protegida separadamente. Tais objetos devem manter uma grande quantidade de informao, tal como uma fila das threads que esto bloqueadas. Ter uma estrutura de dados grande para cada objeto desperdcio. O Solaris fornece uma soluo espao-eficaz usando uma abstrao chamada turnstile. Um objeto de sincronizao contm um ponteiro para um turnstile, o qual contm todos os dados necessrios para manipular o objeto, tal como a fila de threads bloqueadas e um ponteiro para a thread que atualmente possui o recurso. Os turnstiles so alocados dinamicamente de um pool que cresce com o nmero de threads alocadas no sistema.
5.6.8 Anlise
Os otimizadores de escalonadores fazem do Solaris um sofisticado ambiente para multithreaded e processamento tempo real para monoprocessadores e multiprocessadores. O Solaris apropriado para muitas aplicaes tempo real, mas ainda primeiramente um sistema operacional de propsito geral.
A thread escalonada roda em um perodo fixo de tempo de quantum. No fim de seu quantum, ele pode ser preemptado por outra thread de prioridade igual ou superior.
Para isto funcinoar, o sistema escalona no apenas o tempo de CPU, mas tambm o disco e as atividades de rede. No escalonador Tri-nvel, tarefas de propsito geral so totalmente preemptivas. Tarefas tempo real podem ser preemptadas por tarefas iscronas com pontos de preempo bem definidos. Cada tarefa tem uma prioridade fixa de escalonamento, que depende do seu perodo. Quanto menor o perodo maior sua prioridade. Uma tarefa iscrona de alta prioridade pode preemptar uma de mais baixa prioridade num dos pontos de preempo.
Bilbiografia
Vahalia, Uresh. UNIX Internals the New Frontiers. Prentice-Hall, 1996.