Sistemas Operacionais II - Gerncia de tarefas

Prof. Carlos Alberto Maziero PPGIA CCET PUCPR http://www.ppgia.pucpr.br/maziero 1 de agosto de 2008

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.

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, criador de grcos GNUPlot 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 3 5 5 7 8 9 11 11 12 13 15 17 22 23 24 25 27 29 31 32 34 34 41

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 baseado em prioridades . . . . 5.5.1 Envelhecimento de tarefas . . . . . . . . 5.5.2 Denio de prioridades . . . . . . . . . 5.6 Outros algoritmos de escalonamento . . . . . . 5.7 Um escalonador real . . . . . . . . . . . . . . .

A O Task Control Block do Linux

c Prof. Carlos Maziero

Objetivos 3

1 Objetivos
Em um sistema de computao, freqente 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.

2 O conceito de tarefa
Uma tarefa denida como sendo a execuo de um uxo seqencial 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 seqncia 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:

c Prof. Carlos Maziero

O conceito de tarefa 4

Um programa um conjunto de uma ou mais seqncias 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 seqncias 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 seqncias 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; 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.

c Prof. Carlos Maziero

A gerncia de tarefas 5

Figura 1: Tarefas de um navegador Internet

3 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.

c Prof. Carlos Maziero

Sistemas mono-tarefa 6

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.

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 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 basicamente os seguintes passos sobre uma la de programas a executar, armazenada no disco: repetir carregar um programa do disco para a memria carregar os dados de entrada do disco para a memria transferir a execuo para o programa recm carregado aguardar o trmino da execuo do programa escrever os resultados gerados pelo programa no disco at processar todos os programas da la 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

c Prof. Carlos Maziero

Sistemas multi-tarefa 7

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:

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

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

c Prof. Carlos Maziero

Sistemas de tempo compartilhado 8

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 pode inviabilizar o 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 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.
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

c Prof. Carlos Maziero

Ciclo de vida das tarefas 9

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.

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: 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.

c Prof. Carlos Maziero

Ciclo de vida das tarefas 10

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 conseqncia 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. Suspensa Pronta : quando o recurso solicitado pela tarefa se torna disponvel, ela pode voltar a executar, portanto volta ao estado de pronta.

c Prof. Carlos Maziero

Implementao de tarefas 11

4 Implementao de tarefas
Nesta seo so descritos os problemas relacionados implementao do conceito de tarefa em um sistema operacional multi-tarefas. 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 a situao atual da tarefa: a instruo que ela est executando, os valores de suas variveis, os arquivos que ela utiliza, por exemplo. Esse estado se modica conforme a execuo da tarefa avana. O estado de uma tarefa em um determinado instante caracterizado pelas seguintes informaes: Registradores do processador: Contador de programa (PC Program Counter), que indica a posio corrente da execuo no cdigo binrio da tarefa. Apontador de pilha (SP Stack Pointer), que aponta para o topo da pilha de execuo (estrutura que armazena os parmetros e endereos de retorno das funes, entre outros dados). Flags indicando vrios aspectos do comportamento do processador naquele momento (nvel usurio ou nvel ncleo, status da ltima operao realizada, etc). Demais registradores (acumulador, de uso geral, de mapeamento de memria, etc). reas de memria usadas pela tarefa. Recursos usados pela tarefa (arquivos abertos, conexes de rede e semforos, entre outros). As informaes que permitem denir completamente o estado de uma tarefa so coletivamente denominadas contexto da tarefa. Cada tarefa ativa no sistema possui uma estrutura de dados associada a ela, onde so armazenadas as informaes relativas ao seu contexto e outros dados necessrios sua gerncia. Essa estrutura de dados geralmente chamada de TCB (do ingls Task Control Block). Cada TCB funciona como um descritor de tarefa e tipicamente contm as seguintes informaes: Identicador da tarefa (geralmente um nmero inteiro). Estado da tarefa (nova, pronta, executando, suspensa ou terminada).

c Prof. Carlos Maziero

Trocas de contexto 12

