So Cap02

Sistemas Operacionais II - Gerncia de Tarefas
Prof. Carlos Alberto Maziero DAInf UTFPR http://dainf.ct.utfpr.edu.br/maziero 18 de novembro de 2011
Copyright (c) 2006 Carlos Alberto Maziero. garantida a permisso para copiar, distribuir e/ou modicar este documento sob os termos da Licena de Documentao Livre GNU (GNU Free Documentation License), Verso 1.2 ou qualquer verso posterior publicada pela Free Software Foundation. A licena est disponvel em http://www.gnu.org/licenses/gfdl.txt. Este texto foi produzido usando exclusivamente software livre: Sistema Operacional Linux (distriA buies Fedora e Ubuntu), compilador de texto L TEX 2 , gerenciador de referncias BibTeX, editor grco Inkscape, criadores de grcos GNUPlot e GraphViz e processador PS/PDF GhostScript, entre outros.
c prof. Carlos Maziero
SUMRIO 2
Sumrio
1 2 3 Objetivos O conceito de tarefa A gerncia de tarefas 3.1 Sistemas mono-tarefa . . . . . . . . 3.2 Sistemas multi-tarefa . . . . . . . . 3.3 Sistemas de tempo compartilhado 3.4 Ciclo de vida das tarefas . . . . . . Implementao de tarefas 4.1 Contextos . . . . . . . . . . 4.2 Trocas de contexto . . . . . . 4.3 Processos . . . . . . . . . . . 4.3.1 Criao de processos 4.4 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 6 6 7 8 9 11 11 12 13 14 17 23 24 25 26 28 30 32 33 34 38 38
Escalonamento de tarefas 5.1 Objetivos e mtricas . . . . . . . . . . . . . . . . 5.2 Escalonamento preemptivo e no-preemptivo 5.3 Escalonamento FCFS (First-Come, First Served) 5.4 Escalonamento SJF (Shortest Job First) . . . . . . 5.5 Escalonamento por prioridades . . . . . . . . . 5.5.1 Denio de prioridades . . . . . . . . . 5.5.2 Inanio e envelhecimento de tarefas . 5.5.3 Inverso e herana de prioridades . . . 5.6 Outros algoritmos de escalonamento . . . . . . 5.7 Um escalonador real . . . . . . . . . . . . . . .
Objetivos 3
Resumo Um sistema de computao quase sempre tem mais atividades a executar que o nmero de processadores disponveis. Assim, necessrio criar mtodos para multiplexar o(s) processador(es) da mquina entre as atividades presentes. Alm disso, como as diferentes tarefas tm necessidades distintas de processamento, e nem sempre a capacidade de processamento existente suciente para atender a todos, estratgias precisam ser denidas para que cada tarefa receba uma quantidade de processamento que atenda suas necessidades. Este mdulo apresenta os principais conceitos, estratgias e mecanismos empregados na gesto do processador e das atividades em execuo em um sistema de computao.
Objetivos
Em um sistema de computao, frequente a necessidade de executar vrias tarefas distintas simultaneamente. Por exemplo: O usurio de um computador pessoal pode estar editando uma imagem, imprimindo um relatrio, ouvindo msica e trazendo da Internet um novo software, tudo ao mesmo tempo. Em um grande servidor de e-mails, centenas de usurios conectados remotamente enviam e recebem e-mails atravs da rede. Um navegador Web precisa buscar os elementos da pgina a exibir, analisar e renderizar o cdigo HTML e o grcos recebidos, animar os elementos da interface e responder aos comandos do usurio. No entanto, um processador convencional somente trata um uxo de instrues de cada vez. At mesmo computadores com vrios processadores (mquinas Dual Pentium ou processadores com tecnologia hyper-threading, por exemplo) tm mais atividades a executar que o nmero de processadores disponveis. Como fazer para atender simultaneamente as mltiplas necessidades de processamento dos usurios? Uma soluo ingnua seria equipar o sistema com um processador para cada tarefa, mas essa soluo ainda invivel econmica e tecnicamente. Outra soluo seria multiplexar o processador entre as vrias tarefas que requerem processamento. Por multiplexar entendemos compartilhar o uso do processador entre as vrias tarefas, de forma a atend-las da melhor maneira possvel. Os principais conceitos abordados neste captulo compreendem: Como as tarefas so denidas; Quais os estados possveis de uma tarefa; Como e quando o processador muda de uma tarefa para outra; Como ordenar (escalonar) as tarefas para usar o processador.
O conceito de tarefa 4
O conceito de tarefa
Uma tarefa denida como sendo a execuo de um uxo sequencial de instrues, construdo para atender uma nalidade especca: realizar um clculo complexo, a edio de um grco, a formatao de um disco, etc. Assim, a execuo de uma sequncia de instrues em linguagem de mquina, normalmente gerada pela compilao de um programa escrito em uma linguagem qualquer, denominada tarefa ou atividade (do ingls task). importante ressaltar as diferenas entre os conceitos de tarefa e de programa: Um programa um conjunto de uma ou mais sequncias de instrues escritas para resolver um problema especco, constituindo assim uma aplicao ou utilitrio. O programa representa um conceito esttico, sem um estado interno denido (que represente uma situao especca da execuo) e sem interaes com outras entidades (o usurio ou outros programas). Por exemplo, os arquivos C:\Windows\notepad.exe e /usr/bin/nano so programas de edio de texto. Uma tarefa a execuo, pelo processador, das sequncias de instrues denidas em um programa para realizar seu objetivo. Trata-se de um conceito dinmico, que possui um estado interno bem denido a cada instante (os valores das variveis internas e a posio atual da execuo) e interage com outras entidades: o usurio, os perifricos e/ou outras tarefas. Tarefas podem ser implementadas de vrias formas, como processos (Seo 4.3) ou threads (Seo 4.4). Fazendo uma analogia clssica, pode-se dizer que um programa o equivalente de uma receita de torta dentro de um livro de receitas (um diretrio) guardado em uma estante (um disco) na cozinha (o computador). Essa receita de torta dene os ingredientes necessrios e o modo de preparo da torta. Por sua vez, a ao de executar a receita, providenciando os ingredientes e seguindo os passos denidos na receita, a tarefa propriamente dita. A cada momento, a cozinheira (o processador) est seguindo um passo da receita (posio da execuo) e tem uma certa disposio dos ingredientes e utenslios em uso (as variveis internas da tarefa). Assim como uma receita de torta pode denir vrias atividades inter-dependentes para elaborar a torta (preparar a massa, fazer o recheio, decorar, etc), um programa tambm pode denir vrias sequncias de execuo inter-dependentes para atingir seus objetivos. Por exemplo, o programa do navegador Web ilustrado na gura 1 dene vrias tarefas que uma janela de navegador deve executar simultaneamente, para que o usurio possa navegar na Internet: 1. Buscar via rede os vrios elementos que compem a pgina Web; 2. Receber, analisar e renderizar o cdigo HTML e os grcos recebidos; 3. Animar os diferentes elementos que compem a interface do navegador; 4. Receber e tratar os eventos do usurio (clicks) nos botes do navegador;
O conceito de tarefa 5
4 2 1 3
Figura 1: Tarefas de um navegador Internet Dessa forma, as tarefas denem as atividades a serem realizadas dentro do sistema de computao. Como geralmente h muito mais tarefas a realizar que processadores disponveis, e as tarefas no tm todas a mesma importncia, a gerncia de tarefas tem uma grande importncia dentro de um sistema operacional.
A gerncia de tarefas 6
A gerncia de tarefas
Em um computador, o processador tem executar todas as tarefas submetidas pelos usurios. Essas tarefas geralmente tm comportamento, durao e importncia distintas. Cabe ao sistema operacional organizar as tarefas para execut-las e decidir em que ordem faz-lo. Nesta seo ser estudada a organizao bsica do sistema de gerncia de tarefas e sua evoluo histrica.
3.1
Sistemas mono-tarefa
Os primeiros sistemas de computao, nos anos 40, executavam apenas uma tarefa de cada vez. Nestes sistemas, cada programa binrio era carregado do disco para a memria e executado at sua concluso. Os dados de entrada da tarefa eram carregados na memria juntamente com a mesma e os resultados obtidos no processamento eram descarregados de volta no disco aps a concluso da tarefa. Todas as operaes de transferncia de cdigo e dados entre o disco e a memria eram coordenados por um operador humano. Esses sistemas primitivos eram usados sobretudo para aplicaes de clculo numrico, muitas vezes com ns militares (problemas de trigonometria, balstica, mecnica dos uidos, etc). A gura 2 a seguir ilustra um sistema desse tipo.
dados
Memria
tarefa resultados
disco
3 processador 2
control. de disco 1 4
barramentos
Figura 2: Sistema mono-tarefa: 1) carga do cdigo na memria, 2) carga dos dados na memria, 3) processamento, consumindo dados e produzindo resultados, 4) ao trmino da execuo, a descarga dos resultados no disco. Nesse mtodo de processamento de tarefas possvel delinear um diagrama de estados para cada tarefa executada pelo sistema, que est representado na gura 3.
nova
inicia a execuo
executando
termina a execuo
terminada
Figura 3: Diagrama de estados de uma tarefa em um sistema mono-tarefa. Com a evoluo do hardware, as tarefas de carga e descarga de cdigo entre memria e disco, coordenadas por um operador humano, passaram a se tornar crticas: mais tempo era perdido nesses procedimentos manuais que no processamento da tarefa em
Sistemas multi-tarefa 7
si. Para resolver esse problema foi construdo um programa monitor, que era carregado na memria no incio da operao do sistema com a funo de coordenar a execuo dos demais programas. O programa monitor executava continuamente os seguintes passos sobre uma la de programas a executar, armazenada no disco: 1. carregar um programa do disco para a memria; 2. carregar os dados de entrada do disco para a memria; 3. transferir a execuo para o programa recm-carregado; 4. aguardar o trmino da execuo do programa; 5. escrever os resultados gerados pelo programa no disco. Percebe-se claramente que a funo do monitor gerenciar uma la de programas a executar, mantida no disco. Na medida em que os programas so executados pelo processador, novos programas podem ser inseridos na la pelo operador do sistema. Alm de coordenar a execuo dos demais programas, o monitor tambm colocava disposio destes uma biblioteca de funes para simplicar o acesso aos dispositivos de hardware (teclado, leitora de cartes, disco, etc). Assim, o monitor de sistema constitui o precursor dos sistemas operacionais.
3.2
Sistemas multi-tarefa
O uso do programa monitor agilizou o uso do processador, mas outros problemas persistiam. Como a velocidade de processamento era muito maior que a velocidade de comunicao com os dispositivos de entrada e sada1 , o processador cava ocioso durante os perodos de transferncia de informao entre disco e memria. Se a operao de entrada/sada envolvia tas magnticas, o processador podia car vrios minutos parado, esperando. O custo dos computadores era elevado demais (e sua capacidade de processamento muito baixa) para permitir deix-los ociosos por tanto tempo. A soluo encontrada para resolver esse problema foi permitir ao processador suspender a execuo da tarefa que espera dados externos e passar a executar outra tarefa. Mais tarde, quando os dados de que necessita estiverem disponveis, a tarefa suspensa pode ser retomada no ponto onde parou. Para tal, necessrio ter mais memria (para poder carregar mais de um programa ao mesmo tempo) e denir procedimentos para suspender uma tarefa e retom-la mais tarde. O ato de retirar um recurso de uma tarefa (neste caso o recurso o processador) denominado preempo. Sistemas que implementam esse conceito so chamados sistemas preemptivos. A adoo da preempo levou a sistemas mais produtivos (e complexos), nos quais vrias tarefas podiam estar em andamento simultaneamente: uma estava ativa e as demais suspensas, esperando dados externos ou outras condies. Sistemas que suportavam essa funcionalidade foram denominados monitores multi-tarefas. O diagrama de estados da gura 4 ilustra o comportamento de uma tarefa em um sistema desse tipo:
Essa diferena de velocidades permanece imensa nos sistemas atuais. Por exemplo, em um computador atual a velocidade de acesso memria de cerca de 10 nanossegundos (10 109 s), enquanto a velocidade de acesso a dados em um disco rgido IDE de cerca de 10 milissegundos (10 103 s), ou seja, um milho de vezes mais lento!
1

