SO Conteudo

5
Sistemas Operacionais como Programas Concorrentes

Rmulo Silva de Oliveira (UFSC, romulo@das.ufsc.br )1 Alexandre da Silva Carissimi (UFRGS, asc@inf.ufrgs.br)2 Simo Sirineo Toscani (UFRGS, PUCRS, simao@inf.ufrgs.br 3
Resumo: Este texto discute as possveis organizaes para um kernel (ncleo) de sistema operacional. Inicialmente feita uma rpida reviso dos conceitos fundamentais dos sistemas operacionais e dos mecanismos clssicos para a sincronizao de processos. Em seguida, diversas organizaes possveis para o kernel do sistema operacional so apresentadas. Em muitas delas o kernel aparece como um programa concorrente, onde a preocupao com a sincronizao entre processos est sempre presente. No final, o kernel do Linux descrito, como um estudo de caso.
Doutor em Engenharia Eltrica, nfase em Sistemas de Informao, pela UFSC e Mestre em Cincia da Computao pelo Programa de Ps-Graduao em Computao da UFRGS. Professor do Instituto de Informtica da UFRGS de 1989 a 1999, atualmente Professor do Departamento de Automao e Sistemas da Universidade Federal de Santa Catarina e orientador de Mestrado junto ao Programa de Ps-Graduao em Computao da UFRGS. DASCTC-UFSC, Caixa Postal 476, Florianpolis-SC, 88040-900 2 Doutor em Informtica pelo Instituto Nacional Politcnico de Grenoble (INPG), Franca. Mestre em Cincia da Computao pelo Programa de Ps-Graduao em Computacao e Engenheiro Eletricista pela UFRGS. Professor do Departamento de Informatica Aplicada da UFRGS. Caixa Postal 15064, Porto Alegre-RS, 91501-970 Doutor em Informtica pela Universidade Nova de Lisboa, Portugal. Mestre em Informtica pela PUC/RJ. Engenheiro eletricista pela UFRGS. Professor do Instituto de Informtica da UFRGS de 1975 a 1998. Atualmente, professor da Faculdade de Informtica, PUCRS e orientador de Mestrado junto ao Programa de Ps-Graduao em Computao da UFRGS. Av. Ipiranga, 6681 - Prdio 30, bloco 4, Porto Alegre RS, 90619-900
3
ERAD 2002 - 2a Escola Regional de Alto Desempenho
ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes
5.1. Introduo
O sistema operacional uma camada de software colocada entre o hardware e os programas que executam tarefas para os usurios. Essa viso de um sistema computacional ilustrada na figura 5.1. Esta seo contm uma reviso dos conceitos fundamentais dos sistemas operacionais e est baseada em [OLI 01].
EDITOR TEXTO CONTABILIDADE WWW BROWSER QUAKE
SISTEMA OPERACIONAL HARDWARE
Figura 5.1: Sistema computacional. O sistema operacional procura tornar a utilizao do computador, ao mesmo tempo, mais eficiente e mais conveniente. A utilizao mais eficiente busca um maior retorno no investimento feito no hardware. Maior eficincia significa mais trabalho obtido do mesmo hardware. Tipicamente isso obtido atravs do compartilhamento de recursos entre programas, como, por exemplo, espao na memria principal, tempo de processador, impressora, espao e acesso a disco. Uma utilizao mais conveniente implica na diminuio no tempo necessrio para a construo dos programas e aprendizado para utilizao do Sistema. Isso obtido, escondendo-se do programador detalhes do hardware e do sistema operacional. Isso tambm implica a reduo no custo do software, pois so necessrias menos horas de programador. Para atingir os objetivos propostos, o sistema operacional oferece diversos tipos de servios. A definio precisa dos servios depende do sistema operacional em considerao. Entretanto, a maioria dos sistemas operacionais oferece um conjunto bsico de servios, sempre necessrios. Todo sistema operacional oferece meios para que um programa seja carregado na memria principal e executado. Em geral, um arquivo contm o programa a ser executado. O sistema operacional recebe o nome do arquivo, aloca memria para o programa, copia o contedo do arquivo para a memria principal e inicia sua execuo. Talvez o servio mais importante oferecido pelo sistema operacional seja o que permite a utilizao de arquivos, servio este implementado atravs do sistema de arquivos. Atravs dele, possvel criar, escrever, ler e destruir arquivos. Atravs da leitura e escrita, possvel copiar, imprimir, consultar e atualizar arquivos. Em geral, tambm existem operaes do tipo renomear, obter o tamanho, obter a data de criao e outras informaes a respeito dos arquivos. Todo acesso aos perifricos feito atravs do sistema operacional. Na maioria das vezes, os discos magnticos so acessados de forma indireta, atravs dos arquivos. Entretanto, muitos dispositivos podem ser acessados de forma direta. Entre eles, esto os terminais, impressoras, fitas magnticas e linhas de comunicao. Para tanto, devem existir servios do tipo alocao de perifrico, leitura, escrita e liberao. Em geral, tambm pode-se obter informaes a respeito de cada perifrico e alterar algumas de suas caractersticas. Por exemplo, alterar a velocidade de uma linha de comunicao.
ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.
medida que diversos usurios compartilham um computador, passa a ser importante gerenciar os recursos que cada usurio emprega. Essa informao pode ser utilizada tanto para fins de clculo de um valor a ser cobrado pelo uso do computador como na identificao de gargalos dentro do sistema. O compartilhamento de um computador, ou recursos em geral, s vivel se houver algum tipo de proteo entre os usurios. No aceitvel, por exemplo, que um usurio envie dados para a impressora no meio da listagem de outro usurio. Outro exemplo de interferncia entre usurios seria a destruio de arquivos ou o cancelamento da execuo do programa de outra pessoa. Cabe ao sistema operacional garantir que cada usurio possa trabalhar sem sofrer interferncia danosa dos demais. Os programas solicitam servios ao sistema operacional atravs das chamadas de sistema, tambm conhecidas como API (Application Program Interface). Elas so semelhantes s chamadas de subrotinas. Entretanto, enquanto as chamadas de subrotinas so transferncias para procedimentos normais do programa, as chamadas de sistema transferem a execuo para o cdigo do sistema operacional. O retorno da chamada de sistema, assim como o retorno de uma subrotina, faz com que a execuo do programa seja retomada a partir da instruo que segue a chamada. Para o programador assembly (linguagem de montagem), as chamadas de sistema so bastante visveis. Por exemplo, o conhecido "INT 21H" no MS-DOS. Em uma linguagem de alto nvel, elas ficam escondidas dentro da biblioteca utilizada pelo compilador. O programador chama subrotinas de uma biblioteca. So as subrotinas da biblioteca que chamam o sistema. Por exemplo, qualquer funo da biblioteca que acesse o terminal (como printf() na linguagem C) exige uma chamada de sistema. A lista de servios do sistema operacional agora transformada em uma lista de chamadas de sistema. A descrio dessas chamadas forma um dos mais importantes manuais de um sistema operacional. Os programas de sistema, algumas vezes chamados de utilitrios, so programas normais executados fora do kernel do sistema operacional. Eles utilizam as mesmas chamadas de sistema disponveis aos demais programas. Esses programas implementam tarefas bsicas para a utilizao do sistema e muitas vezes so confundidos com o prprio sistema operacional. Como implementam tarefas essenciais para a utilizao do computador, so, em geral, distribudos pelo prprio fornecedor do sistema operacional. Exemplos so os utilitrios para manipulao de arquivos: programas para listar arquivo, imprimir arquivo, copiar arquivo, trocar o nome de arquivo, listar o contedo de diretrio, entre outros. O mais importante programa de sistema o interpretador de comandos (shell), o qual ativado pelo sistema operacional sempre que um usurio inicia sua sesso de trabalho. Sua tarefa receber comandos do usurio e disparar sua execuo. Algumas vezes o sistema operacional oferece uma interface grfica de usurio (GUI graphical user interface). A nica diferena est na comodidade para o usurio, que passa a usar cones, menus e mouse no lugar de digitar comandos textuais.
5.1.1. Multiprogramao
Em um sistema multiprogramado diversos programas so mantidos na memria ao mesmo tempo. Suponha que o sistema operacional inicia a execuo do programa 1. Aps algum tempo, da ordem de milisegundos, o programa 1 solicita algum tipo de operao de entrada ou sada. Por exemplo, uma leitura do disco. Sem multiprogramao, o processador ficaria parado durante a realizao do acesso. Em um sistema multiprogramado, enquanto o perifrico executa o comando enviado, o sistema operacional inicia a execuo de outro programa. Por exemplo, o programa 2. Dessa
forma, processador e perifrico trabalham ao mesmo tempo. Enquanto o processador executa o programa 2, o perifrico realiza a operao solicitada pelo programa 1. Em sistemas operacionais conveniente diferenciar um programa de sua execuo, para tanto usado o conceito de processo. No existe uma definio objetiva, aceita por todos, para a idia de processo. Na maioria das vezes, um processo definido como "um programa em execuo". O conceito de processo bastante abstrato, mas essencial no estudo de sistemas operacionais. Um programa uma seqncia de instrues. algo passivo dentro do sistema. Ele no altera o seu prprio estado. O processo um elemento ativo. O processo altera o seu estado, medida que executa um programa. o processo que faz chamadas de sistema, ao executar os programas. possvel que vrios processos executem o mesmo programa ao mesmo tempo. Por exemplo, diversos usurios podem estar utilizando simultaneamente o editor de texto favorito da instalao. Existe um nico programa "editor de texto". Para cada usurio, existe um processo executando o programa. Cada processo representa uma execuo independente do editor de textos. Todos os processos utilizam uma mesma cpia do cdigo do editor de textos, porm cada processo trabalha sobre uma rea de variveis privativa. A descrio acima mostrou diversos momentos pelos quais passa o processo durante a sua existncia. A partir dessa descrio, pode-se estabelecer os estados possveis para um processo. Aps ser criado, o processo precisa de processador para executar. Entretanto, o processador poder estar ocupado com outro processo, e ele dever esperar. Diversos processos podem estar nesse mesmo estado. Por exemplo, imagine que o processo 1 est acessando um perifrico. O processo 2 est executando. Quando termina a operao de E/S do processo 1, ele precisa de processador para voltar a executar. Como o mesmo est ocupado com o processo 2, o processo 1 dever esperar. Por alguma razo, o sistema operacional pode decidir executar o processo 1 imediatamente. Entretanto, o problema no muda. Agora o processo 2 quem dever esperar at que o processador fique livre. Suponha que existe um nico processador no computador. Nesse caso, necessrio manter uma fila com os processos aptos a ganhar o processador. Essa fila chamada "fila de aptos" (ready queue). No estado executando, um processo efetivamente tem seu cdigo executado pelo processador e pode fazer chamadas de sistema. At a chamada de sistema ser atendida, o processo no pode continuar sua execuo. Ele fica bloqueado e s volta a disputar o processador aps a concluso da chamada. Enquanto espera pelo trmino da chamada de sistema, o processo est no estado bloqueado (blocked). A mudana de estado de qualquer processo iniciada por um evento. Esse evento aciona o sistema operacional, que ento altera o estado de um ou mais processos. Como visto antes, a transio do estado de executando para bloqueado feita atravs de uma chamada de sistema. Uma chamada de sistema necessariamente feita pelo processo no estado executando. Ele fica no estado bloqueado at o atendimento da mesma. Com isso, o processador fica livre. O sistema operacional ento seleciona um processo da fila de aptos para receber o processador. O processo selecionado passa do estado de apto para o estado executando. O mdulo do sistema operacional que faz essa seleo chamado de escalonador (scheduler). Existem solues de escalonamento onde o processo executando somente libera o processador voluntariamente, ao solicitar uma operao que leve ao seu bloqueio. Este tipo de soluo dita no-preemptiva. Quando o escalonamento, por ser baseado em prioridades ou fatias de tempo, pode transferir automaticamente um processo do estado executando para o estado apto, ento, tem-se uma soluo do tipo preemptiva.
Outro tipo de evento corresponde s interrupes do hardware. Elas, em geral, informam o trmino de uma operao de E/S. Isso significa que um processo bloqueado ser liberado. O processo liberado passa do estado de bloqueado para o estado de apto. Ele volta a disputar o processador com os demais da fila de aptos. Alguns outros caminhos tambm so possveis no grafo de estados. A destruio do processo pode ser em funo de uma chamada de sistema ou por solicitao do prprio processo. Entretanto, alguns sistemas podem resolver abortar o processo, caso um erro crtico tenha acontecido durante uma operao de E/S. Nesse caso, passa a existir um caminho do estado bloqueado para a destruio. Algumas chamadas de sistema so muito rpidas. Por exemplo, leitura da hora atual. No existe acesso a perifrico, mas apenas consulta s variveis do prprio sistema operacional. Nesse caso, o processo no precisa voltar para a fila de aptos. Ele simplesmente retorna para a execuo aps a concluso da chamada. Isso implica um caminho do estado bloqueado para o estado executando. Muitos sistemas procuram evitar que um nico processo monopolize a ocupao do processador. Se um processo est h muito tempo no processador, ele volta para o fim da fila de aptos. Um novo processo da fila de aptos ganha o processador. Dessa forma, cada processo tem a chance de executar um pouco. Esse mecanismo cria um caminho entre o estado executando e o estado apto. A figura 5.2 mostra o grafo de estados dos processos com esses novos caminhos.
C ria o
L im ite d e T e m p o
S e le o
A p to
Ex e c u ta n d o
C h a m a d a S is te m a
D e stru i o
R e to rn o Im e d ia to
In te rru p o d e H a rd w a re
Blo q u e a d o
E rro C rtic o
Figura 5.2: Diagrama de estados de um processo.
5.1.2. Mecanismo de interrupes

Talvez o mais importante conceito na realizao de um sistema operacional seja o conceito de interrupo. atravs de seu emprego que a multiprogramao, chamadas de sistema, e os mecanismos de gerncia de memria, gerncia de E/S, entre outros, so implementados. O mecanismo de interrupo um recurso comum a todos os processadores empregado para sinalizar a ocorrncia de um evento e solicitar a interveno do processador para que esse evento seja tratado de forma adeqada. Fisicamente, um barramento de controle usado para enviar sinais eltricos associados a ocorrncia evento. Essa forma empregada para que o evento chame a ateno do processador. Em resposta a essa ao, o processador desvia (interrompe) a posio atual do programa em execuo para uma rotina especfica responsvel por realizar uma srie de aes relacionadas ao tratamento dessa interrupo. A rotina responsvel por atender a
interrupo chamada de tratador de interrupo. Quando o tratador termina, a execuo retorna ao ponto em que o programa se encontrava sem que esse perceba que foi interrompido. Em certos aspectos, uma interrupo semelhante a uma chamada de subrotina: em ambos casos existe uma rotina que ativada e, quando termina, a execuo retorna ao ponto original. Entretanto, interrupes diferem drasticamente na forma pela qual so ativadas. Por serem vinculadas a ocorrncia de eventos externos, o momento exato de sua ativao no pode ser previsto pelo programa podendo se situar em qualquer ponto de um programa (interrupes de software, como ser visto mais adiante, so excees). Entretanto, existem momentos em que um programa no pode ser interrompido, como, por exemplo, quando est alterando variveis que tambm so acessadas pelo tratador de interrupo. Se uma interrupo ocorrer nesse instante, o tratador ser ativado e ir acessar variveis que podem estar com seus valores temporariamente inconsistentes por estarem sendo manipuladas pelo programa. necessrio ento impedir que isso ocorra. A soluo para esse problema desligar temporariamente o atendimento a interrupes, enquanto o programa realiza uma tarefa crtica que no pode ser interrompida. Os processadores normalmente dispem de instrues para habilitar e desabilitar interrupes. Enquanto as interrupes estiverem desabilitadas, o tratador de interrupo no acionado. Ainda, para que a execuo do programa interrompido no seja comprometido necessrio que a execuo do tratador de interrupo mantenha o estado do processador inalterado. Em outras palavras, o contedo de todos registradores internos dever ser o mesmo que no momento que ocorreu a interrupo. Alguns processadores salvam automaticamente o contudo de todos registradores quando ocorre uma interrupo. Outros processadores salvam apenas alguns, cabendo rotina que atende interrupo salvar os demais registradores. O tratador de interrupo termina ao executar uma instruo especial de retorno da interrupo. Essa instruo restaura o contudo original dos registradores, salvos no momento da ativao, e faz o processador retomar a execuo do programa interrompido. Uma questo ainda persiste. Como em um computador podem ocorrer vrias interrupes necessrio identificar a fonte da interrupo para realizar o procedimento apropriado. A maioria dos processadores admitem diversos tipos de interrupes. Cada tipo de interrupo identificado por um nmero, como, por exemplo, de zero a 255. Nesse caso, a soluo mais simples consiste em atribuir um tipo diferente a cada interrupo. Nesse caso, a ocorrncia de um evento externo no somente interrompe o processador, mas tambm a identifica atravs de seu tipo. O endereo de um tratador de interrupo chamado vetor de interrupo. O termo usado pois ele "aponta" para a rotina de atendimento da interrupo. Cada tipo de interrupo possui associado um vetor de interrupo. Em geral, existe uma tabela na memria com todos os vetores de interrupo, ou seja, com os endereos das rotinas responsveis por tratar os respectivos tipos de interrupo. Ela chamada de tabela dos vetores de interrupo. Para que uma mesma rotina atenda diversos tipos de interrupo, basta colocar o seu endereo em diversas entradas da tabela. Entretanto, o mais comum utilizar uma rotina para cada tipo de interrupo. A ocorrncia de uma interrupo dispara no processador uma seqncia de atendimento. O processador verifica se o tipo de interrupo sinalizado est habilitado. Caso negativo, ignorado. Se estiver habilitado, o contedo dos registradores salvo na pilha, o endereo da rotina responsvel pelo tratamento daquele tipo de interrupo obtido na entrada correspondente ao nmero da interrupo que ocorreu e a execuo
desviada para esse endereo. Toda essa seqncia executada pelo hardware, comandada pela unidade de controle do processador. Interrupes de software (tambm chamadas de traps) so causadas pela execuo de uma instruo especfica para isso. Ela tem como parmetro o nmero da interrupo que deve ser ativada. O efeito semelhante a uma chamada de subrotina, pois o prprio programa interrompido quem gera a interrupo, levando execuo do tratador correspondente. A vantagem sobre subrotinas que o endereo do tratador no precisa ser conhecido pelo programa que causa a interrupo. Basta conhecer o tipo de interrupo apropriado.O maior uso para interrupes de software a implementao das chamadas de sistema, atravs das quais os programas de usurios solicitam servios ao sistema operacional. No possvel desabilitar interrupes de software, mesmo porque no necessrio. Somente quem pode gerar uma interrupo de software a rotina em execuo. Se a rotina em execuo no deseja que interrupes de software aconteam, basta no gerar nenhuma. Entretanto, a ocorrncia de uma interrupo de software desabilita interrupes exatamente da mesma forma que acontece com as interrupes de hardware. Na maioria dos processadores, a mesma seqncia de eventos que ocorrem aps uma interrupo de hardware acontece tambm aps uma interrupo de software. Existe uma terceira classe de interrupes geradas pelo prprio processador. So as interrupes por erro, muitas vezes chamadas de interrupes de exceo. Elas acontecem quando o processador detecta algum tipo de erro na execuo do programa. Por exemplo, uma diviso por zero ou o acesso a uma posio de memria que na verdade no existe ou no foi previamente alocada para o processo. O procedimento de atendimento a essa classe de interrupes igual ao descrito anteriormente.
5.1.3. Mecanismos de proteo

Na multiprogramao diversos processos compartilham o computador. necessrio que o sistema operacional oferea proteo aos processos e garanta a utilizao correta do sistema. Para isso necessrio o auxlio da arquitetura do processador (hardware). A forma usual definir dois modos de operao para o processador. Pode-se cham-los de modo usurio e modo supervisor. Quando o processador est em modo supervisor, no existem restries, e qualquer instruo pode ser executada. Em modo usurio, algumas instrues no podem ser executadas. Essas instrues so chamadas de instrues privilegiadas, e somente podem ser executadas em modo supervisor. Se um processo de usurio tentar executar uma instruo privilegiada em modo usurio, o hardware automaticamente gera uma interrupo e aciona o sistema operacional, o qual poder abortar o processo de usurio. As interrupes, alm de acionarem o sistema operacional, tambm chaveiam automaticamente o processador para modo supervisor. Nesse mecanismo, o sistema operacional executa com o processador em modo supervisor. Os processos de usurio executam em modo usurio. Quando ligado o processador, ele inicia em modo supervisor e o sistema operacional realiza todas as inicializaes necessrias. Para proteger os perifricos, as instrues de E/S so tornadas privilegiadas. Se um processo de usurio tentar acessar diretamente um perifrico, ocorre uma interrupo. O sistema operacional ativado, j em modo supervisor, e o processo de usurio abortado, pois tentou um acesso ilegal. A nica forma de o processo de usurio realizar uma operao de E/S atravs de uma chamada de sistema. Quando ocorre uma interrupo do perifrico, o sistema operacional ativado. Como ocorreu uma interrupo, o processador chaveado para modo supervisor. Por
exemplo, para atender as chamadas de sistema, ele precisa acessar os perifricos. Como foi dito antes, isso agora s possvel com o processador em modo supervisor. A execuo de uma interrupo de software ou trap implica tambm em chavear o processador para modo supervisor (lembre que as chamadas de sistemas so normalmente empregadas para implementar as chamadas de sistema). A figura 5.3 ilustra as situaes em que ocorrem trocas do modo de operao. Observe que o sistema operacional ativado em trs situaes. Primeiro, por uma interrupo de perifrico, informando a concluso de alguma operao de E/S. Segundo, por uma interrupo do hardware de proteo, porque o processo em execuo tentou uma operao ilegal. Esse hardware de proteo aparece tipicamente incorporado ao prprio processador, fazendo parte do mesmo circuito integrado. Finalmente, por uma interrupo de software, que representa uma chamada de sistema do processo em execuo. Em todas elas, o sistema operacional ser ativado em modo supervisor.
Instruo "passa p/ modo usurio"
Siste m a O p e ra c io na l e m M o d o Sup e rviso r
Interrupo (perifrico)
Pro c e sso d e Usu rio e m M o d o Usu rio
Interrupo (proteo)
Interrupo de software (chamada de sistema)
Figura 5.3: Modos de operao do processador. Pelo que foi apresentado at aqui, possvel perceber que a proteo das rotinas que atendem interrupes vital. Se o usurio conseguir instalar suas rotinas no lugar dos tratadores de interrupo do sistema operacional, ele conseguir o processador em modo supervisor. Alm disso, um usurio poder corromper o sistema se for capaz de alterar reas de cdigo ou variveis do sistema operacional. necessrio proteger a memria do sistema operacional, tanto cdigo como dados. Ao mesmo tempo, necessrio proteger a memria usada por um processo do acesso de outros processos. Para implementar a proteo de memria, o sistema operacional tambm necessita de auxlio da arquitetura do hardware. Existem muitas maneiras de realizar a proteo da memria, sendo a mais importante apresentada mais adiante (seo 1.1.5). Para evitar que um nico processo de usurio monopolize a utilizao do processador, empregado um temporizador (timer). O temporizador um relgio de tempo real, implementado pelo hardware, que gera interrupes de tempos em tempos. O perodo do temporizador corresponde ao intervalo de tempo entre interrupes. Em geral, ele da ordem de milisegundos. As interrupes do temporizador ativam o sistema operacional. Ele ento verifica se o processo executando j est h muito tempo com o processador. Nesse caso, o sistema pode suspender o processo por exceder o limite de tempo de execuo. Mais tarde, o processo suspenso ter oportunidade para executar novamente. O controle do temporizador deve ser feito atravs de instrues privilegiadas. Se o processo usurio desligar o temporizador, ele ter controle do processador por tempo indeterminado. O temporizador ligado garante que o sistema operacional ser acionado ao menos uma vez a cada perodo de alguns milisegundos. Todo o mecanismo de proteo est baseado em interrupes. O processo usurio deve sempre executar com as interrupes habilitadas. Somente assim, uma operao ilegal ser detectada. Ao mesmo tempo, a instruo que desabilita interrupes
deve ser privilegiada. Isso necessrio para que o processo usurio no possa desabilitar as interrupes e tornar o mecanismo inoperante.
5.1.4. Chaveamento de processos

A base da multiprogramao o compartilhamento do processador entre os processos. Por exemplo, enquanto o processo 1 fica bloqueado, espera de um dispositivo perifrico, o processo 2 ocupa o processador. Em sistema multiprogramado, necessrio interromper processos para continu-los mais tarde. Essa tarefa chamada de chaveamento de processo. Para passar o processador do processo 1 para o processo 2, necessrio salvar o contexto de execuo do processo 1. Quando o processo 1 receber novamente o processador, o seu contexto de execuo ser restaurado. necessrio salvar tudo que poder ser destrudo pelo processo 2, enquanto ele executa. O contexto de execuo inclui o contedo dos registradores do processador. O processo 2, ao executar, vai colocar seus prprios valores nos registradores. Entretanto, quando o processo 1 voltar a executar, ele espera encontrar nos registradores os mesmos valores que havia no momento da interrupo. O programa do usurio sequer sabe que ser interrompido diversas vezes durante a sua execuo. Logo, no possvel deixar para o programa a tarefa de salvar os registradores. Isso deve ser feito pelo prprio sistema operacional. Em geral, salvar o contexto de execuo do processo em execuo a primeira tarefa do sistema operacional, ao ser acionado. Da mesma forma, a ltima tarefa do sistema operacional ao entregar o processador para um processo repor o seu contexto de execuo. Ao repor o valor usado pelo processo no registrador apontador de instrues (program counter), o processador volta a executar instrues do programa do usurio. O mdulo do sistema operacional que realiza a reposio do contexto chamado de dispatcher. Um processo uma abstrao que rene uma srie de atributos como espao de endereamento, descritores de arquivos abertos, permisses de acesso, quotas, etc. Um processo possui ainda reas de cdigo, dados e pilha de execuo. Tambm associado ao processo um fluxo de execuo. Por sua vez, uma thread nada mais que um fluxo de execuo. Na maior parte das vezes, cada processo formado por um conjunto de recursos mais uma nica thread. A idia de multithreading associar vrios fluxos de execuo (vrias threads) a um nico processo. Em determinadas aplicaes, conveniente disparar vrias threads dentro do mesmo processo (programao concorrente). importante notar que as threads existem no interior de um processo, compartilhando entre elas os recursos do processo, como o espao de endereamento (cdigo e dados). Devido a essa caracterstica, a gerncia de threads (criao, destruio, troca de contexto, sincronizao) "mais leve" quando comparada com processos. Por exemplo, criar um processo implica alocar e inicializar estruturas de dados no sistema operacional para represent-lo. Por outro lado, criar uma thread implica apenas definir uma pilha e um novo contexto de execuo dentro de um processo j existente. O chaveamento entre duas threads de um mesmo processo muito mais rpido que o chaveamento entre dois processos. Por exemplo, como todas as threads de uma mesmo processo compartilham o mesmo espao de endereamento, a MMU (memory management unit) no afetada pelo chaveamento entre elas. Em funo do exposto acima, threads so muitas vezes chamadas de processos leves. Duas maneiras bsicas podem ser utilizadas para implementar o conceito de threads. Na primeira, o sistema operacional suporta apenas processos convencionais, isto , processos com uma nica thread. O conceito de thread ento implementado
10 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes
pelo prprio processo a partir de uma biblioteca ligada ao programa do usurio. Devido a essa caracterstica, threads implementadas dessa forma so denominadas de threads do nvel do usurio (user-level threads). No segundo caso, o sistema operacional suporta diretamente o conceito de thread. A gerncia de fluxos de execuo pelo sistema operacional no orientada a processos mas sim a threads. As threads que seguem esse modelo so ditas threads do nvel do sistema (kernel threads). O primeiro mtodo denominado N:1 (many-to-one). A principal vantagem o fato de as threads serem implementadas em espao de usurio, no exigindo assim nenhuma interao com o sistema operacional. Esse tipo de thread oferece um chaveamento de contexto mais rpido e menor custo para criao e destruio. A biblioteca de threads responsvel pelo compartilhamento, entre elas, do tempo alocado ao processo. Uma thread efetuando uma operao de entrada ou sada bloqueante provoca o bloqueio de todas as threads do seu processo. Existem tcnicas de programao para evitar isso, mas so relativamente complexas. O segundo mtodo dito 1:1 (one-to-one). Ele resolve os problemas de aproveitamento do paralelismo real dentro de um nico programa e processamento junto com E/S. Para que isso seja possvel, o sistema operacional deve ser projetado de forma a considerar a existncia de threads dividindo o espao de endereamento do processo hospedeiro. A desvantagem desse mtodo que as operaes relacionadas com as threads passam necessariamente por chamadas ao sistema operacional, o que torna threads tipo 1:1 "menos leves" que threads do tipo N:1.
5.1.5. Memria lgica e memria fsica

A memria lgica de um processo aquela que o processo enxerga, ou seja, aquela que o processo capaz de acessar. Os endereos manipulados pelo processo so endereos lgicos. Em outras palavras, as instrues de mquina de um processo especificam endereos lgicos. Por exemplo, um processo executando um programa escrito na linguagem C manipula variveis tipo pointer. Essas variveis contm endereos lgicos. Em geral, cada processo possui a sua memria lgica, que independente da memria lgica dos outros processos. A memria fsica aquela implementada pelos circuitos integrados de memria, pela eletrnica do computador. O endereo fsico aquele que vai para a memria fsica, ou seja, usado para enderear os circuitos integrados de memria. O espao de endereamento lgico de um processo formado por todos os endereos lgicos que esse processo pode gerar. Existe um espao de endereamento lgico por processo. J o espao de endereamento fsico formado por todos os endereos aceitos pelos circuitos integrados de memria. A unidade de gerncia de memria (Memory Management Unit, MMU) o componente do hardware responsvel por prover os mecanismos que sero usados pelo sistema operacional para gerenciar a memria. Entre outras coisas, a MMU que vai mapear os endereos lgicos gerados pelos processos nos correspondentes endereos fsicos que sero enviados para a memria. A figura 5.4 ilustra o papel da MMU entre o processador e a memria. Na verdade, o processador e a MMU formam, na maioria das vezes, um nico circuito integrado.
11 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

Endereo Lgico Endereo Fsico
Processador
MMU
Memria
Figura 5.4: Diagrama incluindo a MMU entre o processador e a memria. A figura 5.5 ilustra o funcionamento da tcnica de paginao. O exemplo da figura utiliza um tamanho de memria exageradamente pequeno para tornar a figura mais clara e menor. O espao de endereamento lgico de um processo dividido em pginas lgicas de tamanho fixo. No exemplo, todos os nmeros mostrados so valores binrios. A memria lgica composta por 12 bytes. Ela foi dividida em 3 pginas lgicas de 4 bytes cada uma. O endereo lgico tambm dividido em duas partes: um nmero de pgina lgica e um deslocamento dentro dessa pgina. No exemplo, endereos lgicos possuem 5 bits. Considere o byte Y2. Ele possui o endereo lgico 00101. Pode-se ver esse endereo composto por duas partes. Os primeiros 3 bits indicam o nmero da pgina, isto , 001. Os ltimos 2 bits indicam a posio de Y2 dentro da pgina, isto , 01. Observe que todos os bytes pertencentes a uma mesma pgina lgica apresentam o mesmo nmero de pgina. De forma semelhante, todas as pginas possuem bytes com deslocamento entre 00 e 11.
Memria Lgica
000 00 000 01 000 10 000 11 001 00 001 01 001 10 001 11 010 00 010 01 010 10 010 11 X1 X2 X3 X4 Y1 Y2 Y3 Y4 Z1 Z2 Z3 Z4 End.Fsico de Y2 101 01
Memria Fsica
Z1 Z2 Z3 Z4 000 00 000 01 000 10 000 11 001 00 001 01 001 10 001 11 010 00 010 01 010 10 010 11 011 00 011 01 011 10 011 11 100 00 100 01 100 10 100 11 101 00 101 01 101 10 101 11
X1 X2 X3 X4
End.Lgico de Y2 001 01
Tabela de Pginas
Pg.Lgica Pg.Fsica 000 001 010 010 101 000 Y1 Y2 Y3 Y4
Figura 5.5: Mecanismo bsico de paginao.
A memria fsica tambm dividida em pginas fsicas com tamanho fixo, idntico ao tamanho da pgina lgica. No exemplo, a memria fsica composta por 24 bytes. A pgina fsica tem o mesmo tamanho que a pgina lgica, ou seja, 4 bytes. A memria fsica foi dividida em 6 pginas fsicas de 4 bytes cada uma. Os endereos de memria fsica tambm podem ser vistos como compostos por duas partes. Os 3 primeiros indicam um nmero de pgina fsica. Os 2 ltimos bits indicam um deslocamento dentro dessa pgina fsica. Um programa carregado pgina a pgina. Cada pgina lgica do processo ocupa exatamente uma pgina fsica da memria fsica. Entretanto, a rea ocupada pelo processo na memria fsica no precisa ser contgua. Mais do que isso, a ordem em que as pginas lgicas aparecem na memria fsica pode ser qualquer, no precisa ser a mesma da memria lgica. Observe que, no exemplo, o contedo das pginas lgicas foi espalhado pela memria fsica, mantendo o critrio de que cada pgina lgica carregada em exatamente uma pgina fsica. Durante a carga montada uma tabela de pginas para o processo. Essa tabela informa, para cada pgina lgica, qual a pgina fsica correspondente. Quando um processo executa, ele manipula endereos lgicos. O programa escrito com a suposio que ele vai ocupar uma rea contgua de memria, que inicia no endereo zero, ou seja, vai ocupar a memria lgica do processo. Para que o programa execute corretamente, necessrio transformar o endereo lgico especificado em cada instruo executada, no endereo fsico correspondente. Isso feito com o auxlio da tabela de pginas. O endereo lgico gerado inicialmente dividido em duas partes: um nmero de pgina lgica e um deslocamento dentro da pgina. O nmero da pgina lgica usado como ndice no acesso tabela de pginas. Cada entrada da tabela de pginas possui o mapeamento de pgina lgica para pgina fsica. Dessa forma, obtido o nmero da pgina fsica correspondente. J o deslocamento do byte dentro da pgina fsica ser o mesmo deslocamento desse byte dentro da pgina lgica, pois cada pgina lgica carregada exatamente em uma pgina fsica. Basta juntar o nmero de pgina fsica obtido na tabela de pginas com o deslocamento j presente no endereo lgico para obter-se o endereo fsico do byte em questo. A figura 5.5 mostra como o endereo lgico do byte Y2 transformado no endereo fsico correspondente. Um aspecto importante da paginao a forma como a tabela de pginas implementada. Observe que ela deve ser consultada a cada acesso memria. Uma soluo manter a tabela de pginas na prpria memria. A MMU possui ento dois registradores para localizar a tabela na memria. O registrador de base da tabela de pginas (Page Table Base Register, PTBR) indica o endereo fsico de memria onde a tabela est colocada. O registrador de limite da tabela de pginas (Page Table Limit Register, PTLR) indica o nmero de entradas da tabela. O problema desse mecanismo que agora cada acesso que um processo faz memria lgica transforma-se em dois acessos memria fsica. Quando ocorre um chaveamento de processos, os valores do PTBR e do PTLR para a tabela de pginas do processo que recebe o processador devem ser copiados do DP para os registradores na MMU. Uma forma de reduzir o tempo de acesso memria no esquema anterior adicionar uma memria cache especial que vai manter as entradas da tabela de pginas mais recentemente utilizadas. Essa memria cache interna MMU chamada normalmente de Translation Lookaside Buffer (TLB). O acesso a essa cache rpido e no degrada o tempo de acesso memria como um todo. Quando a entrada requerida da tabela de pginas est na TLB, o acesso memria lgica do processo feito com
um nico acesso memria fsica. Quando a entrada da tabela de pginas associada com a pgina lgica acessada no est na TLB, necessrio um duplo acesso memria fsica, como no esquema anterior. Nesse caso, a entrada referente a pgina lgica acessada includa na TLB, na suposio (correta na maioria das vezes) de que o processo acessar essa pgina mais vezes logo em seguida. Quando a TLB usada e ocorre um chaveamento de processos, novamente os valores do PTBR e do PTLR para a tabela de pginas do processo que recebe o processador devem ser copiados do DP para os registradores na MMU. Alm disso, a TLB deve ser esvaziada (flushed). Isso necessrio, pois ela ainda contm entradas da tabela de pgina do processo que executou antes e agora perdeu o processador. Esquemas alternativos incluem o nmero do processo em cada entrada da TLB para resolver esse problema.
5.2. Reviso de programao concorrente

Um programa que executado por apenas um processo chamado de programa seqencial. A grande maioria dos programas escritos so programas seqenciais. Nesse caso, existe somente um fluxo de controle durante a execuo. Isso permite, por exemplo, que o programador realize uma "execuo imaginria" de seu programa apontando com o dedo, a cada instante, a linha que est sendo executada no momento. Um programa concorrente executado simultaneamente por diversos processos que cooperam entre si, isto , trocam informaes. Para o programador realizar agora uma "execuo imaginria", ele vai necessitar de vrios dedos, um para cada processo que faz parte do programa. Nesse contexto, trocar informaes significa trocar dados ou realizar algum tipo de sincronizao. necessria a existncia de interao entre processos para que o programa seja considerado concorrente. Embora a interao entre processos possa ocorrer atravs do acesso a arquivos comuns, esse tipo de concorrncia tratada na disciplina de Banco de Dados. A programao concorrente tratada neste texto utiliza mecanismos rpidos para interao entre processos: variveis compartilhadas e troca de mensagens. O termo "programao concorrente" vem do ingls concurrent programming, onde concurrent significa "acontecendo ao mesmo tempo". Uma traduo mais exata seria programao concomitante. Entretanto, o termo programao concorrente j est estabelecido no Brasil, sendo algumas vezes usado o termo programao paralela. O verbo "concorrer" admite em portugus vrios sentidos. Pode ser usado no sentido de cooperar, como em "tudo concorria para o bom xito da operao". Tambm pode ser usado com o significado de disputa ou competio, como em "ele concorreu a uma vaga na universidade". Em uma forma menos comum ele significa tambm existir simultaneamente. De certa forma, todos os sentidos so aplicveis aqui na programao concorrente. Em geral, processos concorrem (disputam) pelos mesmos recursos do hardware e do sistema operacional. Por exemplo, processador, memria, perifricos, estruturas de dados, etc. Ao mesmo tempo, pela prpria definio de programa concorrente, eles concorrem (cooperam) para o xito do programa como um todo. Certamente, vrios processos concorrem (existem simultaneamente) em um programa concorrente. Logo, programao concorrente um bom nome para o que se vai tratar nessa seo. Maiores informaes podem ser encontradas em [OLI 01].
5.2.1. Problema da seo crtica

Uma forma de implementar a passagem de dados so variveis compartilhadas pelos processos envolvidos na comunicao. A passagem de dados acontece quando um processo escreve em uma varivel que ser lida por outro processo. A quantidade exata de memria compartilhada entre os processos pode variar conforme o programa. Processos podem compartilhar todo o seu espao de endereamento, apenas um segmento de memria ou algumas variveis. No entanto, o compartilhamento de uma mesma regio de memria por 2 ou mais processos pode causar problemas. A soluo est em controlar o acesso dos processos a essas variveis compartilhadas de modo a garantir que um processo no acesse uma estrutura de dados enquanto essa estiver sendo atualizada por outro processo. Os problemas desse tipo podem acontecer de maneira muito sutil. Chama-se de seo crtica aquela parte do cdigo de um processo que acessa uma estrutura de dados compartilhada. O problema da seo crtica est em garantir que, quando um processo est executando sua seo crtica, nenhum outro processo entre na sua respectiva seo crtica. Por exemplo, isso significa que, enquanto um processo estiver inserindo nomes em uma fila, outro processo no poder retirar nomes da fila, e vice-versa. Uma soluo para o problema da seo crtica estar correta quando apresentar as seguintes quatro propriedades: - A soluo no depende das velocidades relativas dos processos; - Quando um processo P deseja entrar na seo crtica e nenhum outro processo est executando a sua seo crtica, o processo P no impedido de entrar; - Nenhum processo pode ter seu ingresso na seo crtica postergado indefinidamente, ou seja, ficar esperando para sempre; - Existe exclusividade mtua entre os processos com referncia a execuo das respectivas sees crticas. Solues erradas para o problema da seo crtica normalmente apresentam a possibilidade de postergao indefinida ou a possibilidade de deadlock. Ocorre postergao indefinida quando um processo est preso tentando entrar na seo crtica e nunca consegue por ser sempre preterido em benefcio de outros processos. Ocorre deadlock quando dois ou mais processos esto espera de um evento que nunca vai acontecer. Isto pode ocorrer porque cada um detm um recurso que o outro precisa, e solicita o recurso que o outro detm. Como nenhum dos dois vai liberar o recurso que possui antes de obter o outro, ambos ficaro bloqueados indefinidamente. Uma soluo simples para o problema da seo crtica desabilitar interrupes. Toda vez que um processo vai acessar variveis compartilhadas ele antes desabilita as interrupes. Dessa forma, ele pode acessar as variveis com a certeza de que nenhum outro processo vai ganhar o processador. No final da seo crtica, ele torna a habilitar as interrupes. Esse esquema efetivamente usado por alguns sistemas operacionais. Outra soluo possvel para o problema da seo crtica o Spin-Lock. Essa soluo baseada em instrues de mquina que permitem trocar entre si o valor de uma posio de memria com o valor contido em um registrador. Essa troca feita de forma indivisvel, isto , sem ser interrompida antes de seu trmino. As intrues "Testand-Set e "Compare on Store", disponveis em processadores comerciais, so exemplos tpicos.
Com base no comportamento dessas instrues possvel proteger a entrada da seo crtica por uma varivel que ocupar a posio [mem] da memria. Essa varivel normalmente chamada de lock (fechadura). Quando lock contm "0", a seo crtica est livre. Quando lock contm "1", ela est ocupada. A varivel inicializada com "0":
int lock = 0;
Antes de entrar na seo crtica, um processo precisa "fechar a porta", colocando "1" em lock. Entretanto, ele s pode fazer isso se "a porta estiver aberta". Logo, antes de entrar na seo crtica, o processo executa o seguinte cdigo:
do { reg = 1; Test_and_set( reg, lock); } while( reg == 1); cdigo-da-seo-crtica
Observe que o processo fica repetidamente colocando "1" em lock e lendo o valor que estava l antes. Se esse valor era "1", a seo estava (e est) ocupada, e o processo repete a operao. Quando o valor lido de lock for "0", ento a seo crtica est livre, o processo sai do do-while e prossegue sua execuo dentro da seo crtica. Ao sair da seo crtica, basta colocar "0" na varivel lock. Se houver algum processo esperando para entrar, a sua instruo swap pegar o valor "0", e ele entrar. A vantagem do Spin-Lock sua simplicidade, aliada ao fato de que no necessrio desabilitar interrupes. A instruo de mquina necessria est presente em praticamente todos os processadores atuais. Essa mesma soluo funciona em mquinas com vrios processadores, a partir de alguns cuidados na construo do hardware. Entretanto, Spin-Lock tem como desvantagem o busy-waiting. O processo que est no lao de espera executando "swap" ocupa o processador enquanto espera. Alm disso, existe a possibilidade de postergao indefinida, quando vrios processos esto esperando simultaneamente para ingressar na seo crtica e um processo "muito azarado" sempre perde na disputa de quem "pega antes" o valor "0" colocado na varivel lock. Na prtica o spin-lock muito usado em situaes nas quais a seo crtica pequena (algumas poucas instrues). Nesse caso, a probabilidade de um processo encontrar a seo crtica ocupada baixssima, o que torna o busy-waiting e a postergao indefinida situaes teoricamente possveis, mas altamente improvveis.
5.2.2. Semforos
Um mecanismo de sincronizao entre processos muito empregado o semforo. Ele foi criado pelo matemtico holands E. W. Dijkstra em 1965. O semforo um tipo abstrato de dado composto por um valor inteiro e uma fila de processos. Somente duas operaes so permitidas sobre o semforo. Elas so conhecidas como P (do holands proberen, testar) e V (do holands verhogen, incrementar). Quando um processo executa a operao P sobre um semforo, o seu valor inteiro decrementado. Caso o novo valor do semforo seja negativo, o processo bloqueado e inserido no fim da fila desse semforo. Quando um processo executa a operao V sobre um semforo, o seu valor inteiro incrementado. Caso exista algum processo bloqueado na fila desse semforo, o primeiro processo da fila liberado. Pode-
se sintetizar o funcionamento das operaes P e V sobre o semforo S da seguinte forma:

P(S): S.valor = S.valor - 1; Se S.valor < 0 Ento bloqueia o processo, insere em S.fila V(S): S.valor = S.valor + 1; Se S.valor <= 0 Ento retira processo P de S.fila, acorda P
Para que semforos funcionem corretamente, essencial que as operaes P e V sejam atmicas. Isso , uma operao P ou V no pode ser interrompida no meio e outra operao sobre o mesmo semforo iniciada. Semforos tornam a proteo da seo crtica muito simples. Para cada estrutura de dados compartilhada, deve ser criado um semforo S inicializado com o valor 1. Todo processo, antes de acessar essa estrutura, deve executar um P(S), ou seja, a operao P sobre o semforo S associado com a estrutura de dados em questo. Ao sair da seo crtica, o processo executa V(S). Uma variao muito comum de semforos so as construes mutex ou semforo binrio. Nesse caso, tem-se um semforo capaz de assumir apenas os valores 0 e 1. Ele pode ser visto como uma varivel tipo mutex, a qual assume apenas os valores livre e ocupado. Nesse caso, as operaes P e V so normalmente chamadas de lock e unlock, respectivamente. Assim como P e V, elas devem ser atmicas. Sua operao :
lock(x): Se x est livre Ento marca x como ocupado Seno insere processo no fim da fila "x" unlock(x): Se fila "x" est vazia Ento marca x como livre Seno libera processo do incio da fila "x"
O problema da seo crtica pode ser facilmente resolvido com o mutex:

mutex x = LIVRE; ... lock(x); /* entrada da seo crtica */ Seo Crtica; unlock(x); /* sada da seo crtica */
5.2.3. Mensagens
Tipicamente, o mecanismo que permite a troca de mensagens entre processos implementado pelo sistema operacional. Ele acessado atravs de duas chamadas de sistema bsicas: Send e Receive. A chamada de sistema Send possui pelo menos dois parmetros: a mensagem a ser enviada e o destinatrio da mensagem. Existem dois tipos de endereamento. No endereamento direto, a mensagem endereada explicitamente a um processo em particular. O processo remetente deve conhecer o identificador do processo destinatrio. Dessa forma, o processo remetente somente pode enviar mensagens para os processos dos quais ele conhece o identificador ou processos que possuem um identificador pblico. Em geral, isso no um problema pois os processos envolvidos na comunicao fazem parte do mesmo programa. Alguns sistemas trabalham com endereamento indireto. Nesse caso, o sistema operacional implementa um recurso chamado de caixa postal. Mensagens no so enviadas para processos, mas sim para caixas postais. As mensagens devero ser retiradas da caixa postal por outro processo. O sistema operacional normalmente fornece chamadas de sistema que permitem a criao e a destruio de caixas postais. Tambm o sistema operacional que controla quais processos possuem o direito de ler ou escrever na caixa postal. O processo remetente somente pode enviar mensagens para as caixas postais das quais ele conhece o identificador, ou para as caixas postais que possuem um identificador pblico. Alm disso, ele deve possuir o direito de escrita sobre a caixa postal em questo. A chamada de sistema Receive possui pelo menos um parmetro: o endereo da varivel do processo onde dever ser colocada a mensagem lida. Em alguns sistemas, todas as mensagens recebidas pelo processo so enfileiradas, e a chamada Receive retorna a primeira mensagem da fila. Opcionalmente, a chamada Receive possui como parmetro o identificador do processo do qual se deseja receber a mensagem. Nesse caso, a chamada somente ser satisfeita com uma mensagem do processo especificado. Quando endereamento indireto usado, a chamada Receive possui como segundo parmetro o identificador da caixa postal em questo. Um processo somente pode retirar mensagens das caixas postais das quais ele conhece o identificador, ou de caixas postais que possuem um identificador pblico. Alm disso, ele deve possuir o direito de leitura sobre a caixa postal em questo. Diversas variaes so possveis a partir dos esquemas descritos acima. Por exemplo, mensagens podem ter prioridades. Nesse caso, elas so enfileiradas conforme a sua respectiva prioridade, e o Receive sempre retorna a mensagem de mais alta prioridade que est disponvel. Existem ainda trs comportamentos possveis para o Receive quando no existe uma mensagem disponvel para o processo. O processo pode ficar bloqueado at que chegue uma mensagem que satisfaa o Receive. O processo pode retornar imediatamente com uma indicao de falha. Ou ainda, o processo pode ficar bloqueado por algum tempo esperando uma mensagem e retornar ao final desse com uma indicao de falha, caso nenhuma mensagem tenha chegado. Suponha agora que endereamento direto usado, e o processo P enviou uma mensagem para o processo Q, mas o processo Q ainda no executou o Receive. Alguns sistemas oferecem buffers para as mensagens que foram enviadas mas ainda no foram recebidas. Nesse caso, o processo remetente retorna imediatamente da chamada Send, e o sistema operacional armazena a mensagem. Ela ser entregue quando o processo destinatrio executar um Receive. Como os recursos do sistema so limitados, uma
soluo alternativa armazenar at um determinado limite, medido em mensagens ou em bytes. Quando esse limite atingido, o sistema operacional passa a bloquear os processos remetentes cujos respectivos destinatrios ainda no executaram o Receive. No outro extremo, tem-se os sistemas que no oferecem buffers para as mensagens e o remetente sempre bloqueado at o respectivo destinatrio executar Receive.
5.3. Organizao de sistemas operacionais

Um sistema operacional tambm um programa de computador e, como tal, possui uma especificao e um projeto. A especificao do mesmo corresponde lista de servios que deve executar e as chamadas de sistema que deve suportar. Por outro lado, o seu projeto ou design diz respeito sua estrutura interna, como as diferentes rotinas necessrias na implementao dos servios so organizadas internamente. O tamanho de um sistema operacional pode variar desde alguns milhares de linhas no caso de um pequeno ncleo para aplicaes embutidas (embedded) at vrios milhes de linhas, como na verso 2.4 do Linux, chegando a 30 milhes de linhas no caso do Windows 2000 [STA 01]. Embora princpios bsicos como baixo acoplamento e alta coeso [PRE 01] sejam sempre desejveis, existem algumas formas de organizao interna para sistemas operacionais que tornaram-se clssicas. Tambm ao longo do tempo a terminologia sofreu variaes. A forma como os termos so apresentados neste texto procura criar uma taxonomia coerente e didtica, mesmo que alguns autores, em alguns momentos, possam ter usados os termos com um sentido ligeiramente diferente. No interrompvel Kernel monoltico Interrompvel
No preemptvel Sistema operacional Kernel convencional Pontos de preempo Preemptvel Com kernel Microkernel Com servidores Figura 5.6: Taxonomia das organizaes de sistemas operacionais. Ao longo dos ltimos 40 anos, sistemas operacionais tm crescido de tamanho e de complexidade. Conforme o histrico que aparece em [STA 01], o CTSS, criado pelo MIT em 1963, ocupava aproximadamente 32 Kbytes de memria. O sistema OS/360, introduzido em 1964 pela IBM, incluia mais de 1 milho de instrues de mquina. Ainda no incio dos anos 70, o Multics, desenvolvido principalmente pelo MIT e pela
Bell Labs, j possuia mais de 20 milhes de instrues de mquina. Atualmente mesmo microcomputadores pessoais executam sistemas operacionais com elevada complexidade. O Windows NT 4.0 possui 16 milhes de linhas de cdigo e o Windows 2000 mais de 30 milhes de linhas de cdigo. Desde o incio, sistemas operacionais foram considerados um dos tipos de software mais difceis de serem construdos. Por exemplo, em [BOE 81] o autor classifica os sistemas em 3 tipos com o propsito de estimar seus custos, e os sistemas operacionais so includos na classe mais complexa. Ao longo dos anos, muito esforo foi colocado no sentido de criar as estruturas de software mais apropriadas para organizar internamente os sistemas operacionais. Existem grandes diferenas entre os servios oferecidos por um pequeno sistema operacional de propsito especfico, embutido em um equipamento qualquer, e um sistema operacional de propsito geral como o Linux ou o Windows. Entretanto, as estruturas de software empregadas no variam tanto assim, mesmo entre sistemas cujo tamanho difere por 3 ordens de grandeza (milhares de linhas versus milhes de linhas). A taxonomia apresentada neste texto classifica a organizao interna dos sistemas operacionais conforme a rvore mostrada na figura 5.6. No restante desta seo cada uma das organizaes que aparecem na rvore sero caracterizadas e discutidas. As recomendaes da engenharia de software valem tambm nesta rea. O desenvolvimento de um sistema operacional no deixa de ser um projeto de software e sofre dos mesmos problemas que aplicaes em geral. Por exemplo, a criao do OS/360 nos anos 60 envolveu cerca de 5000 programadores, o que obviamente no tolera prticas ad-hoc de desenvolvimento. Propriedades como modularidade, interfaces claras e a mais simples possvel entre os mdulos, alta coeso e baixo acoplamento so muito bem vindas.
5.3.1. Kernel monoltico

A forma mais simples de organizar um sistema operacional colocar toda a sua funcionalidade dentro de um nico programa chamado kernel. O kernel inclui o cdigo necessrio para prover toda a funcionalidade do sistema operacional (escalonamento, gerncia de memria, sistema de arquivos, protocolos de rede, device-drivers, etc). O kernel executa em modo supervisor e suporta o conjunto de chamadas de sistemas. Ele carregado na inicializao do computador e permanece sempre na memria principal. Internamente, o cdigo do kernel dividido em procedimentos os quais podem ser agrupados em mdulos. De qualquer forma, tudo ligado (linked) junto e qualquer rotina pode, a princpio, chamar qualquer outra rotina. Todas as rotinas e estruturas de dados fazem parte de um nico espao lgico de endereamento. O conceito de processo existe fora do kernel, mas no dentro dele. Apenas um fluxo de execuo existe dentro do kernel. Chama-se esse projeto de kernel monoltico (figura 5.7). Uma interrupo de hardware ou de software gera um chaveamento de contexto do processo que estava executando para o fluxo interno do kernel, o qual possui seu prprio espao de endereamento e uma pilha para as chamadas de subrotinas internas.
Figura 5.7: Kernel monoltico. Duas melhorias podem ser feitas sem alterar a essncia do kernel monoltico. Uma delas a introduo de programas de sistema. Os programas de sistema so programas que executam fora do kernel (em modo usurio), fazem chamadas de sistema como programas normais, mas implementam funcionalidades tpicas de sistemas operacionais, como listar os arquivos de um diretrio ou gerenciar o compartilhamento de uma impressora (spooler de impresso). Uma vantagem de transferir parte da funcionalidade do kernel para os programas de sistema a economia de memria. O kernel est sempre residente, enquanto programas de sistema so carregados para a memria somente quando necessrio. Alm disso, programas de sistema podem ser atualizados com facilidade, enquanto uma atualizao do kernel exige uma reinstalao e reinicializao do sistema. Outra vantagem com relao questo da confiabilidade, pois uma falha em um programa de sistema dificilmente compromete os demais programas e o prprio kernel. Finalmente, programas de sistema geram uma modularizao de qualidade que facilita o desenvolvimento e a manuteno do sistema. Outra melhoria so os mdulos dinamicamente carregveis, isto , permitir que algumas partes do kernel possam ser carregadas e removidas dinamicamente, sem interromper a execuo do sistema. Tipicamente isto feito para permitir que novos device-drivers sejam instalados sem a reinicializao do sistema. Memria alocada para o kernel, o cdigo do device-driver carregado para esta memria, o endereo de suas rotinas includo em tabelas do kernel, e uma ligao dinmica entre o mdulo carregado e o resto do kernel realizada. Mais recentemente este tipo de mecanismo foi ampliado para que outras funcionalidades possam tambm ser carregadas dinamicamente, como novos sistemas de arquivos. Entretanto, a maior parte do kernel e toda a sua funcionalidade bsica possui carga esttica. Existem duas variaes de kernel monoltico no que diz respeito s interrupes de hardware. Na forma mais simples, o kernel executa com interrupes desabilitadas. O kernel monoltico no-interrompvel possui cdigo mais simples, pois enquanto o kernel est executando nada mais acontece, nem mesmo interrupes de perifricos como temporizadores e controladores de disco. Programas de usurio executam com interrupes habilitadas todo o tempo. O preo a ser pago por esta simplificao uma reduo no desempenho. Por exemplo, se o controlador do disco termina o acesso em andamento e gera uma interrupo enquanto o kernel est executando, o disco ficar parado at que o kernel termine sua execuo, retorne a executar cdigo de usurio e
habilite as interrupes. Perifricos sero sub-utilizados, alm de haver uma troca de contexto desnecessria, pois o processo de usurio ativado ser interrompido. Uma forma mais eficiente executar o cdigo do kernel com interrupes habilitadas. O kernel monoltico interrompvel possui desempenho melhor pois os eventos associados com perifricos e temporizadores ganham imediata ateno, mesmo quando o cdigo do kernel est executando. Entretanto, preciso notar que tratadores de interrupes podem acessar estruturas de dados do kernel, as quais podem estar inconsistentes enquanto uma chamada de sistema atendida. Nessa situao, a execuo do tratador de interrupo poderia corromper todo o sistema. Na construo de um kernel monoltico interrompvel necessrio identificar todas as estruturas de dados acessadas por tratadores de interrupo e, quando o cdigo normal do kernel acessa essas estruturas de dados, interrupes devem ser desabilitadas (pelo menos aquelas cujos tratadores acessem a estrutura em questo). As estruturas de dados acessadas por tratadores de interrupo formam uma seo crtica que deve ser protegida, e o mecanismo usado para isto simplesmente desabilitar as interrupes enquanto estas estruturas de dados estiverem sendo acessadas. preciso cuidado quando as sees com interrupes desabilitadas aparecem aninhadas, pois neste caso somente ao sair da seo mais externa que as interrupes podem ser habilitadas novamente. Imagine agora a situao onde o cdigo de um kernel monoltico interrompvel est executando em funo da chamada de sistema de um processo de baixa prioridade. Neste momento ocorre uma interrupo de tempo (timer tick) e um processo de alta prioridade liberado. No kernel monoltico interrompvel o tratador da interrupo executa, mas ao seu trmino o cdigo do kernel volta a executar em nome de um processo de baixa prioridade, mesmo que um processo de alta prioridade aguarde na fila do processador. Tem-se ento, que este tipo de kernel intrinsicamente nopremptvel, isto , nenhum processo recebe o processador enquanto a linha de execuo dentro do kernel no for concluda ou ficar bloqueada por alguma razo.
5.3.2. Kernel convencional

Chama-se de kernel convencional (figura 5.8) aquele que, alm de interrompvel, permite uma troca de contexto mesmo quando cdigo do kernel estiver executando. A passagem de um kernel monoltico interrompvel para um kernel convencional possui vrias implicaes. Entre elas pode-se destacar que agora o conceito de processo existe tambm dentro do kernel, uma vez que o processo pode ser suspenso e liberado mais tarde enquanto executa cdigo do kernel. No kernel monoltico apenas uma pilha basta, pois a cada momento apenas um fluxo de execuo existe dentro dele. Interrupes podem acontecer, mas ainda assim uma nica pilha suficiente. No kernel convencional um processo pode passar o processador para outro processo que tambm vai executar cdigo do kernel. Logo, necessria uma pilha interna ao kernel para cada processo, alm das pilhas em modo usurio.
Figura 5.8: Kernel convencional. Quando o processo executando cdigo do usurio faz uma chamada de sistema, ocorre um chaveamento no modo de execuo e no espao de endereamento, mas conceitualmente o mesmo processo continua executando. Apenas agora ele executa cdigo do kernel. Este processo executa at que a chamada de sistema seja concluda. Nesse caso simplesmente efetuado um retorno para o contexto do usurio. Tambm possvel que esse processo tenha que esperar por algum evento como, por exemplo, um acesso a disco. Nesse caso ele fica bloqueado e um outro processo passa a ser executado. Como vrios processos podem estar bloqueados simultaneamente dentro do kernel, deve existir no espao de endereamento do kernel uma pilha para cada processo. Observe que, neste tipo de kernel, o processo executando cdigo do kernel no perde o processador para outro processo, a no ser que fique bloqueado, caracterizando assim um kernel convencional no-preemptvel. No kernel convencional as interrupes de software e de exceo esto fortemente associadas com o processo em execuo, representando uma chamada de sistema ou uma violao de algum tipo. Assim, as ativaes dos tratadores desses dois tipos de interrupes so vistas apenas como uma nova fase na vida do processo. O mesmo no ocorre com as interrupes de hardware, as quais esto associadas, na maioria das vezes, com solicitaes de entrada e sada feitas por outros processos. No kernel monoltico, a chamada de sistema implica em chavear o modo de execuo, o espao de endereamento e o prprio processo. No kernel convencional, a chamada de sistema implica to somente no chaveamento do modo de execuo e uma adaptao no espao de endereamento. Se acontecer um retorno imediato da chamada de sistema (por exemplo com gettime() ou read() de dados bufferizados), os outros dois tipos de chaveamento sequer acontecero. O resultado final a melhoria no desempenho do sistema, embora o cdigo do kernel fique um pouco mais complexo. Em alguns sistemas esta soluo dita empregar um processo envelope, pois os processos "envelopam" (executam) tanto o programa usurio como o cdigo do sistema operacional [HOL 83]. possvel a existncia de processos que jamais executam cdigo fora do kernel, isto , processos que executam tarefas auxiliares dentro do kernel e no esto associados com nenhum programa de usurio em particular. Este tipo de processo pode ser usado para, por exemplo, escrever blocos de arquivos alterados para o disco. O cdigo do kernel convencional pode ser visto como um conjunto de rotinas, possivelmente agrupadas em mdulos, que esto disposio dos processos. Obviamente os usurios esto sujeitos ao controle de acesso embutido no kernel, o qual
preservado pela MMU, que impede o acesso direto memria do kernel por parte de programas de usurio. Muitas vezes o espao de endereamento de um processo inclui tanto os segmentos com cdigo e dados do programa de usurio quanto o cdigo e dados do kernel. Mecanismos de proteo associados com o modo de execuo impedem que o cdigo executado em modo usurio acesse diretamente os bytes pertencentes aos segmentos do sistema. Quando o processo dentro do kernel deve ser bloqueado, ocorre um chaveamento entre processos. Algumas rotinas do kernel so responsveis por este efeito e, quando elas executam, conceitualmente nenhum processo est executando. Tem-se a transio: - Processo P1 executando cdigo do kernel. - Processo P1 chama rotina que executa chaveamento entre processos. - Rotina de chaveamento salva todo o contexto do processo P1. - Processo P1 transformou-se em um fluxo de execuo interno ao kernel, no vinculado a nenhum processo, cujo nico propsito carregar o prximo processo a executar. - Rotina de chaveamento de processos carrega todo o contexto do processo P2, o fluxo de execuo transforma-se no processo P2. - Processo P2 retoma a execuo do ponto onde havia sido bloqueado. A distino entre kernel monoltico interrompvel e kernel convencional nopreemptvel pode ser resumida pela execuo do cdigo do kernel estar associada com processos ou com um fluxo desvinculado do conceito de processo. Na prtica isto pode ser determinado pelo nmero de pilhas internas ao kernel. Se existe somente uma pilha dentro do kernel, tem-se um kernel monoltico interrompvel. J o kernel convencional, mesmo no-preemptvel, exige uma pilha dentro do kernel para cada processo. Ao mesmo tempo, as rotinas do kernel convencional devem ser re-entrantes, isto , devem ser programadas de tal forma que um processo possa iniciar a execuo, ser suspenso por algum motivo, e a mesma rotina ser ento executada por outro processo. O kernel agora corresponde realmente a um programa concorrente, algo que no acontecia com o kernel monoltico. Como o kernel convencional um programa concorrente, as suas estruturas de dados devem ser protegidas, pois formam sees crticas dentro do programa. A sincronizao entre processos dentro do kernel feita de vrias formas. Primeiramente, no kernel convencional no-preemptvel o processo s libera o processador voluntariamente. Desta forma, a maioria das estruturas de dados no precisa ser protegida pois garantido, pela disciplina de programao, que o processo fazendo o acesso deixar a estrutura em um estado consistente antes de liberar o processador. Quando, em funo dos algoritmos usados, o processo necessita bloquear-se ainda com uma estrutura de dados em estado inconsistente, alguma primitiva de sincronizao deve ser usada, como semforos ou algo semelhante. Se outro processo chamar o kernel e tentar acessar esta estrutura de dados que est inconsistente, ento ele ficar bloqueado no semforo. Finalmente, estruturas de dados tambm acessadas pelos tratadores de interrupo de hardware somente podem ser acessadas por um processo com as interrupes desabilitadas, como j acontecia antes no kernel monoltico. Outra questo relevante, relacionada com as estruturas de dados internas ao kernel, leva ao surgimento de mais dois tipos de kernel convencionais. O kernel convencional com pontos de preempo somente suspende um processo que executa cdigo do kernel em pontos previamente definidos do cdigo, nos quais sabido que nenhuma estrutura de dados est inconsistente. O desempenho deste tipo de kernel superior ao kernel monoltico, mas o processo de mais alta prioridade ainda obrigado a
esperar at que a execuo do processo de mais baixa prioridade atinja um ponto de preempo. O sistema SVR4.2/MP funciona assim. Por outro lado, o kernel convencional preemptvel realiza o chaveamento de contexto to logo o processo de mais alta prioridade seja liberado. Para isto, todas as estruturas de dados do kernel que so compartilhadas entre processos devem ser protegidas por algum mecanismo de sincronizao, como semforos, mutexes, etc. Esta soluo, usada no Solaris 2.x, resulta em melhor resposta do sistema aos eventos externos, e um comportamento mais coerente com as prioridades dos processos. Uma vez que existe no kernel convencional uma estrutura disponvel para a convivncia de vrios fluxos de execuo simultneos internos ao kernel, pode-se utilizar construes denominadas de threads do kernel. As threads do kernel so fluxos de execuo que executam o tempo todo cdigo do kernel e no possuem nenhum cdigo de usurio associado. Elas executam tarefas auxiliares, como a manuteno dos nveis de memria disponvel atravs da escrita de buffers para o disco ou implementam protocolos de comunicao em rede. Alguns sistemas como o Solaris [VAH 96] vo alm, e transformam os tratadores de interrupo em threads de kernel. Dessa forma, a nica coisa que o tratador de interrupo propriamente dito faz liberar a thread de kernel correspondente, inserindo-a na fila do processador. O cdigo executado pela thread que realiza efetivamente o tratamento da interrupo. A sincronizao com respeito s estruturas de dados do kernel feita normalmente, pois tanto processos normais como threads de kernel podem ser bloqueados se isto for necessrio. O cdigo fica mais simples e robusto, pois agora no necessrio determinar exatamente qual estrutura de dados acessada por qual tratador de interrupo, para desabilitar as interrupes corretamente durante o acesso. Simplesmente cada estrutura de dados compartilhada protegida por um semforo ou semelhante e o problema est resolvido. A experincia com o Solaris tambm mostra que no existe reduo de desempenho quando este esquema utilizado, pois um conjunto de threads pode ser previamente criado, para evitar o custo da criao a cada interrupo.
5.3.3. Microkernel
Recentemente uma organizao tem sido proposta na qual a funcionalidade tpica de kernel dividida em duas grandes camadas. Esta soluo baseia-se na existncia de um microkernel, o qual suporta os servios mais elementares de um sistema operacional: gerncia de processador e uma gerncia de memria simples. A idia de microkernel foi popularizada pelo sistema operacional Mach [TAN 95]. Na sua forma mais simples, o microkernel corresponde funcionalidade de mais baixo nvel do kernel convencional preemptvel, aquela responsvel por realizar o chaveamento dos processos envelopes. O microkernel suporta um kernel semelhante ao convencional preemptvel, separado da funcionalidade inserida no microkernel. Esta soluo ilustrada pela figura 5.9 e ser chamada de microkernel com kernel.
Figura 5.9: Microkernel com kernel. Um passo adiante na idia de microkernel criar um conjunto de processos servidores autnomos, tal que as chamadas de servio dos processos de usurio so feitas diretamente, sem passar por uma camada que uniformize a interface do kernel. Nesta soluo tem-se um microkernel que suporta um conjunto de processos com espaos de endereamento independentes. Alguns processos executam programas de usurio enquanto outros implementam servios do sistema operacional, tais como o sistema de arquivos e o gerenciador de memria virtual. Quando o processo do usurio necessita ler um arquivo ele envia uma mensagem para o processo "sistema de arquivos", o qual executa o pedido e retorna outra mensagem com o resultado. A participao do microkernel resume-se a dividir o tempo do processador entre os diversos processos e prover o mecanismo de comunicao entre eles. Internamente, o microkernel tem a forma de um pequeno kernel monoltico. As desvantagens do kernel monoltico no so to srias neste caso pois o cdigo do microkernel pequeno. Por sua vez, cada processo servidor constitui um espao de endereamento independente e pode ser composto por vrias threads para melhorar o seu desempenho. Chama-se essa organizao de microkernel com processos servidores (figura 5.10). Os processos servidores que necessitam acesso especial podem executar em modo supervisor. O modo de execuo passa a ser uma caracterstica do processo, definida pelo administrador do sistema. Modos de execuo intermedirios podem ser utilizados se estiverem disponveis. O microkernel sempre executa em modo supervisor e pode ser visto como um componente monoltico. Um sistema operacional bastante conhecido que trabalha dessa forma o Minix [TAN 00]. A existncia de processos servidores representa uma decomposio funcional que facilita o desenvolvimento do sistema operacional nos aspectos de codificao, teste e manuteno. As vantagens da organizao baseada em microkernel so semelhantes quelas dos programas de sistema: facilidade para atualizaes, isolamento entre os diferentes componentes, depurao e manuteno mais fcil, modularizao superior, facilidade para distribuio e tolerncia a falhas. Tambm, agora, tem-se o microkernel e os processos servidores executando em espao de endereamento diferentes, o que timo do ponto de vista da engenharia de software, embora represente uma penalidade no tempo de execuo. Isto resulta em facilidade para desenvolver e testar novos processos servidores. Tambm o sistema como um todo responde melhor s definies de prioridades feitas pela administrao, pois a preempo ocorre mais facilmente.
Figura 5.10: Microkernel com processos servidores. A grande motivao para empregar uma organizao como esta a modularidade e flexibilidade resultantes. possvel configurar cada instalao com apenas os processos servidores desejados, depois atualiz-los sem a necessidade de reinicializar o sistema. especialmente atraente em sistemas distribudos, pois os mecanismos utilizados para implementar servios distribudos so complexos e, se colocados todos em um kernel convencional, o tornariam intratvel. Nesta organizao pode-se com mais facilidade distribuir os processos por diferentes computadores e ainda assim obter elevado nvel de transparncia. Apenas o microkernel deve executar em todos os computadores, j que no existe memria compartilhada entre os processos servidores e os processos usurios. Uma das mais notveis capacidades dos sistemas baseados em microkernel suportar simultaneamente vrias API de diferentes sistemas operacionais. Por exemplo, possvel colocar sobre um mesmo microkernel processos servidores que suportem as chamadas da API Win32 e outros processos servidores que suportem a API Posix. Embora todo este cdigo de sistema operacional represente uma carga considervel para o computador, em determinados ambientes esta possibilidade atrativa. Esta capacidade pode tambm ser implementada sobre outros tipos de organizao, mas no com a mesma facilidade. A maior desvantagem dessa soluo o custo muito mais alto associado com uma chamada de sistema, que agora implica em vrios chaveamentos sucessivos. Alm disso, o programa de usurio deve montar e desmontar mensagens ao solicitar servios para outros processos, pois mensagens formam a base da comunicao neste tipo de organizao. Cada passagem de nvel (processo de usurio para microkernel para processo de sistema e tudo de volta) implica no gasto de tempo do processador. Por exemplo, a comunicao entre sistema de arquivos e gerncia de memria era feita antes com uma chamada de subrotina, mas agora exige uma chamada ao microkernel. Quanto menor a funcionalidade do microkernel, maior a penalidade no desempenho. Assim, uma tendncia atual tem sido a re-incorporao de servidores importantes ao microkernel. Ele passa a ser um pouco menos micro, perdendo em parte a flexibilidade, mas o desempenho melhora. Isto conseguido atravs da reduo do nmero de chaveamentos de modo de execuo e de espaos de endereamento no atendimento das chamadas de sistema. Os servios que so os maiores candidatos a serem includos no microkernel so a gerncia de memria e os device-drivers, pelo menos aqueles associados com os principais perifricos do sistema.
Esta questo do desempenho resultou em variaes na literatura a respeito de onde est exatamente a fronteira entre um kernel e um microkernel. Por exemplo, quais os servios que devem ser implementados ou qual o tamanho mximo que um microkernel pode ter. Entretanto, mais ou menos consenso que, minimamente, o microkernel deve oferecer processos (e threads), comunicao entre processos, facilidades para a gerncia de entrada/sada e interrupes e gerncia de memria fsica (de baixo nvel). O mecanismo tipicamente usado entre processos acima do microkernel a troca de mensagens. Uma das motivaes bsicas dessa organizao a independncia entre os processos servidores, e a definio de variveis compartilhadas prejudicaria esse propsito. O microkernel suporta primitivas elementares de envio e recepo de mensagens, as quais so usadas pelos processos de usurio para solicitar servios aos processos servidores e por estes para enviar as respectivas respostas. As variaes tpicas dos mecanismos de mensagens, como endereamento direto ou indireto, mensagens tipadas ou no, grau de bufferizao, semntica das primitivas, tambm so encontradas aqui. Para que o microkernel cumpra seu papel de isolar os diferentes processos, ele deve ser capaz de controlar os direitos de acesso e a integridade das mensagens. Para evitar que o envio de uma mensagem implique na cpia memriamemria, operao tipicamente lenta, mecanismos como remapeamento de pginas podem ser usados. Neste caso, a mensagem no realmente copiada, mas a pgina fsica que ela ocupa mapeada na tabela de pginas do processo destinatrio. Uma questo importante como o microkernel deve tratar a ocorrncia de uma interrupo. Algumas interrupes, como as dos temporizadores do hardware (timers) e aquelas associadas com erros de execuo (acesso ilegal a memria, instruo ilegal, etc) possuem um tratamento bvio. A questo refere-se s interrupes geradas por perifricos cuja gerncia realizada por processos servidores que executam fora do microkernel. Uma soluo simples permitir que processos servidores instalem suas rotinas de tratamento de interrupes. Uma chamada de microkernel permite ao processo servidor informar que, na ocorrncia de interrupo do tipo x, a rotina y do processo servidor deve ser chamada. Este esquema pode ser usado em sistemas menores, mas possui vrias desvantagens. Por exemplo, se memria virtual for empregada possvel que a rotina em questo sequer esteja residente na memria principal. Alm disso, a programao do processo servidor fica mais complexa, pois alm das mensagens dos processos clientes ele deve se preocupar agora com rotinas executadas automaticamente. Entretanto, este tipo de programao comum no mundo Unix, quando o mecanismo de sinais utilizado. Uma soluo mais harmoniosa com a organizao geral do sistema fazer o microkernel transformar as interrupes em mensagens. Inicialmente, o processo servidor interessado nas interrupes do tipo x informa isto ao microkernel. Sempre que ocorrer uma interrupo deste tipo, o microkernel gera automaticamente uma mensagem para o processo servidor em questo, informando que uma interrupo daquele tipo aconteceu. A programao do processo servidor simplificada, pois ele agora sempre recebe mensagens, seja dos demais processos, seja do dispositivo de hardware que ele controla. Obviamente, existe uma penalidade em termos de desempenho na montagem e envio dessa mensagem, se comparada com a soluo onde uma rotina do processo servidor chamada diretamente. O aspecto mais complexo no projeto de um microkernel est exatamente na gerncia da memria. Para que os processos executando acima do microkernel possuam espaos de endereamento independentes, o microkernel deve criar e manter as respectivas tabelas de pginas e de segmentos, conforme a arquitetura do processador.
Ele tambm deve gerenciar quais pginas fsicas esto livres na memria. Entretanto, o mecanismo de memria virtual envolve interaes com o disco e deveria, a princpio, ficar fora do microkernel. Quando um processo executa um acesso ilegal a memria o microkernel pode recorrer a um processo servidor para realizar o tratamento da falta de pgina, com possvel acesso a disco e escolha de pgina vtima. Entretanto, a API do microkernel para este processo servidor exige um projeto cuidadoso, ou srias penalidades no desempenho acontecero. Sistemas baseados em microkernel podem variar com respeito aos modos de execuo. A maioria dos processadores oferecem pelo menos dois modos de execuo: supervisor e usurio. No caso de mais de dois denomina-se os demais como modos de execuo intermedirios, com mais direitos que o modo usurio mas nem todos os direitos do modo supervisor. Por exemplo, o Intel Pentium oferece 4 nveis de proteo: o nvel 0 corresponde ao modo supervisor, nvel 3 o modo usurio tpico e os nveis 1 e 2 oferecem direitos intermedirios. Se o sistema est baseado em microkernel, naturalmente o cdigo de usurio executa em modo usurio e o cdigo do microkernel executa em modo supervisor. Entretanto, o cdigo dos servidores permite vrias possibilidades. Buscando segurana possvel executar o cdigo dos servidores em modo usurio, obrigando a realizao de uma chamada ao microkernel toda vez que uma operao restrita for necessria. Esta soluo gera vrios chaveamentos de modo de operao e a execuo de cdigo extra pelo microkernel para testar a validade das operaes solicitadas. Com o propsito de tornar o sistema mais rpido, possvel executar o cdigo dos servidores em modo supervisor. O sistema fica mais simples e rpido, porm agora qualquer servidor pode corromper todo o sistema e a proteo que havia antes, mesmo entre servidores, perdida. Idealmente o cdigo do sistema operacional no deveria conter erros, mas a nossa experincia diria mostra que isto no sempre verdade. Por fim, modos de execuo intermedirios podem ser usados para os servidores, buscando uma soluo de compromisso. Por exemplo, permitir que processos servidores acessem alguns endereos de entrada e sada previamente estabelecidos, o que no possvel para processos que executam em modo usurio. Sistemas baseados em microkernel tambm podem variar com respeito aos espaos de endereamento. Logicamente, o cdigo de usurio executa em espao de endereamento prprio, o mesmo acontecendo com o cdigo do microkernel. Entretanto, o cdigo de cada servidor pode executar em espao de endereamento independente ou ser ligado ao cdigo do microkernel, ocupando portanto o mesmo espao de endereamento. Novamente, tem-se uma questo de isolamento (proteo) versus desempenho. O chaveamento entre espaos de endereamento exige comandos para a MMU (memory management unit) e tambm esvaziamento de sua cache interna, a TLB (translation lookaside buffer). Ao juntar microkernel e servidores no mesmo espao de endereamento, no necessrio chavear o contexto da MMU quando o servidor faz uma solicitao de servio ao microkernel. Entretanto, o isolamento j no imposto pela MMU, o que diminui o isolamento entre os diferentes componentes do sistema operacional. Tambm fica mais complexa a carga dinmica de servidores. Concluindo, sistemas do tipo microkernel com kernel podem ser considerados uma simplificao da idia geral de microkernel. Eles tm uma organizao modular, com interfaces claras entre os seus componentes. Dados essenciais so encapsulados e somente podem ser acessados atravs das rotinas apropriadas. Entretando, vrios servidores importantes executam em modo supervisor no mesmo espao de endereamento, formando o kernel sobre o microkernel. Esta organizao busca
melhorar o desempenho do sistema ao reduzir a necessidade de chaveamentos de contextos e modos de execuo. Existe aqui portanto uma variao da idia de microkernel, onde todos os processos servidores so agrupados em um componente de software, o qual adiciona uma interface para as chamadas de sistema. Infelizmente, a terminologia, que j varia no mundo acadmico, varia ainda mais no mundo comercial. Como os departamentos de marketing das empresas determinaram que microkernel bom, agora todos os desenvolvedores de sistemas operacionais tentam mostrar que, de alguma forma, o seu sistema tambm baseado em microkernel.
5.3.4. Comparao entre as organizaes

As tcnicas apresentadas nas sees anteriores so as fundamentais, mas nada impede que um sistema operacional seja construdo misturando vrios aspectos aqui descritos. Por exemplo, o conceito de processo servidor pode ser usado sobre um kernel monoltico para suportar determinados servios com tempo de resposta mais dilatado. O microkernel em si pode ser visto como um kernel monoltico com pouqussimos servios. Cada sistema operacional existente utiliza uma mistura dessas tcnicas, em geral aproximando-se mais de uma delas. As estruturas de software apresentadas neste texto devem ser entendidas como os modelos abstratos (as receitas de bolo) utilizados na construo dos sistemas operacionais, embora cada sistema (cada bolo) tenha sempre as suas peculiaridades e caractersticas prprias. Como regra geral, sistemas acadmicos buscam a elegncia e a qualidade no projeto, e portanto tendem a usar microkernel. Por outro lado, sistemas comerciais buscam principalmente desempenho, usando por isto solues baseadas em kernel convencional. De qualquer forma, todos os sistemas apresentam uma mistura das formas bsicas, repletas de detalhes especficos, que vo alm dos objetivos deste texto. Como em qualquer tipo de software, a chave para entender a organizao interna de um sistema operacional est na compreenso de como ele foi decomposto em diversas partes. A decomposio pode ser analisada segundo diferentes perspectivas, mas quatro delas destacam-se, para os propsitos deste texto. Primeiramente, tem-se a decomposio do cdigo em rotinas e mdulos. Isto feito para encapsular variveis locais, tanto a nvel de rotina como de mdulo, e tambm rotinas internas ao seu mdulo, as quais no podem ser chamadas de outros mdulos. Orientao a objetos vai nessa mesma direo, embora ainda no seja empregada completamente na construo de kernel. Este particionamento efetuado pelo compilador e pelo ligador, durante a traduo do cdigo fonte do sistema operacional. A diviso rgida do sistema em camadas no normalmente suportada por compiladores e ligadores, dependendo da sua adoo como disciplina de projeto e de programao. Uma decomposio bvia est relacionada com os direitos de acesso de cada parte, atravs dos modos de execuo do processador. Considerar-se-, aqui, a existncia de apenas dois modos de execuo (supervisor e usurio), embora outros intermedirios tambm possam existir. Este particionamento decidido em projeto e implementado pela unidade de controle do processador. O sistema operacional tambm pode ser decomposto em vrios espaos de endereamento. Neste caso, a visibilidade das rotinas e estruturas de dados do sistema operacional pelas outras partes do mesmo pode ser limitada atravs da criao de vrios espaos de endereamento independentes. Este particionamento efetuado pela MMU. Finalmente, tem-se a decomposio da execuo do sistema operacional em vrios fluxos de execuo separados, os quais provavelmente colaboram entre si, tornando o sistema operacional um programa concorrente. O termo fluxo de execuo
usado para designar threads, processos, ou quaisquer construes semelhantes. Este particionamento efetuado por uma deciso de projeto e disciplina de programao. Uma vez definidas as quatro perspectivas da decomposio de um sistema operacional que sero analisadas aqui, pode-se investigar como cada tipo de organizao decompe o sistema operacional nessas perspectivas. Embora o texto tenha indicado a existncia de variaes a partir das organizaes bsicas, a anlise considera apenas as 3 principais formas de organizao: kernel monoltico interrompvel, kernel convencional preemptvel e microkernel com processos servidores. A decomposio em rotinas e mdulos pode ser aplicada a qualquer forma de organizao. A modularizao um dos pilares da computao e pode ser aplicada a qualquer tipo de software. At mesmo no microkernel, embora pequeno, a modularizao vai melhorar a legibilidade e robustez, facilitando testes e manuteno. A decomposio em modos de execuo bem caracterstica em cada forma de organizao: - No kernel monoltico interrompvel os processos de usurio executam em modo usurio, enquanto o kernel executa em modo supervisor. - No kernel convencional preemptvel o processo executa cdigo de usurio em modo usurio e, aps uma chamada de sistema, executa cdigo do kernel em modo supervisor. Os tratadores de interrupo fazem parte do kernel e executam em modo supervisor. Durante o chaveamento entre processos so executadas instrues fora do contexto de qualquer processo. Este pequeno fluxo de execuo interno ao kernel tambm executa em modo supervisor. - No microkernel com processos servidores os processos de usurio executam cdigo de usurio em modo usurio e o microkernel executa em modo supervisor. Os processos servidores podem executar em modo usurio, modo supervisor ou algum modo intermedirio, dependendo do tipo de servio prestado e do projeto do sistema. A decomposio em espaos de endereamento tambm caracteriza com fora as diferentes organizaes: - No kernel monoltico interrompvel cada processo de usurio possui um espao de endereamento prprio, enquanto o kernel executa em seu prprio espao de endereamento, o qual permite acesso a toda a memria. - No kernel convencional preemptvel existem algumas possibilidades. Em essncia cada processo possui um espao de endereamento quando executa cdigo de usurio e passa para outro espao de endereamento quando executa cdigo do kernel. Entretanto, uma nica tabela de pginas e/ou segmentos pode ser usada para os dois espaos de endereamento, sendo a distino obtida atravs do modo de execuo, ou seja, as partes da memria associadas com o kernel somente podem ser acessadas quando o processo executa em modo supervisor, isto , executa cdigo do kernel. Neste caso, uma chamada de sistema tem o efeito de mudar o processador para modo supervisor, liberar as partes do kernel nas tabelas de memria e desviar a execuo para o cdigo do kernel. Tratadores de interrupo tambm executam neste espao de endereamento ampliado. - No microkernel com processos servidores cada processo, seja de usurio seja servidor, executa em um espao de endereamento prprio. O microkernel tambm possui seu prprio espao de endereamento, permitindo acesso a toda a memria. A decomposio em fluxos de execuo tambm caracteriza muito bem as diferentes solues de organizao usadas em sistemas operacionais: - No kernel monoltico interrompvel cada processo de usurio corresponde a um fluxo de execuo. Se threads so suportadas, cada processo de usurio pode conter
vrios fluxos de execuo. O kernel, por sua vez, composto por um nico fluxo de execuo principal, associado com uma chamada de sistema. - No kernel convencional preemptvel cada processo est associado com um fluxo de execuo. Se threads so suportadas ento cada processo estar associado com vrios fluxos de execuo. Estes fluxos executam tanto cdigo de usurio quanto o cdigo do kernel. Durante o chaveamento de contexto entre processos existe um momento no qual a execuo est desvinculada de qualquer processo e pode ser pensada como um fluxo do kernel que aparece somente neste momento. Finalmente, tratadores de interrupo representam fluxos disparados por interrupes do hardware e encerrados ao trmino da rotina de tratamento. - O microkernel com processos servidores tipicamente suporta threads. Logo, cada processo, seja de usurio ou servidor, pode estar associado com vrios fluxos de execuo. O microkernel pode ser implementado de vrias formas, mas na mais simples ele seria apenas um ncleo monoltico no interrompvel, caracterizado portanto por apenas um fluxo de execuo. Na verdade esta descrio pode tornar-se recursiva, na medida que aplicarmos tambm ao microkernel as vrias solues possveis descritas para o kernel principal. Para completar a comparao entre as 3 solues bsicas, considerar-se-, agora, o que acontece quando um programa de usurio faz uma chamada de sistema read() para ler dados de um arquivo previamente aberto. Na maioria das linguagens de programao o programador chama uma rotina da biblioteca da linguagem que, por sua vez, chama o sistema operacional. Em funo do propsito deste texto, ignora-se a biblioteca da linguagem e iniciar a anlise a partir da chamada ao sistema operacional propriamente dita. Tambm ser suposto que este read() no pode ser satisfeito com dados na memria principal e um acesso ao disco ser necessrio. No kernel monoltico interrompvel o processo deve colocar os parmetros nos locais apropriados e executar a interrupo de software associada com chamadas de sistema. Em funo da interrupo de software a execuo desvia para o cdigo do kernel, executando em modo supervisor e com um novo espao de endereamento. Inicialmente o contexto de execuo do processo chamador salvo. feito o processamento da chamada at o ponto no qual o pedido de acesso a disco foi enfileirado e nada mais resta a fazer. Neste momento um outro processo selecionado para execuo. Mais tarde uma interrupo do controlador do disco vai sinalizar a concluso da leitura. O tratador desta interrupo vai liberar o processo chamador, que volta a disputar o processador. sem dvida a organizao mais simples. Sua limitao est em permitir que um processo de baixa prioridade monopolize o processador enquanto executa cdigo do kernel. No kernel convencional preemptvel o processo tambm deve colocar os parmetros nos locais apropriados e executar a interrupo de software associada com chamadas de sistema. Em funo da interrupo de software a execuo desvia para o cdigo do kernel, executando em modo supervisor e com um espao de endereamento ampliado. Entretanto, conceitualmente, o mesmo processo est executando. feito o processamento da chamada at o ponto no qual o pedido de acesso a disco foi enfileirado e nada mais resta a fazer. Neste momento o processo declara-se bloqueado e solicita um chaveamento de processo. Seu contexto salvo e o contexto de outro processo da fila de aptos carregado. Observe que durante a transio a execuo prossegue sem estar conceitualmente associada com nenhum processo em particular. Esta transio crtica e acontece com interrupes desabilitadas. Mais tarde, a interrupo do controlador do disco sinaliza a concluso da operao e o seu tratador vai liberar o processo chamador, colocando-o novamente na fila de aptos. Depois de algum
tempo ele eleito para execuo, a qual retomada dentro do kernel, no ponto imediatamente posterior quele onde ele solicitou o seu bloqueio. O processamento da chamada de sistema concludo e este processo finalmente retorna para o cdigo de usurio, restaurando modo de execuo e espao de endereamento. Nesta organizao, caso uma interrupo de hardware libere um processo de mais alta prioridade, o mesmo retoma sua execuo, mesmo que outro processo de mais baixa prioridade esteja executando cdigo do kernel. Esta soluo melhora o comportamento do sistema, se comparada com o kernel monoltico, pois ela respeita mais as diferentes prioridades dos processos. Entretanto, sua programao mais complexa, pois agora todo o kernel tornou-se um enorme programa concorrente. No microkernel com processos servidores o processo de usurio monta uma mensagem com a requisio de um read e seus parmetros. Ele ento solicita ao microkernel que envie esta mensagem para o processo servidor "sistema de arquivos" atravs do servio send(). Isto implica em uma interrupo de software e a correspondente execuo do cdigo do microkernel. O microkernel verifica a integridade e validade da mensagem e a insere na fila de mensagens endereadas para o processo servidor. Provavelmente o processo servidor "sistema de arquivos" possui uma prioridade maior que processos de usurio e, caso ele esteja bloqueado por uma chamada receive() anterior, ele ser liberado. Neste caso o send() do processo usurio acaba resultando em sua preempo por processo de mais alta prioridade. Seja como for a mensagem ser transferida para o processo servidor onde provavelmente uma de suas threads atender a requisio. Possivelmente o device-driver do disco em questo implementado por outro processo servidor, e a mesma seqncia de eventos acontecer novamente, agora com o servidor "sistema de arquivos" no papel de cliente do servidor "device-driver do disco". As respostas para as requisies implicam novamente em mensagens, dessa vez fazendo o caminho inverso. No final, tem-se 3 processos envolvidos, 2 envios de mensagem com requisio e 2 envios de mensagem com resposta, o que implica em 8 chamadas ao microkernel (4 send e 4 receive). Este tipo de organizao exige cuidado na implementao para que o desempenho no fique muito abaixo daquele obtido com um kernel convencional.
5.4. Outras formas de organizao

De maneira ortogonal s organizaes fundamentais apresentadas na seo anterior, existem tcnicas que podem ser aplicadas no sentido de minimizar a complexidade do projeto ou permitir a adaptao das organizaes bsicas a contextos diferentes. Abaixo so analisadas 3 dessas tcnicas: a organizao em camadas, o emprego de mquinas virtuais e a adaptao do kernel para mquinas multiprocessadoras.
5.4.1. Organizao em camadas

Uma das primeiras tcnicas, alm da modularidade, usadas para lidar com a complexidade dos sistemas operacionais foi a organizao hierrquica. Nesta estrutura o sistema dividido em camadas. Cada camada utiliza os servios da camada inferior e cria novos servios para a camada superior. Idealmente, a implementao de uma camada pode ser livremente substituda por outra, desde que a nova implementao suporte a mesma interface e oferea os mesmos servios. Esta idia apareceu pela
primeira vez no sistema operacional THE (Technische Hogeschool Eindhoven, [DIJ 68]), criado por Dijkstra no final dos anos 60. Mais tarde esta mesma soluo foi usada pela ISO (International Standards Organization) na famosa organizao em 7 camadas do seu modelo de referncia para redes de computadores, o OSI - Open Systems Interconnection. O sistema operacional THE foi organizado em 5 camadas. Na camada 0 ficava o hardware. Na camada 1 ficava o escalonamento do processador e a criao do conceito de processo. A camada 2 correspondia gerncia de memria e era responsvel pela implementao de memria virtual. A camada 3 continha o device-driver para o console do operador. A camada 4 implementava o sistema de buffers para os demais dispositivos de entrada e sada e, por estar na camada 4, podia usar a memria virtual implementada pela camada 3 e enviar mensagens para o operador pela camada 2. Finalmente, programas de usurio executavam na camada 5. Em geral no fcil compor uma pilha de camadas de tal sorte que cada camada utilize somente as camadas inferiores. Veja, por exemplo, o relacionamento entre sistema de arquivos e gerncia de memria. O sistema de arquivos faz chamadas para a gerncia de memria solicitando pginas fsicas para implementar um esquema de cache para os arquivos. Por outro lado, a gerncia de memria pode solicitar uma leitura de arquivo quando ocorrer uma falta de pgina. A estrutura em camadas que o sistema deve ter para satisfazer a todas as necessidades no bvia.
5.4.2. Mquinas virtuais

interessante notar que idias que parecem ser novas nem sempre so to novas assim. No incio da dcada de 70 a IBM oferecia um produto chamado CP (Control Program, [SIL 99]) que criava, sobre o hardware do computador IBM 370, a iluso de vrias mquinas virtuais. Sobre cada mquina virtual era possvel executar um sistema operacional completo. Outro sistema que segue a filosofia das mquinas virtuais, pelo menos parcialmente, Real-Time Linux. O RT-Linux (http://www.rtlinux.org) uma extenso do Linux que se prope a suportar tarefas com restries temporais crticas. O seu desenvolvimento iniciou no "Department of Computer Science" do "New Mexico Institute of Technology". Atualmente o sistema mantido pela empresa FSMLabs e j est em sua terceira verso. O RT-Linux um sistema operacional no qual um microkernel de tempo real coexiste com o kernel do Linux. O objetivo deste arranjo permitir que aplicaes utilizem os servios sofisticados e o bom comportamento no caso mdio do Linux tradicional, ao mesmo tempo em que permite que tarefas de tempo real operem sobre um ambiente mais previsvel e com baixa latncia. O microkernel de tempo real executa o kernel convencional como sua tarefa de mais baixa prioridade (Tarefa Linux), usando o conceito de mquina virtual para tornar o kernel convencional e todas as suas aplicaes completamente interrompveis. Todas as interrupes so inicialmente tratadas pelo microkernel de tempo real, e so passadas para a tarefa Linux somente quando no existem tarefas de tempo real para executar. Para minimizar mudanas no kernel convencional, o hardware que controla interrupes emulado. Assim, quando o kernel convencional "desabilita interrupes", o software que emula o controlador de interrupes passa a enfileirar as interrupes que acontecerem e no forem completamente tratadas pelo microkernel de tempo real. Pode-se dizer que o microkernel controla o mecanismo real de interrupes
do processador, enquando o kernel Linux manipula um sistema virtual de interrupes, suportado pelo microkernel atravs da manipulao de interrupes reais.
5.4.3. Multiprocessamento simtrico

As colocaes feitas nas sees anteriores consideraram um sistema operacional para mquinas com um nico processador. No caso de uma mquina SMP (symmetric multiprocessing) outros mecanismos devem ser acrescentados. Na arquitetura SMP todos os processadores so tratados igualmente, no existe a figura de um processador principal ou mestre (por isto o termo "simtrico"). Todos os processadores compartilham a mesma memria e um dispositivo no hardware chamado de rbitro de barramento evita os conflitos nos acessos. rbitros de barramento tambm so usados em monoprocessadores para controlar diferentes operaes de DMA (Direct Memory Access). Por exemplo, no Intel Pentium a instruo LOCK informa ao rbitro de barramento que a prxima instruo de mquina deve ser atmica, com respeito ao acesso memria. O hardware tambm responsvel por manter a consistncia entre as caches dos vrios processadores e a memria principal. Uma descrio mais detalhada deste tipo de arquitetura pode ser encontrada em [VAH 96]. O objetivo do sistema operacional em uma mquina SMP oferecer a mesma viso que o usurio tem quando a mquina possui um nico processador. O porte do sistema operacional de uma mquina monoprocessadora para uma mquina SMP no exageradamente complexo, mas exige alguns cuidados. Os detalhes obviamente dependem da organizao original do sistema operacional. Como diversos processadores executam simultaneamente, dois ou mais processos podem fazer chamadas de sistema ao mesmo tempo. Pensando em um kernel monoltico, o cdigo do kernel no reentrante, e deve ser criado um mecanismo que torne este cdigo um recurso no compartilhvel, isto , uma seo crtica. Nesse caso, o primeiro processo adquire o "direito de executar cdigo do kernel" e os demais processadores ficam esperando. Considerando a durao de algumas chamadas de sistema, esta soluo muito ineficiente. Embora seja possvel imaginar melhorias neste contexto, na prtica kernel monoltico no usado como base para sistemas SMP. No restante dessa seo, ser considerado um kernel convencional preemptvel como organizao original. Na mquina monoprocessadora o kernel convencional preemptvel utiliza mecanismos de sincronizao clssicos para evitar que dois processos corrompam as estruturas de dados. Mecanismos de sincronizao so construdos a partir de algum tipo de operao atmica. As operaes atmicas mais populares no caso de monoprocessador so "desabilitar interrupes" e "instrues tipo swap ou test-and-set". Ocorre que, na presena de vrios processadores, estas operaes deixam de ser atmicas. Desabilitar interrupes no interrompe a execuo nos demais processadores e a instruo de mquina tipo swap faz dois acessos a memria, o qual pode ser intercalado com outro swap executado em outro processador, tornando o mecanismo intil. A soluo dotar o hardware do rbitro de barramento com a capacidade de bloquear a memria para uso exclusivo de um nico processador. Se isto feito durante a execuo de uma instruo tipo "swap", fica garantida a sua atomicidade e o mecanismo de sincronizao funciona. O mecanismo do spin-lock pode ser ento usado para implementar as operaes atmicas P e V dos semforos. A partir deste momento tem-se os dois tipos fundamentais de sincronizao. Logo, a chave para adaptar o kernel convencional para uso em mquina SMP adaptar os mecanismos de sincronizao internos do kernel para que funcionem tambm no ambiente multiprocessado.
Em geral as operaes P e V dos semforos so mais demoradas quando a seo crtica est livre. Ao mesmo tempo, o busy-waiting do spin-lock mais eficiente quando a seo crtica, embora ocupada, ser logo liberada. Como regra geral os semforos ou qualquer outro mecanismo que bloqueia o processo so usados somente quando a espera pode ser longa. No caso de simples excluso mtua durante operaes rpidas o spinlock preferido. Por exemplo, as prprias operaes P e V so tornadas atmicas atravs de spin-lock. Boa parte dos sistemas operacionais utilizam um conjunto de mecanismos de sincronizao, empregando um ou outro conforme a situao [VAH 96]. Com respeito aos deadlocks, a forma mais comum de evit-lo dentro do kernel ordenar as sees crticas e aloc-las sempre em ordem crescente, tornando impossvel a ocorrncia de uma lista circular [SIL 99]. Quando esta soluo impossvel, pode-se utilizar construes do tipo try-lock, onde o processo que tenta requisitar uma seo crtica no fica bloqueado. Neste caso necessrio prever no cdigo alguma ao para o processo que tenta entrar em uma seo crtica mas o acesso negado. No momento de estabecer quais so as sees crticas do kernel, com o propsito de protege-las, surge a questo da granularidade. Tem-se uma proteo com granularidade grande quando as sees crticas correspondem a grandes trechos de cdigo e at mesmo subsistemas completos. Por exemplo, possvel considerar todo o sistema de arquivos como uma seo crtica e controlar o acesso atravs de um nico semforo. Desta forma, a cada momento apenas um processo pode estar executando cdigo do sistema de arquivos. Uma forma alternativa usar granularidade pequena, protegendo cada tabela ou lista individualmente. Em geral, granularidade grande diminui o paralelismo possvel dentro do kernel, ao passo que granularidade pequena aumenta o custo de alocar e liberar sees crticas, as quais esto livres na maior parte do tempo. A melhor soluo depende do padro de utilizao do sistema operacional por parte dos processos e da probabilidade de conflitos dentro do kernel. Nas mquinas SMP o escalonamento um pouco mais complexo, em funo da existncia de vrios processos no estado de apto. Uma caracterstica importante a existncia de memria cache nos processadores. Muitas vezes mais interessante manter um processo suspenso enquanto existe um processador livre, para que ele volte a executar no mesmo processador que executara antes, podendo-se assim aproveitar o contedo da cache de memria. Se ele for disparado em um processador diferente, ser necessrio gastar tempo extra para carregar a cache deste outro processador com as posies de memria que interessam a este processo. O mesmo pode ser dito para a TLB da MMU em algumas arquiteturas.
5.5. Estudo de caso - Linux

Linux um sistema operacional com cdigo fonte aberto, estilo Unix, originalmente criado por Linus Torvalds a partir de 1991 com o auxlio de desenvolvedores espalhados ao redor do mundo. Linux "software livre" no sentido que pode ser copiado, modificado, usado de qualquer forma e redistribudo sem nenhuma restrio, sendo distribudo sob o "GNU General Public License". O sistema operacional Linux inclui multiprogramao, memria virtual, bibliotecas compartilhadas, protocolos de rede TCP/IP e muitas outras caractersticas consistentes com um sistema multiusurio tipo Unix. Uma descrio completa do Linux no cabe neste texto. Alm da pgina oficial http://www.linux.org, qualquer pesquisa na Internet ou na livraria vai revelar uma enorme quantidade de material sobre o assunto.
O Linux um sistema operacional em evoluo, e existem diferenas importantes entre suas verses. Este texto descreve a verso 2.2 e baseia-se, principalmente, na descrio que aparece em [BOV 01]. O Linux evolui rapidamente e alguns aspectos descritos aqui j sofreram alteraes na verso 2.4. Em alguns momentos sero feitas referncias arquitetura do Pentium Intel, por ser o processador mais usado na execuo do Linux. Esta seo descreve principalmente sistemas com um nico processador, mas so feitas algumas consideraes sobre o ambiente SMP. O Linux segue a linha do kernel convencional no-preemptvel, mas inclui suporte para multiprocessamento simtrico. Dentro do kernel existem dois tipos principais de fluxo de controle: aqueles originados por um processo realizando uma chamada de sistema e aqueles disparados pela ocorrncia de interrupes de hardware ou de proteo, estas ltimas chamadas de excees. Estes fluxos de controle internos ao kernel no possuem um descritor prprio e eles no so escalonados por algum algoritmo central. Muitas vezes executam do incio ao fim, pois o kernel no preemptvel, porm a execuo de vrios fluxos dentro do kernel pode ser intercalada quando acontecem interrupes ou quando o processo solicita seu prprio bloqueio, liberando o processador voluntariamente. Este entrelaamento da execuo dentro do kernel exige cuidados com as estruturas de dados compartilhadas. Um processo executando em modo kernel no pode ser substitudo por outro processo de mais alta prioridade, a no ser quando o processo executando no kernel solicita explicitamente o seu prprio bloqueio, seguido de um chaveamento. O processo dentro do kernel pode ser interrompido pela ocorrncia de interrupes de hardware e de proteo, mas ao trmino do respectivo tratador ele retoma a sua execuo. O fluxo de controle associado com uma interrupo somente pode ser interrompido pela ocorrncia de outra interrupo de hardware ou proteo. Uma conseqncia dessa organizao que chamadas de sistema no bloqueantes so atmicas com respeito s chamadas de sistema executadas por outros processos. Logo, uma estrutura de dados do kernel no acessada por tratadores de interrupo de hardware ou proteo no precisa ser protegida. Apenas necessrio que, antes de liberar o processador, o processo executando cdigo do kernel coloque as estruturas de dados em um estado consistente. Esta a maior vantagem da no preempo. A maior desvantagem est em fazer um processo de alta prioridade esperar que um processo de baixa prioridade termine a sua chamada de sistema antes de obter o processador. Em alguns momentos so utilizadas "operaes atmicas" para garantir a consistncia de uma operao, mesmo com interrupes habilitadas. Uma operao atmica neste contexto corresponde a uma nica instruo de mquina, a qual no pode ser interrompida durante sua execuo. No caso do Pentium Intel, pode-se usar uma instruo do tipo l/modifica/escreve no caso de monoprocessador, ou uma instruo do tipo l/modifica/escreve precedida da instruo LOCK, no caso de multiprocessadores. Muitas vezes as interrupes so simplesmente desabilitadas durante o acesso a uma estrutura de dados, para garantir que no haver interferncia de nenhum tipo. Este o mecanismo mais freqente no Linux. importante observar que desabilitar interrupes no impede as interrupes de proteo (excees). Tambm podem existir sees crticas aninhadas, quando as interrupes j desabilitadas so novamente desabilitadas. Neste caso, no basta habilitar as interrupes na sada da seo crtica, necessrio recolocar o valor original da flag EF encontrado no incio de cada seo crtica. A seqncia fica sendo: salva as flags em uma varivel, desabilita interrupes, executa a seo crtica, restaura as flags a partir da varivel usada.
No Linux, um tratador de interrupo no precisa realizar todo o trabalho associado com a interrupo que ocorreu. Ele pode "anotar" parte do trabalho para ser realizado mais tarde. No Linux 2.2 este trabalho postergado chamado de bottom-half e ser executado em um momento conveniente para o kernel, tal como no trmino de uma chamada de sistema, no trmino do tratamento de uma exceo, no trmino do tratamento de uma interrupo ou no momento do chaveamento entre dois processos. A capacidade de postergar parte de seu trabalho importante, pois como tratadores de interrupo no podem ficar bloqueados como se fossem processos, eles no podem depender da disponibilidade de estruturas de dados compartilhadas para terminar seu trabalho. Existem vrios tipos de bottom-half, e o momento de execuo de cada um depende dos recursos que eles necessitam. O mecanismo do bottom-half um passo na direo de threads de kernel, as quais representam uma soluo mais elegante. Em alguns momentos o cdigo do kernel utiliza semforos para proteger sees crticas. Os semforos so definidos da forma tradicional, como uma estrutura de dados composta por um contador inteiro, uma lista de processos bloqueados e mais campos auxiliares. Na implementao das operaes P e V, as interrupes so desabilitadas para garantir sua atomicidade em monoprocessadores. Em alguns momentos dentro do kernel o fluxo de controle no pode ficar bloqueado, e neste caso utilizada uma variao da operao P que, em caso do recurso ocupado, retorna um cdigo de erro mas no causa o bloqueio. Tambm existe uma variao da operao P usada em device-drivers, na qual o processo pode ficar bloqueado mas continua sensvel aos sinais Unix, os quais podem fazer este processo acordar e desistir de obter o semforo. Como o kernel no preemptvel, poucos semforos so utilizados. No caso de monoprocessamento, semforos so usados apenas quando o processo poder ficar bloqueado mais tarde em funo de um acesso a disco, ou quando um tratador de interrupo pode acessar uma estrutura de dados global do kernel. Eles so encontrados principalmente na gerncia de memria e no sistema de arquivos. Deadlock evitado atravs da ordenao dos semforos e alocao deles em uma certa ordem [SIL 99]. Em mquinas SMP diversos processadores podem executar em modo supervisor simultaneamente, logo os benefcios de um kernel no preemptvel so reduzidos. necessria uma sincronizao explcita nas sees crticas do kernel atravs de semforos e/ou spin-locks. Linux verso 2.0 usava uma soluo bem simples: A qualquer instante, no mximo um processador podia acessar as estruturas de dados do kernel e tratar interrupes. Esta soluo limitava o paralelismo no sistema. Na verso 2.2 muitas sees crticas foram tratadas individualmente e a restrio geral foi removida. Spin-locks so usados. A soluo implica em busy-waiting, pois o processador continua a executar o lao do spin-lock enquanto espera a seo crtica ser liberada. Se a seo crtica for rpida, ainda melhor isto do que realizar um chaveamento de processo. Observe que o spin-lock impede o acesso estrutura de dados por outro processador, mas no impede que tratadores de interrupo disparados no mesmo processador que obteve o spin-lock acessem estas estruturas. Logo, so usadas macros que, ao mesmo tempo, adquirem o spin-lock e desabilitam as interrupes. Alm do spin-lock simples (libera ou proibe qualquer tipo de acesso), o kernel do Linux utiliza uma variao chamada "read/write spin-lock", o qual permite o acesso simultneo de vrios processos leitores, mas garante excluso mtua na escrita. A verso 2.2 ainda inclui um spin-lock global do kernel, usado para proteger coletivamente todas as estruturas de dados usadas no acesso a arquivos, a maioria das relacionadas com comunicao via rede, todas as relacionadas com IPC (Inter-Process Communication) entre processos de usurio e ainda outras mais. Qualquer rotina que acesse uma dessas estruturas de dados precisa obter este spin-lock antes, o que significa
que um grande nmero de chamadas de sistema no Linux no podem executar simultaneamente em diferentes processadores. Fosse o Linux um kernel convencional preemptvel, o paralelismo potencial do SMP seria muito melhor aproveitado. Mesmo assim, vrias estruturas de dados j esto protegidas por spin-locks individuais. A granularidade menor no mecanismo de sincronizao proporciona maior paralelismo e desempenho. Entretanto, sua incluso em um kernel originalmente monoprocessado e no preemptivo deve ser muito cuidadosa para evitar deadlock e outras anomalias. importante destacar que o kernel do Linux est em constante evoluo. Por exemplo, j na verso 2.4 o mecanismo de bottom-half foi melhorado de tal forma que possa existir execuo simultnea destes blocos de cdigo em diferentes processadores, aumentando o desempenho do sistema. Em geral, possvel dizer que a evoluo do kernel do Linux o leva, a cada passo, mais perto da idia de um programa concorrente onde processos executam concorrentemente no kernel e podem ser preemptados a qualquer momento. A longo prazo o kernel do Linux dever tornar-se mais um programa concorrente tpico e menos um aglomerado de tratamentos diferenciados para dezenas de situaes especficas. A descrio do kernel do Linux feita aqui foi simplificada. Em [BOV 01] so dedicadas mais de 600 pginas ao assunto.
5.6. Concluses
Ao longo dos ltimos 40 anos, muito esforo foi empreendido no sentido de criar as estruturas de software mais apropriadas para organizar internamente os sistemas operacionais. Existem diferenas entre os servios oferecidos por um pequeno sistema operacional de propsito especfico e um sistema operacional de propsito geral. Tambm existem diferenas entre o ambiente computacional da dcada de 60 e este do incio do sculo 21. Apesar disto, o nmero de diferentes organizaes para sistemas operacionais no grande. Tambm razovel afirmar que, desde o incio dos anos 70, o sistema operacional Unix exerceu indiscutvel influncia sobre os projetistas da rea. Este texto discutiu as possveis organizaes para um kernel (ncleo) de sistema operacional. Inicialmente foi feita uma rpida reviso dos conceitos fundamentais dos sistemas operacionais e dos mecanismos clssicos para a sincronizao de processos. Em seguida, diversas organizaes possveis para o kernel do sistema operacional foram apresentadas. Em muitas delas o kernel apareceu como um programa concorrente, onde a preocupao com a sincronizao entre processos est presente. O texto buscou definir uma taxonomia para orientar o leitor no entendimento das organizaes existentes e nas conseqncias de cada uma delas. O Linux foi usado como estudo de caso. O sistema operacional sempre teve o papel de um administrador, tentando compatibilizar, da melhor forma possvel, as demandas dos programas de usurio com os recursos existentes no hardware. Atualmente esto acontecendo importante mudanas nestas duas reas. Os recursos disponveis no hardware continuam a aumentar a taxas geomtricas, sendo a capacidade dos discos, a velocidade das redes, o tamanho da memria principal e a interconectividade as grandes vedetes. Por outro lado, aplicaes distribudas e/ou envolvendo mdias contnuas so cada vez mais requisitadas e problemas com segurana aumentam a cada dia. Tambm esto sendo dissiminadas plataformas do tipo wireless e embedded, com demandas especficas e recursos limitados. Aps vrias dcadas de lenta evoluo, existe o sentimento de que os sistemas operacionais devero em breve necessitar um salto de flexibilidade em sua
organizao, para atender as demandas da computao no sculo 21. Com certeza, as organizaes apresentadas neste texto continuaro a evoluir nos prximos anos.
5.7. Agradecimentos
Os autores agradecem a Carlos Montez, Fbio Rodrigues de la Rocha, Mauro M. Mattos e Rafael R. Obelheiro, pelas vrias sugestes e comentrios.
5.8. Bibliografia
[BOE 81] [BOV 01] [DIJ 68] [HOL 83] [OLI 01] BOEHM, B. Software Engineering Economics. Prentice-Hall, 1981. BOVET, D.P.; CESATI, M. Understanding the Linux Kernel. OReilly & Associates, 2001. 684p. DIJKSTRA, E.W. The Structure of the THE Multiprogramming System. Comm. of the ACM, vol. 11, n. 5, pp. 341-346, May 1968. HOLT, R.C. Concurrent Euclid, The Unix System, and Tunis. Addison-Wesley, 1983. 323p. OLIVEIRA, R.S. de; CARISSIMI, A. da S.; TOSCANI, S.S. Sistemas Operacionais. Porto Alegre: Sagra-Luzzatto, 2001. 233p. {Srie Livros Didticos do Instituto de Informtica da UFRGS, N.11} PRESSMAN, R.S. Software Engineering: A Practitioners Approach. 5th edition. McGraw-Hill Higher Education, 2001. 860p. SILBERSCHATZ, A.; GALVIN, P.B. Operating Systems Concepts. 5th edition. John Wiley & Sons, 1999. 888p. STALLINGS, W. Operating Systems. 4th edition. Prentice-Hall, 2001. 779p. TANENBAUM, A.S. Distributed Operating Systems. Prentice-Hall, 1995. 614p. TANENBAUM, A.S.; WOODHULL, A.S. Sistemas Operacionais: Projeto e Implementao. 2a edio. Bookman, 2000. 759p. VAHALIA, U. Unix Internals: The New Frontiers. Prentice-Hall, 1996. 601p.
[PRE 01] [SIL 99] [STA 01] [TAN 95] [TAN 00] [VAH 96]

SO Conteudo

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SO Conteudo

Загружено:

Авторское право:

Доступные форматы

5

Sistemas Operacionais como Programas Concorrentes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

SISTEMA OPERACIONAL HARDWARE

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

Figura 5.2: Diagrama de estados de um processo.

5.1.2. Mecanismo de interrupes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

5.1.3. Mecanismos de proteo

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

Siste m a O p e ra c io na l e m M o d o Sup e rviso r

Pro c e sso d e Usu rio e m M o d o Usu rio

Interrupo de software (chamada de sistema)

ERAD 2002 - 2a Escola Regional de Alto Desempenho

ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

5.1.4. Chaveamento de processos

ERAD 2002 - 2a Escola Regional de Alto Desempenho

10 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

5.1.5. Memria lgica e memria fsica

ERAD 2002 - 2a Escola Regional de Alto Desempenho

11 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

Figura 5.5: Mecanismo bsico de paginao.

ERAD 2002 - 2a Escola Regional de Alto Desempenho

12 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

13 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

5.2. Reviso de programao concorrente

ERAD 2002 - 2a Escola Regional de Alto Desempenho

14 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

5.2.1. Problema da seo crtica

ERAD 2002 - 2a Escola Regional de Alto Desempenho

15 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

ERAD 2002 - 2a Escola Regional de Alto Desempenho

16 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

se sintetizar o funcionamento das operaes P e V sobre o semforo S da seguinte forma:

O problema da seo crtica pode ser facilmente resolvido com o mutex:

ERAD 2002 - 2a Escola Regional de Alto Desempenho

17 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

ERAD 2002 - 2a Escola Regional de Alto Desempenho

18 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

5.3. Organizao de sistemas operacionais

ERAD 2002 - 2a Escola Regional de Alto Desempenho

19 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

5.3.1. Kernel monoltico

ERAD 2002 - 2a Escola Regional de Alto Desempenho

20 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

21 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

5.3.2. Kernel convencional

ERAD 2002 - 2a Escola Regional de Alto Desempenho

22 ERAD 2002 - So Leopoldo, 15-19/jan/2002. Sistemas Operacionais como Programas Concorrentes

ERAD 2002 - 2a Escola Regional de Alto Desempenho

23 ERAD 2002 - Sistemas Operacionais como Programas Concorrentes - Oliveira,Carissimi, Toscani.

ERAD 2002 - 2a Escola Regional de Alto Desempenho