Valores dos registradores do processador quando o contexto foi salvo pela ltima vez. Lista das reas de memria usadas pela tarefa (exclusivas ou compartilhadas com outras tarefas). Listas de arquivos abertos, conexes de rede e outros recursos usados pela tarefa (exclusivos ou compartilhados com outras tarefas). Informaes de contabilizao (data de incio, tempo de processamento, volume de dados lidos/escritos, etc.). Outras informaes (prioridade, proprietrio, etc.). Os TCBs das tarefas so organizados em listas ou vetores (lista de tarefas prontas, lista de tarefas aguardando um pacote de rede, etc). Para ilustrar o conceito de TCB, o apndice A 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 um 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 (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, tempos de vida e 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. importante observar que uma troca de contexto pode ser

c Prof. Carlos Maziero

Processos 13

provocada pelo m do quantum atual (atravs de uma interrupo de tempo), por um evento em um perifrico (tambm atravs de uma interrupo) ou pela execuo de uma chamada de sistema pela tarefa corrente (ou seja, por uma interrupo de software).

Figura 7: Passos de uma troca de contexto. A realizao de uma troca de contexto completa, envolvendo a interrupo de uma tarefa, armazenamento do contexto, escalonamento e reativao da tarefa escolhida, uma operao relativamente rpida (de dezenas a centenas de micro-segundos, dependendo do hardware e do sistema operacional). Quanto menor o tempo despendido nas trocas de contexto, maior ser a ecincia da gerncia de tarefas, pois menos tempo ser gasto nessas atividades e sobrar mais tempo de processador para as tarefas. Assim, possvel denir uma medida de ecincia E do uso do processador por um sistema de tempo compartilhado, que funo da relao entre as duraes mdias do quantum de tempo tq e da troca de contexto ttc : E= tq tq + ttc

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 do quantum, diminuindo o valor mdio de tq ).

4.3 Processos
Alm de seu prprio cdigo, 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

c Prof. Carlos Maziero

Processos 14

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, 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 seqencial (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, 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 ao processo pb . A gura 8 ilustra o conceito de processo, visto como um continer de recursos.

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

c Prof. Carlos Maziero

Processos 15

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.

Figura 9: A chamada de sistema fork: antes (esq) e depois (dir) de sua execuo pelo ncleo do sistema UNIX. 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:
1 2 3 4

#include #include #include #include

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

c Prof. Carlos Maziero

Processos 16

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 <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 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.
1
init-+-aacraid |-ahc_dv_0 |-atd |-avaliacao_horac

c Prof. Carlos Maziero

Threads 17

10

15

20

25

30

35

40

|-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,

c Prof. Carlos Maziero

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). Grosso modo, cada thread de usurio corresponde a uma tarefa a ser executada. 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). Sem poder contar com o suporte do sistema operacional para a criao de mltiplos threads, os desenvolvedores contornaram o problema construindo bibliotecas para gerenciar threads dentro de cada processo, sem o envolvimento do ncleo. 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 naquele 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.

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

c Prof. Carlos Maziero

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 freqente nos sistemas operacionais atuais, incluindo o Windows NT e seus descendentes, alm da maioria dos UNIXes.

Figura 11: O modelo de threads 1:1.

c Prof. Carlos Maziero

Threads 20

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 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.

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 modelos de implementao de threads e faz um comparativo entre eles. 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. Esse padro amplamente difundido e suportado hoje em dia. A listagem a seguir, extrada de [Barney, 2005], exemplica o uso do padro PThreads.

c Prof. Carlos Maziero

Modelo Resumo N:1 Todos os N threads do processo so mapeados em um nico thread de ncleo bibliotecas no nvel usurio baixa nulo alta no rpida injusta GNU Portable Threads 1:1 Cada thread do processo tem um thread correspondente no ncleo dentro do ncleo mdia mdio baixa sim lenta justa Windows XP, Linux

Threads 21
N:M Os N threads do processo so mapeados em um conjunto de M threads de ncleo em ambos alta alto alta sim depende depende da situao Solaris, FreeBSD KSE

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

Tabela 1: Quadro comparativo dos modelos de threads.

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

#include <pthread.h> #include <stdio.h> #include <stdlib.h> #define NUM_THREADS 5