terminou de ser carregada em memria
Sistemas de tempo compartilhado 8
nova
pronta
inicia a execuo
executando
termina a execuo
terminada
dado disponvel ou evento ocorreu
suspensa
aguarda um dado externo ou outro evento
Figura 4: Diagrama de estados de uma tarefa em um sistema multi-tarefas.
3.3
Sistemas de tempo compartilhado
Solucionado o problema de evitar a ociosidade do processador, restavam no entanto vrios outros problemas a resolver. Por exemplo, um programa que contm um lao innito jamais encerra; como fazer para abortar a tarefa, ou ao menos transferir o controle ao monitor para que ele decida o que fazer? Situaes como essa podem ocorrer a qualquer momento, por erros de programao ou intencionalmente, como mostra o exemplo a seguir:
1 2 3 4 5 6 7 8 9
void main () { int i = 0, soma = 0 ; while (i < 1000) soma += i ; // erro: o contador i no foi incrementado printf ("A soma vale %d\n", soma); }
Esse tipo de programa podia inviabilizar o funcionamento do sistema, pois a tarefa em execuo nunca termina nem solicita operaes de entrada/sada, monopolizando o processador e impedindo a execuo das demais tarefas (pois o controle nunca volta ao monitor). Alm disso, essa soluo no era adequada para a criao de aplicaes interativas. Por exemplo, um terminal de comandos pode ser suspenso a cada leitura de teclado, perdendo o processador. Se ele tiver de esperar muito para voltar ao processador, a interatividade com o usurio ca prejudicada. Para resolver essa questo, foi introduzido no incio dos anos 60 um novo conceito: o compartilhamento de tempo, ou time-sharing, atravs do sistema CTSS Compatible TimeSharing System [Corbat, 1963]. Nessa soluo, cada atividade que detm o processador recebe um limite de tempo de processamento, denominado quantum2 . Esgotado seu quantum, a tarefa em execuo perde o processador e volta para uma la de tarefas prontas, que esto na memria aguardando sua oportunidade de executar. Em um sistema operacional tpico, a implementao da preempo por tempo tem como base as interrupes geradas pelo temporizador programvel do hardware. Esse temporizador normalmente programado para gerar interrupes em intervalos regulares (a cada milissegundo, por exemplo) que so recebidas por um tratador de
A durao atual do quantum depende muito do tipo de sistema operacional; no Linux ela varia de 10 a 200 milissegundos, dependendo do tipo e prioridade da tarefa [Love, 2004].
2
Ciclo de vida das tarefas 9
interrupo (interrupt handler); as ativaes peridicas do tratador de interrupo so normalmente chamadas de ticks do relgio. Quando uma tarefa recebe o processador, o ncleo ajusta um contador de ticks que essa tarefa pode usar, ou seja, seu quantum denido em nmero de ticks. A cada tick, o contador decrementado; quando ele chegar a zero, a tarefa perde o processador e volta la de prontas. Essa dinmica de execuo est ilustrada na gura 5.
ticks do relgio de hardware
ncleo
tarefa
c=20
tarefa
c=19
...
c=18
tarefa
c=2
tarefa
c=1
ncleo
c=0
ativaes do tratador de interrupo
Figura 5: Dinmica da preempo por tempo (quantum igual a 20 ticks). O diagrama de estados das tarefas deve ser reformulado para incluir a preempo por tempo que implementa a estratgia de tempo compartilhado. A gura 6 apresenta esse novo diagrama.
m do quantum
nova
terminou de ser carregada em memria
recebe o processador
pronta
executando
termina a execuo
terminada
dado disponvel ou evento ocorreu
suspensa
aguarda um dado externo ou outro evento
Figura 6: Diagrama de estados de uma tarefa em um sistema de tempo compartilhado.
3.4
Ciclo de vida das tarefas
O diagrama apresentado na gura 6 conhecido na literatura da rea como diagrama de ciclo de vida das tarefas. Os estados e transies do ciclo de vida tm o seguinte signicado:
Ciclo de vida das tarefas 10
Nova : A tarefa est sendo criada, i.e. seu cdigo est sendo carregado em memria, junto com as bibliotecas necessrias, e as estruturas de dados do ncleo esto sendo atualizadas para permitir sua execuo. Pronta : A tarefa est em memria, pronta para executar (ou para continuar sua execuo), apenas aguardando a disponibilidade do processador. Todas as tarefas prontas so organizadas em uma la cuja ordem determinada por algoritmos de escalonamento, que sero estudados na Seo 5. Executando : O processador est dedicado tarefa, executando suas instrues e fazendo avanar seu estado. Suspensa : A tarefa no pode executar porque depende de dados externos ainda no disponveis (do disco ou da rede, por exemplo), aguarda algum tipo de sincronizao (o m de outra tarefa ou a liberao de algum recurso compartilhado) ou simplesmente espera o tempo passar (em uma operao sleeping, por exemplo). Terminada : O processamento da tarefa foi encerrado e ela pode ser removida da memria do sistema. To importantes quanto os estados das tarefas apresentados na gura 6 so as transies entre esses estados, que so explicadas a seguir: Nova : Esta transio ocorre quando uma nova tarefa admitida no sistema e comea a ser preparada para executar. Nova Pronta : ocorre quando a nova tarefa termina de ser carregada em memria, juntamente com suas bibliotecas e dados, estando pronta para executar. Pronta Executando : esta transio ocorre quando a tarefa escolhida pelo escalonador para ser executada, dentre as demais tarefas prontas. Executando Pronta : esta transio ocorre quando se esgota a fatia de tempo destinada tarefa (ou seja, o m do quantum); como nesse momento a tarefa no precisa de outros recursos alm do processador, ela volta la de tarefas prontas, para esperar novamente o processador. Executando Terminada : ocorre quando a tarefa encerra sua execuo ou abortada em consequncia de algum erro (acesso invlido memria, instruo ilegal, diviso por zero, etc). Na maioria dos sistemas a tarefa que deseja encerrar avisa o sistema operacional atravs de uma chamada de sistema (no Linux usada a chamada exit). Terminada : Uma tarefa terminada removida da memria e seus registros e estruturas de controle no ncleo so apagadas. Executando Suspensa : caso a tarefa em execuo solicite acesso a um recurso no disponvel, como dados externos ou alguma sincronizao, ela abandona o processador e ca suspensa at o recurso car disponvel.
Implementao de tarefas 11
Suspensa Pronta : quando o recurso solicitado pela tarefa se torna disponvel, ela pode voltar a executar, portanto volta ao estado de pronta. A estrutura do diagrama de ciclo de vida das tarefas pode variar de acordo com a interpretao dos autores. Por exemplo, a forma apresentada neste texto condiz com a apresentada em [Silberschatz et al., 2001] e outros autores. Por outro lado, o diagrama apresentado em [Tanenbaum, 2003] divide o estado suspenso em dois subestados separados: bloqueado, quando a tarefa aguarda a ocorrncia de algum evento (tempo, entrada/sada, etc) e suspenso, para tarefas bloqueadas que foram movidas da memria RAM para a rea de troca pelo mecanismo de memria virtual (vide Seo ??). Todavia, tal distino de estados no faz mais sentido nos sistemas operacionais atuais baseados em memria paginada, pois neles os processos podem executar mesmo estando somente parcialmente carregados na memria.
Implementao de tarefas
Conforme apresentado, uma tarefa uma unidade bsica de atividade dentro de um sistema. Tarefas podem ser implementadas de vrias formas, como processos, threads, jobs e transaes. Nesta seo so descritos os problemas relacionados implementao do conceito de tarefa em um sistema operacional tpico. So descritas as estruturas de dados necessrias para representar uma tarefa e as operaes necessrias para que o processador possa comutar de uma tarefa para outra de forma eciente e transparente.
4.1
Contextos
Na Seo 2 vimos que uma tarefa possui um estado interno bem denido, que representa sua situao atual: a posio de cdigo que ela est executando, os valores de suas variveis e os arquivos que ela utiliza, por exemplo. Esse estado se modica conforme a execuo da tarefa evolui. O estado de uma tarefa em um determinado instante denominado contexto. Uma parte importante do contexto de uma tarefa diz respeito ao estado interno do processador durante sua execuo, como o valor do contador de programa (PC - Program Counter), do apontador de pilha (SP - Stack Pointer) e demais registradores. Alm do estado interno do processador, o contexto de uma tarefa tambm inclui informaes sobre os recursos usados por ela, como arquivos abertos, conexes de rede e semforos. Cada tarefa presente no sistema possui um descritor associado, ou seja, uma estrutura de dados que a representa no ncleo. Nessa estrutura so armazenadas as informaes relativas ao seu contexto e os demais dados necessrios sua gerncia. Essa estrutura de dados geralmente chamada de TCB (do ingls Task Control Block) ou PCB (Process Control Block). Um TCB tipicamente contm as seguintes informaes: Identicador da tarefa (pode ser um nmero inteiro, um apontador, uma referncia de objeto ou um identicador opaco); Estado da tarefa (nova, pronta, executando, suspensa, terminada, ...); Informaes de contexto do processador (valores contidos nos registradores);
Trocas de contexto 12
Lista de reas de memria usadas pela tarefa; Listas de arquivos abertos, conexes de rede e outros recursos usados pela tarefa (exclusivos ou compartilhados com outras tarefas); Informaes de gerncia e contabilizao (prioridade, usurio proprietrio, data de incio, tempo de processamento j decorrido, volume de dados lidos/escritos, etc.). Dentro do ncleo, os descritores das tarefas so organizados em listas ou vetores de TCBs. Por exemplo, normalmente h uma lista de tarefas prontas para executar, uma lista de tarefas aguardando acesso ao disco rgido, etc. Para ilustrar o conceito de TCB, o Apndice ?? apresenta o TCB do ncleo Linux (verso 2.6.12), representado pela estrutura task_struct denida no arquivo include/linux/sched.h.
4.2
Trocas de contexto
Para que o processador possa interromper a execuo de uma tarefa e retornar a ela mais tarde, sem corromper seu estado interno, necessrio denir operaes para salvar e restaurar o contexto da tarefa. O ato de salvar os valores do contexto atual em seu TCB e possivelmente restaurar o contexto de outra tarefa, previamente salvo em outro TCB, denominado troca de contexto. A implementao da troca de contexto uma operao delicada, envolvendo a manipulao de registradores e ags especcos de cada processador, sendo por essa razo geralmente codicada em linguagem de mquina. No Linux as operaes de troca de contexto para a plataforma Intel x86 esto denidas atravs de diretivas em Assembly no arquivo arch/i386/kernel/process.c dos fontes do ncleo. Durante uma troca de contexto, existem questes de ordem mecnica e de ordem estratgica a serem resolvidas, o que traz tona a separao entre mecanismos e polticas j discutida anteriormente (vide Seo ??). Por exemplo, o armazenamento e recuperao do contexto e a atualizao das informaes contidas no TCB de cada tarefa so aspectos mecnicos, providos por um conjunto de rotinas denominado despachante ou executivo (do ingls dispatcher). Por outro lado, a escolha da prxima tarefa a receber o processador a cada troca de contexto estratgica, podendo sofrer inuncias de diversos fatores, como as prioridades, os tempos de vida e os tempos de processamento restante de cada tarefa. Essa deciso ca a cargo de um componente de cdigo denominado escalonador (scheduler, vide Seo 5). Assim, o despachante implementa os mecanismos da gerncia de tarefas, enquanto o escalonador implementa suas polticas. A gura 7 apresenta um diagrama temporal com os principais passos envolvidos em uma troca de contexto. A realizao de uma troca de contexto completa, envolvendo a interrupo de uma tarefa, o salvamento de seu contexto, o escalonamento e a reativao da tarefa escolhida, uma operao relativamente rpida (de dezenas a centenas de micro-segundos, dependendo do hardware e do sistema operacional). A parte potencialmente mais demorada de uma troca de contexto a execuo do escalonador; por esta razo, muitos sistemas operacionais executam o escalonador apenas esporadicamente, quando h necessidade de reordenar a la de tarefas prontas. Nesse caso, o despachante sempre ativa a primeira tarefa da la.

interrupo operaes no ncleo
Processos 13
Tarefa t1
tratador de interrupo
dispatcher
scheduler
dispatcher
Tarefa t2 t
salva contexto
restaura contexto
TCB(t1)
TCB(t2)
Figura 7: Passos de uma troca de contexto. importante observar que uma troca de contexto pode ser provocada pelo m do quantum atual (atravs de uma interrupo de tempo), por um evento ocorrido em um perifrico (tambm atravs de uma interrupo do hardware) ou pela execuo de uma chamada de sistema pela tarefa corrente (ou seja, por uma interrupo de software) ou at mesmo por algum erro de execuo que possa provocar uma exceo no processador.
4.3
Processos
Alm de seu prprio cdigo executvel, cada tarefa ativa em um sistema de computao necessita de um conjunto de recursos para executar e cumprir seu objetivo. Entre esses recursos esto as reas de memria usadas pela tarefa para armazenar seu cdigo, dados e pilha, seus arquivos abertos, conexes de rede, etc. O conjunto dos recursos alocados a uma tarefa para sua execuo denominado processo. Historicamente, os conceitos de tarefa e processo se confundem, sobretudo porque os sistemas operacionais mais antigos, at meados dos anos 80, somente suportavam uma tarefa para cada processo (ou seja, uma atividade associada a cada contexto). Essa viso vem sendo mantida por muitas referncias at os dias de hoje. Por exemplo, os livros [Silberschatz et al., 2001] e [Tanenbaum, 2003] ainda apresentam processos como equivalentes de tarefas. No entanto, quase todos os sistemas operacionais contemporneos suportam mais de uma tarefa por processo, como o caso do Linux, Windows XP e os UNIX mais recentes. Os sistemas operacionais convencionais atuais associam por default uma tarefa a cada processo, o que corresponde execuo de um programa sequencial (um nico uxo de instrues dentro do processo). Caso se deseje associar mais tarefas ao mesmo contexto (para construir o navegador Internet da gura 1, por exemplo), cabe ao desenvolvedor escrever o cdigo necessrio para tal. Por essa razo, muitos livros ainda usam de forma equivalente os termos tarefa e processo, o que no corresponde mais realidade. Assim, hoje em dia o processo deve ser visto como uma unidade de contexto, ou seja, um continer de recursos utilizados por uma ou mais tarefas para sua execuo. Os processos so isolados entre si pelos mecanismos de proteo providos pelo hardware (isolamento de reas de memria, nveis de operao e chamadas de sistema) e pela prpria gerncia de tarefas, que atribui os recursos aos processos (e no s tarefas), impedindo que uma tarefa em execuo no processo pa acesse um recurso atribudo
Processos 14
ao processo pb . A gura 8 ilustra o conceito de processo, visto como um continer de recursos.

Processo pa
tarefas memria
Processo pb
tarefas memria
arqs abertos
conexes
arqs abertos
conexes
ncleo
Figura 8: O processo visto como um continer de recursos. O ncleo do sistema operacional mantm descritores de processos, denominados PCBs (Process Control Blocks), para armazenar as informaes referentes aos processos ativos. Cada processo possui um identicado nico no sistema, o PID Process IDentier. Associando-se tarefas a processos, o descritor (TCB) de cada tarefa pode ser bastante simplicado: para cada tarefa, basta armazenar seu identicador, os registradores do processador e uma referncia ao processo ao qual a tarefa est vinculada. Disto observase tambm que a troca de contexto entre tarefas vinculadas ao mesmo processo muito mais simples e rpida que entre tarefas vinculadas a processos distintos, pois somente os registradores do processador precisam ser salvos/restaurados (as reas de memria e demais recursos so comuns s duas tarefas). Essas questes so aprofundadas na Seo 4.4. 4.3.1 Criao de processos
Durante a vida do sistema, processos so criados e destrudos. Essas operaes so disponibilizadas s aplicaes atravs de chamadas de sistema; cada sistema operacional tem suas prprias chamadas para a criao e remoo de processos. No caso do UNIX, processos so criados atravs da chamada de sistema fork, que cria uma rplica do processo solicitante: todo o espao de memria do processo replicado, incluindo o cdigo da(s) tarefa(s) associada(s) e os descritores dos arquivos e demais recursos associados ao mesmo. A gura 9 ilustra o funcionamento dessa chamada. A chamada de sistema fork invocada por um processo (o pai), mas dois processos recebem seu retorno: o processo pai, que a invocou, e o processo lho, recm-criado, que possui o mesmo estado interno que o pai (ele tambm est aguardando o retorno da chamada de sistema). Ambos os processos tm os mesmos recursos associados, embora em reas de memria distintas. Caso o processo lho deseje abandonar o uxo de execuo herdado do processo pai e executar outro cdigo, poder faz-lo atravs da chamada de sistema execve. Essa chamada substitui o cdigo do processo que a invoca pelo cdigo executvel contido em um arquivo informado como parmetro. A listagem a seguir apresenta um exemplo de uso dessas duas chamadas de sistema:

Processo pai
tarefas memria
Processos 15
Processo pai
tarefas memria
Processo lho
tarefas memria
arqs abertos
conexes
arqs abertos
conexes
arqs abertos
conexes
fork
return
return
ncleo
ncleo
Figura 9: A chamada de sistema fork: antes (esq) e depois (dir) de sua execuo pelo ncleo do sistema UNIX.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
#include #include #include #include #include
<unistd.h> <sys/types.h> <sys/wait.h> <stdio.h> <stdlib.h>
int main (int argc, char *argv[], char *envp[]) { int pid ; /* identificador de processo */ pid = fork () ; /* replicao do processo */
if ( pid < 0 ) /* fork no funcionou */ { perror ("Erro: ") ; exit (-1) ; /* encerra o processo */ } else if ( pid > 0 ) /* sou o processo pai */ { wait (0) ; /* vou esperar meu filho concluir */ } else /* sou o processo filho*/ { /* carrega outro cdigo binrio para executar */ execve ("/bin/date", argv, envp) ; perror ("Erro: ") ; /* execve no funcionou */ } printf ("Tchau !\n") ; exit(0) ; /* encerra o processo */ }
A chamada de sistema exit usada no exemplo acima serve para informar ao ncleo do sistema operacional que o processo em questo no mais necessrio e pode ser
Processos 16
destrudo, liberando todos os recursos a ele associados (arquivos abertos, conexes de rede, reas de memria, etc). Processos podem solicitar ao ncleo o encerramento de outros processos, mas essa operao s aplicvel a processos do mesmo usurio, ou se o processo solicitante pertencer ao administrador do sistema. Na operao de criao de processos do UNIX aparece de maneira bastante clara a noo de hierarquia entre processos. medida em que processos so criados, forma-se uma rvore de processos no sistema, que pode ser usada para gerenciar de forma coletiva os processos ligados mesma aplicao ou mesma sesso de trabalho de um usurio, pois iro constituir uma sub-rvore de processos. Por exemplo, quando um processo encerra, seus lhos so informados sobre isso, e podem decidir se tambm encerram ou se continuam a executar. Por outro, nos sistemas Windows, todos os processos tm o mesmo nvel hierrquico, no havendo distino entre pais e lhos. O comando pstree do Linux permite visualizar a rvore de processos do sistema, como mostra a listagem a seguir.
Threads 17
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
init-+-aacraid |-ahc_dv_0 |-atd |-avaliacao_horac |-bdflush |-crond |-gpm |-kdm-+-X | -kdm---kdm_greet |-keventd |-khubd |-2*[kjournald] |-klogd |-ksoftirqd_CPU0 |-ksoftirqd_CPU1 |-kswapd |-kupdated |-lockd |-login---bash |-lpd---lpd---lpd |-5*[mingetty] |-8*[nfsd] |-nmbd |-nrpe |-oafd |-portmap |-rhnsd |-rpc.mountd |-rpc.statd |-rpciod |-scsi_eh_0 |-scsi_eh_1 |-smbd |-sshd-+-sshd---tcsh---top | |-sshd---bash | -sshd---tcsh---pstree |-syslogd |-xfs |-xinetd -ypbind---ypbind---2*[ypbind]
Outro aspecto importante a ser considerado em relao a processos diz respeito comunicao. Tarefas associadas ao mesmo processo podem trocar informaes facilmente, pois compartilham as mesmas reas de memria. Todavia, isso no possvel entre tarefas associadas a processos distintos. Para resolver esse problema, o ncleo deve prover s aplicaes chamadas de sistema que permitam a comunicao inter-processos (IPC Inter-Process Communication). Esse tema ser estudado em profundidade no Captulo ??.
4.4
Threads
Conforme visto na Seo 4.3, os primeiros sistemas operacionais suportavam apenas uma tarefa por processo. medida em que as aplicaes se tornavam mais complexas,
Threads 18
essa limitao se tornou um claro inconveniente. Por exemplo, um editor de textos geralmente executa tarefas simultneas de edio, formatao, paginao e vericao ortogrca sobre a mesma massa de dados (o texto sob edio). Da mesma forma, processos que implementam servidores de rede (de arquivos, bancos de dados, etc) devem gerenciar as conexes de vrios usurios simultaneamente, que muitas vezes requisitam as mesmas informaes. Essas demandas evidenciaram a necessidade de suportar mais de uma tarefa operando no mesmo contexto, ou seja, dentro do mesmo processo. De forma geral, cada uxo de execuo do sistema, seja associado a um processo ou no interior do ncleo, denominado thread. Threads executando dentro de um processo so chamados de threads de usurio (user-level threads ou simplesmente user threads). Cada thread de usurio corresponde a uma tarefa a ser executada dentro de um processo. Por sua vez, os uxos de execuo reconhecidos e gerenciados pelo ncleo do sistema operacional so chamados de threads de ncleo (kernel-level threads ou kernel threads). Os threads de ncleo representam tarefas que o ncleo deve realizar. Essas tarefas podem corresponder execuo dos processos no espao de usurio, ou a atividades internas do prprio ncleo, como drivers de dispositivos ou tarefas de gerncia. Os sistemas operacionais mais antigos no ofereciam suporte a threads para a construo de aplicaes. Sem poder contar com o sistema operacional, os desenvolvedores de aplicaes contornaram o problema construindo bibliotecas que permitiam criar e gerenciar threads dentro de cada processo, sem o envolvimento do ncleo do sistema. Usando essas bibliotecas, uma aplicao pode lanar vrios threads conforme sua necessidade, mas o ncleo do sistema ir sempre perceber (e gerenciar) apenas um uxo de execuo dentro de cada processo. Por essa razo, esta forma de implementao de threads nomeada Modelo de Threads N:1: N threads no processo, mapeados em um nico thread de ncleo. A gura 10 ilustra esse modelo.
Processo pa
threads memria
Processo pb
threads memria
biblioteca
biblioteca
thread de ncleo
ncleo
thread de ncleo
Figura 10: O modelo de threads N:1. O modelo de threads N:1 muito utilizado, por ser leve e de fcil implementao. Como o ncleo somente considera uma thread, a carga de gerncia imposta ao ncleo pequena e no depende do nmero de threads dentro da aplicao. Essa caracterstica este modelo torna til na construo de aplicaes que exijam muitos threads, como jogos ou simulaes de grandes sistemas (a simulao detalhada do trfego virio de
Threads 19
uma cidade grande, por exemplo, pode exigir um thread para cada veculo, resultando em centenas de milhares ou mesmo milhes de threads). Um exemplo de implementao desse modelo a biblioteca GNU Portable Threads [Engeschall, 2005]. Entretanto, o modelo de threads N:1 apresenta problemas em algumas situaes, sendo o mais grave deles relacionado s operaes de entrada/sada. Como essas operaes so intermediadas pelo ncleo, se um thread de usurio solicitar uma operao de E/S (recepo de um pacote de rede, por exemplo) o thread de ncleo correspondente ser suspenso at a concluso da operao, fazendo com que todos os threads de usurio associados ao processo parem de executar enquanto a operao no for concluda. Outro problema desse modelo diz respeito diviso de recursos entre as tarefas. O ncleo do sistema divide o tempo do processador entre os uxos de execuo que ele conhece e gerencia: as threads de ncleo. Assim, uma aplicao com 100 threads de usurio ir receber o mesmo tempo de processador que outra aplicao com apenas um thread (considerando que ambas as aplicaes tm a mesma prioridade). Cada thread da primeira aplicao ir portanto receber 1/100 do tempo que recebe o thread nico da segunda aplicao, o que no pode ser considerado uma diviso justa desse recurso. A necessidade de suportar aplicaes com vrios threads (multithreaded) levou os desenvolvedores de sistemas operacionais a incorporar a gerncia dos threads de usurio ao ncleo do sistema. Para cada thread de usurio foi ento denido um thread correspondente dentro do ncleo, suprimindo com isso a necessidade de bibliotecas de threads. Caso um thread de usurio solicite uma operao bloqueante (leitura de disco ou recepo de pacote de rede, por exemplo), somente seu respectivo thread de ncleo ser suspenso, sem afetar os demais threads. Alm disso, caso o hardware tenha mais de um processador, mais threads da mesma aplicao podem executar ao mesmo tempo, o que no era possvel no modelo anterior. Essa forma de implementao, denominada Modelo de Threads 1:1 e apresentada na gura 11, a mais frequente nos sistemas operacionais atuais, incluindo o Windows NT e seus descendentes, alm da maioria dos UNIXes.
Processo pa
threads memria
Processo pb
threads memria
ncleo
threads de ncleo
Figura 11: O modelo de threads 1:1. O modelo de threads 1:1 adequado para a maioria da situaes e atende bem s necessidades das aplicaes interativas e servidores de rede. No entanto, pouco escalvel: a criao de um grande nmero de threads impe um carga signicativa
Threads 20
ao ncleo do sistema, inviabilizando aplicaes com muitas tarefas (como grandes servidores Web e simulaes de grande porte). Para resolver o problema da escalabilidade, alguns sistemas operacionais implementam um modelo hbrido, que agrega caractersticas dos modelos anteriores. Nesse novo modelo, uma biblioteca gerencia um conjunto de threads de usurio (dentro do processo), que mapeado em um ou mais threads do ncleo. O conjunto de threads de ncleo associados a um processo geralmente composto de um thread para cada tarefa bloqueada e mais um thread para cada processador disponvel, podendo ser ajustado dinamicamente conforme a necessidade da aplicao. Essa abordagem hbrida denominada Modelo de Threads N:M, onde N threads de usurio so mapeados em M N threads de ncleo. A gura 12 apresenta esse modelo.
Processo pa
threads memria
Processo pb
threads memria
biblioteca
biblioteca
thread de ncleo
ncleo
threads de ncleo
Figura 12: O modelo de threads N:M. O modelo N:M implementado pelo Solaris e tambm pelo projeto KSE (KernelScheduled Entities) do FreeBSD [Evans and Elischer, 2003] baseado nas idias apresentadas em [Anderson et al., 1992]. Ele alia as vantagens de maior interatividade do modelo 1:1 maior escalabilidade do modelo N:1. Como desvantagens desta abordagem podem ser citadas sua complexidade de implementao e maior custo de gerncia dos threads de ncleo, quando comparado ao modelo 1:1. A tabela 1 resume os principais aspectos dos trs modelos de implementao de threads e faz um comparativo entre eles.
Threads 21
Modelo Resumo
Local da implementao Complexidade Custo de gerncia para o ncleo Escalabilidade Suporte a vrios processadores Velocidade das trocas de contexto entre threads Diviso de recursos entre tarefas Exemplos
N:1 1:1 Todos os N threads do pro- Cada thread do processo cesso so mapeados em tem um thread corresponum nico thread de n- dente no ncleo cleo bibliotecas no nvel usu- dentro do ncleo rio baixa mdia nulo mdio alta no rpida baixa sim lenta
N:M Os N threads do processo so mapeados em um conjunto de M threads de ncleo em ambos alta alto alta sim rpida entre threads no mesmo processo, lenta entre threads de processos distintos varivel, pois o mapeamento thread processador dinmico Solaris, FreeBSD KSE
injusta
justa
GNU Portable Threads
Windows XP, Linux
Tabela 1: Quadro comparativo dos modelos de threads.
Threads 22
No passado, cada sistema operacional denia sua prpria interface para a criao de threads, o que levou a problemas de portabilidade das aplicaes. Em 1995 foi denido o padro IEEE POSIX 1003.1c, mais conhecido como PThreads [Nichols et al., 1996], que busca denir uma interface padronizada para a criao e manipulao de threads na linguagem C. Esse padro amplamente difundido e suportado hoje em dia. A listagem a seguir, extrada de [Barney, 2005], exemplica o uso do padro PThreads (para compilar deve ser usada a opo de ligao -lpthread).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
#include <pthread.h> #include <stdio.h> #include <stdlib.h> #define NUM_THREADS 5 /* cada thread vai executar esta funo */ void *PrintHello (void *threadid) { printf ("%d: Hello World!\n", (int) threadid); pthread_exit (NULL); } /* thread "main" (vai criar as demais threads) */ int main (int argc, char *argv[]) { pthread_t thread[NUM_THREADS]; int status, i; /* cria as demais threads */ for(i = 0; i < NUM_THREADS; i++) { printf ("Creating thread %d\n", i); status = pthread_create (&thread[i], NULL, PrintHello, (void *) i); if (status) /* ocorreu um erro */ { perror ("pthread_create"); exit (-1); } } /* encerra a thread "main" */ pthread_exit (NULL); }
O conceito de threads tambm pode ser utilizado em outras linguagens de programao, como Java, Python, Perl, C++ e C#. O cdigo a seguir traz um exemplo simples de criao de threads em Java (extrado da documentao ocial da linguagem):
Escalonamento de tarefas 23
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
public class MyThread extends Thread { int threadID; MyThread (int ID) { threadID = ID; } public void run () { int i ; for (i = 0; i< 100 ; i++) System.out.println ("Hello from t" + threadID + "!") ; } public static void main (String args[]) { MyThread t1 = new MyThread (1); MyThread t2 = new MyThread (2); MyThread t3 = new MyThread (3); t1.start (); t2.start (); t3.start (); } }
Escalonamento de tarefas
Um dos componentes mais importantes da gerncia de tarefas o escalonador (task scheduler), que decide a ordem de execuo das tarefas prontas. O algoritmo utilizado no escalonador dene o comportamento do sistema operacional, permitindo obter sistemas que tratem de forma mais eciente e rpida as tarefas a executar, que podem ter caractersticas diversas: aplicaes interativas, processamento de grandes volumes de dados, programas de clculo numrico, etc. Antes de se denir o algoritmo usado por um escalonador, necessrio ter em mente a natureza das tarefas que o sistema ir executar. Existem vrios critrios que denem o comportamento de uma tarefa; uma primeira classicao possvel diz respeito ao seu comportamento temporal das tarefas: Tarefas de tempo real : exigem previsibilidade em seus tempos de resposta aos eventos externos, pois geralmente esto associadas ao controle de sistemas crticos, como processos industriais, tratamento de uxos multimdia, etc. O escalonamento de tarefas de tempo real um problema complexo, fora do escopo deste livro e discutido mais profundamente em [Burns and Wellings, 1997, Farines et al., 2000]. Tarefas interativas : so tarefas que recebem eventos externos (do usurio ou atravs da rede) e devem respond-los rapidamente, embora sem os requisitos de previsibilidade das tarefas de tempo real. Esta classe de tarefas inclui a maior parte das aplicaes dos sistemas desktop (editores de texto, navegadores Internet, jogos) e dos servidores de rede (e-mail, web, bancos de dados).
Objetivos e mtricas 24
Tarefas em lote (batch) : so tarefas sem requisitos temporais explcitos, que normalmente executam sem interveno do usurio, como procedimentos de backup, varreduras de anti-vrus, clculos numricos longos, renderizao de animaes, etc. Alm dessa classicao, as tarefas tambm podem ser classicadas de acordo com seu comportamento no uso do processador: Tarefas orientadas a processamento (CPU-bound tasks): so tarefas que usam intensivamente o processador na maior parte de sua existncia. Essas tarefas passam a maior parte do tempo nos estados pronta ou executando. A converso de arquivos de vdeo e outros processamentos numricos longos (como os feitos pelo projeto SETI@home [Anderson et al., 2002]) so bons exemplos desta classe de tarefas. Tarefas orientadas a entrada/sada (IO-bound tasks): so tarefas que dependem muito mais dos dispositivos de entrada/sada que do processador. Essas tarefas despendem boa parte de suas existncias no estado suspenso, aguardando respostas s suas solicitaes de leitura e/ou escrita de dados nos dispositivos de entrada/sada. Exemplos desta classe de tarefas incluem editores, compiladores e servidores de rede. importante observar que uma tarefa pode mudar de comportamento ao longo de sua execuo. Por exemplo, um conversor de arquivos de udio WAVMP3 alterna constantemente entre fases de processamento e de entrada/sada, at concluir a converso dos arquivos desejados.
5.1
Objetivos e mtricas
Ao se denir um algoritmo de escalonamento, deve-se ter em mente seu objetivo. Todavia, os objetivos do escalonador so muitas vezes contraditrios; o desenvolvedor do sistema tem de escolher o que priorizar, em funo do perl das aplicaes a suportar. Por exemplo, um sistema interativo voltado execuo de jogos exige valores de quantum baixos, para que cada tarefa pronta receba rapidamente o processador (provendo maior interatividade). Todavia, valores pequenos de quantum implicam em uma menor ecincia E no uso do processador, conforme visto na Seo 4.2. Vrios critrios podem ser denidos para a avaliao de escalonadores; os mais frequentemente utilizados so: Tempo de execuo ou de vida (turnaround time, tt ): diz respeito ao tempo total da vida de cada tarefa, ou seja, o tempo decorrido entre a criao da tarefa e seu encerramento, computando todos os tempos de processamento e de espera. uma medida tpica de sistemas em lote, nos quais no h interao direta com os usurios do sistema. No deve ser confundido com o tempo de processamento (tp ), que o tempo total de uso de processador demandado pela tarefa. Tempo de espera (waiting time, tw ): o tempo total perdido pela tarefa na la de tarefas prontas, aguardando o processador. Deve-se observar que esse tempo no inclui os tempos de espera em operaes de entrada/sada (que so inerentes aplicao).
Escalonamento preemptivo e no-preemptivo 25
Tempo de resposta (response time, tr ): o tempo decorrido entre a chegada de um evento ao sistema e o resultado imediato de seu processamento. Por exemplo, o tempo decorrido entre apertar uma tecla e o caractere correspondente aparecer na tela, em um editor de textos. Essa medida de desempenho tpica de sistemas interativos, como sistemas desktop e de tempo-real; ela depende sobretudo da rapidez no tratamento das interrupes de hardware pelo ncleo e do valor do quantum de tempo, para permitir que as tarefas cheguem mais rpido ao processador quando saem do estado suspenso. Justia : este critrio diz respeito distribuio do processador entre as tarefas prontas: duas tarefas de comportamento similar devem receber tempos de processamento similares e ter duraes de execuo similares. Ecincia : a ecincia E, conforme denido na Seo 4.2, indica o grau de utilizao do processador na execuo das tarefas do usurio. Ela depende sobretudo da rapidez da troca de contexto e da quantidade de tarefas orientadas a entrada/sada no sistema (tarefas desse tipo geralmente abandonam o processador antes do m do quantum, gerando assim mais trocas de contexto que as tarefas orientadas a processamento).
5.2
Escalonamento preemptivo e no-preemptivo
O escalonador de um sistema operacional pode ser preemptivo ou no-preemptivo: Sistemas preemptivos : nestes sistemas uma tarefa pode perder o processador caso termine seu quantum de tempo, execute uma chamada de sistema ou caso ocorra uma interrupo que acorde uma tarefa mais prioritria (que estava suspensa aguardando um evento). A cada interrupo, exceo ou chamada de sistema, o escalonador pode reavaliar todas as tarefas da la de prontas e decidir se mantm ou substitui a tarefa atualmente em execuo. Sistemas no-preemptivos : a tarefa em execuo permanece no processador tanto quanto possvel, s abandonando o mesmo caso termine de executar, solicite uma operao de entrada/sada ou libere explicitamente o processador, voltando la de tarefas prontas (isso normalmente feito atravs de uma chamada de sistema sched_yield() ou similar). Esses sistemas so tambm conhecidos como cooperativos, pois exigem a cooperao das tarefas para que todas possam executar. A maioria dos sistemas operacionais de uso geral atuais preemptiva. Sistemas mais antigos, como o Windows 3.*, PalmOS 3 e MacOS 8 e 9 operavam de forma cooperativa. Em um sistema preemptivo, normalmente as tarefas s so interrompidas quando o processador est no modo usurio; a thread de ncleo correspondente a cada tarefa no sofre interrupes. Entretanto, os sistemas mais sosticados implementam a preempo de tarefas tambm no modo ncleo. Essa funcionalidade importante para sistemas de tempo real, pois permite que uma tarefa de alta prioridade chegue mais rapidamente ao processador quando for reativada. Ncleos de sistema que oferecem essa possibilidade so denominados ncleos preemptivos; Solaris, Linux 2.6 e Windows NT so exemplos de ncleos preemptivos.
Escalonamento FCFS (First-Come, First Served) 26
5.3
Escalonamento FCFS (First-Come, First Served)
A forma de escalonamento mais elementar consiste em simplesmente atender as tarefas em sequncia, medida em que elas se tornam prontas (ou seja, conforme sua ordem de chegada na la de tarefas prontas). Esse algoritmo conhecido como FCFS First Come - First Served e tem como principal vantagem sua simplicidade. Para dar um exemplo do funcionamento do algoritmo FCFS, consideremos as tarefas na la de tarefas prontas, com suas duraes previstas de processamento e datas de ingresso no sistema, descritas na tabela a seguir: tarefa ingresso durao t1 0 5 t2 0 2 t3 1 4 t4 3 3
O diagrama da gura 13 mostra o escalonamento do processador usando o algoritmo FCFS cooperativo (ou seja, sem quantum ou outras interrupes). Os quadros sombreados representam o uso do processador (observe que em cada instante apenas uma tarefa ocupa o processador). Os quadros brancos representam as tarefas que j ingressaram no sistema e esto aguardando o processador (tarefas prontas).
t4 t3 t2 t1 0 1 3 5 7 11 14 t
Figura 13: Escalonamento FCFS. Calculando o tempo mdio de execuo (Tt , a mdia de tt (ti )) e o tempo mdio de espera (Tw , a mdia de tw (ti )) para o algoritmo FCFS, temos: Tt = tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (5 0) + (7 0) + (11 1) + (14 3) = 4 4 5 + 7 + 10 + 11 33 = = = 8.25s 4 4
Tw =
tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (0 0) + (5 0) + (7 1) + (11 3) = 4 4 0 + 5 + 6 + 8 19 = = = 4.75s 4 4
O escalonamento FCFS no leva em conta a importncia das tarefas nem seu comportamento em relao aos recursos. Por exemplo, com esse algoritmo as tarefas
Escalonamento FCFS (First-Come, First Served) 27
orientadas a entrada/sada iro receber menos tempo de processador que as tarefas orientadas a processamento (pois geralmente no usam integralmente seus quanta de tempo), o que pode ser prejudicial para aplicaes interativas. A adio da preempo por tempo ao escalonamento FCFS d origem a outro algoritmo de escalonamento bastante popular, conhecido como escalonamento por revezamento, ou Round-Robin. Considerando as tarefas denidas na tabela anterior e um quantum tq = 2s, seria obtida a sequncia de escalonamento apresentada na gura 14.
t4 t3 t2 t1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 t
Figura 14: Escalonamento Round-Robin. Na gura 14, importante observar que a execuo das tarefas no obedece uma sequncia bvia como t1 t2 t3 t4 t1 t2 . . ., mas uma sequncia bem mais complexa: t1 t2 t3 t1 t4 t3 . . .. Isso ocorre por causa da ordem das tarefas na la de tarefas prontas. Por exemplo, a tarefa t1 para de executar e volta la de tarefas prontas no instante t = 2, antes de t4 ter entrado no sistema (em t = 3). Por isso, t1 retorna ao processador antes de t4 (em t = 6). A gura 15 detalha a evoluo da la de tarefas prontas ao longo do tempo, para esse exemplo. Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para o algoritmo round-robin, temos: Tt = tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (13 0) + (4 0) + (12 1) + (14 3) = 4 4 13 + 4 + 11 + 11 39 = = = 9.75s 4 4 tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) 8 + 2 + 7 + 8 25 = = = 6.25s 4 4 4
Tw =
Observa-se o aumento nos tempos Tt e Tw em relao ao algoritmo FCFS simples, o que mostra que o algoritmo round-robin menos eciente para a execuo de tarefas em lote. Entretanto, por distribuir melhor o uso do processador entre as tarefas ao longo do tempo, ele pode proporcionar tempos de resposta bem melhores s aplicaes interativas. O aumento da quantidade de trocas de contexto tambm tem um impacto negativo na ecincia do sistema operacional. Quanto menor o nmero de trocas de contexto e menor a durao de cada troca, mais tempo sobrar para a execuo das tarefas em
Escalonamento SJF (Shortest Job First) 28
t=0
t2
t1
t=7
t3
t4
t1
t=0
t2
t1
t=8
t1
t3
t4
t=1
t3
t2
t1
t=9
t1
t3
t4
t=2
t1
t3
t2
t=10
t4
t1
t3
t=3
t4
t1
t3
t2
t=11
t4
t1
t3
t=4
t4
t1
t3
t2
t=12
t4
t1
t3
t=5
t4
t1
t3
t=13
t4
t1
t=6
t3
t4
t1
t=14
t4
Figura 15: Evoluo da la de tarefas prontas no escalonamento Round-Robin. si. Assim, possvel denir uma medida de ecincia E do uso do processador, em funo das duraes mdias do quantum de tempo tq e da troca de contexto ttc : E= tq tq + ttc
Por exemplo, um sistema no qual as trocas de contexto duram 1ms e cujo quantum 20 mdio de 20ms ter uma ecincia E = 20+1 = 95, 2%. Caso a durao do quantum 2 seja reduzida para 2ms, a ecincia cair para E = 2+1 = 66, 7%. A ecincia nal da gerncia de tarefas inuenciada por vrios fatores, como a carga do sistema (mais tarefas ativas implicam em mais tempo gasto pelo escalonador, aumentando ttc ) e o perl das aplicaes (aplicaes que fazem muita entrada/sada saem do processador antes do nal de seu quantum, diminuindo o valor mdio de tq ).
5.4
Escalonamento SJF (Shortest Job First)
O algoritmo de escalonamento que proporciona os menores tempos mdios de execuo e de espera conhecido como menor tarefa primeiro, ou SJF (Shortest Job First). Como o nome indica, ele consiste em atribuir o processador menor (mais curta) tarefa da la de tarefas prontas. Pode ser provado matematicamente que esta estratgia sempre proporciona os menores tempos mdios de espera. Aplicando-se este algoritmo s tarefas da tabela anterior, obtm-se o escalonamento apresentado na gura 16.
Escalonamento SJF (Shortest Job First) 29
t4 t3 t2 t1 0 1 2 3 6 9 14 t
Figura 16: Escalonamento SJF. Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para o algoritmo SJF, temos: Tt = tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (14 0) + (2 0) + (6 1) + (9 3) = 4 4 14 + 2 + 5 + 6 27 = = = 6.75s 4 4 tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (9 0) + (0 0) + (2 1) + (6 3) = 4 4 9 + 0 + 1 + 3 13 = = 3.25s = 4 4
Tw =
Deve-se observar que o comportamento expresso na gura 16 corresponde verso cooperativa do algoritmo SJF: o escalonador aguarda a concluso de cada tarefa para decidir quem ir receber o processador. No caso preemptivo, o escalonador deve comparar a durao prevista de cada nova tarefa que ingressa no sistema com o tempo restante de processamento das demais tarefas presentes, inclusive aquela que est executando no momento. Essa abordagem denominada por alguns autores de menor tempo restante primeiro (SRTF Short Remaining Time First) [Tanenbaum, 2003]. A maior diculdade no uso do algoritmo SJF consiste em estimar a priori a durao de cada tarefa, ou seja, antes de sua execuo. Com exceo de algumas tarefas em lote ou de tempo real, essa estimativa invivel; por exemplo, como estimar por quanto tempo um editor de textos ir ser utilizado? Por causa desse problema, o algoritmo SJF puro pouco utilizado. No entanto, ao associarmos o algoritmo SJF preempo por tempo, esse algoritmo pode ser de grande valia, sobretudo para tarefas orientadas a entrada/sada. Suponha uma tarefa orientada a entrada/sada em um sistema preemptivo com tq = 10ms. Nas ltimas 3 vezes em que recebeu o processador, essa tarefa utilizou 3ms, 4ms e 4.5ms de cada quantum recebido. Com base nesses dados histricos, possvel estimar qual a durao da execuo da tarefa na prxima vez em que receber o processador. Essa estimativa pode ser feita por mdia simples (clculo mais rpido) ou por extrapolao (clculo mais complexo, podendo inuenciar o tempo de troca de contexto ttc ).
Escalonamento por prioridades 30
A estimativa de uso do prximo quantum assim obtida pode ser usada como base para a aplicao do algoritmo SJF, o que ir priorizar as tarefas orientadas a entrada/sada, que usam menos o processador. Obviamente, uma tarefa pode mudar de comportamento repentinamente, passando de uma fase de entrada/sada para uma fase de processamento, ou vice-versa. Nesse caso, a estimativa de uso do prximo quantum ser incorreta durante alguns ciclos, mas logo voltar a reetir o comportamento atual da tarefa. Por essa razo, apenas a histria recente da tarefa deve ser considerada (3 a 5 ltimas ativaes). Outro problema associado ao escalonamento SJF a possibilidade de inanio (starvation) das tarefas mais longas. Caso o uxo de tarefas curtas chegando ao sistema seja elevado, as tarefas mais longas nunca sero escolhidas para receber o processador e vo literalmente morrer de fome, esperando na la sem poder executar. Esse problema pode ser resolvido atravs de tcnicas de envelhecimento de tarefas, como a apresentada na Seo 5.5.2.
5.5
Escalonamento por prioridades
Vrios critrios podem ser usados para ordenar a la de tarefas prontas e escolher a prxima tarefa a executar; a data de ingresso da tarefa (usada no FCFS) e sua durao prevista (usada no SJF) so apenas dois deles. Inmeros outros critrios podem ser especicados, como o comportamento da tarefa (em lote, interativa ou de tempo-real), seu proprietrio (administrador, gerente, estagirio), seu grau de interatividade, etc. No escalonamento por prioridades, a cada tarefa associada uma prioridade, geralmente na forma de um nmero inteiro. Os valores de prioridade so ento usados para escolher a prxima tarefa a receber o processador, a cada troca de contexto. O algoritmo de escalonamento por prioridades dene um modelo genrico de escalonamento, que permite modelar vrias abordagens, entre as quais o FCFS e o SJF. Para ilustrar o funcionamento do escalonamento por prioridades, sero usadas as tarefas descritas na tabela a seguir, que usam uma escala de prioridades positiva (ou seja, onde valores maiores indicam uma prioridade maior): tarefa ingresso durao prioridade t1 0 5 2 t2 0 2 3 t3 1 4 1 t4 3 3 4
O diagrama da gura 17 mostra o escalonamento do processador usando o algoritmo por prioridades em modo cooperativo (ou seja, sem quantum ou outras interrupes). Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para esse algoritmo, temos: Tt = tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (7 0) + (2 0) + (14 1) + (10 3) = 4 4 7 + 2 + 13 + 7 29 = = = 7.25s 4 4
t4 t3 t2 t1 0 1 3 5 7 10 14 t
Figura 17: Escalonamento por prioridades (cooperativo). Tw = tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (2 0) + (0 0) + (10 1) + (7 3) = 4 4 2 + 0 + 9 + 4 15 = = = 3.75s 4 4
Quando uma tarefa de maior prioridade se torna disponvel para execuo, o escalonador pode decidir entregar o processador a ela, trazendo a tarefa atual de volta para a la de prontas. Nesse caso, temos um escalonamento por prioridades preemptivo, cujo comportamento apresentado na gura 18 (observe que, quando t4 ingressa no sistema, ela recebe o processador e t1 volta a esperar na la de prontas).
t4 t3 t2 t1 0 1 3 5 7 10 14 t
Figura 18: Escalonamento por prioridades (preemptivo). Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para esse algoritmo, temos: Tt = tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (10 0) + (2 0) + (14 1) + (6 3) = 4 4 10 + 2 + 13 + 3 28 = = = 7s 4 4 tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) 5 + 0 + 9 + 0 14 = = = 3.5s 4 4 4
Tw =
5.5.1
Denio de prioridades
A denio da prioridade de uma tarefa inuenciada por diversos fatores, que podem ser classicados em dois grande grupos: Fatores externos : so informaes providas pelo usurio ou o administrador do sistema, que o escalonador no conseguiria estimar sozinho. Os fatores externos mais comuns so a classe do usurio (administrador, diretor, estagirio) o valor pago pelo uso do sistema (servio bsico, servio premium) e a importncia da tarefa em si (um detector de intruso, um script de recongurao emergencial, etc). Fatores internos : so informaes que podem ser obtidas ou estimadas pelo escalonador, com base em dados disponveis no sistema local. Os fatores internos mais utilizados so a idade da tarefa, sua durao estimada, sua interatividade, seu uso de memria ou de outros recursos, etc. Todos esses fatores devem ser combinados para produzir um valor de prioridade para cada tarefa. Todos os fatores externos so expressos por valor inteiro denominado prioridade esttica (ou prioridade de base), que resume a opinio do usurio ou administrador sobre aquela tarefa. Os fatores internos mudam continuamente e devem ser recalculados periodicamente pelo escalonador. A combinao da prioridade esttica com os fatores internos resulta na prioridade dinmica ou nal, que usada pelo escalonador para ordenar as tarefas prontas. A gura 19 resume esse procedimento.
classe do usurio valor pago importncia da tarefa ...
fatores externos
prioridade esttica
idade da tarefa durao estimada grau de interatividade uso de outros recursos ...
prioridade dinmica
fatores internos
Figura 19: Composio da prioridade dinmica. Em geral, cada famlia de sistemas operacionais dene sua prpria escala de prioridades estticas. Alguns exemplos de escalas comuns so: Windows 2000 e sucessores : processos e threads so associados a classes de prioridade (6 classes para processos e 7 classes para threads); a prioridade nal de uma thread depende de sua prioridade de sua prpria classe de prioridade e da classe de prioridade do processo ao qual est associada, assumindo valores entre 0 e 31. As prioridades do processos, apresentadas aos usurios no Gerenciador de Tarefas, apresentam os seguintes valores default:
4: baixa ou ociosa 6: abaixo do normal 8: normal 10: acima do normal 13: alta 24: tempo-real Geralmente a prioridade da tarefa responsvel pela janela ativa recebe um incremento de prioridade (+1 ou +2, conforme a congurao do sistema). No Linux (ncleo 2.4 e sucessores) h duas escalas de prioridades: Tarefas interativas: a escala de prioridades negativa: a prioridade de cada tarefa vai de -20 (mais importante) a +19 (menos importante) e pode ser ajustada atravs dos comandos nice e renice. Esta escala padronizada em todos os sistemas UNIX. Tarefas de tempo-real: a prioridade de cada tarefa vai de 1 (mais importante) a 99 (menos importante). As tarefas de tempo-real tm precedncia sobre as tarefas interativas e so escalonadas usando polticas distintas. Somente o administrador pode criar tarefas de tempo-real. 5.5.2 Inanio e envelhecimento de tarefas
No escalonamento por prioridades bsico, as tarefas de baixa prioridade s recebem o processador na ausncia de tarefas de maior prioridade. Caso existam tarefas de maior prioridade frequentemente ativas, as de baixa prioridade podem sofrer de inanio (starvation), ou seja, nunca ter acesso ao processador. Alm disso, em sistemas de tempo compartilhado, as prioridade estticas denidas pelo usurio esto intuitivamente relacionadas proporcionalidade na diviso do tempo de processamento. Por exemplo, se um sistema recebe duas tarefas iguais com a mesma prioridade, espera-se que cada uma receba 50% do processador e que ambas concluam ao mesmo tempo. Caso o sistema receba trs tarefas: t1 com prioridade 1, t2 com prioridade 2 e t3 com prioridade 3, espera-se que t3 receba mais o processador que t2 , e esta mais que t1 (assumindo uma escala de prioridades positiva). Entretanto, se aplicarmos o algoritmo de prioridades bsico, as tarefas iro executar de forma sequencial, sem distribuio proporcional do processador. Esse resultado indesejvel ocorre porque, a cada m de quantum, sempre a mesma tarefa escolhida para processar: a mais prioritria. Essa situao est ilustrada na gura 20. Para evitar a inanio e garantir a proporcionalidade expressa atravs das prioridades estticas, um fator interno denominado envelhecimento (task aging) deve ser denido. O envelhecimento indica h quanto tempo uma tarefa est aguardando o processador e aumenta sua prioridade proporcionalmente. Dessa forma, o envelhecimento evita a inanio dos processos de baixa prioridade, permitindo a eles obter o processador periodicamente. Uma forma simples de implementar o envelhecimento est resumida no seguinte algoritmo (que considera uma escala de prioridades positiva):
t3 t2 t1 0 t
Figura 20: Escalonamento por prioridades.
Denies: ti : tarefa i pei : prioridade esttica de ti pdi : prioridade dinmica de ti N : nmero de tarefas no sistema Quando uma tarefa nova tn ingressa no sistema: pen prioridade inicial default pdn pen Para escolher a prxima tarefa a executar tp : escolher tp | pdp = maxN (pdi ) i=1 pdp pep i p : pdi pdi + Em outras palavras, a cada turno o escalonador escolhe como prxima tarefa (tp ) aquela com a maior prioridade dinmica (pdp ). A prioridade dinmica dessa tarefa igualada sua prioridade esttica (pdp pep ) e ento ela recebe o processador. A prioridade dinmica das demais tarefas aumentada de , ou seja, elas envelhecem e no prximo turno tero mais chances de ser escolhidas. A constante conhecida como fator de envelhecimento. Usando o algoritmo de envelhecimento, a diviso do processador entre as tarefas se torna proporcional s suas prioridades. A gura 21 ilustra essa proporcionalidade na execuo das trs tarefas t1 , t2 e t3 com p(t1 ) < p(t2 ) < p(t3 ), usando a estratgia de envelhecimento. Nessa gura, percebe-se que todas as trs tarefas recebem o processador periodicamente, mas que t3 recebe mais tempo de processador que t2 , e que t2 recebe mais que t1 . 5.5.3 Inverso e herana de prioridades
Outro problema relevante que pode ocorrer em sistemas baseados em prioridades a inverso de prioridades [Sha et al., 1990]. Este tipo de problema mais complexo que o anterior, pois envolve o conceito de excluso mtua: alguns recursos do sistema devem ser usados por um processo de cada vez, para evitar problemas de consistncia de seu estado interno. Isso pode ocorrer com arquivos, portas de entrada sada e conexes
t3 t2 t1 0
Figura 21: Escalonamento por prioridades com envelhecimento. de rede, por exemplo. Quando um processo obtm acesso a um recurso com excluso mtua, os demais processos que desejam us-lo cam esperando no estado suspenso, at que o recurso esteja novamente livre. As tcnicas usadas para implementar a excluso mtua so descritas no Captulo ??. A inverso de prioridades consiste em processos de alta prioridade serem impedidos de executar por causa de um processo de baixa prioridade. Para ilustrar esse problema, pode ser considerada a seguinte situao: um determinado sistema possui um processo de alta prioridade pa , um processo de baixa prioridade pb e alguns processos de prioridade mdia pm . Alm disso, h um recurso R que deve ser acessado em excluso mtua; para simplicar, somente pa e pb esto interessados em usar esse recurso. A seguinte sequncia de eventos, ilustrada na gura 22, um exemplo de como pode ocorrer uma inverso de prioridades: 1. Em um dado momento, o processador est livre e alocado a um processo de baixa prioridade pb ; 2. durante seu processamento, pb obtm o acesso exclusivo a um recurso R e comea a us-lo; 3. pb perde o processador, pois um processo com prioridade maior que a dele (pm ) foi acordado devido a uma interrupo; 4. pb volta ao nal da la de tarefas prontas, aguardando o processador; enquanto ele no voltar a executar, o recurso R permanecer alocado a ele e ningum poder us-lo; 5. Um processo de alta prioridade pa recebe o processador e solicita acesso ao recurso R; como o recurso est alocado ao processo pb , pa suspenso at que o processo de baixa prioridade pb libere o recurso. Neste momento, o processo de alta prioridade pa no pode continuar sua execuo, porque o recurso de que necessita est nas mos do processo de baixa prioridade pb . Dessa forma, pa deve esperar que pb execute e libere R, o que justica o nome inverso de prioridades. A espera de pa pode ser longa, pois pb tem baixa prioridade e pode demorar a receber o processador novamente, caso existam outros processos em execuo no sistema (como pm ). Como tarefas de alta prioridade so geralmente crticas para o funcionamento de um sistema, a inverso de prioridades pode ter efeitos graves.