/* each thread will run this */ void *PrintHello(void *threadid) { printf("%d: Hello World!\n", (int) threadid); pthread_exit(NULL); } /* main thread (create the other threads) */ int main (int argc, char *argv[]) { pthread_t thread[NUM_THREADS]; int status, i; /* creating 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) { perror ("pthread_create");

c Prof. Carlos Maziero

Escalonamento de tarefas 22

28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

exit(-1); } }

/* waiting for threads termination */ for(i=0; i<NUM_THREADS; i++) { printf("Waiting for thread %d\n", i); status = pthread_join(thread[i], NULL); if (status) { perror ("pthread_join"); exit(-1); } }
pthread_exit(NULL); }

5 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). Tarefas em lote (batch) : so tarefas sem requisitos temporais explcitos, que normalmente executam sem interveno do usurio, como procedimentos de backup,

c Prof. Carlos Maziero

Objetivos e mtricas 23

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 [of California, 2005]) 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 freqentemente utilizados so: Tempo de execuo ou de retorno (turnaround time, tt ): diz respeito ao tempo total de 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. 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).

c Prof. Carlos Maziero

Escalonamento preemptivo e no-preemptivo 24

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

c Prof. Carlos Maziero

Escalonamento FCFS (First-Come, First Served) 25

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.

5.3 Escalonamento FCFS (First-Come, First Served)

A forma de escalonamento mais elementar consiste em simplesmente atender as tarefas em seqncia, 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).

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 (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (5 0) + (7 0) + (11 1) + (14 3) = 4 4

Tt =

c Prof. Carlos Maziero

Escalonamento FCFS (First-Come, First Served) 26

= Tw =

5 + 7 + 10 + 11 33 = = 8.25s 4 4

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 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 seqncia de escalonamento apresentada na gura 14.

Figura 14: Escalonamento Round-Robin. Na gura 14, importante observar que a execuo das tarefas no obedece uma seqncia bvia como t1 t2 t3 t4 t1 t2 . . ., mas uma seqncia 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 (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

Tt =

c Prof. Carlos Maziero

Escalonamento SJF (Shortest Job First) 27

Figura 15: Evoluo da la de tarefas prontas no escalonamento Round-Robin.

Tw =

tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) 8 + 2 + 7 + 8 25 = = = 6.25s 4 4 4

Observa-se o aumento nos tempos Tt e Tw e tambm mais trocas de contexto que no algoritmo FCFS, 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 melhores tempos de resposta s aplicaes interativas.

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.

c Prof. Carlos Maziero

Escalonamento SJF (Shortest Job First) 28

Figura 16: Escalonamento SJF. Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para o algoritmo SJF, temos: 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

Tt =

Tw =

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

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

c Prof. Carlos Maziero

Escalonamento baseado em prioridades 29

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 ). 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 longos. 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.1.

5.5 Escalonamento baseado em 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 baseado em 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 baseado em 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 baseado em 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:

c Prof. Carlos Maziero

Escalonamento baseado em prioridades 30

Figura 17: Escalonamento baseado em prioridades (cooperativo).

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

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 baseado em 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).

Figura 18: Escalonamento baseado em prioridades (preemptivo). Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para esse algoritmo, temos:

c Prof. Carlos Maziero

Escalonamento baseado em prioridades 31

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

Envelhecimento de tarefas

Em sistemas interativos, a intuio associada s prioridade estticas (denidas pelo usurio) a de 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 terminem juntas. Caso o sistema receba trs tarefas: t1 com prioridade 3, t2 com prioridade 2 e t3 com prioridade 1, espera-se que t1 receba mais o processador que t2 , e esta mais que t3 (assumindo uma escala de prioridades positiva). Entretanto, se aplicarmos o algoritmo de prioridades bsico, as tarefas iro executar de forma seqencial, 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 19.

Figura 19: Violao da proporcionalidade. Para 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. Com isso, os processos de menor prioridade tm chance de receber o processador periodicamente. Dessa forma, o envelhecimento evita a inanio (starvation) dos processos de menor prioridade. Uma forma simples de implementar o envelhecimento est resumida no seguinte algoritmo (que considera uma escala de prioridades positiva):

c Prof. Carlos Maziero

Escalonamento baseado em prioridades 32

Denies: ti : tarefa i pei : prioridade esttica de ti pdi : prioridade dinmica de ti N : nmero de tarefas no sistema Quando uma nova tarefa 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 esse algoritmo, a diviso do processador entre as tarefas se torna proporcional s suas prioridades. A gura 20 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 t1 recebe proporcionalmente mais tempo de processador que t2 , e que t2 recebe mais que t3 .

Figura 20: Proporcionalidade garantida atravs do envelhecimento.

5.5.2

Denio de prioridades

A denio da prioridade de uma tarefa inuenciada por diversos fatores, que podem ser classicados em dois grande grupos:

c Prof. Carlos Maziero

Escalonamento baseado em prioridades 33

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 21 resume esse procedimento.

Figura 21: 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

c Prof. Carlos Maziero

Outros algoritmos de escalonamento 34

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.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] e os escalonadores multi-processador [Black, 1990].

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 22): 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.

c Prof. Carlos Maziero

Um escalonador real 35

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.

Figura 22: 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 seqencial. 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?

c Prof. Carlos Maziero

Um escalonador real 36

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.

Exerccios
1. Considerando o diagrama de estados dos processos apresentado na gura 23, complete o diagrama com a transio de estado que est faltando e apresente o signicado de cada um dos estados e transies.

Figura 23: 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.

c Prof. Carlos Maziero

Um escalonador real 37

(f) A tarefa s precisa do processador para poder executar. (g) O acesso a um semforo em uso pode levar 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

int y = 0 ; void threadBody { int x = 0 ; sleep (10) ; printf ("x: %d, y:%d\n", ++x, ++y) ; thread_exit(); }

c Prof. Carlos Maziero

Um escalonador real 38

10 11 12 13 14 15 16 17 18 19 20 21

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 seqncia 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.

c Prof. Carlos Maziero

REFERNCIAS 39