inverso de prioridades!
Pa recebe o recurso e o processador
Pa acorda, solicita o recurso e ca bloqueado esperando
Pa Pm Pb
Pm recebe o processador
R
Pb aloca um recurso para si
Pb libera o recurso bloqueado e perde o processador
t 0
Pm libera o processador
Figura 22: Cenrio de uma inverso de prioridades. Uma soluo elegante para o problema da inverso de prioridades obtida atravs de um protocolo de herana de prioridade [Sha et al., 1990]. O protocolo de herana de prioridade mais simples consiste em aumentar temporariamente a prioridade do processo pb que detm o recurso de uso exclusivo R. Caso esse recurso seja requisitado por um processo de maior prioridade pa , o processo pb herda temporariamente a prioridade de pa , para que possa voltar a executar e liberar o recurso R mais rapidamente. Assim que liberar o recurso, pb retorna sua prioridade anterior. Essa estratgia est ilustrada na gura 23.
Pa acorda, solicita o recurso e ca bloqueado esperando
Pa Pm Pb
Pm recebe o processador
R
Pb aloca um recurso para si
Pb libera o recurso bloqueado e perde o processador
t 0
Figura 23: Um protocolo de herana de prioridade. Provavelmente o melhor exemplo real de inverso de prioridades tenha ocorrido na sonda espacial Mars Pathnder, enviada pela NASA em 1996 para explorar o solo marciano (Figura 24) [Jones, 1997]. O software da sonda executava sobre o sistema operacional de tempo real VxWorks e consistia de 97 threads com vrios nveis de prioridades. Essas tarefas se comunicavam atravs de uma rea de trasferncia em memria compartilhada, com acesso mutuamente exclusivo controlado por semforos (semforos so estruturas de sincronizao discutidas na Seo ??). A gerncia da rea de transferncia estava a cargo de uma tarefa t g , rpida mas de alta prioridade, que era ativada frequentemente para mover blocos de informao para dentro e fora dessa rea. A coleta de dados meteorolgicos era feita por uma tarefa tm de baixa prioridade, que executava esporadicamente e escrevia seus dados na rea de transferncia, para uso por outras tarefas. Por m, a comunicao com a Terra estava sob a responsabilidade de uma tarefa tc de prioridade mdia e potencialmente demorada (tabela 2 e gura 25).
Figura 24: Sonda Mars Pathnder com o rob Sojourner (NASA). tarefa funo prioridade durao tg gerncia da rea de transferncia alta curta tm coleta de dados meteorolgicos baixa curta tc comunicao com a Terra mdia longa Tabela 2: Algumas tarefas do software da sonda Mars Pathnder.
thread tg watchdog
thread tm sensores meteorolgicos e ambientais rea de transferncia
thread tc
rdio e antena
outra threads
Figura 25: Principais tarefas do software embarcado da sonda Mars Pathnder. Como o sistema VxWorks dene prioridades preemptivas, as tarefas eram atendidas conforme suas necessidades na maior parte do tempo. Todavia, a excluso mtua no
Outros algoritmos de escalonamento 38
acesso rea de transferncia escondia uma inverso de prioridades: caso a tarefa de coleta de dados meteorolgicos tm perdesse o processador sem liberar a rea de transferncia, a tarefa de gerncia t g teria de car esperando at que tm voltasse a executar para liberar a rea. Isso poderia poderia demorar se, por azar, a tarefa de comunicao estivesse executando, pois ela tinha mais prioridade que tm . Como todos os sistemas crticos, a sonda Mars Pathnder possui um sistema de proteo contra erros, ativado por um temporizador (watchdog). Caso a gerncia da rea de transferncia casse parada por muito tempo, um procedimento de reincio geral do sistema era automaticamente ativado pelo temporizador. Dessa forma, a inverso de prioridades provocava reincios espordicos e imprevisveis no software da sonda, interrompendo suas atividades e prejudicando seu funcionamento. A soluo foi obtida atravs da herana de prioridades: caso a tarefa de gerncia t g fosse bloqueada pela tarefa de coleta de dados tm , esta ltima herdava a alta prioridade de t g para poder liberar rapidamente a rea de transferncia, mesmo se a tarefa de comunicao tc estivesse em execuo.
5.6
Outros algoritmos de escalonamento
Alm dos algoritmos de escalonamento vistos nesta seo, diversos outros podem ser encontrados na literatura e em sistemas de mercado, como os escalonadores de tempo-real [Farines et al., 2000], os escalonadores multimdia [Nieh and Lam, 1997], os escalonadores justos [Kay and Lauder, 1988, Ford and Susarla, 1996], os escalonadores multi-processador [Black, 1990] e multi-core [Boyd-Wickizer et al., 2009].
5.7
Um escalonador real
Na prtica, os sistemas operacionais de mercado implementam mais de um algoritmo de escalonamento. A escolha do escalonador adequado feita com base na classe de escalonamento atribuda a cada tarefa. Por exemplo, o ncleo Linux implementa dois escalonadores (gura 26): um escalonador de tarefas de tempo-real (classes SCHED_FIFO e SCHED_RR) e um escalonador de tarefas interativas (classe SCHED_OTHER) [Love, 2004]. Cada uma dessas classes de escalonamento est explicada a seguir: Classe SCHED_FIFO : as tarefas associadas a esta classe so escalonadas usando uma poltica FCFS sem preempo (sem quantum) e usando apenas suas prioridades estticas (no h envelhecimento). Portanto, uma tarefa desta classe executa at bloquear por recursos ou liberar explicitamente o processador (atravs da chamada de sistema sched_yield()). Classe SCHED_RR : implementa uma poltica similar anterior, com a incluso da preempo por tempo. O valor do quantum proporcional prioridade atual de cada tarefa, variando de 10ms a 200ms. Classe SCHED_OTHER : suporta tarefas interativas em em lote, atravs de uma poltica baseada em prioridades dinmicas com preempo por tempo com quantum varivel. Tarefas desta classe somente so escalonadas se no houverem tarefas prontas nas classes SCHED_FIFO e SCHED_RR.

sched_yield
Um escalonador real 39
SCHED_FIFO
sched_yield / m de quantum
SCHED_RR
sched_yield / m de quantum
SCHED_OTHER
suspensa
Figura 26: O escalonador multi-las do Linux. As classes de escalonamento SCHED_FIFO e SCHED_RR so reservadas para tarefas de tempo-real, que s podem ser lanadas pelo administrador do sistema. Todas as demais tarefas, ou seja, a grande maioria das aplicaes e comandos dos usurios, executa na classe de escalonamento SCHED_OTHER.
Questes
1. Explique o que , para que serve e o que contm um PCB - Process Control Block. 2. O que so threads e para que servem? 3. Quais as principais vantagens e desvantagens de threads em relao a processos? 4. Fornea dois exemplos de problemas cuja implementao multi-thread no tem desempenho melhor que a respectiva implementao sequencial. 5. O que signica time sharing e qual a sua importncia em um sistema operacional? 6. Como e com base em que critrios escolhida a durao de um quantum de processamento? 7. Explique o que escalonamento round-robin, dando um exemplo. 8. Explique o que , para que serve e como funciona a tcnica de aging. 9. Explique os conceitos de inverso e herana de prioridade.
executando
Exerccios
1. Considerando o diagrama de estados dos processos apresentado na gura 27, complete o diagrama com a transio de estado que est faltando e apresente o signicado de cada um dos estados e transies.
Figura 27: Diagrama de estados de processos. 2. Indique se cada uma das transies de estado de tarefas a seguir denidas possvel ou no. Se for possvel, d um exemplo de situao na qual essa transio ocorre. (a) executando pronta (b) executando suspensa (c) suspensa executando (d) suspensa terminada (e) executando terminada (f) pronta suspensa 3. Relacione as armaes abaixo aos respectivos estados no ciclo de vida das tarefas (Nova, Pronta, Executando, Suspensa, Terminada): (a) O cdigo da tarefa est sendo carregado. (b) A tarefas so ordenadas por prioridades. (c) A tarefa sai deste estado ao solicitar uma operao de entrada/sada. (d) Os recursos usados pela tarefa so devolvidos ao sistema. (e) A tarefa vai a este estado ao terminar seu quantum. (f) A tarefa s precisa do processador para poder executar. (g) A requisio de acesso a um semforo em uso leva a tarefa a este estado. (h) A tarefa pode criar novas tarefas. (i) H uma tarefa neste estado para cada processador do sistema. (j) A tarefa aguarda a ocorrncia de um evento externo. 4. Desenhe o diagrama de tempo da execuo do cdigo a seguir e informe qual a sada do programa na tela e a durao aproximada de sua execuo.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
int main() { int x = 0 ; fork () ; x++ ; sleep (5) ; wait (0) ; fork () ; wait (0) ; sleep (5) ; x++ ; printf ("Valor de x: %d\n", x) ; }
5. Considerando as implementaes de threads N:1 e 1:1 para o trecho de cdigo a seguir, a) desenhe os diagramas de execuo, b) informe as duraes aproximadas de execuo e c) indique a sada do programa na tela. Considere a operao sleep() como uma chamada de sistema (syscall). Signicado das operaes: thread_create: cria uma nova thread, que pode executar (ser escalonada) imediatamente. thread_join: espera o encerramento da thread informada como parmetro. thread_exit: encerra a thread.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
int y = 0 ; void threadBody { int x = 0 ; sleep (10) ; printf ("x: %d, y:%d\n", ++x, ++y) ; thread_exit(); } main () { thread_create (&tA, threadBody, ...) ; thread_create (&tB, threadBody, ...) ; sleep (1) ; thread_join (&tA) ; thread_join (&tB) ; sleep (1) ; thread_create (&tC, threadBody, ...) ; thread_join (&tC) ; }
6. A tabela a seguir representa um conjunto de tarefas prontas para utilizar o processador. Para as polticas FCFS, SJF e PRIO cooperativas, indique a sequncia de execuo das tarefas, o tempo mdio de execuo (tournaround time) e o tempo mdio de espera (waiting time). Tarefa t1 ingresso 0 durao 5 prioridade 2 t2 0 4 3 t3 3 5 5 t4 5 6 9 t5 6 4 6
Consideraes: as trocas de contexto tm durao nula; para tarefas de mesma prioridade, use FCFS como critrio de desempate; para tarefas de mesma idade, a tarefa ti com menor i prevalece; todas as tarefas so orientadas a processamento; valores maiores de prioridade indicam maior prioridade. 7. Repita o exerccio anterior para as polticas SJF e PRIO preemptivas. 8. Idem, para a poltica RR (Round-Robin) com tq = 2. 9. Associe as armaes a seguir aos seguintes modelos de threads: a) many-to-one (N:1); b) one-to-one (1:1); c) many-to-many (N:M): (a) Tem a implementao mais simples, leve e eciente. (b) Multiplexa os threads de usurio em um pool de threads de ncleo. (c) Pode impor uma carga muito pesada ao ncleo. (d) No permite explorar a presena de vrias CPUs. (e) Permite uma maior concorrncia sem impor muita carga ao ncleo. (f) Geralmente implementado por bibliotecas. (g) o modelo implementado no Windows NT e seus sucessores. (h) Se um thread bloquear, todos os demais tm de esperar por ele. (i) Cada thread no nvel do usurio tem sua correspondente dentro do ncleo. (j) o modelo com implementao mais complexa. 10. Considere um sistema de tempo compartilhado com valor de quantum tq e durao da troca de contexto ttc . Considere tarefas de entrada/sada que usam em mdia p% de seu quantum de tempo cada vez que recebem o processador. Dena a ecincia E do sistema como uma funo dos parmetros tq , ttc e p. 11. No algoritmo de envelhecimento denido na Seo 5.5.2, o que seria necessrio modicar para suportar uma escala de prioridades negativa? 12. Voc deve analisar o software da sonda Mars Pathnder discutido na Seo 5.5.3. O sistema usa escalonamento por prioridades preemptivo, sem envelhecimento e sem compartilhamento de tempo. Suponha que as tarefas t g e tm detm a rea de transferncia de dados durante todo o perodo em que executam. Os dados de um trecho de execuo das tarefas so indicados na tabela a seguir (observe que t g executa mais de uma vez).
REFERNCIAS 43
Tarefa tg ingresso 0, 5, 10 durao 1 prioridade alta
tm tc 2 3 2 10 baixa mdia
Desenhe o diagrama de tempo da execuo sem e com o protocolo de herana de prioridades e discuta sobre as diferenas observadas entre as duas execues.
Projetos Referncias
[Anderson et al., 2002] Anderson, D., Cobb, J., Korpela, E., Lebofsky, M., and Werthimer, D. (2002). SETI@home: An experiment in public-resource computing. Communications of the ACM, 45(11):5661. [Anderson et al., 1992] Anderson, T., Bershad, B., Lazowska, E., and Levy, H. (1992). Scheduler activations: eective kernel support for the user-level management of parallelism. ACM Transactions on Computer Systems, 10(1):5379. B. (2005). POSIX [Barney, 2005] Barney, http://www.llnl.gov/computing/tutorials/pthreads. threads programming.
[Black, 1990] Black, D. L. (1990). Scheduling and resource management techniques for multiprocessors. Technical Report CMU-CS-90-152, Carnegie-Mellon University, Computer Science Dept. [Boyd-Wickizer et al., 2009] Boyd-Wickizer, S., Morris, R., and Kaashoek, M. (2009). Reinventing scheduling for multicore systems. In 12th conference on Hot topics in operating systems, page 21. USENIX Association. [Burns and Wellings, 1997] Burns, A. and Wellings, A. (1997). Real-Time Systems and Programming Languages, 2nd edition. Addison-Wesley. [Corbat, 1963] Corbat, F. (1963). The Compatible Time-Sharing System: A Programmers Guide. MIT Press. [Engeschall, 2005] Engeschall, R. (2005). http://www.gnu.org/software/pth. The GNU Portable Threads.
[Evans and Elischer, 2003] Evans, J. and Elischer, J. (2003). Kernel-scheduled entities for FreeBSD. http://www.aims.net.au/chris/kse. [Farines et al., 2000] Farines, J.-M., da Silva Fraga, J., and de Oliveira, R. S. (2000). Sistemas de Tempo Real 12a Escola de Computao da SBC. Sociedade Brasileira de Computao.
REFERNCIAS 44
[Ford and Susarla, 1996] Ford, B. and Susarla, S. (1996). CPU Inheritance Scheduling. In Usenix Association Second Symposium on Operating Systems Design and Implementation (OSDI), pages 91105. [Jones, 1997] Jones, M. (1997). What really happened on Mars Rover Pathnder. ACM Risks-Forum Digest, 19(49). [Kay and Lauder, 1988] Kay, J. and Lauder, P. (1988). A fair share scheduler. Communications of the ACM, 31(1):4455. [Love, 2004] Love, R. (2004). Linux Kernel Development. Sams Publishing Developers Library. [Nichols et al., 1996] Nichols, B., Buttlar, D., and Farrell, J. (1996). PThreads Programming. OReilly Media, Inc. [Nieh and Lam, 1997] Nieh, J. and Lam, M. (1997). The design, implementation and evaluation of SMART: a scheduler for multimedia applications. In Proceedings of the 16th ACM Symposium on Operating Systems Principles, pages 184197. [Sha et al., 1990] Sha, L., Rajkumar, R., and Lehoczky, J. (1990). Priority inheritance protocols: An approach to real-time synchronization. IEEE Transactions on Computers, 39(9):11751185. [Silberschatz et al., 2001] Silberschatz, A., Galvin, P., and Gagne, G. (2001). Sistemas Operacionais Conceitos e Aplicaes. Campus. [Tanenbaum, 2003] Tanenbaum, A. (2003). Sistemas Operacionais Modernos, 2a edio. Pearson Prentice-Hall.