(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, o que seria necessrio modicar para suportar uma escala de prioridades negativa?

Projetos Referncias
[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. [Barney, 2005] Barney, B. (2005). POSIX 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. [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. http://www.gnu.org/software/pth. (2005). 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. [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.

c Prof. Carlos Maziero

REFERNCIAS 40

[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. [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. [of California, 2005] of California, http://setiathome.ssl.berkeley.edu. U. (2005). The SETI@home project.

[Silberschatz et al., 2001] Silberschatz, A., Galvin, P., and Gane, G. (2001). Sistemas Operacionais Conceitos e Aplicaes. Campus. [Tanenbaum, 2003] Tanenbaum, A. (2003). Sistemas Operacionais Modernos, 2a edio. Pearson Prentice-Hall.

c Prof. Carlos Maziero

O Task Control Block do Linux 41

A O Task Control Block do Linux

A estrutura em linguagem C apresentada a seguir constitui o descritor de tarefas (Task Control Block) do Linux. Ela foi extrada do arquivo include/linux/sched.h do cdigo-fonte do ncleo Linux 2.6.12 (o arquivo inteiro contm mais de 1.200 linhas de cdigo em C).
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 41 42 43 44

struct task_struct { volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */ struct thread_info *thread_info; atomic_t usage; unsigned long flags; /* per process flags, defined below */ unsigned long ptrace; int lock_depth;

/* BKL lock depth */

int prio, static_prio; struct list_head run_list; prio_array_t *array; unsigned long sleep_avg; unsigned long long timestamp, last_ran; unsigned long long sched_time; /* sched_clock time spent running */ int activated; unsigned long policy; cpumask_t cpus_allowed; unsigned int time_slice, first_time_slice; #ifdef CONFIG_SCHEDSTATS struct sched_info sched_info; #endif struct list_head tasks; /* * ptrace_list/ptrace_children forms the list of my children * that were stolen by a ptracer. */ struct list_head ptrace_children; struct list_head ptrace_list; struct mm_struct *mm, *active_mm;

/* task state */ struct linux_binfmt *binfmt; long exit_state; int exit_code, exit_signal; int pdeath_signal; /* The signal sent when the parent dies */ /* ??? */ unsigned long personality; unsigned did_exec:1;

c Prof. Carlos Maziero

O Task Control Block do Linux 42

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

pid_t pid; pid_t tgid; /* * pointers to (original) parent process, youngest child, younger sibling, * older sibling, respectively. (p->father can be replaced with * p->parent->pid) */ struct task_struct *real_parent; /* real parent process (when being debugged) */ struct task_struct *parent; /* parent process */ /* * children/sibling forms the list of my children plus the * tasks Im ptracing. */ struct list_head children; /* list of my children */ struct list_head sibling; /* linkage in my parents children list */ struct task_struct *group_leader; /* threadgroup leader */

/* PID/PID hash table linkage. */ struct pid pids[PIDTYPE_MAX];

struct completion *vfork_done; int __user *set_child_tid; int __user *clear_child_tid;

/* for vfork() */ /* CLONE_CHILD_SETTID */ /* CLONE_CHILD_CLEARTID */

unsigned long rt_priority; cputime_t utime, stime; unsigned long nvcsw, nivcsw; /* context switch counts */ struct timespec start_time; /* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */ unsigned long min_flt, maj_flt; cputime_t it_prof_expires, it_virt_expires; unsigned long long it_sched_expires; struct list_head cpu_timers[3];

/* process credentials */ uid_t uid,euid,suid,fsuid; gid_t gid,egid,sgid,fsgid; struct group_info *group_info; kernel_cap_t cap_effective, cap_inheritable, cap_permitted; unsigned keep_capabilities:1; struct user_struct *user; #ifdef CONFIG_KEYS struct key *thread_keyring; /* keyring private to this thread */ #endif int oomkilladj; /* OOM kill score adjustment (bit shift). */ char comm[TASK_COMM_LEN]; /* executable name excluding path - access with [gs]et_task_comm (which lock it with task_lock()) - initialized normally by flush_old_exec */ /* file system info */

c Prof. Carlos Maziero

O Task Control Block do Linux 43

96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146

int link_count, total_link_count; /* ipc stuff */ struct sysv_sem sysvsem; /* CPU-specific state of this task */ struct thread_struct thread; /* filesystem information */ struct fs_struct *fs; /* open file information */ struct files_struct *files; /* namespace */ struct namespace *namespace; /* signal handlers */ struct signal_struct *signal; struct sighand_struct *sighand; sigset_t blocked, real_blocked; struct sigpending pending; unsigned long sas_ss_sp; size_t sas_ss_size; int (*notifier)(void *priv); void *notifier_data; sigset_t *notifier_mask; void *security; struct audit_context *audit_context; seccomp_t seccomp;

/* Thread group tracking */ u32 parent_exec_id; u32 self_exec_id; /* Protection of (de-)allocation: mm, files, fs, tty, keyrings */ spinlock_t alloc_lock; /* Protection of proc_dentry: nesting proc_lock, dcache_lock, write_lock_irq(&tasklist_lock); */ spinlock_t proc_lock; /* context-switch lock */ spinlock_t switch_lock; /* journalling filesystem info */ void *journal_info; /* VM state */ struct reclaim_state *reclaim_state;
struct dentry *proc_dentry; struct backing_dev_info *backing_dev_info; struct io_context *io_context; unsigned long ptrace_message; siginfo_t *last_siginfo; /* For ptrace use. */

c Prof. Carlos Maziero

O Task Control Block do Linux 44

147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170

/* * current io wait handle: wait queue entry to use for io waits * If this thread is processing aio, this points at the waitqueue * inside the currently handled kiocb. It may be NULL (i.e. default * to a stack based synchronous wait) if its doing sync IO. */ wait_queue_t *io_wait; /* i/o counters(bytes read/written, #syscalls */ u64 rchar, wchar, syscr, syscw; #if defined(CONFIG_BSD_PROCESS_ACCT) u64 acct_rss_mem1; /* accumulated rss usage */ u64 acct_vm_mem1; /* accumulated virtual memory usage */ clock_t acct_stimexpd; /* clock_t-converted stime since last update */ #endif #ifdef CONFIG_NUMA struct mempolicy *mempolicy; short il_next; #endif #ifdef CONFIG_CPUSETS struct cpuset *cpuset; nodemask_t mems_allowed; int cpuset_mems_generation; #endif };