So Cap02

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

So Cap02

Hochgeladen von

Copyright:

Verfügbare Formate

Sistemas Operacionais II - Gerncia de Tarefas

Prof. Carlos Alberto Maziero DAInf UTFPR http://dainf.ct.utfpr.edu.br/maziero 18 de novembro de 2011

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

Sistemas de tempo compartilhado 8

dado disponvel ou evento ocorreu

aguarda um dado externo ou outro evento

Figura 4: Diagrama de estados de uma tarefa em um sistema multi-tarefas.

Sistemas de tempo compartilhado

c prof. Carlos Maziero

Ciclo de vida das tarefas 9

ticks do relgio de hardware

ativaes do tratador de interrupo

terminou de ser carregada em memria

dado disponvel ou evento ocorreu

aguarda um dado externo ou outro evento

Figura 6: Diagrama de estados de uma tarefa em um sistema de tempo compartilhado.

Ciclo de vida das tarefas

c prof. Carlos Maziero

Ciclo de vida das tarefas 10

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

ao processo pb . A gura 8 ilustra o conceito de processo, visto como um continer de recursos.

c prof. Carlos Maziero

#include #include #include #include #include

<unistd.h> <sys/types.h> <sys/wait.h> <stdio.h> <stdlib.h>

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

GNU Portable Threads

Windows XP, Linux

Tabela 1: Quadro comparativo dos modelos de threads.

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

c prof. Carlos Maziero

Escalonamento preemptivo e no-preemptivo 25

Escalonamento preemptivo e no-preemptivo

c prof. Carlos Maziero

Escalonamento FCFS (First-Come, First Served) 26

Escalonamento FCFS (First-Come, First Served)

tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (0 0) + (5 0) + (7 1) + (11 3) = 4 4 0 + 5 + 6 + 8 19 = = = 4.75s 4 4

c prof. Carlos Maziero

Escalonamento FCFS (First-Come, First Served) 27

c prof. Carlos Maziero

Escalonamento SJF (Shortest Job First) 28

Escalonamento SJF (Shortest Job First)

c prof. Carlos Maziero

Escalonamento SJF (Shortest Job First) 29

c prof. Carlos Maziero

Escalonamento por prioridades 30

Escalonamento por prioridades

c prof. Carlos Maziero