Apost So

Universidade Estadual de Campinas ~o Faculdade de Engenharia Eletrica e de Computaca
Indice
1 Introduc~ ao
Sistemas Operacionais
Notas de aula EA877 | Mini e Microcomputadores: Software
1.1 1.2 1.3 1.4
O que e um Sistema Operacional? Historia dos Sistemas Operacionais De nic~ oes Exemplos
1
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
1 2 4 5
2 Processos
2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 3.3 3.4 3.5 3.6
Conceitos Basicos Concorr^ encia Comunicac~ ao Interprocessos Escalonamento de Processos Processos em Unix Processos em MS-DOS
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
8 8 11 11 13 13 16 17 21 24 26 28
3 Ger^ encia de Memoria

Texto-base: Introduc~ ao a Sistemas Operacionais de E. Cardozo, M. Magalh~ aes e L. F. Faina, 1992 adaptado para EA877 por Ivan L. M. Ricarte
~ o e Automaca ~o Industrial Departamento de Engenharia de Computaca
Ger^ encia Sem Permuta Ger^ encia com Permuta Memoria Virtual Algoritmos de Troca de Pagina Ger^ encia de Memoria no UNIX Ger^ encia de Memoria em MS-DOS Interface do Sistema de Arquivos Projeto do Sistema de Arquivos O Sistema de Arquivos do Unix Sistemas de Arquivos do MS-DOS Princ pios do Hardware Princ pios do Software Discos E/S no Unix E/S em MS-DOS
16
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
4 Sistema de Arquivos
4.1 4.2 4.3 4.4
30
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
30 31 35 37
5 Entrada e Sa da
5.1 5.2 5.3 5.4 5.5
39
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
39 41 44 47 49
1996 i
Cardozo, Magalh~ aes, Faina & Ricarte
Cap tulo 1 Introduc~ ao

Programas computacionais (ou software ) constituem o elo entre o aparato eletr^ onico (ou hardware ) e o ser humano. Tal elo se faz necessario dada a discrep^ ancia entre o tipo de informac~ ao manipulada pelo homem e pela maquina. A maquina opera com cadeias de codigos binarios enquanto o homem opera com estruturas mais abstratas como conjuntos, arquivos, algoritmos, etc. Programas computacionais podem ser grosseiramente divididos em dois tipos: programas do sistema, que manipulam a operac~ ao do computador programas aplicativos, que resolvem problemas para o usuario. O mais importante dos programas do sistema e o sistema operacional, que controla todos os recursos do computador e proporciona a base de sustentac~ ao para a execuc~ ao de programas aplicativos.
1.1 O que e um Sistema Operacional?

A maioria de usuarios de computador t^ em alguma experi^ encia com sistemas operacionais, mas e dif cil de nir precisamente o que e um sistema operacional. Parte do problema decorre do fato do sistema operacional realizar duas func~ oes basicas e, dependendo do ponto de vista abordado, uma das func~ oes e mais destacada do que a outra. Estas func~ oes s~ ao descritas a seguir. A arquitetura (conjunto de instruc~ oes, organizac~ ao de memoria, E/S e estrutura de barramento) da maioria dos computadores a n vel de linguagem de maquina e primitiva e dif cil de programar, especi camente para operac~ oes de entrada e sa da. E prefer vel para um programador trabalhar com abstrac~ oes de mais alto n vel onde detalhes de implementac~ ao das abstrac~ oes n~ ao s~ ao vis veis. No caso de discos, por exemplo, uma abstrac~ ao t pica e que estes armazenam uma colec~ ao de arquivos identi cados por nomes simbolicos. O programa que esconde os detalhes de implementac~ ao das abstrac~ oes e o sistema operacional. A abstrac~ ao apresentada ao usuario pelo sistema operacional e simples e mais facil de usar que o hardware original. Nesta vis~ ao, a func~ ao do sistema operacional e apresentada ao usuario como uma maquina estendida ou maquina virtual que e mais facil de programar que o hardware que a suporta.
ii
1.1.1 O Sistema Operacional como uma Maquina Virtual
c 1996
DCA/FEEC/UNICAMP
Introduc~ ao
Historia dos Sistemas Operacionais 1.2]
Um computador moderno e composto de varios subsistemas tais como processadores, memorias, discos, terminais, tas magneticas, interfaces de rede, impressoras, e outros dispositivos de E/S. Sob este ponto de vista, o sistema operacional tem a func~ ao de gerenciar de forma adequada estes recursos de modo que as tarefas impostas pelos usuarios sejam atendidas da forma mais rapida e con avel poss vel. Um exemplo t pico e o compartilhamento da unidade central de processamento (CPU) entre as varias tarefas (programas) em sistemas multiprogramados. O sistema operacional e o responsavel pela distribuic~ ao de forma otimizada da CPU entre as tarefas em execuc~ ao.
1.1.2 O Sistema Operacional como um Gerenciador de Recursos
1.2 Historia dos Sistemas Operacionais

Os sistemas operacionais t^ em evolu do com o passar dos anos. Nas proximas sec~ oes vamos apresentar de forma sucinta este desenvolvimento. Apos muitos esforcos mal sucedidos de se construir computadores digitais antes da 2a guerra mundial, em torno da metade da decada de 1940 alguns sucessos foram obtidos na construc~ ao de maquinas de calculo empregando-se valvulas e reles. Estas maquinas eram enormes, ocupando salas com racks que abrigavam dezenas de milhares de valvulas (e consumiam quantidades imensas de energia). Naquela epoca, um pequeno grupo de pessoas projetava, construia, programava, operava e dava manutenc~ ao em cada maquina. Toda programac~ ao era feita absolutamente em linguagem de maquina, muitas vezes interligando plugs para controlar func~ oes basicas da maquina. Linguagens de programac~ ao eram desconhecidas, assim como sistemas operacionais. Por volta de 1950 foram introduzidos os cart~ oes perfurados aumentando a facilidade de programac~ ao.
1.2.1 A Primeira Gerac~ ao (1945-1955): Valvulas e Plugs
1.2.2 A Segunda Gerac~ ao (1955-1965): Transistores e Processamento em Batch

A introduc~ ao do transistor mudou radicalmente o quadro. Computadores tornaram-se con aveis e difundidos (com a fabricac~ ao em serie), sendo empregados em atividades multiplas. Pela primeira vez, houve uma separac~ ao clara entre projetistas, construtores, operadores, programadores e pessoal de manutenc~ ao. Entretanto, dado seu custo ainda elevado, somente corporac~ oes e universidades de porte detinham recursos e infraestrutura para empregar os computadores desta gerac~ ao. Estas maquinas eram acondicionadas em salas especiais com pessoal especializado para sua operac~ ao. Para rodar um job (programa), o programador produzia um conjunto de cart~ oes perfurados (um cart~ ao por comando do programa), e o entregava ao operador que dava entrada do programa no computador. Quando o computador completava o trabalho, o operador devolvia os cart~ oes com a impress~ ao dos resultados ao programador. A maioria dos computadores de 2a gerac~ ao foram utilizados para calculos cient cos e de engenharia. Estes sistemas eram largamente programados em FORTRAN e ASSEMBLY. Sistemas operacionais t picos1 eram o FMS (Fortran Monitor Systems) e o IBSYS (IBM's Operating Systems).
1
No in cio dos anos 60, a maioria dos fabricantes de computadores tinha duas linhas distintas e incompat veis de produtos. De um lado, havia os computadores cient cos que eram usados para calculos numericos na ci^ encia e engenharia. Do outro, haviam os computadores comerciais que executavam tarefas como ordenac~ ao de dados e impress~ ao de relatorios, sendo utilizados principalmente por instituic~ oes nanceiras. A IBM tentou resolver este problema introduzindo a serie System/360. Esta serie consistia de maquinas com mesma arquitetura2 e conjunto de instruc~ oes. Desta maneira, programas escritos para uma maquina da serie executavam em todas as demais. A serie 360 foi projetada para atender tanto aplicac~ oes cient cas quanto comerciais. N~ ao foi poss vel para a IBM escrever um sistema operacional que atendesse a todos os con itos de requisitos dos usuarios. O resultado foi um sistema operacional (OS/360) enorme e complexo comparado com o FMS. A despeito do tamanho e problemas, o OS/360 atendia relativamente bem as necessidades dos usuarios. Ele tambem popularizou muitas tecnicas ausentes nos sistemas operacionais de 2a gerac~ ao, como por exemplo a multiprogramac~ ao. Outra caracter stica apresentada foi a capacidade de ler jobs dos cart~ oes perfurados para os discos, assim que o programador os entregasse. Dessa maneira, assim que um job terminasse, o computador iniciava a execuc~ ao do seguinte, que ja f^ ora lido e armazenado em disco. Esta tecnica foi chamada spool (simultaneous peripherical operation on line), sendo tambem utilizada para a sa da de dados. O tempo de espera dos resultados dos programas reduziu-se drasticamente com a 3a gerac~ ao de sistemas. O desejo por respostas rapidas abriu caminho para o time-sharing, uma variac~ ao da multiprogramac~ ao onde cada usuario tem um terminal on-line e todos compartilham uma unica CPU. Apos o sucesso do primeiro sistema operacional com capacidade de time-sharing (o CTSS) desenvolvido no MIT3, um consorcio envolvendo o MIT, a GE e o Laboratorio Bell foi formado com o intuito de desenvolver um projeto ambicioso para a epoca: um sistema operacional que suportasse centenas de usuarios on-line. O MULTICS (MULTiplexed Information and Computing Service) introduziu muitas ideias inovadoras, mas sua implementac~ ao mostrou-se impraticavel para a decada de sessenta. O projeto MULTICS in uenciou os pesquisadores da Bell que viriam a desenvolver o UNIX uma decada depois.
1.2.3 A Terceira Gerac~ ao (1965-1980): Circuitos Integrados e Multiprogramac~ ao
Com o desenvolvimento de circuitos LSI, chips contendo milhares de transistores em um cent metro quadrado de sil cio, surgiu a era dos computadores pessoais e estac~ oes de trabalho. Em termos de arquitetura, estes n~ ao diferem dos minicomputadores da classe do PDP-11, exceto no quesito mais importante: preco. Enquanto os minicomputadores atendiam companhias e universidades, os computadores pessoais e estac~ oes de trabalho passaram a atender usuarios individualmente. O aumento do potencial destas maquinas criou um vast ssimo mercado de software a elas dirigido. Como requisito basico, estes produtos (tanto aplicativos quanto o proprio sistema operacional) necessitavam ser \amigaveis", visando usuarios sem conhecimento aprofundado de computadores e sem intenc~ ao de estudar muito para utiliza-los. Esta foi certamente a maior mudanca em relac~ ao ao OS/360 que
2 3
1.2.4 A Quarta Gerac~ ao (1980-): Computadores Pessoais e Estac~ oes de Trabalho
Que eram capazes de gerenciar apenas um job por vez.
Por sinal, o termo arquitetura de computador foi introduzido pelos projetistas deste sistema. Massachussets Institute of Technology.
c 1996
DCA/FEEC/UNICAMP
Introduc~ ao
Exemplos 1.4]
era t~ ao obscuro que diversos livros foram escritos sobre ele. Dois sistemas operacionais dominaram o mercado: MS-DOS para os computadores pessoais e UNIX para as estac~ oes de trabalho. O proximo desenvolvimento no campo dos sistemas operacionais surgiu com a tecnologia de redes de computadores: os sistemas operacionais de rede e distribu dos. Sistemas operacionais de rede diferem dos sistemas operacionais para um simples processador no tocante a capacidade de manipular recursos distribu dos pelos processadores da rede. Por exemplo, um arquivo pode ser acessado por um usuario num processador, mesmo que sicamente o arquivo se encontre em outro processador. Sistemas operacionais de rede prov^ eem ao usuario uma interface transparente de acesso a recursos compartilhados (aplicativos, arquivos, impressoras, etc), sejam estes recursos locais ou remotos. Sistemas operacionais distribu dos s~ ao muito mais complexos. Estes sistemas permitem que os processadores cooperem em servicos intr nsecos de sistemas operacionais tais como escalonamento de tarefas e paginac~ ao. Por exemplo, num sistema operacional distribu do uma tarefa pode \migrar" durante sua execuc~ ao de um computador sobrecarregado para outro que apresente carga mais leve. Contrario aos sistemas operacionais de rede que s~ ao largamente dispon veis comercialmente, sistemas operacionais distribu dos t^ em sua utilizac~ ao ainda restrita.
ao suporte de multiplos processos concorrentes, permite que instruc~ oes e dados de dois ou mais processos disjuntos estejam residentes na memoria principal simultaneamente. cuta instruc~ oes uma a uma, certos projetos mais avancados incrementaram a velocidade efetiva de computac~ ao permitindo que varias instruc~ oes fossem executadas ao mesmo tempo. Um computador com multiplos processadores que compartilhem uma memoria principal comum e chamado um multiprocessador. O sistema que suporta tal con gurac~ ao e um sistema que suporta o multiprocessamento. interface do usuario com o sistema operacional. Este processo l^ e o teclado a espera de comandos, interpreta-os e passa seus par^ ametros ao sistema operacional. Servicos como login e logout, manipulac~ ao de arquivos, e execuc~ ao de programas s~ ao solicitados atraves do interpretador de comandos.
Multiprocessamento Embora a maioria dos computadores disponha de uma unica CPU que exe-
Interpretador de Comandos (Shell) O interpretador de comando e um processo que perfaz a
Chamadas de Sistema (System Calls) Assim como o interpretador de comandos e a interface
1.3 De nic~ oes

Nesta sec~ ao, alguns termos basicos relativos a sistemas operacionais s~ ao de nidos. Nos cap tulos seguintes, os conceitos associados ser~ ao aprofundados. programa em execuc~ ao. Ele e uma entidade ativa que compete por recursos oferecidos pelo sistema (acesso a discos, perifericos, e principalmente CPU) e interage com outros processos. Um processo pode assumir de tr^ es estados, que s~ ao: executando (usando a CPU para executar as instruc~ oes do programa), bloqueado (aguardando outros recursos | alem da CPU | n~ ao dispon veis no momento), ou ativo (aguardando apenas CPU para executar).
entre usuario e sistema operacional, as chamadas do sistema constituem a interface entre programas aplicativos e o sistema operacional. As chamadas do sistema s~ ao func~ oes que podem ser ligadas com os aplicativos provendo servicos como leitura do relogio interno, operac~ oes de entrada/sa da e comunicac~ ao inter-processos.
Processos Um processo (as vezes chamado de tarefa ou de processo sequencial) e basicamente um
Arquivos Uma das func~ oes associadas a sistemas operacionais e esconder os detalhes de hardware do usuario. O conceito de arquivos oferece um n vel de abstrac~ ao que adequado para manipular grupos de dados armazenados em discos e perifericos de entrada e sa da (I/O). Alem de suportar func~ oes para transferir dados entre discos (ou perifericos) e a aplicac~ ao, o sistema operacional pode tambem suportar func~ oes para organizar os dados do disco em diretorios e para controlar o acesso a estes dados. Codigo Reentrante Um codigo de um programa e dito ser reentrante quando um segundo processo
pode iniciar a execuc~ ao deste codigo mesmo que o codigo esteja sendo executado por um outro processo.
Sistemas Multitarefas e Multiusuarios Um sistema operacional multitarefa se distingue pela sua
habilidade de suportar a execuc~ ao concorrente de processos sobre um processador unico, sem necessariamente prover forma elaborada de gerenciamento de recursos (CPU, memoria, etc). Sistemas operacionais multiusuarios permitem acessos simult^ aneos ao computador atraves de dois ou mais terminais de entrada. Embora frequentemente associada com multiprogramac~ ao, multitarefa n~ ao implica necessariamente em uma operac~ ao multiusuario. Operac~ ao multiprocessos sem suporte de multiusuarios pode ser encontrado em sistemas operacionais de alguns computadores pessoais avancados e em sistemas de tempo-real.
1.4 Exemplos
No restante desta apostila, os conceitos que ser~ ao apresentados | ger^ encia de processos e de memoria, manipulac~ ao de arquivos e de dispositivos de entrada e sa da | ser~ ao ilustrados sob a optica de dois sistemas operacionais de ampla utilizac~ ao, MS-DOS e Unix. Estes dois sistemas s~ ao brevemente introduzidos a seguir. O ja citado projeto MULTICS (Sec~ ao 1.2.3) n~ ao obteve sucesso por ser ambicioso demais. Um dos pesquisadores deste projeto, Ken Thompson (Bell Labs) decidiu escrever uma vers~ ao simpli cada deste sistema em uma maquina ja sem uso (um minicomputador PDP-7). Esta vers~ ao do sistema foi batizada de UNICS (Uniplexed Information and Computing Service), uma brincadeira com relac~ ao ao \multiplexed" de MULTICS. Posteriormente, este sistema simpli cado viria a alcancar grande sucesso sob o nome de Unix.
DCA/FEEC/UNICAMP 5
Multiprogramac~ ao Multiprogramac~ ao e um conceito mais geral que multitarefa e denota um sistema
operacional que prov^ e gerenciamento da totalidade de recursos tais como CPU, memoria, sistema de arquivos, em adic~ ao ao suporte da execuc~ ao concorrente dos processos. Quando um sistema operacional permite apenas a monoprogramac~ ao, a execuc~ ao de programas passa por diversas fases, alternando momentos em que o processo se encontra executando ou bloqueado. Atraves do uso da multiprogramac~ ao e poss vel reduzir os per odos de inatividade da CPU e consequentemente aumentar a e ci^ encia do uso do sistema como um todo. O termo multiprogramac~ ao denota um sistema operacional o qual em adic~ ao
4
1.4.1 Unix
c 1996
Introduc~ ao
Exemplos 1.4]
Apos a vers~ ao inicial, desenvolvida por esforco pessoal de Thompson, outras pessoas passaram a colaborar com o projeto e o sistema foi transportado para outras maquinas da fam lia PDP-11. Como o esforco de transportar o codigo desenvolvido em assembly era muito grande, o grupo decidiu desenvolver tambem uma linguagem de alto-n vel para reescrever o sistema. A primeira linguagem desenvolvida foi B posteriormente, o sistema foi reescrito na linguagem que sucedeu B, a linguagem C. Pelo trabalho em Unix, Thompson and Dennis Ritchie receberam posteiormente o pr^ emio ACM Turing. Unix logo alcancou sucesso entre os usuarios de PDP-11, que eram na epoca principalmente universidades. Com o desenvolvimento de um compilador C portatil (por Steve Johnson, de Bell Labs), Unix pode ser transportado facilmente para outros sistemas computacionais. Em meados da decada de 1980, a AT&T (companhia que controlava Bell Labs) passou a comercializar sua vers~ ao \o cial" de Unix. Em contraposic~ ao a esta vers~ ao, ha o sistema Unix desenvolvido (a partir da vers~ ao para o PDP-11) na Universidade da California em Berkeley, usualmente conhecido como Unix BSD (Berkeley Software Distribution). Varias empresas que passaram a distribuir suas vers~ oes de Unix para seus sistemas utilizaram como base o Unix BSD, tais como a Sun e a DEC. As diferencas entre estas duas vers~ oes de Unix levaram ao desenvolvimento de um padr~ ao para uniformizar as interfaces de acesso aos servicos do sistema. Esta interface e conhecida como POSIX (Portable Operating System, Unix), e de ne nomes e formatos padronizados para servicos comuns do sistema operacional, tais como open, read e fork. Uma aplicac~ ao que utilize os servicos do sistema operacional de nidos pelo padr~ ao POSIX pode ser transportada para qualquer sistema tipo Unix sem problemas. Entretanto, a quest~ ao da uniformidade dos diferentes sistemas Unix ainda n~ ao foi completamente respondida. Ha ainda hoje distinc~ ao entre sistemas produzidos pela Open Software Foundation (OSF, um consorcio de empresas de computac~ ao do porte da IBM, HP e DEC) e pela Unix International (UI, outro consorcio liderado pela AT&T), alem de empresas que utilizam suas proprias variac~ oes, como o AIX da IBM. mesmo assim, Unix e um dos sistemas operacionais de maior aceitac~ ao na comunidade \n~ ao-comercial". A raz~ ao da aceitac~ ao do UNIX e explicada por: ser escrito em linguagem de alto n vel, o que facilita seu transporte para diferentes plataformas ter interface simples para com o usuario (shell) fornecer primitivas que permitem o desenvolvimento de programas complexos a partir de programas mais simples suportar estrutura hierarquica de arquivos ter formatac~ ao de arquivos baseada no conceito de stream (cadeia) de bytes ter interfaceamento simples e consistente com os dispositivos perifericos ser multiusuario/multiprogramado esconder a arquitetura do hardware, permitindo que um programa execute em multiplas plataformas.
o processador 8088 da Intel, com arquitetura interna de 16 bits mas trabalhando em um barramento externo de dados de 8 bits. Apesar de que ja existia na epoca o processador 8086, com barramento externo de 16 bits, os perifericos para o 8088 eram muito mais baratos, o que determinou a escolha nal. A nal de contas, este era apenas um computador pessoal, que seria utilizado apenas para jogos. Pelo mesmo racioc nio, a IBM procurou uma pequena empresa de Seattle, a Microsoft, para licenciar uma vers~ ao de um interpretador BASIC para o seu computador pessoal. O proprietario da empresa, Bill Gates, havia desenvolvido um interpretador BASIC para o primeiro computador pessoal, o Altair. Aproveitando a ocasi~ ao, a IBM manifestou interesse em um sistema operacional. Na epoca, a Microsoft vendia o sistema Unix sob licenca da AT&T, mas este sistema seria muito grande para os recursos oferecidos pela maquina (64 KBytes de memoria, sem disco r gido). A recomendac~ ao foi adotar o sistema CP/M-86, da Digital Research, a empresa que havia produzido o ent~ ao popular sistema operacional CP/M para processadores de 8 bits. No entanto, o cronograma para o CP/M-86 estava atrasado, e a IBM n~ ao queria esperar. Voltando a Gates, pediu-lhe que produzisse um sistema operacional para 16 bits. Gates ent~ ao comprou o software 86-DOS da empresa Seattle Computer Products (que o utilizava para testar as placas de memoria que produzia) e contratou o autor do programa, Tim Patterson, para fazer uma adaptac~ ao rapida. Desta forma, nasceu MS-DOS, embarcado em IBM-PCs a partir de 1981. Provavelmente, se a IBM ou a Microsoft pudessem imaginar o n vel de sucesso que esta combinac~ ao iria obter, mais cuidado teria sido dado ao desenvolvimento do sistema. O motivo do sucesso deste sistema foi o fato de ter sido adotada uma arquitetura aberta, onde os componentes estavam dispon veis em qualquer loja de eletr^ onica e os diagramas esquematicos e codigo basico podiam ser encontrados no livro que descrevia o sistema. Desta forma, diversos fabricantes passaram a desenvolver modelos \compat veis" com o IBM-PC, e MS-DOS era o sistema operacional de todos eles. Entre as caracter sticas do IBM-PC que tiveram re exo no software desenvolvido para ele est~ ao o modelo de memoria e a falta de protec~ ao de hardware. Apesar do processador 8088 ter um espaco de enderecamento de 1 MByte, apenas os primeiros 640 KBytes (dez vezes maior que a memoria f sica) estavam dispon veis como RAM, sendo o restante do espaco de enderecamento alocado a outras memorias, como ROM e memoria de v deo. Esta caracter stica trouxe re exos posteriores, quando nenhum programa rodando em MS-DOS podia ser maior que 640 KBytes.
hardware ou software para este sistema. Desta forma, ela selecionou como plataforma de hardware
1.4.2 MS-DOS
MS-DOS (MicroSoft Disk Operating System), provavelmente o sistema operacional com maior numero de usuarios, foi desenvolvido de forma n~ ao t~ ao pro ssional. Quando a IBM decidiu lancar seu computador pessoal no in cio da decada de 1980, a empresa n~ ao estava interessada no desenvolvimento de
6
c 1996
DCA/FEEC/UNICAMP
Processos
Concorr^ encia 2.2]
ao m sem interrupc~ ao para evitar inconsist^ encias. Em situac~ oes como estas, a parte do codigo que o manipula o recurso compartilhado e uma regi~ ao cr tica. O codigo que implementa uma regi~ ao cr tica deve obedecer a uma serie de restric~ oes:
Cap tulo 2 Processos

2.1 Conceitos Basicos
No cap tulo anterior de nimos o conceito de processo | essencialmente, um programa em execuc~ ao. Um processo possui duas importantes propriedades: o resultado da execuc~ ao de um processo independe da velocidade com que o processo e executado se um processo for executado novamente com os mesmos dados, ele passara precisamente pela mesma sequ^ encia de instruc~ oes e fornecera o mesmo resultado. Estas propriedades enfatizam a natureza sequencial de um processo. O processo sequencial e de nido pelo resultado de suas instruc~ oes, n~ ao pela velocidade com que as instruc~ oes s~ ao executadas. A maioria dos computadores modernos s~ ao capazes de realizar diversas atividades em paralelo. Enquanto roda um programa do usuario, o computador pode ler um disco ou utilizar a impressora. Em sistemas multiprogramados, a CPU e comutada de programa a programa em per odos da ordem de milesimos de segundos, dando ao usuario a impress~ ao de paralelismo. A ger^ encia de atividades paralelas e dif cil de ser implementada com e ci^ encia. Entretanto, projetistas de sistemas operacionais ao longo dos anos v^ em desenvolvendo modelos objetivando tornar esta tarefa mais simples. No modelo mais empregado atualmente, todos os programas executaveis no computador, muitas vezes incluindo subsistemas do sistema operacional, est~ ao organizados na forma de processos. Conceitualmente, cada processo tem uma CPU virtual propria. A posse da CPU real e passada periodicamente de processo a processo. Em sistemas multiprogramados, a velocidade de execuc~ ao de um processo e func~ ao da quantidade de processos competindo pela CPU. Isto implica que o tempo de execuc~ ao de um processo varia a cada nova execuc~ ao, dependendo da \carga" da maquina | ou seja, processos n~ ao devem ser programados com considerac~ oes intr nsecas de tempo. Neste cap tulo, avancaremos no estudo de processos, analisando problemas de concorr^ encia, escalonamento e comunicac~ ao interprocessos.
dois processos n~ ao podem estar simultaneamente executando regi~ oes cr ticas referentes a um mesmo recurso compartilhado (garantia de mutua exclus~ ao) a garantia de mutua exclus~ ao deve ser independente da velocidade relativa dos processos ou numero de CPUs nenhum processo executando fora de regi~ oes cr ticas pode bloquear outro processo nenhum processo deve esperar um tempo arbitrariamente longo para poder executar uma regi~ ao cr tica. Varios algoritmos de controle visando garantir as propriedades acima foram propostos. Estes algoritmos s~ ao classi cados segundo o modo com que esperam pela autorizac~ ao de entrada numa regi~ ao cr tica: espera ocupada (usando a CPU durante a espera) ou bloqueada (n~ ao competindo pela CPU). Todo algoritmo de mutua exclus~ ao possui duas func~ oes delimitadoras. A primeira func~ ao e evocada quando o processo deseja iniciar a execuc~ ao de uma regi~ ao cr tica. Quando esta func~ ao retorna, o processo esta apto a executar a regi~ ao cr tica. No nal da execuc~ ao da regi~ ao cr tica, o processo evoca a segunda func~ ao, que ent~ ao provoca o retorno da primeira func~ ao em outro processo. Para permitir que regi~ oes cr ticas que acessam recursos compartilhados distintos possam ser executadas ao mesmo tempo, a cada recurso compartilhado e associado um identi cador, e as duas func~ oes que comp~ oem o algoritmo de garantia de mutua exclus~ ao possuem este identi cador como par^ ametro. Nesta sec~ ao analisaremos varias propostas para garantir exclus~ ao mutua nas regi~ oes cr ticas, n~ ao permitindo que mais de um processo possam manipular um recurso compartilhado ao mesmo tempo. Em todas, o processo que esta tentanto acessar uma regi~ ao cr tica em execuc~ ao por outro processo permanece em espera ocupada, isto e, competindo pela CPU mas sem avancar no seu processamento.
2.2.1 Mutua Exclus~ ao Com Espera Ocupada
Desabilitar Interrupc~ oes A soluc~ ao mais simples e o metodo de desabilitar todas as interrupc~ oes
quando se esta entrando na regi~ ao cr tica, e reabilita-las ao sair. Esta proposta n~ ao e muito atrativa, pois da ao processo usuario poder de desabilitar todas as interrupc~ oes, inclusive aquelas que permitem o nucleo reassumir a CPU. Caso o processo n~ ao as reabilite por algum motivo, o sistema operacional jamais reassume o controle do harware. Por outro lado, e conveniente para o sistema operacional desabilitar interrupc~ oes durante algumas instruc~ oes, enquanto esta atualizando variaveis internas. Assim, desabilitar interrupc~ oes e uma soluc~ ao util para o sistema operacional, mas n~ ao para processos de aplicac~ ao. recurso compartilhado, uma variavel global LOCK, inicialmente igual a 0. Quando um processo deseja entrar em sua regi~ ao cr tica ele primeiro testa o valor de LOCK. Se for 0, o processo altera para 1 e executa a regi~ ao cr tica. Se for 1, ele espera ate que seja 0. Embora pareca uma boa soluc~ ao, o que ira ocorrer se dois processos testam uma variavel de valor 0 ao mesmo tempo?
DCA/FEEC/UNICAMP 9
2.2 Concorr^ encia

Em muitos sistemas operacionais, processos frequentemente compartilham outros recursos alem da CPU. Em muitos casos, o recurso so pode atender a uma requisic~ ao por vez, e deve atend^ e-la do princ pio
8
Variaveis LOCK Uma segunda tentativa leva-nos a uma soluc~ ao por software. Considere, para cada
c 1996
Processos
Comunicac~ ao Interprocessos 2.3]
de acesso a regi~ ao cr tica | ou seja, esta variavel indica quem deve esperar e quem pode entrar na sec~ ao cr tica. Se TURN for , o processo pode entrar na regi~ ao cr tica. Ao sair, deve passar o valor de TURN para + 1 (modulo o numero total de processos). Este algoritmo garante a mutua exclus~ ao, mas os processos estritamente se alternam na posse do recurso compartilhado. Isto faz com que um processo necessite aguardar o acesso a um recurso compartilhado por todos os demais ate que chegue novamente a sua vez. O que ocorre quando a frequ^ encia de acesso for diferente entre os processos?
i i i
Altern^ ancia Estrita Esta proposta de ne uma variavel TURN que indica qual processo tem o direito
a caracter stica de mutua exclus~ ao, pois eles devem garantir que apenas um processo pode estar ativo1 no monitor em um dado instante. Monitores constituem-se em um conceito de linguagem de programac~ ao, ou seja, o compilador reconhece que os monitores s~ ao especiais e pode manusear as chamadas do monitor diferentemente de outras chamadas. Monitores, apesar de elegantes na manutenc~ ao de mutua exclus~ ao, t^ em aplicac~ ao restrita pois raras s~ ao as linguagens de programac~ ao que os incorporam.
Soluc~ ao de Peterson Esta soluc~ ao e obtida pela combinac~ ao das ideias de variaveis LOCK e TURN,
criando-se tambem uma soluc~ ao por software para o problema. Ela evita os problemas individuais das soluc~ oes anteriores, mas e pouco utilizada na pratica por utilizar espera ocupada.
2.3 Comunicac~ ao Interprocessos

Muitos autores consideram os mecanismos de exclus~ ao mutua apresentados acima como formas de processos se comunicarem. Entretanto, preferimos considerar tais mecanismos como de sincronizac~ ao interprocessos, usando o termo comunicac~ ao apenas quando ocorrer interc^ ambio de informac~ ao entre processos. Sincronizac~ ao e procedimento de controle, normalmente usado para garantir mutua exclus~ ao e gerenciar a competic~ ao entre os processos. Comunicac~ ao, por sua vez, visa promover a cooperac~ ao entre os processos.
(Test and Set Lock) presente em muitos processadores. Esta instruc~ ao permite a implementac~ ao de variaveis LOCK cujo teste e atualizac~ ao s~ ao at^ omicos (em outras palavras, a instruc~ ao TSL e indivis vel mesmo frente a interrupc~ oes de hardware ).
Instruc~ ao TSL Esta proposta requer suporte de hardware. Ela utiliza uma instruc~ ao da forma TSL
2.2.2 Mutua Exclus~ ao com Espera Bloqueada
Passagem de Mensagem Este metodo de comunicac~ ao entre processos usa duas chamadas de sis-
Ser~ ao apresentados a seguir alguns mecanismos de garantia de mutua exclus~ ao que bloqueiam os processos quando tentam executar uma regi~ ao cr tica \ocupada". S~ ao mais e cientes que os anteriores, posto que processos bloqueados n~ ao competem pela CPU.
tema, send (que envia umamensagem a um processo destino) e receive (que recebe uma mensagem de um processo fonte). Destino e fonte de mensagens s~ ao bu ers alocados pelos processos para ns de envio e recepc~ ao de mensagens. Mensagens s~ ao estruturas cujo conteudo e interpretado unicamente pelos processos emissor e receptor da mensagem.
Sleep e Wakeup Um dos metodos mais simples de implementac~ ao da espera bloqueada e a utilizac~ ao
do par sleep e wakeup. sleep e uma chamada de sistema que muda o estado de um processo em execuc~ ao para bloqueado. Um processo bloqueado volta a tornar-se ativo quando outro processo o desbloqueia atraves da chamada wakeup. O metodo e o mesmo que emprega variaveis LOCK operadas por instruc~ oes TSL, exceto que quando a variavel apresenta valor 1, o processo executa sleep. O processo que altera o valor de LOCK para 0 ao sair da regi~ ao cr tica e o responsavel por ativar um processo bloqueado (via wakeup). Infelizmente, deixar ao programador a responsabilidade da execuc~ ao destas chamadas pode levar a um estado onde todos os processos encontram-se bloqueados | uma situac~ ao denominada deadlock. usuario, mas atraves variaveis do tipo semaforos, que contam o numero de vezes que a operac~ ao wakeup foi realizada. Duas operac~ oes, DOWN e UP s~ ao de nidas. A operac~ ao DOWN veri ca se o valor do semaforo e maior que 0. Se o for, decrementa este valor e continua. Se o valor e 0, o processo e bloqueado. A operac~ ao UP incrementa o valor do semaforo. Se um ou mais processos estiverem bloqueados sobre aquele semaforo, um deles e escolhido pelo sistema para completar a operac~ ao DOWN (emitindo-lhe um wakeup). As operac~ oes com semaforos s~ ao at^ omicas ou indivis veis, implementadas com instruc~ oes TSL.
Compartilhamento de Dados Processos podem se comunicar atraves do compartilhamento de uma

area comum onde dados podem ser escritos por um e lidos por outro processo. O acesso a esta area comum deve ser disciplinado por um mecanismo de mutua exclus~ ao (tipicamente semaforos) ou tornando as instruc~ oes de leitura e gravac~ ao at^ omicas. Duas primitivas s~ ao necessarias, STORE (que grava dados na posic~ ao compartilhada especi cada) e FETCH (que acessa dados da posic~ ao compartilhada especi cada).
Semaforos Nesta abordagem, o bloqueio ou reativac~ ao de processos n~ ao e realizada diretamente pelo
de troca de mensagens que estrutura processos como servidores ou clientes. Um processo servidor disp~ oe de um conjunto de servicos que s~ ao disponibilizados para outros processos (atraves de uma rotina REGISTER RPC). Um processo cliente pode evocar um destes servicos como se evocasse um procedimento local, passando par^ ametros para sua execuc~ ao se for o caso, atraves de uma rotina CALL RPC. Recebida a requisic~ ao, o servidor executa o servico e retorna os resultados ao cliente. O envio e recepc~ ao de par^ ametros e retornos se da por troca de mensagens, que cam transparentes para o programador.
Chamada de Procedimentos Remotos Chamada de procedimentos remotos (RPC) e uma forma
2.4 Escalonamento de Processos

Quando mais de um processo esta ativo (pronto para executar), cabe ao sistema operacional decidir qual tera a posse da CPU. A parte do sistema operacional que toma esta decis~ ao e chamada escalonador e o algoritmo utilizado e o algoritmo de escalonamento. Varios criterios devem ser observados por um algoritmo de escalonamento: progresso: garantir que cada processo tenha acesso a CPU
1
Monitores Semaforos tornam simples a protec~ ao de recursos compartilhados, mas n~ ao garantem que n~ ao va haver deadlocks : a troca na ordem da chamada das primitivas pode gerar uma situac~ ao de bloqueio mutuo. Monitores s~ ao uma proposta de mecanismo de sincronizac~ ao de alto n vel. Um monitor e uma colec~ ao de procedimentos, variaveis e estruturas de dados agrupados em um bloco. Os processos podem acessar os procedimentos do monitor mas n~ ao suas estruturas internas. Monitores apresentam
10
Executando qualquer um de seus procedimentos.
c 1996
DCA/FEEC/UNICAMP
11
Processos
Processos em Unix 2.5]
e ci^ encia: manter a CPU ocupada praticamente 100% do tempo tempo de resposta: minimizar o tempo de resposta na execuc~ ao dos processos, principalmente os
interativos (editores, planilhas, etc)
2.5 Processos em Unix

Unix e um sistema que suporta multiprogramac~ ao, e como tal pode ter diversos processos rodando simultaneamente | alguns processos de usuarios, outros processos do nucleo do sistema. Cada processo corresponde a execuc~ ao de um programa e consiste de um conjunto de bytes que a CPU interpreta como instruc~ ao de maquina, dado e pilha. O processo executa uma sequ^ encia de instruc~ oes que e auto-contida e que n~ ao salta para um outro processo. Ele l^ e e escreve seus dados nas suas areas de dado e pilha, mas n~ ao pode ler ou escrever nas areas de dado e pilha de outro processo. Os processos comunicam com outros processos e com o resto do sistema atraves de chamadas de sistema. Do ponto de vista pratico, um processo em UNIX e uma entidade criada pela chamada fork, que cria um novo processo pela duplicac~ ao do estado de um processo que executa a chamada. O processo que chamou fork e identi cado como \processo pai" e o processo criado por esta chamada e identi cado como \processo lho". Para que um processo lho execute um programa diferente do processo pai, uma chamada do sistema exec deve ser invocada apos o fork. Todo processo tem um unico pai mas pode ter varios lhos, determinando assim uma hierarquia de processos. Exceto pelo primeiro processo (processo 0, na raiz da hierarquia), qualquer outro processo e criado atraves da chamada fork. O processo 0 e um processo especial criado quando da iniciac~ ao do sistema (boot). Apos criar o processo 1, conhecido como init, o processo 0 torna-se o processo swapper. O processo 1 e ancestral de qualquer outro processo no sistema, possuindo uma relac~ ao especial com estes. O contexto de um processo e o estado de nido pelo seu texto correspondendo aos valores das suas variaveis globais e estruturas de dados, os valores dos registros de maquina usados, os valores armazenados no seu slot na tabela de processos e o conteudo das suas pilhas de usuario e nucleo. Quando o nucleo decide executar um novo processo realiza-se uma mudanca de contexto. Quando da realizac~ ao de uma mudanca de contexto o nucleo salva informac~ oes su cientes de modo a que posteriormente ele possa recuperar o contexto do processo anterior e continuar a sua execuc~ ao. Da mesma forma, quando da mudanca do modo usuario para o modo nucleo, o nucleo salva as informac~ oes necessarias para que o processo possa retornar ao modo usuario e continuar a execuc~ ao. Neste ultimo caso, temos uma mudanca de modo e n~ ao de um chaveamento de contexto. A vida de um processo pode ser representada por um conjunto de estados (Figura 2.1): executando no modo usuario executando no modo nucleo pronto ou bloqueado (dormindo). O nucleo protege a sua consist^ encia permitindo chaveamento de contexto apenas quando o processo transita do estado \executando no modo nucleo" para o modo \bloqueado". O nucleo tambem eleva o n vel de execuc~ ao do processador quando da execuc~ ao de regi~ oes cr ticas de modo a impedir interrupc~ oes que possam provocar inconsist^ encias em suas estruturas de dados. O escalonador de processo realiza, periodicamente, a \preempc~ ao" de processos executando no modo usuario de forma a que os processos n~ ao monopolizem a CPU.
tempo de espera: minimizar o tempo de espera de servicos n~ ao interativos (compilac~ ao, impress~ ao,
etc)
vaz~ ao: maximizar o numero de processos executados por hora.

E importante observar que alguns desses objetivos s~ ao contraditorios. Se um algoritmo favorece o escalonamento de processos interativos certamento estara comprometendo os n~ ao interativos. Na sequ^ encia apresentaremos alguns algoritmos de escalonamento.
Escalonamento Round Robin Este e o mais antigo e simples algoritmo de escalonamento. Cada
processo e executado por um intervalo de tempo (quantum). Se o processo ainda estiver executando ao nal do quantum, ele e suspenso e a CPU e alocada a outro processo. Se o processo acabar ou for bloqueado antes do nal do quantum, a CPU tambem e passada a outro processo. O tamanho do quantum e cr tico nesta abordagem. Se for muito pequeno, diminui a e ci^ encia da CPU, pois a alocac~ ao da CPU para outro processo implica em uma sobrecarga de processamento para o chaveamento de recursos entre os processos. Se for muito grande, degrada a resposta para os processos interativos. sos s~ ao de igual import^ ancia. Certas aplicac~ oes, como controle de processos industriais, demandam um algoritmo de escalonamento com prioridades | desta forma, e poss vel tratar adequadamente situac~ oes de emerg^ encia. O princ pio do escalonamento por prioridades e que cada processo tem associada uma prioridade, e processos com prioridades superiores devem ser executados primeiro. Para prevenir que processos de alta prioridade executem inde nidamente, o escalonador pode diminuir a prioridade dos processos com o aumento de seu respectivo tempo de execuc~ ao | um processo conhecido como envelhecimento.
Algoritmos com Prioridades O algoritmo Round Robin faz a considerac~ ao que todos os proces-
Multiplas Filas Este e um algoritmo que de ne classes com prioridades. Processos na classe de
menor prioridade s~ ao executados por um quantum processos na classe seguinte, por dois quanta na proxima classe por quatro quanta, e assim por diante. Quando um processo utiliza todos os quanta a ele alocados, o mesmo e interrompido e sua classe tem a prioridade diminu da. Este algoritmo diminui o numero de comutac~ oes da CPU entre os processos ativos.
Tarefas Pequenas Primeiro Este algoritmo e designado para aplicac~ oes n~ ao interativas, onde o
tempo medio de execuc~ ao e conhecido a priori. O algoritmo de ne que as tarefas menores devem ser executadas primeiro. Prova-se que esta pol tica minimiza o tempo medio de espera dos jobs.
2.6 Processos em MS-DOS

Assim como Unix, MS-DOS tem um processo (command.com) que comeca a executar quando o sistema e iniciado e controla a interac~ ao entre entre o sistema e o usuario. Entretanto, ha uma diferenca fundamental entre os modelos de execuc~ ao nos dois sistemas. Como MS-DOS n~ ao suporta multiprogramac~ ao, quando um processo lho e iniciado a partir de command.com ele passa a ter controle total sobre a maquina. Ao contrario do que acontece em Unix, n~ ao e poss vel executar processos independentes simultaneamente em uma mesma maquina. Quando um processo lho e iniciado, o processo pai
DCA/FEEC/UNICAMP 13
Algoritmo Policy-Driven Este algoritmo particiona a CPU de forma equ^ anime entre os usuarios
n =n
(n~ ao entre os processos). O algoritmo de ne que se existirem usuarios ligados ao sistema, cada usuario devera receber 1 do poder da CPU. Para isto, o sistema deve manter informac~ oes do tempo de CPU que cada usuario ja disp^ os desde que entrou no sistema, e do instante de tempo que cada usuario ligou-se ao sistema.
12
c 1996
Processos
Processos em MS-DOS 2.6]
Executando em Modo Usurio
chamada de sistema ou interrupo
retorno
Executando em Modo Ncleo
interrupo/retorno 2
um apontador para o PSP do processo corrente. 3. Carregar o codigo binario na primeira posic~ ao apos o PSP. 4. Iniciar a execuc~ ao do programa. Escalonamento da CPU tambem e simples. Como so ha um processo ativo, este processo retem a posse da CPU o tempo todo, a n~ ao ser quando um processo TSR toma o controle da execuc~ ao.
escalonado aguardando evento 3 evento Pronto
Bloqueado
Figura 2.1: Estados de um processo deve car suspenso aguardando o m da execuc~ ao do processo lho. MS-DOS tem dois tipos de arquivos executaveis binarios, e ha correspondentemente dois tipos de processos. Um arquivo com extens~ ao .com n~ ao tem nenhum cabecalho e ocupa um unico segmento combinando texto, dados e pilha, ate o limite maximo de 64 KBytes. O conteudo do arquivo e uma imagem exata do codigo executavel. Embora o segmento n~ ao possa ocupar mais do que 64 KBytes, o processo recebe para si toda a memoria dispon vel. Uma tentativa de iniciar um novo processo lho nesta situac~ ao iria falhar por falta de memoria, a n~ ao ser que o programador explicitamente libere a porc~ ao da memoria que ele n~ ao ira usar para o sistema operacional com uma chamada do sistema. O outro tipo de arquivo executavel tem extens~ ao .exe. O processo criado por este tipo de arquivo pode ter diversos segmentos: texto, dados, pilha e segmentos extras. Um arquivo .exe incorpora informac~ ao de relocac~ ao, e pode ser relocado enquanto carregado. MS-DOS diferencia estes dois tipos de arquivo pelo conteudo de seus dois primeiros bytes, e n~ ao pela extens~ ao do nome do arquivo. Todo processo em MS-DOS tem um bloco de 256 bytes, o PSP (Program Segment Pre x), que descreve informac~ ao basica para o controle do processo, tal como tamanho do programa, apontador para o bloco do ambiente, apontador para o processo pai, e o endereco da rotina que sera invocada caso haja uma interrupc~ ao do usuario (Control-C). Normalmente, quando um processo encerra sua execuc~ ao, o espaco em memoria ocupado por ele e retomado pelo sistema e o processo deixa de existir. Uma alternativa permitida por MS-DOS e a sa da de um processo que mantem sua imagem em memoria, mesmo sem ser executado. Este tipo de processo, conhecido como TSR (Terminate and Stay Resident), e usualmente reativado por uma combinac~ ao especial de teclas. A forma pela qual MS-DOS permite que isto aconteca e atraves da modi cac~ ao, pelo proprio processo do usuario, de rotinas que ir~ ao tratar interrupc~ oes de teclado. A ger^ encia de processos em MS-DOS e simples. Quando um processo requer o carregamento e execuc~ ao de um outro programa, os seguintes passos s~ ao executados pelo sistema operacional: 1. Encontrar um bloco de memoria grande o su ciente para o processo. Para um arquivo .exe, esta informac~ ao esta contida no cabecalho para arquivos .com, toda a memoria dispon vel e alocada para o processo. 2. Contruir o PSP nos primeiros 256 bytes da area alocada. Uma variavel global do sistema mantem
14
c 1996
DCA/FEEC/UNICAMP
15
Ger^ encia de Memoria
Ger^ encia com Permuta 3.2]
processos em memoria, a CPU devera estar ocupada o tempo todo. Este modelo e otimista, entretanto, pois assume que os 5 processos nunca estejam esperando por E/S ao mesmo tempo.
Cap tulo 3 Ger^ encia de Memoria

A parte do sistema operacional que gerencia a memoria e chamada de gerenciador de memoria. Dentre outras tarefas, o gerenciador de memoria monitora quais partes da memoria est~ ao em uso e quais est~ ao dispon veis aloca e libera memoria para os processos gerencia a permuta de processos entre memoria principal e secundaria (quando a memoria principal n~ ao e capaz de abrigar todos os processos). Sistemas de ger^ encia de memoria podem ser divididos em duas classes: aqueles que mant^ em os processos xos em memoria primaria e aqueles que movem processos entre a memoria principal e secundaria (tipicamente disco) durante a execuc~ ao, neste caso baseando-se em tecnicas de swapping (permuta) ou paginac~ ao.
Se adotarmos a estrategia de admitir mais de um processo na memoria por vez, devemos estabelecer uma estrategia de organizac~ ao da memoria. A estrategia mais simples consiste em dividir a memoria em n (possivelmente diferentes) partic~ oes. Quando um processo inicia, este pode ser colocado em uma la de entrada para ocupar a menor partic~ ao de tamanho su ciente para acomoda-lo. Desde que as partic~ oes s~ ao xas, qualquer espaco em uma partic~ ao n~ ao usado pelo processo e perdido. A Figura 3.1(a) apresenta este esquema de partic~ ao.
partio 4 700K partio 4
3.1.3 Multiprogramac~ ao com Partic~ oes Fixas
partio 3
partio 3
400K partio 2 partio 2
3.1 Ger^ encia Sem Permuta

O esquema mais simples poss vel de ger^ encia de memoria consiste em ter-se somente um processo na memoria durante toda a sua execuc~ ao. O usuario carrega um programa do disco (ou ta) para a memoria, podendo este fazer uso de toda a maquina. Se a memoria for insu ciente, o programa simplesmente tem sua execuc~ ao rejeitada. Quando o sistema e organizado dessa maneira, somente um processo pode estar em execuc~ ao por vez. O usuario entra com um comando no terminal, e o sistema operacional carrega o programa requerido do disco para a memoria e o executa. Quando o processo termina, o sistema operacional reassume a CPU e espera por um novo comando para carregar um outro processo na memoria ja liberada pelo primeiro. Embora a monoprogramac~ ao seja usada em pequenos computadores, em grandes computadores com multiplos usuarios ela e proibitiva. Multiprogramac~ ao, alem de suportar processos simult^ aneos de diversos usuarios, tambem permite utilizar melhor a CPU durante acessos de um processo a dispositivos de entrada e sa da. E comum para um processo permanecer em um loop lendo um bloco de dados de um arquivo em disco e ent~ ao realizando alguma computac~ ao sobre o conteudo dos blocos lidos. Se for gasto 40 ms para ler um bloco e a computac~ ao demanda apenas 10 ms, sem a multiprogramac~ ao a CPU estara desocupada esperando pelo acesso ao disco durante 80% do tempo. Quando a multiprogramac~ ao e usada, o percentual de utilizac~ ao da CPU aumenta. A grosso modo, se a media dos processos utilizam CPU somente 20% do tempo que permanecem na memoria, com 5
16
200K partio 1 100K sistema operacional (a) sistema operacional (b) partio 1
3.1.1 Monoprogramac~ ao
Figura 3.1: Organizac~ oes com partic~ oes xas: (a) Partic~ oes de memoria xa com las de entrada separadas para cada partic~ ao (b) partic~ ao de memoria xa com uma la simples de entrada A desvantagem de se ordenar os processos que chegam em las separadas torna-se aparente quando a la para a maior partic~ ao esta vazia, mas a la para a menor partic~ ao esta cheia, como no caso das partic~ oes 1 e 4 na Figura 3.1(a). Uma organizac~ ao alternativa e manter uma la unica como na Figura 3.1(b). Toda vez que uma partic~ ao e liberada, a mesma e alocada ao primeiro processo da la. Uma vez que e indesejavel gastar uma partic~ ao grande com um processo pequeno, uma estrategia mais e caz e procurar em toda la de entrada a maior tarefa para a partic~ ao liberada. Note que o ultimo algoritmo discrimina os processos pequenos, quando e usualmente desejavel dar a eles o melhor tratamento, n~ ao o pior.
3.1.2 Multiprogramac~ ao e Uso da Memoria
3.2 Ger^ encia com Permuta

Num sistema operando em batch, a organizac~ ao da memoria em partic~ oes xas e simples e efetiva. Quanto mais jobs estiverem na memoria, mais a CPU estara ocupada e n~ ao ha raz~ ao para usar algo mais complicado. Com time-sharing, a situac~ ao e diferente: ha normalmente mais usuarios que memoria
DCA/FEEC/UNICAMP 17
c 1996
Ger^ encia com Permuta 3.2]
para armazenar os seus processos, sendo ent~ ao necessario mover temporariamente processos para disco. Obviamente, para continuar sua execuc~ ao, um processo movido para disco deve ser trazido novamente para a memoria. Outro aspecto fundamental nesta abordagem de ger^ encia e como controlar onde ha espaco dispon vel na memoria. As duas estrategias mais utilizadas s~ ao ger^ encia de espaco livre por mapa de bits ou por listas encadeadas, que ser~ ao descritas na sequ^ encia.
3.2.1 Multiprogramac~ ao com Partic~ oes Variaveis

Em princ pio, um sistema que utiliza swapping pode ser baseado em partic~ oes xas. Sempre que um processo e bloqueado, ele pode ser movido para o disco e um outro processo trazido do disco para a sua partic~ ao em memoria. Na pratica, partic~ oes xas s~ ao pouco atrativas quando a area de memoria e escassa pois muita memoria e perdida por programas muito menores que o tamanho da partic~ ao. Assim sendo, um novo sistema de ger^ encia de memoria foi desenvolvido, chamado ger^ encia com partic~ oes variaveis. Quando partic~ oes variaveis s~ ao usadas, o numero e tamanho de processos na memoria varia dinamicamente. A Figura 3.2 mostra como partic~ oes variaveis trabalham. Inicialmente, somente o processo A esta na memoria. Ent~ ao o processo B e C s~ ao criados ou trazidos do disco. Na Figura 3.2(d) o processo A termina ou e movido para o disco. Ent~ ao o processo D inicia e B termina. Finalmente, processo E inicia.
para compactar toda a memoria. Certos mainframes utilizam hardware especial para a compactac~ ao da memoria. Um ponto negativo neste metodo de ger^ encia e saber o quanto de memoria alocar para um processo. Se os processos s~ ao criados com um tamanho xo que permanece constante ao longo de sua execuc~ ao, ent~ ao a alocac~ ao e simples: aloca-se exatamente o necessario ao tamanho do processo, nem mais nem menos. Na pratica, os segmentos de dados e pilha de um processo tendem a crescer durante a sua execuc~ ao. Alocac~ ao din^ amica de memoria e recurs~ ao (presentes em praticamente em todas as linguagens modernas de programac~ ao) s~ ao exemplos t picos de crescimento destes segmentos. Se o processo necessitar expandir sua memoria e existir um buraco adjacente, simplesmente o buraco pode vir a ser incorporado ao espaco de enderecamento do processo. De outra forma, se o processo esta adjacente a outro processo, o primeiro devera ser movido para um buraco grande o su ciente para armazena-lo, ou um ou mais processos ter~ ao que ser movidos para disco com o intuito de criar espaco na memoria. Se o processo n~ ao puder crescer na memoria e a area do disco reservada para abrigar processos permutados estiver cheia, o processo deve ser terminado. Com um mapa de bits, a memoria e dividida em unidades de alocac~ ao, desde um pequeno numero de palavras ate muitos quilobytes. Para cada unidade de alocac~ ao existe um bit no mapa de bits, que e 0 se a unidade estiver livre e 1 caso esteja ocupada (ou vice-versa). A Figura 3.3 mostra parte da memoria e o correspondente mapa de bits.
A 8 B C 16 D 24 ....
3.2.2 Ger^ encia com Mapa de Bits
C
11111000 11111111 10011111 (a)
B E
A sistema operacional (b)
A sistema operacional (c) sistema operacional (d)
D sistema operacional (e)
D sistema operacional (f)
D sistema operacional (g)

P 0 A
(b) B 5 B 6 8 p 9 14 C P 15 17 B 18 19 D P 20 25
sistema operacional (a)
Figura 3.2: Organizac~ ao com swapping: mudancas na alocac~ ao de memoria com processos chegando e deixando a memoria (regi~ oes escuras representam espaco n~ ao usado) A principal diferenca entre partic~ oes xas da Figura 3.1 e partic~ oes variaveis da Figura 3.2 e que o numero, a localizac~ ao e o tamanho das partic~ oes variam dinamicamente ao longo do tempo. A exibilidade de n~ ao se ter um numero xo de partic~ oes aumenta a utilizac~ ao da memoria, mas tambem complica a tarefa de alocar e liberar a memoria, bem como gerencia-la. E poss vel combinar todos os buracos disjuntos num unico espaco dispon vel agrupando-se todos processos para um lado da memoria. Esta tecnica e conhecida como compactac~ ao da memoria. Ela n~ ao e empregada com frequ^ encia pelo fato de requerer muito tempo de CPU. Por exemplo, um microcomputador com 1 MByte de memoria e que pode copiar 1 Byte por s (1 MByte/s), gasta um segundo
18
P: processo B: buraco (c)
Figura 3.3: Organizac~ ao com mapa de bits: (a) parte da memoria com 5 processos e 3 buracos (as marcas mostram as unidades de alocac~ ao da memoria e as regi~ oes escuras est~ ao livres) (b) mapa de bits correspondente (c) a mesma informac~ ao como uma lista ligada O tamanho de cada unidade de alocac~ ao e uma importante caracter stica de projeto. Para pequenas unidades de alocac~ ao tem-se um mapa de bits maior. Entretanto, mesmo com uma unidade de alocac~ ao t~ ao pequena como 4 bytes, cada 32 bits de memoria requer somente 1 bit no mapa (3% da memoria). Se a unidade de alocac~ ao for escolhida grande, o mapa de bits sera pequeno, mas memoria consideravel pode ser desperdicada se o tamanho do processo n~ ao for um multiplo exato da unidade de alocac~ ao.
DCA/FEEC/UNICAMP 19
c 1996
Memoria Virtual 3.3]
Um mapa de bits (ocupando uma porc~ ao xa da memoria) prov^ e uma maneira simples de gerenciar memoria, uma vez que o tamanho do mapa de bits depende somente do tamanho da memoria e do tamanho da unidade de alocac~ ao. O problema principal com isto e que quando se decide trazer um processo de k unidades de alocac~ ao para a memoria, o gerenciador de memoria deve pesquisar no mapa de bits uma sequ^ encia de k consecutivos bits 0 no mapa. Esta operac~ ao e lenta, raz~ ao pela qual os mapas de bits s~ ao evitados na pratica. Outra maneira de gerenciar a memoria e manter uma lista de alocac~ oes e segmentos de memoria livre, onde um segmento e um processo ou um buraco entre dois processos. A memoria da Figura 3.3(a) e representada na mesma gura (c) como uma lista encadeada de segmentos. Cada entrada da lista especi ca um buraco (B) ou um processo (P), contendo o endereco onde comeca, onde termina (ou tamanho do bloco), e um ponteiro para a proxima entrada da lista. Neste exemplo, a lista de segmentos e mantida ordenada por enderecos. A vantagem desse metodo e que quando o processo termina ou e movido para o disco, torna-se simples combinar o buraco criado com buracos adjacentes. Quando processos e buracos s~ ao mantidos na lista ordenada por enderecos, varios algoritmos podem ser usados para alocar memoria, a m de criar ou permutar processos. Tais algoritmos s~ ao evocados quando o gerenciador de memoria necessita um segmento de memoria de bytes.
M
Todos os quatro algoritmos podem melhorar seus desempenhos mantendo-se em separado listas para processos e buracos. Neste caso, todos devotam suas energias para inspec~ ao de buracos, n~ ao de processos. O preco pago por esse aumento de velocidade na alocac~ ao e uma complexidade adicional e diminuic~ ao de velocidade quando se trata de liberar memoria, uma vez que um segmento livre tem de ser removido da lista de processos e inserido na lista de buracos. Novamente, a ine ci^ encia esta em se determinar poss veis fus~ oes. Os algoritmos apresentados acima mant^ em o rastreamento da memoria principal. Assim, quando processos s~ ao permutados do disco para a memoria, o sistema pode alocar espaco em memoria para eles. Em alguns sistemas, quando um processo esta na memoria, nenhum espaco em disco e a ele reservado. Quando for movido da memoria, espaco deve ser alocado na area de disco para abriga-lo (portanto, em cada troca o processo pode residir em lugares diferentes no disco). Neste caso, os algoritmos para ger^ encia de espaco para permuta s~ ao os mesmos usados para ger^ encia da memoria principal. Em outros sistemas, quando um processo e criado, um espaco para permuta e alocado em disco (usando um dos algoritmos descritos acima). Sempre que um processo em memoria da lugar a outro processo, ele e colocado no espaco em disco a ele previamente alocado. Quando um processo termina, o seu espaco para permuta em disco e desalocado. Esta tecnica e mais e ciente que a anterior pois uma unica alocac~ ao de espaco em disco por processo e necessaria (lembre-se que um processo pode ser permutado varias vezes durante a sua execuc~ ao). Entretanto, uma area maior de disco deve ser reservada para swapping.
3.2.3 Ger^ encia com Listas Encadeadas
3.2.4 Alocac~ ao de Espaco para Permuta
ate encontrar um buraco de tamanho maior ou igual a . Caso o buraco tenha tamanho ,o buraco e quebrado em dois segmentos: um para o processo (de tamanho ) e o outro para a memoria n~ ao usada (de tamanho ; ). First- t e um algoritmo rapido pois naliza a busca o mais cedo poss vel.
M N > M M N M
Algoritmo First- t E o algoritmo mais simples. O algoritmo procura ao longo da lista de segmentos
3.3 Memoria Virtual

Desde o in cio da informatica, o tamanho dos programas vem superando a quantidade de memoria dispon vel para abriga-los. A soluc~ ao usualmente adotada era dividir o programa em partes, chamados overlays, que eram mantidas em disco e permutadas para a memoria pelo sistema operacional. Overlays apresentavam um problema: a partic~ ao do programa era deixada a cargo do programador. Um metodo que foi desenvolvido para deixar o particionamento do programa a cargo do sistema operacional veio a ser conhecido como memoria virtual. A ideia basica e que a combinac~ ao do tamanho do programa, dados e pilha, pode exceder a quantia de memoria f sica dispon vel. O sistema operacional mantem aquelas partes do programa correntemente em uso na memoria principal e o resto no disco. Memoria virtual pode tambem trabalhar em um sistema com multiprogramac~ ao. De fato, memoria virtual e multiprogramac~ ao est~ ao intimamente relacionadas. Enquanto um programa esta esperando que parte de seu espaco de enderecamento seja trazido a memoria, o programa e bloqueado, aguardando E/S. Ate que a operac~ ao de E/S seja completada, a CPU pode ser direcionada para outro processo. A maioria dos sistemas com memoria virtual usa uma tecnica chamada paginac~ ao. Em qualquer computador existe certo conjunto de enderecos de memoria que programas podem referenciar | seu espaco de enderecamento. Enderecos podem ser gerados por exemplo usando indexac~ ao, registradores base ou registradores de segmento. Estes enderecos gerados pelos programas s~ ao chamados enderecos virtuais e formam o espaco virtual de enderecamento do processo. Em computadores sem memoria virtual, o endereco virtual e colocado
DCA/FEEC/UNICAMP 21
Algoritmo Next- t Este algoritmo trabalha da mesma forma que o rst- t, exceto que guarda a
posic~ ao da lista onde o ultimo buraco foi alocado. Da proxima vez que e chamado, o algoritmo comeca a procurar a partir deste ponto. proximo de . E um algoritmo lento e cria na memoria buracos pequenos que di cilmente ser~ ao alocados. Entretanto, para grande, o best- t aumenta as chances de se encontrar na lista um buraco de tamanho adequado, posto que minimiza o uso buracos grandes para atender alocac~ oes pequenas. Como um exemplo, considere a Figura 3.3. Se um bloco de tamanho 2 for solicitado, o algoritmo rst t alocara o buraco 5, e o best t o buraco 18.
M M
Algoritmo Best- t Este algoritmo procura pela lista inteira e toma o buraco de tamanho mais
Algoritmo Quick- t Este algoritmo mantem listas separadas para tamanhos comumente requeridos.
Por exemplo, seja uma tabela com n entradas, na qual a primeira e um ponteiro para a cabeca da lista de buracos de tamanho 4 KBytes, a segunda e um ponteiro para a cabeca da lista de buracos de tamanho 8 KBytes, a terceira de tamanho 12 KBytes, e assim sucessivamente. Com o quick- t, acha-se um buraco de tamanho requerido muito rapidamente, mas com a desvantagem de todos os esquemas de classi car os buracos por tamanho, a saber, quando um processo termina ou e permutado para disco, determinar seus vizinhos para uma poss vel fus~ ao e uma operac~ ao custosa. Se fus~ oes n~ ao forem feitas, a memoria rapidamente se fragmentara em um grande numero de pequenos buracos n~ ao utilizaveis.
20
3.3.1 Paginac~ ao
c 1996

espao de endereamento virtual (tabela) 0 2 1 1 2 6 8-12K 3 0 4 12-16K 4 16-20K 5 5 20-24K 6 X 7 X 8 X 9 5 10 X 11 7 12 X 13 X 14 X 15 X : pgina de 4 Kbytes X: pgina ausente (em disco) 28-32K 24-28K 7 6 4 3 4-8K 2 0-4K 1 espao de endereamento real (fsico) 0
Memoria Virtual 3.3]
diretamente no barramento de memoria e causa uma palavra da memoria f sica com mesmo endereco ser lida ou escrita. Quando memoria virtual e usada, os enderecos de memoria n~ ao v~ ao diretamente para o barramento de memoria. Ao inves disso, eles v~ ao a unidade de ger^ encia de memoria (Memory Management Unit, MMU), onde um hardware espec co mapeia os enderecos virtuais nos enderecos da memoria f sica como ilustrado na Figura 3.4.
processador
CPU endereo virtual MMU memria control. de disco
barramento endereo fsico
Figura 3.4: A posic~ ao e func~ ao da MMU Um exemplo de como este mapeamento trabalha e mostrado na Figura 3.5. Neste exemplo, temos um computador que pode gerar enderecos de 16 bits, de 0 ate 64 KBytes. Estes s~ ao os enderecos virtuais. Este computador, entretanto, tem somente 32 KBytes de memoria f sica, assim, embora programas de 64K possam ser escritos, eles n~ ao podem ser carregados para a memoria na sua totalidade para serem executados. Uma copia completa de um nucleo de imagem do programa, acima de 64K, deve estar presente no disco os pedacos podem ser trazidos para a memoria pelo sistema a medida que se tornem necessarios. O espaco de enderecamento virtual e dividido em unidades chamadas paginas. As unidades correspondentes na memoria f sica s~ ao chamadas page frames. As paginas e page frames s~ ao sempre do mesmo tamanho. Neste exemplo elas s~ ao de 4K, mas tamanhos de paginas de 512 bytes, 1K, e 2K s~ ao comumente usados. Com 64K de espaco de endereco virtual e 32K de memoria f sica, temos 16 paginas e 8 page frames. Transfer^ encias entre memoria e disco s~ ao sempre feitas em unidades de paginas. Quando o programa tenta acessar o endereco 0, o endereco virtual 0 e enviado para a MMU. Ela reconhece que este endereco cai na pagina 0 (0 a 4095), o qual, de acordo com seu mapeamento e a page frame numero 2 (8192 ate 12287). Ele ent~ ao transforma o endereco para 8192 e coloca o endereco 8192 no barramento. A tabela de memoria nada sabe a respeito da MMU, e apenas v^ e uma requisic~ ao para leitura ou escrita no endereco 8192, a qual e respeitada. Assim, a MMU mapeou todo endereco virtual entre 0 e 4095 em endereco f sico de 8192 a 12287. Uma tentaiva de acessar uma pagina n~ ao mapeada provoca uma falta de pagina (page fault). Neste caso, o sistema operacional libera um page frame e escreve seu conteudo de volta no disco. Ele ent~ ao busca a pagina referenciada para o page frame liberado, atualiza o mapa, e retorna a instruc~ ao interrompida.
Figura 3.5: Relac~ ao entre endereco virtual e endereco f sico de memoria, dada pela tabela de paginas ser~ ao responsaveis por ter de lembrar onde foram posicionadas areas de dados com func~ oes muitas vezes distintas | por exemplo, para codigo e para tabelas de dados. Alem disto, o crescimento de uma area alem do previsto pode levar a uma situac~ ao de choque entre estas areas. Para algumas aplicac~ oes, um espaco enderecavel bidimensional e mais conveniente. Esta alternativa e suportada atraves do conceito de segmentac~ ao, onde posic~ oes de memoria s~ ao identi cadas por um par (segmento, deslocamento). Esta abordagem de segmentac~ ao interpreta o espaco de memoria sob um ponto de vista mais proximo da logica do programador | por exemplo, um segmento pode conter procedimentos, ou tabelas de dados. Como cada segmento tem um espaco de enderecamento independente dos outros, o crescimento de um segmento n~ ao afeta os demais. A traduc~ ao de enderecos segmentados para enderecos f sicos ocorre de maneira similar a traduc~ ao de enderecos virtuais. O sistema deve manter uma tabela mapeando segmentos para os enderecos da memoria. Uma diferenca fundamental e que segmentos t^ em dimens~ oes distintas, e portanto a informac~ ao sobre o comprimento de um segmento tambem deve ser mantida. O fato de se trabalhar com partic~ oes de tamanhos variaveis implica que apos um tempo de uso a fragmentac~ ao ira ocorrer, e pode ser necessario aplicar mecanismos de compactac~ ao. Uma forma de reduzir o problema de fragmentac~ ao mantendo-se o princ pio de segmentac~ ao e combinar este esquema com paginac~ ao | ou seja, cada segmento e dividido em paginas de tamanho xo, que s~ ao trazidas para a memoria de acordo com a demanda. Atraves do uso de segmentos e poss vel compartilhar trechos de codigo que s~ ao comuns entre diversas aplicac~ oes. Isto e util, por exemplo, em sistemas de interfaces gra cas, onde grandes bibliotecas s~ ao responsaveis pela ger^ encia de sistemas de janelas. Alem disto, o uso de segmentos facilita tambem a
DCA/FEEC/UNICAMP 23
3.3.2 Segmentac~ ao
Paginac~ ao prov^ e uma tecnica para implementac~ ao de um grande espaco enderecavel numa memoria f sica limitada. Este espaco de enderecamento e unidimensional, pois a posic~ ao de memoria e identi cada por um unico valor que vai de 0 ate um endereco maximo. Esta caracter stica implica que programadores
22
c 1996
Algoritmos de Troca de Pagina 3.4]
protec~ ao de acesso a areas da memoria.
3.4 Algoritmos de Troca de Pagina

Quando uma falta de pagina ocorre, o sistema operacional tem que escolher uma pagina para remover da memoria a m de dar lugar a que sera trazida do disco. Se a pagina a ser removida foi modi cada enquanto estava na memoria, ela deve ser reescrita no disco para manter a copia em disco atualizada. Se, todavia, a pagina n~ ao tiver sido alterada, a copia do disco ja esta atualizada, n~ ao sendo necessaria sua reescrita. A pagina a ser lida e simplesmente superposta a pagina retirada. Apesar de ser poss vel escolher uma pagina aleatoria para dar lugar a pagina em demanda, o desempenho do sistema e melhorado se for escolhida uma pagina pouco usada (referenciada). Se uma pagina muito usada e removida, ela provavelmente tera de ser trazida de volta em breve, resultando um esforco adicional. Algoritmos e cientes de troca de pagina visam minimizar este esforco. O melhor algoritmo de troca de paginas e facil de descrever mas imposs vel de implementar. No momento que ocorre uma falta de pagina, um certo conjunto de paginas esta na memoria. Uma dessas paginas sera referenciada em muitas das proxima instruc~ oes (a pagina contendo a instruc~ ao). Outras paginas n~ ao ser~ ao referenciadas antes de 10, 100, ou talvez 1000 instruc~ oes. Cada pagina pode ser rotulada com o numero de instruc~ oes que ser~ ao executadas antes que a pagina seja inicialmente referenciada. O algoritmo da pagina otima simplesmente diz que a pagina com o maior rotulo deve ser removida, adiando-se o maximo poss vel a proxima falta de pagina. O unico problema com este algoritimo e que ele n~ ao e realizavel. No momento da falta de pagina, o sistema operacional n~ ao tem como saber quando cada pagina sera referenciada. No entanto, uma aplicac~ ao a posteriori deste algoritmo e util para comparar o desempenho de algoritmos realizaveis com o melhor poss vel.
para distinguir paginas que n~ ao foram referenciadas recentemente daquelas que tenham sido. Quando uma falta de pagina ocorre, o sistema operacional examina todas as paginas e as classi ca em quatro categorias baseado nos valores correntes de seus bits RM : Classe 0 (00) n~ ao referenciada, n~ ao modi cada. Classe 1 (01) n~ ao referenciada, modi cada.
Classe 2 (10) referenciada, n~ ao modi cada. Classe 3 (11) referenciada, modi cada.
Ainda que as paginas na classe 1 parecam, a primeira vista, imposs veis de existir, elas ocorrem quando as paginas da classe 3 t^ em seu bit R zerado pela interrupc~ ao do relogio. Interrupc~ oes de relogio n~ ao zeram o bit M porque esta informac~ ao e necessaria para determinar se uma pagina tera que ser reescrita no disco ou n~ ao. O algoritimo N~ ao Recentemente Usada (NRU) remove uma pagina aleatoria da classe n~ ao vazia de numerac~ ao mais baixa. A estrategia impl cita neste algoritmo e que e melhor remover uma pagina modi cada que n~ ao foi referenciada pelo menos no ultimo tick de relogio, que uma pagina n~ ao modi cada mas muito usada. As caracter sticas principais do NRU e que ele e facil de entender, e ciente de se implementar, e gera um desempenho que, enquanto certamente n~ ao otimo, e geralmente tido como adequado. O algoritmo de paginac~ ao First-In-First-Out (FIFO) e similar ao NRU. O sistema operacional mantem uma lista de todas as paginas correntes na memoria, sendo a pagina da cabeca da lista a mais velha e a pagina do m a instalada mais recentemente. Em uma falta de pagina, a pagina da cabeca e removida e a nova pagina acrescentada no m da lista. Uma simples modi cac~ ao no FIFO para evitar o problema da retirada de uma pagina muito usada e o algoritmo Segunda Chance. A ideia e primeiro examinar a pagina mais velha como uma v tima potencial. Se seu bit R e 0, a pagina e trocada imediatamente. Se o bit R e 1, o bit e zerado e a pagina e colocada no m da lista de paginas, como se estivesse acabado de chegar a memoria. Ent~ ao a pesquisa continua. O que o Segunda Chance faz e procurar por uma pagina velha que n~ ao tem sido referenciada no tick de relogio anterior. Se todas as paginas tiverem sido referenciadas, o algoritmo degenera-se e torna-se simplesmente um FIFO. Uma boa aproximac~ ao para o algoritmo otimo e baseada em uma observac~ ao comum que as paginas muito usadas nas ultimas instruc~ oes provavelmente ser~ ao usadas nas proximas instruc~ oes. Da mesma forma, paginas que n~ ao t^ em sido usadas por um longo tempo provavelmente continuar~ ao sem uso. Esta observac~ ao sugere um algoritmo realizavel: quando ocorre uma falta de pagina, retira-se a pagina que n~ ao tem sido usada por um tempo longo. Esta estrategia e chamada de Menos Recentemente Usada (Least Recently Used, LRU). Embora o algoritmo LRU seja teoricamente realizavel, seu custo e alto. Para implementac~ ao completa do LRU, e necessario manter uma lista ligada de todas as paginas em memoria, com a pagina mais recentemente usada no in cio e a menos recentemente usada no nal. A di culdade e que a lista deve
DCA/FEEC/UNICAMP 25
3.4.1 Troca Otima de Pagina
3.4.3 Troca da Pagina FIFO
3.4.2 Troca da Pagina N~ ao Recentemente Usada (NRU)
Para permitir que o sistema operacional colete estat sticas sobre quais paginas est~ ao sendo usadas e quais n~ ao est~ ao, muitos computadores com memoria virtual t^ em 2 bits associados a cada pagina. Um bit, R ou bit de refer^ encia, e ativado pelo hardware em qualquer leitura ou escrita de pagina. O outro bit, M ou bit de modi cac~ ao, e ativado pelo hardware quando ha alterac~ ao no conteudo de uma pagina. Uma vez que um bit foi ativado, ele permanece ativado ate que o sistema operacional o desative por software. Se o hardware n~ ao disp~ oe dos bits R e M, eles podem ser simulados por software atraves das rotinas de tratamento de faltas de pagina e de protec~ ao. Quando um processo e iniciado, todas as suas entradas de tabela de paginas s~ ao marcadas como ausentes na memoria. T~ ao logo uma pagina seja referenciada, uma falta de pagina ocorrera. O sistema operacional ent~ ao ativa o bit R (em sua tabela interna), muda a entrada de tabela de paginas para apontar para a pagina correta com modo READ ONLY e reinicia a instruc~ ao. Se a pagina e subsequentemente escrita, uma falta de protec~ ao da pagina ocorrera, pemitindo ao sistema operacional ativar o bit M e mudar o modo da pagina para READ/WRITE. Os bits R e M podem ser usados para construir um algoritmo de paginac~ ao como se segue. Quando um processo e iniciado, ambos os bits de pagina para todas estas paginas s~ ao declarados 0 pelo sistema operacional. Periodicamente (a cada interrupc~ ao de relogio | tipicamente 20 mseg), o bit R e zerado,
24
3.4.4 Troca da Pagina Menos Recentemente Usada (LRU)
c 1996
Ger^ encia de Memoria no UNIX 3.5]
ser atualizada em toda refer^ encia de memoria. Encontrar a pagina na lista, remov^ e-la de sua posic~ ao corrente, e mov^ e-la para o in cio representa um esforco n~ ao desprez vel. Manipular uma lista ligada a toda instruc~ ao e proibitivo, ate mesmo em hardware. Entretanto, ha outras maneiras de implementar LRU com um hardware especial. Vamos considerar o caminho mais simples primeiro. Este metodo requer equipar o hardware com um contador de 64 bits, C, que e automaticamente incrementado apos cada instruc~ ao. Alem disso, cada entrada na tabela de paginas deve tambem ter um campo grande o bastante para conter o contador. Apos cada refer^ encia de memoria, o valor corrente de C e armazenado na entrada da tabela de paginas para a pagina referenciada. Quando ocorre uma falta de pagina, o sistema operacional examina todos os contadores na tabela de paginas para achar o menor deles. A pagina correspondente e a menos recentemente usada. Agora vejamos um segundo algoritmo LRU, tambem em hardware. Para uma maquina com page frames, o LRU deve manter uma matriz de bits, inicialmente todos zero. Quando o page frame e referenciado, o hardware primeiro ativa todos os bits da linha para 1, atribuindo a todos os bits da coluna o valor 0. Em algum instante, a linha na qual o valor binario e menor, e a menos recentemente usada, a linha na qual o valor e o proximo superior e a segunda menos recentemente usada, e assim por diante.
N N N k k k
Simulac~ ao do LRU em Software

Embora os algoritmos apresentados sejam realizaveis, eles s~ ao dependentes de hardware especial, e s~ ao de pouco uso para o projetista de sistema operacional construindo um sistema para uma maquina que n~ ao disp~ oe deste hardware. Uma soluc~ ao que pode ser implementada em software faz-se necessaria. Uma possibilidade e o algoritmo chamado de N~ ao Frequentemente Usada (NFU). O algoritmo NFU requer um contador em software associado a cada pagina, inicialmente zero. Em cada tick de relogio, o sistema operacional pesquisa todas as paginas na memoria. Para cada pagina, o bit R, que e 0 ou 1, e adicionado ao contador. Em suma, os contadores s~ ao uma tentativa de guardar a frequ^ encia com que cada pagina tem sido referenciada. Quando uma falta de pagina ocorre, a pagina com o menor contador e escolhida para substituic~ ao. O principal problema com o NFU e que ele nunca esquece refer^ encias anteriores. Paginas muito (e n~ ao mais) refenciadas no comeco da execuc~ ao de um programa permanecem com um contador alto ate o nal da execuc~ ao. Felizmente, uma pequena modi cac~ ao no NFU faz com que este seja capaz de simular LRU muito bem (o algoritmo modi cado e denominado Aging ). A modi cac~ ao tem duas partes. Primeiro, os contadores s~ ao cada um deslocados 1 bit para a direita antes do bit R ser incrementado. Segundo, o bit R e incrementado no bit mais a esquerda. Quando ocorre ume falta de pagina, a pagina de menor contador e removida. E obvio que a pagina que n~ ao tenha sido referenciada por, digamos, quatro ticks de relogio tera quatro zeros signi cativos em seu contador, tendo assim um valor mais baixo que o contador de uma pagina que tenha sido referenciada nos quatro ultimos ticks de relogio. Uma diferenca entre LRU e Aging e que no ultimo os contadores t^ em um numero nito de bits (tipicamente 8). Portanto, n~ ao podemos classi car as paginas segundo refer^ encias anteriores a capacidade do contador.
demanda. Este esquema requer do hardware a possibilidade de reiniciar uma instruc~ ao interrompida pela aus^ encia de pagina cujo endereco foi referenciado na instruc~ ao. Assim que a pagina e trazida para a memoria, a instruc~ ao interrompida e reiniciada. No esquema de paginac~ ao por demanda, o espaco virtual de enderecamento e muito superior a quantidade de memoria f sica dispon vel, sendo limitado apenas pelo capacidade de enderecamento virtual da MMU. O nucleo mantem quatro estruturas principais para ns de ger^ encia de memoria: tabela de paginas, tabela de frames, descritores de blocos e tabela de uso de swap. A tabela de paginas tem como entrada o numero da pagina. Deve-se notar que esta tabela tem dimens~ ao xa pois a quantidade de paginas e igual a dimens~ ao f sica de memoria dividida pelo tamanho da pagina. Cada entrada na tabela possui campos descrevendo, entre outras informac~ oes, o endereco f sico de memoria que contem os dados referentes a pagina, a idade da pagina (i.e., por quantos ciclos esta pagina esta ativa na memoria), os ags de refer^ encia, modi cac~ ao, validade e protec~ ao. A tabela de frames armazena dados adicionais a pagina, tais como o endereco f sico de memoria que contem os dados referentes a pagina, um contador de refer^ encia indicando quantos processos compartilham esta pagina em memoria, e o numero do bloco alocado a pagina. Finalmente, a tabela de uso de swap e acessada tendo como ndice o dispositivo de swap e numero do bloco neste dispositivo. Esta tabela armazena apenas um contador de refer^ encia indicando quantas paginas se utilizam deste bloco em disco. Deve-se notar que algumas informac~ oes s~ ao replicadas em tabelas distintas. Esta replicac~ ao visa bene ciar a e ci^ encia do esquema de paginac~ ao, diminuindo o numero de consultas as tabelas. O processo paginador remove da memoria paginas n~ ao referenciadas pelos processos por um longo tempo. Quando executado, o processo vai montando uma lista de paginas candidatas a permuta (Figura 3.6). O processo paginador zera o bit de refer^ encia da pagina, como descrito na Sec~ ao 3.4.2. Uma pagina e candidata a permuta quando seu contador de refer^ encia foi zerado ha um determinado numero de passadas do processo paginador. Se uma pagina candidata a permuta e novamente referenciada, a mesma e removida da lista.
pgina referenciada (idade zerada) pgina pronta para swap pgina em memria pgina no refenciada (idade aumentando) 1 2 3 .... n
pgina em swap-in disco swap-out
Figura 3.6: Fila de paginas candidatas a permuta O processo paginador e ativado quando a quantidade de memoria dispon vel atinge um limite m nimo. Paginas s~ ao ent~ ao removidas da memoria e gravadas em disco ate que um limiar de memoria livre seja atingido. Ao gravar uma pagina em disco, o processo paginador apaga o bit de validade da pagina e decrementa seu contador de refer^ encia na tabela de frames. Se o contador de refer^ encia vai a zero (indicando que um unico processo estava utilizando a pagina), o nucleo adiciona o campo da tabela de frames referente a pagina numa lista de paginas livres. O conteudo de uma pagina na lista de paginas livres continua valido ate que o sistema associe a pagina a outro processo. Mesmo na lista de paginas livres, uma pagina
DCA/FEEC/UNICAMP 27
3.5 Ger^ encia de Memoria no UNIX

Vers~ oes anteriores ao System V e ao 4.2 BSD empregavam um esquema de permuta (swapping) de processos como pol tica de ger^ encia de memoria. Vers~ oes atuais empregam o esquema de paginac~ ao por
26
c 1996
Ger^ encia de Memoria em MS-DOS 3.6]
pode ser revalidada (sem necessidade de traz^ e-la do disco) caso um processo torne a referencia-la. Neste caso, a pagina e removida da lista de paginas livres, tendo seu bit de validade reativado.
alocac~ ao desejado | rst t, best t ou last t | e outro para indicar se a area de memoria superior deve ou n~ ao ser inclu da na busca por um bloco de memoria livre.
3.6 Ger^ encia de Memoria em MS-DOS

A ger^ encia de memoria em MS-DOS apresenta um modelo razoavelmente complexo, em parte pela arquitetura de memoria adotada pelos processadores da linha Intel 80x86 e em parte heranca de decis~ oes tomadas pela IBM para a implementac~ ao dos primeiros PCs. A complexidade imposta pela arquitetura dos processadores esta relacionada com a caracter stica de compatibilidade de codigo desenvolvido para os processadores antecessores, que deveriam ser capaz de ser executados em cada novo processador. Assim foi que, por exemplo, o 8086, apesar de ser capaz de enderecar 1 MByte de memoria, mantinha um esquema de enderecamento baseado em 16 bits a m de manter compatibilidade com codigo desenvolvido para o 8080. Desta forma, foi introduzido o conceito de segmentos com o limite maximo de 64 KBytes. Com relac~ ao as decis~ oes de projeto da IBM, decidiu-se que os primeiros 640 KBytes (a chamada area de memoria convencional ) seriam alocados ao espaco de enderecamento para programas, enquanto que o espaco de enderecamento entre 640K e 1 Mbyte (a area de memoria superior ) seria reservado para ROMs, RAM de v deo e enderecos de placas de entrada e sa da. Posteriormente (apos MS-DOS 5.0), foram introduzidos mecanismos para que processadores 80386 ou posteriores pudessem usar parte deste espaco de enderecamento | por exemplo, para alocar o programa do sistema operacional, drivers de dispositivos e programas TSR. Pelo esquema de segmentac~ ao do processador, e poss vel que um endereco seja gerado para o espaco de 64 KBytes acima de 1 MByte. Este espaco tem o nome de area de memoria alta, ou HMA. Esta area pode ou ser mapeada para receber o programa do sistema operacional ou, em caso de sistemas que mantem compatibilidade estrita com o processador 8088, ser um espaco que equivale sicamente ao primeiro bloco de 64K, entre os enderecos 0 e 65519. Processadores posteriores ao 8088 podiam ter mais de 1 MByte de memoria f sica | 16M para o 80286 e 4 GBytes para 80386 e posteriores. A memoria acima de 1M e chamada de memoria estendida. MS-DOS n~ ao pode fazer uso diretamente desta area de memoria, uma vez que ele e executado no chamado modo real do processador, que limita acesso ao primeiro megabyte apenas. Foram ent~ ao desenvolvidos aplicativos que permitiam usar este espaco em MS-DOS como discos RAM e cache de bu ers, tais como RAMDRIVE.SYS e SMARTDRV.SYS, respectivamente. A m de se vencer a barreira de 640K com MS-DOS, dois esquemas foram de nidos. O sistema operacional suporta um esquema em software, atraves de chamadas de sistemas que permitem a execuc~ ao de programas em overlays. O outro esquema, em hardware, partiu de um consorcio entre Lotus, Intel e Microsoft para desenvolver um esquema alternativo de memoria. Este esquema foi denominado sistema de memoria expandida (EMS), que permitiu que mesmo um processador 8088 pudesse utilizar grandes memorias f sicas. Neste caso, a memoria esta sicamente alocada em placas de extens~ ao de memoria (desenvolvidas pela Intel), e pode ser acessada por aplicativos como Lotus 1-2-3 e o proprio MS-DOS. A placa de memoria expandida contem registros que mapeiam um espaco de enderecamento virtual de 640K para a memoria sicamente maior, permitindo que programas trabalhassem com dados acima do limite de 640 KBytes. Em processadores 80386 e posteriores, o proprio hardware suporta o mecanismo de paginac~ ao necessario, e a memoria estendida pode ser utilizada para simular a memoria expandida sem necessidade de placas especiais. MS-DOS suporta chamadas do sistema para alocar e liberar blocos de memoria, assim como para modi car o tamanho de um bloco ja alocado. Ha tambem um mecanismo para especi car o tipo de
28
c 1996
DCA/FEEC/UNICAMP
29
Sistema de Arquivos
Projeto do Sistema de Arquivos 4.2]
Cap tulo 4 Sistema de Arquivos

A parte mais vis vel de um sistema operacional e o seu sistema de arquivos. Programas aplicativos utilizam o sistema de arquivos (atraves de chamadas de sistema) para criar, ler, gravar e remover arquivos. Usuarios utilizam interativamente o sistema de arquivos (atraves de shell ) para listar, alterar propriedades e remover arquivos. A conveni^ encia e facilidade de uso de um sistema operacional e fortemente determinada pela interface, estrutura e con abilidade de seu sistema de arquivos. Do ponto de vista do usuario, o aspecto mais importante do sistema de arquivos e como ele se apresenta, isto e, o que constitui um arquivo, como os arquivos s~ ao identi cados e protegidos, que operac~ oes s~ ao permitidas sobre os arquivos, e assim por diante. Para o projetista do sistema, por outro lado, a preocupac~ ao e como organizar e gerenciar arquivos de forma a garantir boa ocupac~ ao do espaco em disco e bom desempenho nas operac~ oes sobre arquivos.
Em muitos sistemas, arquivos regulares s~ ao subdivididos em diferentes tipos em func~ ao de sua utilizac~ ao. Os tipos s~ ao identi cados pelos nomes com que os arquivos regulares terminam | por exemplo, arquivo.c denotando um programa fonte em C e arquivo.obj para um arquivo objeto. Em alguns sistemas, as extens~ oes s~ ao simples convenc~ ao, representando apenas uma facilidade para o usuario identi car o tipo de conteudo no arquivo. Em outros, o sistema operacional tem regras r gidas em relac~ ao aos nomes | por exemplo, \o sistema n~ ao executara um arquivo a menos que sua extens~ ao seja .BIN." Diretorios, os quais em muitos casos s~ ao tambem arquivos, permitem organizar os arquivos de um sistema. Um diretorio contem tipicamente um registro por arquivo. Sistemas primitivos admitiam um unico diretorio compartilhado por todos os usuarios, ou um unico diretorio por usuario. Os sistemas operacionais modernos permitem um numero arbitrario de diretorios por usuario (em geral, formando uma hierarquia). Quando o sistema de arquivos e organizado como uma arvore de diretorios, algum meio se faz necessario para especi car nomes de arquivos. Dois metodos s~ ao comumente empregados. No primeiro metodo, cada arquivo e identi cado pela sequ^ encia de diretorios desde o diretorio raiz ate o arquivo (caminho absoluto). Nomes absolutos para caminhos sempre comecam na raiz e s~ ao unicos. Uma outra forma de especi car nomes de arquivos e atraves de seu caminho relativo. E usado em conjunto com o conceito de diretorio de trabalho (ou diretorio corrente). Um usuario pode designar um diretorio como diretorio corrente. Neste caso, todos os caminhos s~ ao referenciados a partir do diretorio corrente.
4.2 Projeto do Sistema de Arquivos

Examinaremos agora o sistema de arquivos do ponto de vista do projetista de sistemas operacionais. Uma das grandes preocupac~ oes associadas com a manipulac~ ao de sistemas de arquivos refere-se ao desempenho. Discos s~ ao organizados em cilindros, os quais s~ ao compostos de trilhas, que por sua vez s~ ao compostos por setores. Um acesso ao disco envolve movimentac~ ao de partes mec^ anicas para o posicionamento na trilha desejada e a transfer^ encia dos setores contendo dados, sendo que a taxa de transfer^ encia esta associada a velocidade de rotac~ ao do disco. Como estes tempos s~ ao muito mais lentos que a velocidade de processamento, um acesso ine ciente pode tornar a utilizac~ ao do sistema demasiadamente baixa.
4.1 Interface do Sistema de Arquivos

A maior parte dos sistemas operacionais traz a seguinte proposta para armazenagem de informac~ ao: permitir aos usuarios de nir objetos chamados arquivos, que podem armazenar programas, dados, ou qualquer outra informac~ ao. Estes arquivos n~ ao s~ ao parte enderecavel de nenhum processo e o sistema operacional suporta operac~ oes especiais (chamadas de sistema) para criar, destruir, ler, atualizar e proteger arquivos. Todos os sistemas operacionais visam uma independ^ encia dos dispositivos de armazenagem, permitindo acessar um arquivo sem especi car em qual dispositivo o mesmo se encontra sicamente armazenado. Um programa que l^ e um arquivo de entrada e escreve um arquivo de sa da deve ser capaz de operar com arquivos armazenados em quaisquer dispositivos, sem necessidade de um codigo especial para explicitar o tipo de periferico. Alguns sistemas operacionais suportam maior independ^ encia dos dispositivos de armazenagem que outros. No Unix, por exemplo, um sistema de arquivos pode ser montado em qualquer dispositivo de armazenagem, permitindo que qualquer arquivo seja acessado pelo seu nome (path name) sem considerar o dispositivo f sico. No MS-DOS, o usuario deve especi car em qual dispositivo cada arquivo se encontra (exceto quando um dispositivo e default e for omitido). A maior parte dos sistemas operacionais suportam varios tipos de arquivos | por exemplo, arquivos regulares, diretorios e arquivos especiais. Arquivos regulares contem dados e programas do usuario. Diretorios permitem identi car arquivos atraves de nomes simbolicos (sequ^ encia de caracteres ASCII). Arquivos especiais s~ ao usados para especi car perifericos tais como terminais, impressoras e unidades de ta.
30
4.2.1 Ger^ encia de Espaco em Disco

Arquivos s~ ao normalmente armazenados em disco, sendo portanto a ger^ encia do espaco em disco de maior interesse do projetista. Duas estrategias s~ ao poss veis para armazenagem em um arquivo com bytes: bytes consecutivos do disco s~ ao alocados ou o arquivo e dividido em um numero de blocos n~ ao necessariamente cont guos1. Quando blocos de tamanho xo s~ ao adotados, e necessario de nir qual o tamanho do bloco. Uma unidade de alocac~ ao grande, tal como um cilindro, implica que muitos arquivos, ate mesmo arquivos de 1 byte, dever~ ao ocupar o cilindro inteiro. Por outro lado, usar uma unidade de alocac~ ao pequena signi ca que cada arquivo tera muitos blocos, o que pode prejudicar o desempenho de acesso. E compromisso usual escolher um bloco de tamanho entre 512 e 4K bytes. Se um bloco de tamanho 1K for escolhido em um disco com setor de 512 bytes, ent~ ao o sistema de arquivo sempre ira ler ou escrever em dois setores consecutivos, e trata-los como uma unidade indivis vel.
n n
A mesma pol tica esta presente no sistema de ger^ encia de memoria entre a segmentac~ ao pura e a paginac~ ao.
c 1996
DCA/FEEC/UNICAMP
31
Sistema de Arquivos
42 136 45 127 65 254 321 342 123 415 239 124 432 58 490 643 486 12 43 481 971 7 99 640 589 737 872 543 321 13
Projeto do Sistema de Arquivos 4.2]

1001001001011001 0000100100011000 0011001110100100 1000000100001001 0000000000001000
A escolha da estrategia de alocac~ ao de um arquivo no disco traz impactos no desempenho e exibilidade de acesso aos dados armazenados. A seguir, estes impactos ser~ ao analisados para as diversas possibilidades de organizac~ ao. tamanho s~ ao as unicas informac~ oes necessarias para permitir o acesso ao seu conteudo. A transfer^ encia dos dados, uma vez que o posicionamento inicial ja tenha sido completado, e rapido, pois envolve requer mudancas m nimas de posicionamento. Entretanto, armazenar um arquivo como uma sequ^ encia cont gua de bytes apresenta um problema obvio que e o crescimento do arquivo, uma ocorr^ encia muito comum | o arquivo provavelmente tera que ser movido no disco. Embora o problema seja o mesmo que ocorre em ger^ encia de memoria por segmentac~ ao, neste caso o impacto no desempenho e muito maior. possibilidade de se conectar os blocos de um mesmo arquivo e atraves da manutenc~ ao de apontadores de um bloco para o proximo. Assim, em cada bloco a primeira palavra indica qual o proximo bloco da lista, e o restante e a area de dados. A grande vantagem desta estrategia e evitar a fragmentac~ ao que ocorre no uso de alocac~ ao cont gua. No entanto, acessos a posic~ oes arbitrarias do arquivo (o chamado acesso aleatorio ) s~ ao lentos, uma vez que diversos blocos podem ter que ser lidos para alcancar a posic~ ao do dado desejado. um ndice (ou tabela) que e trazido a memoria principal. Desta forma, percorrer uma lista de blocos para alcancar uma posic~ ao arbitraria torna-se uma operac~ ao rapida, que e realizada sem acessos ao disco. A desvantagem deste metodo e que todo o ndice deve ser alocado a memoria principal, o que pode ocupar um espaco consideravel de memoria para discos com grande capacidade.
Alocac~ ao Cont gua Nesta estrategia, a posic~ ao inicial onde o arquivo esta armazenado no disco e seu
0100001100000011 1111000011000010 (b)
410 312
654 318 (a)
597 873
Listas Ligadas de Blocos Quando a estrategia de alocac~ ao em blocos e adotada, uma primeira
Figura 4.1: Organizac~ ao de blocos livres: (a) blocos livres armazenados em lista ligada (b) um mapa de bits. Antes de um arquivo ser manipulado, ele deve ser aberto. Quando um arquivo e aberto, o sistema operacional usa o nome do arquivo para buscar as informac~ oes necessarias para prosseguir com as operac~ oes de acesso ao arquivo. Estas informac~ oes adicionais s~ ao mantidas nos arquivos diretorios. A estrategia de organizac~ ao de arquivos em diretorios mais simples e manter um diretorio unico. Assim, a localizac~ ao de um arquivo reduz-se a procura neste unico diretorio. Encontrado o registro do arquivo, tem-se o numero de blocos do disco, posto que estes s~ ao armazenados no proprio registro. Se o arquivo utiliza mais blocos de disco que o permitido no registro, o arquivo tera registros adicionais no diretorio. Informac~ oes usualmente mantidos s~ ao nome, tipo, usuario (durante a busca, apenas os registros pertencentes ao usuario corrente s~ ao considerados), tamanho e contador de bloco (indica qual bloco esta em uso). Campos adicionais cont^ em os numeros dos blocos de disco que comp~ oem o arquivo. Outra estrategia e a organizac~ ao de sistemas de diretorio em arvore (hierarquicos). Neste caso, todo diretorio (exceto o raiz) e um arquivo. Quando um arquivo e aberto, o sistema de arquivos recebe o nome de arquivo fornecido e localiza seus blocos no disco. Para nomes absolutos, primeiro o sistema de arquivo localiza o diretorio raiz, que e mantido em um lugar xo no disco. Ent~ ao, procura-se pelo arquivo (diretorio) que e o primeiro componente do caminho, e neste diretorio procura pelo proximo componente, ate encontrar a entrada para o arquivo sendo aberto. Nomes de caminhos relativos s~ ao pesquisados de forma id^ entica, apenas partindo do diretorio de trabalho em vez de partir-se do diretorio raiz. Todos os diretorios t^ em registros para . e .., criados juntamente com o diretorio, para indicar respectivamente o diretorio corrente e o diretorio pai. Nenhum mecanismo especial e necessario para manipular estes nomes. N~ ao raro, e conveniente que um mesmo arquivo (ou diretorio) pertenca simultaneamente a diferentes usuarios. A associac~ ao entre um diretorio e um arquivo pertencente a outro diretorio e chamada de conex~ ao ou link. O sistema de arquivos passa a ser organizado como um grafo, e n~ ao mais como uma arvore. Uma possibilidade de suportar o compartilhamento de arquivos e manter um link simbolico. Por exemplo, digamos que um arquivo X em um diretorio D1 deve tambem ser visto por um diretorio D2. O link simbolico sera uma entrada no diretorio D2 com o nome X, mas marcada como sendo um tipo especial de arquivo (link) e cuja informac~ ao associada e o nome absoluto do arquivo compartilhado original (/D1/X).
DCA/FEEC/UNICAMP 33
4.2.2 Estrutura de Diretorio
Listas Ligadas com Indice Nesta estrategia, os apontadores para proximo bloco s~ ao mantidos em
Nos Indices Neste caso, cada arquivo tem uma pequena tabela de ndices chamada de i-node que
mantem os enderecos em disco dos blocos que comp~ oem o arquivo. Quando um arquivo e aberto pela aplicac~ ao, o seu no ndice e lido para a memoria. Os enderecos dos primeiros blocos do arquivo s~ ao mantidos no proprio i-node, de forma que o acesso a pequenos arquivos e e ciente. Os ultimos enderecos do i-node n~ ao apontam diretamente para blocos de dados, mas para blocos contendo enderecos de outros blocos. Em geral, ha um apontador para enderecos indiretos simples (o bloco apontado contem enderecos de blocos de dados), outro para enderecos indiretos duplos (o bloco apontado contem enderecos de blocos que apontam para blocos de dados) e outro para enderecos indiretos triplos (para encontrar o endereco do bloco de dados tr^ es n veis de ndice t^ em de ser acessados). Apenas arquivos muito grandes precisariam usar este ultimo n vel de acesso indireto. sobre blocos livres no disco | informac~ ao que sera fundamental quando a aplicac~ ao requisitar a escrita de dados em arquivos. Dois metodos s~ ao amplamente usados (Figura 4.1). O primeiro consiste no uso de uma lista ligada de blocos, com cada elemento da lista armazenando tantos blocos livres quanto poss vel. Uma outra tecnica de ger^ encia de espaco livre e o mapa de bits. Um disco com blocos necessita de um mapa de bits com bits. Blocos livres s~ ao representados por 1s no mapa de bits blocos alocados por 0s (ou vice-versa). Para um disco cheio (com poucos blocos livres) a lista ligada necessita de menos espaco que o mapa de bits.
n n
Ger^ encia de Espaco Livre Outra quest~ ao importante para o projetista e como manter a informac~ ao
32
c 1996
Sistema de Arquivos
O Sistema de Arquivos do Unix 4.3]
Outra possibilidade depende da utilizac~ ao de nos ndice para a organizac~ ao de arquivos no disco. Neste caso, a entrada do diretorio armazena apenas o apontador para o no ndice do arquivo compartilhado, e o no ndice deve manter um contador de quantas refer^ encias s~ ao feitas ao arquivo (de modo a garantir consist^ encia apos operac~ oes de remoc~ ao). Considerando a import^ ancia da informac~ ao mantida em discos, deve ser uma preocupac~ ao do projetista de um sistema de arquivos o aspecto de con abilidade deste sistema.
livres rastreando todos os blocos que n~ ao est~ ao em uso. Cada ocorr^ encia de um bloco na lista de blocos livres resulta no incremento do segundo contador. Se o sistema de arquivo for consistente, cada bloco tera o valor 1 em um contador e 0 no outro. Contudo, em caso de falha, pode detectar-se as seguintes situac~ oes:
4.2.3 Con abilidade do Sistema de Arquivos
Blocos perdidos: 0 em ambos contadores, ou seja, blocos que n~ ao ocorrem em nenhuma das tabelas.
A soluc~ ao para blocos perdidos e simples: o veri cador do sistema de arquivos acrescenta-os na lista de blocos livres. lista livre.
Bloco livre e ocupado: 1 em ambos contadores. A soluc~ ao tambem e simples: remover o bloco da Blocos multiplamente livres: 0 no contador de blocos ocupados e um valor maior que 1 no contador Blocos multiplamente ocupados: 0 no contador de blocos livres e um valor maior que 1 no contador
de blocos livres. A soluc~ ao neste caso tambem e simples: reconstruir a lista de blocos livres, eliminando-se as duplicac~ oes.
Blocos Defeituosos Discos frequentemente apresentam blocos defeituosos (bad blocks), isto e, blocos
onde a escrita e/ou leitura e impossibilitada. Duas soluc~ oes para o problema de blocos defeituosos s~ ao empregadas, uma em hardware e outra em software. A soluc~ ao em hardware consiste em dedicar um setor no disco para a lista de blocos defeituosos. Quando o controlador do disco e iniciado, este l^ ea lista de blocos defeituosos e escolhe blocos sobressalentes para substitu -los. S~ ao feitas ent~ ao indirec~ oes dos blocos defeituosos para os blocos sobressalentes. Da por diante, qualquer operac~ ao envolvendo um bloco defeituoso tera efeito em seu respectivo bloco sobressalente. A soluc~ ao em software requer que o usuario informe (ou que o sistema de arquivos detecte) os blocos defeituosos. Estes blocos s~ ao encadeados como se fosse um arquivo do sistema, de modo que eles n~ ao far~ ao parte da lista de blocos livres.
Backups Mesmo com uma estrategia engenhosa para tratar os blocos defeituosos, e importante se
de blocos ocupados. Este e o tipo de falha mais grave. A ac~ ao apropriada do utilitario e alocar um bloco livre, copiar o conteudo do bloco duplicado nele, e inserir a copia em um dos arquivos. Desde modo, a informac~ ao dos arquivos n~ ao e alterada (embora certamente incorreta para um dos arquivos), mas a estrutura do sistema de arquivos e, pelo menos, consistente. O erro sera informado para permitir ao usuario examinar a falha.
proceder backups frequentes. Sistemas de arquivos em discos de pequena capacidade podem ser salvos em ta magnetica, por exemplo, tas padr~ ao de 9 trilhas (com capacidade de 50 Megabytes por bobina) ou ta de 8 mm (com capacidade de ate 4 Gigabytes). Para discos de grande capacidade, salvar o conteudo inteiro em tas e inconveniente e consome muito tempo. Uma alternativa e o backup incremental. Em sua forma mais simples, copia-se para ta todos os arquivos a cada semana ou m^ es, e, diariamente, apenas daqueles arquivos que foram modi cados deste o ultimo backup completo. Num outro esquema, mais e ciente, copia-se apenas aqueles arquivos que foram alterados desde o ultimo backup. Para implementar este metodo, o horario da ultima duplicac~ ao para cada arquivo deve ser mantida no disco.
4.3 O Sistema de Arquivos do Unix

Todo arquivo no Unix System V contem um unico i-node. O i-node possui as informac~ oes necessarias para um processo acessar um arquivo, tais como: proprietario do arquivo, direito de acesso, tamanho do arquivo e localizac~ ao dos dados do arquivo no sistema de arquivos. A refer^ encia a um arquivo e feita pelo seu nome e, atraves deste, o nucleo determina o i-node do arquivo. Um i-node existe estaticamente no disco e o nucleo realiza a sua leitura para a memoria quando necessita manipula-lo. O i-node no disco contem os seguintes campos (Figura 4.2): identi cador do dono do arquivo: dividido em dono individual e grupo tipo do arquivo: regular, diretorio, especial ou FIFO (pipes) permiss~ ao de acesso instantes de acesso ao arquivo: ultima modi cac~ ao, ultimo acesso e ultima modi cac~ ao ocorrida no i-node numero de conex~ oes (links) associados ao arquivo enderecos no disco dos blocos de dados do arquivo tamanho do arquivo. A indicac~ ao dos blocos do disco que constituem um determinado arquivo encontra-se no i-node associado ao arquivo. Esta indicac~ ao traduz-se na utilizac~ ao de 13 numeros para blocos. Os 10 primeiros
DCA/FEEC/UNICAMP 35
4.2.4 Consist^ encia do Sistema de Arquivos
Outro topico envolvendo con abilidade e a consist^ encia do sistema de arquivos. Muitos sistemas de arquivos l^ eem blocos, modi cam-nos, e os regravam mais tarde. Se o sistema falha antes que todos os blocos modi cados sejam escritos no disco, o sistema de arquivos assume um estado inconsistente. Este problema e especialmente cr tico se alguns dos blocos que n~ ao foram escritos, s~ ao blocos de i-nodes, blocos de diretorio, ou blocos contendo a lista de blocos livres. Para veri car a consist^ encia do sistema de arquivos, muitos sistemas operacionais utilizam programas utilitarios desenvolvidos para este m. Tais programas s~ ao executados sempre que o sistema e iniciado, particularmente depois de um desligamento abrupto. Para controle de consist^ encia a n vel de blocos, o utilitario constroi uma tabela com dois contadores por bloco, ambos iniciados em 0. O primeiro contador rastreia quantas vezes o bloco aparece referenciado por algum arquivo o segundo contador registra com que frequ^ encia ele aparece na lista de blocos livres. O utilitario acessa a informac~ ao de todos os arquivos, incrementando o primeiro contador para a ocorr^ encia de cada bloco que faz parte de cada arquivo. A seguir, e examinada a lista de blocos
34
c 1996

ponteiro para blocos de dados
Sistema de Arquivos
Sistemas de Arquivos do MS-DOS 4.4]
open: abre um arquivo para leitura/gravac~ ao. Par^ ametros da chamada indicam, por exemplo, se o
arquivo deve ser criado (caso inexista) e permiss~ oes. close: encerra a operac~ ao sobre um arquivo aberto. read: l^ e dados de um arquivo (para um bu er em memoria). write: escreve dados num arquivo (de um bu er em memoria). lseek: altera a posic~ ao corrente de leitura/gravac~ ao no arquivo. chdir: altera o diretorio corrente. chown: altera o usuario que t^ em a posse do arquivo. chmod: altera permiss~ oes de um arquivo. stat: fornece informac~ oes sobre um arquivo (tipicamente as constantes no i-node do arquivo).
INODE arquivo numeros de links identificador do proprietrio grupo do proprietrio tamanho do arquivo data da criao data do ltimo acesso data da ltima modificao
ponteiro para 10 blocos de dados
bloco indireto simples bloco indireto duplo bloco indireto triplo
4.4 Sistemas de Arquivos do MS-DOS

Discos em MS-DOS s~ ao organizados como se segue. O primeiro setor do disco e reservado para o codigo de boot. Apos o setor de boot vem a Tabela de Alocac~ ao de Arquivos (FAT), que e um ndice para uma lista ligada de blocos. Blocos livres s~ ao marcados com um codigo especial nesta tabela. A Figura 4.3 ilustra a organizac~ ao da FAT no MS-DOS. Figura 4.2: Estrutura de i-node numeros (blocos diretos) contem numeros para blocos de disco os tr^ es numeros seguintes indicam respectivamente apontadores indireto simples, indireto duplo e indireto triplo. Os processos enxergam o arquivo como um conjunto de bytes comecando com o endereco 0 e terminando com o endereco equivalente ao tamanho do arquivo menos 1. O nucleo converte esta vis~ ao dos processos em termos de bytes em uma vis~ ao em termos de blocos: o arquivo comeca com o bloco 0 (apontado pelo primeiro numero de bloco no i-node ) e continua ate o numero de bloco logico correspondente ao tamanho do arquivo. Quando da abertura de um arquivo, o sistema operacional utiliza o nome (path) do arquivo fornecido pelo usuario para localizar os blocos do disco associados ao arquivo. O mapeamento do nome nos i-nodes esta associado a forma como o sistema de diretorio encontra-se organizado. A estrutura de diretorio usada no Unix e extremamente simples. Cada entrada contem o nome do arquivo e o numero do seu i-node. Todos os diretorios do Unix s~ ao arquivos e podem conter um numero arbitrario destas entradas. Quando um arquivo e aberto, o sistema deve, atraves do nome do arquivo, localizar os seus blocos no disco. Caso o nome do arquivo seja relativo, o nucleo acessa primeiro o i-node associado ao diretorio corrente. Cada arquivo no Unix e identi cado por um descritor de arquivos (um numero inteiro). Descritores de arquivos identi cam arquivos univocamente a n vel de processo, isto e, dois arquivos abertos pelo mesmo processo possuem descritores necessariamente diferentes. Rotinas do nucleo do sistema operacional operam com estes descritores. As principais chamadas de sistema referentes ao sistema de arquivos s~ ao:
36
FAT x x EOF 13 2 9 8 FREE 4 12 3 FREE EOF EOF EOF BAD 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
10 3 13 5 9 12
} tamanho do disco
Figura 4.3: Estrutura da FAT Cada entrada no diretorio tem 32 bytes, dos quais 11 s~ ao reservados para o nome e extens~ ao do arquivo. Um byte de atributos descreve o tipo e propriedades do arquivo. Hora e data da ultima atualizac~ ao ocupam dois bytes cada. Os dois ultimos campos indicam o endereco do primeiro bloco (2
DCA/FEEC/UNICAMP 37
c 1996
bytes) e o tamanho do arquivo (4 bytes). A partir do primeiro bloco, os demais s~ ao localizados a partir da Tabela de Alocac~ ao de Arquivos.
Cap tulo 5 Entrada e Sa da

Uma das func~ oes do sistema operacional e controlar todos os dispositivos de entrada e sa da (E/S) do computador, emitindo comandos para os dispositivos, atendendo interrupc~ oes e manipulando erros. Deve tambem prover uma interface entre os dispositivos e o resto do sistema, que seja simples e facil de usar (se poss vel, a interface deve ser a mesma para todos os dispositivos). O codigo de entrada e sa da representa uma frac~ ao signi cativa do total do sistema operacional. A forma como o sistema operacional gerencia E/S e o objeto deste cap tulo.
5.1 Princ pios do Hardware

Diferentes indiv duos v^ eem o hardware de E/S de diferentes maneiras. Engenheiros eletr^ onicos v^ eem em termos de chips, os, fontes de pot^ encia, motores e todos os outros componentes f sicos que constituem em conjunto o hardware. Programadores v^ eem como a interface apresentada ao software, os comandos que o hardware aceita, as func~ oes que ele suporta, e os erros que s~ ao reportados. O nosso interesse aqui e restringir em como o hardware e programado, e n~ ao como ele trabalha internamente. Dispositivos de E/S podem ser grosseiramente divididos em duas categorias: dispositivos de bloco e dispositivos de caracter. Um dispositivo de bloco armazena informac~ oes em blocos de tamanho xo, cada um com seu proprio endereco. Tamanhos comuns de blocos est~ ao na faixa de 128 bytes a 4096 bytes. A propriedade essencial dos dispositivos de bloco e que e poss vel ler ou escrever cada bloco independentemente de todos os outros. Em outras palavras, em qualquer instante, o programa pode ler ou escrever qualquer um dos blocos. Discos s~ ao dispositivos de bloco. O outro tipo de dispositivo de E/S, o de caracter, libera ou aceita uma la de caracteres sem estrutura. Ele n~ ao e enderecavel e n~ ao aceita operac~ oes de busca. Terminais, impressoras, leitora optica e outros dispositivos que n~ ao trabalham como os discos s~ ao exemplos de dispositivos de caracter. Este esquema de classi cac~ ao n~ ao e perfeito. Alguns dispositivos n~ ao s~ ao enquadrados nele. Relogios, por exemplo, n~ ao s~ ao enderecaveis por bloco. Nem geram ou aceitam las de caracteres. Tudo o que fazem e gerar interrupc~ oes em intervalos regulares. Contudo, este modelo e geral o su ciente para ser usado como base na construc~ ao de um sistema operacional com bom n vel de independ^ encia dos dispositivos de E/S. O sistema de arquivo, por exemplo, negocia apenas com dispositivos de blocos abstratos, e deixa a parte dependente do dispositivo para o software de mais baixo n vel, chamado acionadores de dispositivos (device drivers).
38
5.1.1 Dispositivos de E/S
c 1996
DCA/FEEC/UNICAMP
39
Entrada e Sa da
Princ pios do Software 5.2]
Unidades de E/S consistem tipicamente de componentes mec^ anicos e eletr^ onicos. E frequente a separac~ ao das duas porc~ oes para se obter um projeto mais geral e modular. O componente eletr^ onico e chamado de controlador do dispositivo (device controller ou adapter). Em mini e microcomputadores, ele normalmente toma forma de um circuito impresso que pode ser inserido no computador. O componente mec^ anico e o dispositivo propriamente dito. O cart~ ao do controlador normalmente tem um conector, no qual um cabo condutor do proprio dispositivo pode ser conectado. Muitos controladores podem manusear dois ou mais dispositivos do mesmo tipo. A distinc~ ao entre dispositivo e controlador deve ser ressaltada, ja que o sistema operacional v^ eo controlador, n~ ao o dispositivo. Normalmente, minicomputadores e microcomputadores usam um barramento unico (Figura 5.1) para comunicac~ ao entre CPU e os controladores. Mainframes frequentemente usam um modelo diferente, no qual multiplos barramentos e computadores especializados de E/S, chamados canais de E/S, aliviam parte da carga da CPU.
unidades de disco
5.1.2 Controladores de Dispositivos
disquete do IBM PC, por exemplo, aceita 15 diferentes comandos, tais como read, write, seek, format, e recalibrate. Muitos dos comandos t^ em par^ ametros, os quais s~ ao tambem carregados nos registradores do controlador. Quando um comando e aceito, a CPU pode abandonar o controlador atender a outra tarefa. Quando completado, o controlador causa uma interrupc~ ao com o objetivo de permitir que o sistema operacional tome o controle da CPU e teste o resultado da operac~ ao. A CPU obtem o resultado e o status do dispositivo pela leitura de um ou mais bytes de informac~ ao nos registradores do controlador.
5.2 Princ pios do Software

Os objetivos gerais do software de E/S s~ ao faceis de serem estabelecidos. A ideia basica e organizar o software como uma serie de camadas, com as mais baixas escondendo peculiaridades do hardware e as mais altas mostrando-se simples para o usuario.
5.2.1 Objetivos do Software de E/S

O conceito chave no projeto do software de E/S e a independ^ encia do dispositivo. Deve ser poss vel escrever programas que usem arquivos gravados em disquete ou em disco r gido, sem a necessidade de modi car o programa para cada tipo de dispositivo. De prefer^ encia, deve ser poss vel utilizar o programa sem recompila-lo. Relacionado com a independ^ encia do dispositivo esta a uniformidade de nome. O nome de um dispositivo ou arquivo deve ser simplesmente uma cadeia de caracteres (string) ou um inteiro n~ ao dependente do dispositivo em nenhum caso. Outra caracter stica importante e a manipulac~ ao de erros. Em geral os erros devem ser manipulados o mais proximo poss vel do hardware. Se o controlador encontra um erro, ele deve tentar corrig -lo, se poss vel. Se n~ ao, o driver do dispositivo deve faz^ e-lo, talvez apenas tentando ler novamente. Muitos erros s~ ao transientes e desaparecem se a operac~ ao for repetida. Somente se as camadas mais baixas n~ ao conseguirem resolver o problema e que este deve ser apresentado as camadas superiores. Transfer^ encias podem ser s ncronas (blocos) e ass ncronas (manipuladas por interrupc~ ao). Muitos dispositivos de E/S s~ ao ass ncronos: a CPU inicia a transfer^ encia e se ocupa de outras atividades ate que chegue uma interrupc~ ao. O sistema operacional realiza as operac~ oes de forma ass ncrona, mas para o usuario ela se apresenta como transfer^ encia de blocos (o que torna muito mais simples a programac~ ao). Alguns dispositivos de E/S, como discos, podem ser utilizados por muitos usuarios ao mesmo tempo. Outros dispositivos, como impressoras, devem ser dedicados a um unico usuario ate que este nalize a operac~ ao. A inclus~ ao de dispositivos dedicados introduz uma variedade de problemas, como o deadlock. Sistemas operacionais devem manipular os dispositivos de maneira a evitar estes problemas. Estes objetivos podem ser organizados de maneira clara e e ciente pela estruturac~ ao do software em quatro camadas: 1. Manipulac~ ao de interrupc~ oes. 2. Drivers de dispositivos. 3. Software do sistema operacional independente do dispositivo. 4. Software do n vel do usuario.
DCA/FEEC/UNICAMP 41
impressora interface controlador-dispositivo controlador de disco controlador de impressora outros controladores
CPU
memria
barramento
Figura 5.1: Um modelo para conex~ ao da CPU, memoria, controladores e dispositivos de E/S A interface entre o controlador e o dispositivo e, via de regra, uma interface de baixo n vel. O disco, por exemplo, pode ser formatado com 8 setores de 512 bytes por trilha. O que realmente sai do driver, entretanto, e uma lista serial de bits, partindo com um pre^ ambulo, depois os 4096 bits no setor, e nalmente o checksum ou o codigo de correc~ ao de erro. O pre^ ambulo e escrito quando o disco e formatado, e contem o numero de cilindros e de setores, o tamanho do setor, e outros dados. A tarefa do controlador e converter a lista serial de bits em um bloco de bytes e realizar alguma correc~ ao de erro necessaria. O bloco de bytes e tipicamente primeiro montado, bit por bit, em um bu er mantido no controlador. Apos o checksum ter sido veri cado e o bloco declarado livre de erro, ele pode ent~ ao ser copiado para a memoria principal. O controlador para o terminal CRT tambem trabalha como um dispositivo serial de bits e em baixo n vel. Ele l^ e da memoria o byte contendo o caracter a ser exibido, e gera os sinais usados na modulac~ ao do feixe do CRT para causar a escrita na tela. O controlador tambem gera os sinais para o feixe CRT fazer o retrace horizontal apos ele ter terminado de esquadrinhar a linha, como tambem sinais para fazer o retrace vertical apos a tela toda ter sido esquadrinhada. Se n~ ao tivessemos um controlador CRT, o sistema operacional teria que gerar estes sinais no tubo. Com o controlador, o sistema operacional inicia-o com poucos par^ ametros, tais como o numero de caracteres por linha e o numero de linhas por tela, deixando o controlador tomar conta do direcionador do feixe de raios catodicos. Cada controlador tem alguns poucos registradores que s~ ao usados para comunicac~ ao com a CPU. Em alguns computadores estes registradores s~ ao parte do espaco de enderecamento regular. O sistema operacional realiza E/S escrevendo comandos nos registradores dos controladores. O controlador de
40
c 1996
Entrada e Sa da
Princ pios do Software 5.2]
5.2.2 Manipuladores de Interrupc~ oes

Interrupc~ oes s~ ao eventos complexos, que devem ser isolados de modo que apenas uma pequena parte do sistema operacional os manipule. Um meio para isolar o tratamento de interrupc~ oes e bloquear os processos aguardando operac~ oes de E/S ate que uma interrupc~ ao anuncie que a operac~ ao se completou. Quando a interrupc~ ao acontece, a rotina de tratamento daquela interrupc~ ao libera o processo bloqueado atraves do envio de uma mensagem. Em alguns sistemas, isto e conseguido fazendo-se um UP sobre um semaforo. Seja qual for a forma adotada, o efeito da interrupc~ ao e que o processo que estava previamente bloqueado devera agora estar habilitado para execuc~ ao.
5.2.3 Drivers de Dispositivos

Todo o codigo dependente do dispositivo aparece no driver do dispositivo. Cada driver manipula um dispositivo ou uma classe de dispositivos intimamente relacionados. Foi visto que cada controlador de dispositivos tem registradores para receber comandos. O driver do dispositivo envia estes comandos e testa se foram carregados propriamente. Desta maneira, o driver e a parte do sistema operacional que conhece quantos registradores tem, por exemplo, o controlador de disco e para que estes s~ ao utilizados. Ele reconhece setores, trilhas, cilindros, cabecas de leitura/escrita, motor, fator de entrelacamento e todos os mecanismos que fazem um disco trabalhar propriamente. Em termos gerais, o trabalho de um driver e aceitar requisic~ oes abstratas de um software de mais alto n vel, e providenciar para que o pedido seja atendido. Uma t pica requisic~ ao e ler um bloco. Se o driver esta desocupado no momento, a requisic~ ao e aceita, sendo processada imediatamente. Caso o driver esteja processando uma requisic~ ao, esta normalmente entra numa la de requisic~ oes pendentes. O primeiro passo e transcrever os termos abstratos da requisic~ ao para ac~ oes concretas. Para um disk driver, por exemplo, isto signi ca informar onde o bloco se encontra no disco, veri car se o motor esta girando, determinar se o braco esta posicionado no cilindro apropriado, e assim por diante. Em poucas palavras, o driver deve decidir quais operac~ oes do controlador s~ ao requeridas e em que sequ^ encia. Uma vez determinado quais comandos emitir ao controlador, este inicia a emiss~ ao escrevendo nos registradores do controlador do dispositivo. Alguns controladores podem manusear somente um comando por vez. Outros controladores aceitam uma lista de comandos, os quais s~ ao carregadas sem a ajuda do sistema operacional. Apos o comando ou comandos terem sido emitidos, podem ocorrer duas situac~ oes. Em muitos casos o device driver deve esperar ate que o controlador execute as operac~ oes requisitadas. Se estas operac~ oes forem lentas (envolvendo movimentos mec^ anicos, por exemplo), o driver bloqueia ate que as operac~ oes se completem. Em outros casos, entretanto, as operac~ oes s~ ao rapidas, situac~ ao esta em que o driver n~ ao precisa ser bloqueado. Como um exemplo dessa situac~ ao, o deslocamento da tela em terminais requer apenas escrita de uns poucos bytes nos registradores do controlador. Nenhum movimento mec^ anico e necessario e a operac~ ao toda pode se completar em alguns microsegundos. Neste ponto, apos a operac~ ao ter sido completada, o driver deve veri car a ocorr^ encia de erros. Se tudo estiver correto, ele passa os dados (o bloco lido, por exemplo) para a proxima camada do software de E/S. Finalmente, ele retorna alguma informac~ ao de status de erros. Se alguma requisic~ ao esta na la, uma delas pode agora ser selecionada e iniciada. Se nenhuma esta na la, o driver ca aguardando a proxima requisic~ ao.
42
Embora parte de software de E/S seja espec co do dispositivo, grande parte e independente do dispositivo. O limite exato entre os drivers e o software independente dos dispositivos e func~ ao do sistema, uma vez que algumas func~ oes que s~ ao independentes do dispositivo podem atualmente estarem nos drivers, por e ci^ encia ou outras raz~ oes. As func~ oes listadas abaixo s~ ao tipicamente implementadas no software independente do dispositivo: interface uniforme para com os drivers de dispositivos identi cac~ ao simbolica dos dispositivos protec~ ao dos dispositivos manipulac~ ao de blocos independente dos dispositivos \bu erizac~ ao" alocac~ ao de espaco nos dispositivos do tipo bloco alocac~ ao e liberac~ ao de dispositivos dedicados ger^ encia de erros. A func~ ao basica do software independente do dispositivo e realizar as func~ oes de E/S que s~ ao comuns a todos os dispositivos, e suportar uma interface uniforme para o software do usuario. Uma quest~ ao fundamental em um sistema operacional e como objetos tais como os arquivos e dispositivos de E/S s~ ao identi cados. O software independente do dispositivo se encarrega do mapeamento simbolico dos nomes dos dispositivos para os seus drivers apropriados. Relacionado ao nome esta a protec~ ao. Como o sistema previne usuarios de acessar dispositivos que n~ ao est~ ao autorizados a acessar? Em muitos microcomputadores, n~ ao ha nenhuma protec~ ao. Em muitos mainframes e superminis, acessos a dispositivos de E/S pelos usuarios e completamente proibido. Diferentes discos podem ter diferentes tamanhos de setor. O software independente do dispositivo deve encobrir este fato e prover um tamanho de bloco uniforme para camadas superiores, por exemplo, pelo tratamento de varios setores como um simples bloco logico. Deste modo, os n veis superiores somente negociam com dispositivos abstratos que usam o mesmo tamanho de bloco logico, independente do tamanho f sico do setor. \Bu erizac~ ao" e uma outra quest~ ao, tanto para dispositivos de blocos como para de caracter. Para dispositivos de bloco, o hardware executa escrita e leitura de blocos inteiros, mas o processo do usuario esta livre para ler ou escrever unidades arbitrarias. Para dispositivos de caracter, usuarios podem escrever dados no sistema mais rapido do que a taxa com que eles s~ ao transferidos para o dispositivo f sico, necessitando assim de \bu erizac~ ao". Entrada de teclado e outro exemplo de atividade que requer \bu erizac~ ao". Quando um arquivo e criado e preenchido com dados, novos blocos de disco t^ em que ser alocados para o arquivo. Para realizar esta alocac~ ao, o sistema operacional precisa de uma lista ou mapa de bits dos blocos livres no disco, mas o algoritmo para localizar um bloco livre e independente do dispositivo e pode ser implementado acima do n vel do driver. Alguns dispositivos, tais como as tas magneticas, podem ser usadas somente por um simples processo em um dado momento. E o sistema operacional que examina a requisic~ ao para usar o dispositivo e aceita ou n~ ao, dependendo da disponibilidade do dispositivo requisitado.
DCA/FEEC/UNICAMP 43
5.2.4 Software de E/S Independente do Dispositivo
c 1996
Entrada e Sa da
camada processos do usurio funcionalidade executa operao de E/S
Discos 5.3]
A manipulac~ ao de erros tambem e feita nesta camada. Um erro t pico e causado por um bloco do disco ruim e que n~ ao pode mais ser lido. Apos o driver tentar ler o bloco varias vezes, ele informa ao software independente do dispositivo a raz~ ao. O erro e ent~ ao tratado. Se ocorreu num arquivo do usuario, e su ciente informar o erro para o mesmo. Entretanto, se o erro ocorreu numa area cr tica, o sistema operacional deve apresentar uma mensagem e, eventualmente, terminar sua execuc~ ao. Embora muito do software de E/S esteja embutido no sistema operacional, uma pequena porc~ ao dele consiste de bibliotecas ligadas juntamente com programas do usuario, e ate mesmo com programas inteiros executando fora do nucleo. Chamadas de sistema, incluindo chamadas do subsistema de E/S, s~ ao normalmente feitas por procedimentos da biblioteca. Quando um programa em C contem a chamada o procedimento da biblioteca fread sera ligado com o programa. A colec~ ao de todos estes procedimentos da biblioteca e parte do sistema de E/S. Enquanto estes procedimentos fazem pouco mais que colocar seus par^ ametros em lugares apropriados para a chamada do sistema, ha outros procedimentos de E/S que fazem o trabalho real. Em particular, a formatac~ ao de uma entrada e sa da e feita por um procedimento da biblioteca. Nem todo o software de E/S utilizado pelo usuario consiste de procedimentos da biblioteca. Outra importante categoria e o sistema spooling. Spooling e o modo de negociac~ ao com os dispositivos dedicados de E/S em um sistema com multiprogramac~ ao, tais como impressoras. Embora seja facil permitir que algum processo do usuario abra o arquivo especial associado a uma impressora, se o processo mantiver o arquivo aberto por varias horas ent~ ao nenhum outro processo podera imprimir. Ao inves disso, o que e feito e criar um processo especial, chamado daemon, e um diretorio especial, chamado spooling directory. Para imprimir um arquivo, o aplicativo recebe o arquivo inteiro para ser impresso e o coloca no spooling directory. Ent~ ao o daemon, o unico processo que tem permiss~ ao de usar o arquivo especial associado a impressora, transfere um arquivo do spooling directory para a impressora por vez. Protegendo-se os arquivos especiais contra o uso direto por usuarios, o problema de se ter alguem monopolizando-os e eliminado. Spooling e tambem usado em outras situac~ oes, tais como a transfer^ encia de arquivos na rede. Para enviar um arquivo a algum lugar, o aplicativo coloca o arquivo dentro do diretorio de spooling da rede. Mais tarde, o network daemon acessa o arquivo e o transmite. A Figura 5.2 resume o sistema de E/S, mostrando todas os n veis e func~ oes principais de cada n vel.
bytes_lidos = fread(buffer, tam_item, n_itens, arquivo)
software independente do dispositivo
identifio, proteo, bloqueio "bufferizao" inicia registradores do dispositivo verifica status da operao desbloqueia o driver quando a operao de E/S se completa
5.2.5 Software a N vel do Usuario
drivers de dispositivos
gerenciadores de interrupo
dispositivos
executa fisicamente a operao de E/S
requisio de E/S
resposta da requisio
Figura 5.2: N veis do sistema de E/S e func~ oes principais de cada n vel setores no anel externo do disco sejam sicamente maiores que aqueles no anel interno. O espaco extra n~ ao e aproveitado. Um aspecto que tem importante implicac~ oes no disk driver e a possibilidade do controlador fazer buscas (seek) em dois ou mais dispositivos ao mesmo tempo. Estas s~ ao conhecidas como busca entrelacada (overlapped seek). Enquanto o controlador e o software est~ ao esperando uma busca se completar em um dispositivo, o controlador pode iniciar uma busca em outro. Muitos controladores podem tambem ler ou escrever em um dispositivo enquanto executam uma busca em um ou mais dispositivos, mas nenhum pode ler ou escrever em dois dispositivos no mesmo tempo. (Ler ou escrever requer que o controlador mova bits na faixa de microsegundos, assim uma transfer^ encia usa muito de sua capacidade computacional). A habilidade de realizar duas ou mais buscas ao mesmo tempo pode reduzir sensivelmente o tempo medio de acesso. Nesta sec~ ao veremos algumas caracter sticas genericas relacionadas com os disk drivers. O tempo de leitura ou escrita de um bloco do disco e determinado por tr^ es fatores: o tempo de seek (tempo para mover o braco para o cilindro desejado), o atraso rotacional (tempo para o setor desejado car sob a cabeca de leitura/escrita), e o tempo de transfer^ encia. Para muitos discos, o tempo de seek domina. Reduzindo-se o tempo de seek, podemos melhorar substancialmente o desempenho do sistema.
5.3 Discos
Dispositivos do tipo bloco s~ ao armazenadores que aceitam dois comandos: escrever um bloco e ler um bloco. Normalmente esses blocos s~ ao armazenados em memoria rotativa, tal como os discos r gidos e ex veis. Nas sec~ oes seguintes, descreveremos brevemente o hardware do disco, passando para os disk drivers a seguir.
5.3.2 Software do Disco
5.3.1 Hardware do Disco
Algoritmos de Escalonamento do Braco do Disco

Se o disk driver aceita uma requisic~ ao por vez e a executa nesta ordem, isto e, First-Come, FirstServed (FCFS), pouco pode ser feito para otimizar o tempo de seek. Entretanto uma estrategia e poss vel: e provavel que enquanto o braco esta executando um seek na metade de uma requisic~ ao, uma outra requisic~ ao de disco pode ter sido gerada por outro processo. Muitos disk drivers mantem
DCA/FEEC/UNICAMP 45
Todos os discos rotativos s~ ao organizados em cilindros, cada qual contendo tantas trilhas quanto cabecas empilhadas verticalmente. As trilhas s~ ao divididas em setores, com um numero de setores na circunfer^ encia, tipicamente entre 8 a 32. Todos os setores cont^ em o mesmo numero de bytes, embora
44
c 1996
Entrada e Sa da
E/S no Unix 5.4]
uma tabela, indexada pelo numero do cilindro, com todas as requisic~ oes pendentes para cada cilindro, encadeadas juntas numa lista. Para este tipo de estrutura de dados, podemos melhorar o algoritmo de escalonamento First-Come, First-Served. Considere um disco com 40 cilindros. Uma requisic~ ao chega para ler um bloco no cilindro 11. Enquanto a busca para o cilindro 11 esta em progresso, novas requisic~ oes chegam para os cilindros 1, 36, 16, 34, 9, e 12, nesta ordem. Elas s~ ao inseridas na tabela de requisic~ oes pendentes, tendo cada cilindro um lista separada. As requisic~ oes s~ ao mostradas na Figura 5.3.
posio inicial
A Figura 5.4 mostra o algoritmo do elevador usando as mesmas sete requisic~ oes da Figura 5.3, assumindo que o bit de direc~ ao esteja inicialmente em UP . A ordem na qual os cilindros s~ ao servidos e 12, 16, 34, 36, 9, e 1, gerando movimento do braco de 1, 4, 18, 2, 27, e 8, num total de 60 cilindros. Neste caso, o algoritmo do elevador e um pouco melhor que SSF, embora seja usualmente pior. Uma propriedade interessante do algoritmo do elevador e que dada uma colec~ ao de requisic~ oes, o limite superior para o total de movimentos e xado: ele e apenas duas vezes o numero de cilindros.
posio inicial X 0 5 X 10 X X 15 X 20 25 X 30 X cilindro
X 0 5
X 10
X X 15
X 20 25
X 30
X cilindro
sequncia de movimentos tempo sequncia de movimentos
tempo
Figura 5.4: Escalonamento de requisic~ oes no disco atraves do algoritmo do elevador Alguns controladores de disco suportam um modo do software para inspecionar o numero de setores correntes sob a cabeca. Com um desses controladores, uma outra otimizac~ ao e poss vel. Se duas ou mais requisic~ oes para o mesmo cilindro est~ ao pendentes, o driver pode emitir a requisic~ ao para o setor que passara sob a cabeca do proximo cilindro. Note que quando trilhas multiplas est~ ao presentes num cilindro, requisic~ oes consecutivas podem ser conduzidas para diferentes trilhas com nenhuma penalidade. O controlador pode selecionar alguma das cabecas instantaneamente, uma vez que selec~ ao de cabeca n~ ao requer movimento dos bracos nem atraso rotacional. Quando existe varios dispositivos, uma tabela de requisic~ oes pendentes deve ser mantida para cada dispositivo separadamente. Quando algum dispositivo esta desocupado, um seek deve ser emitido para mover os seus bracos para o cilindro onde sera necessario (assumindo que o controlador permita seeks sobrepostos). Quando a transfer^ encia corrente termina, um teste pode ser feito para veri car se algum dos dispositivos est~ ao posicionados no cilindro correto. Se um ou mais est~ ao, a proxima transfer^ encia pode ser iniciada no dispositivo que ja esta no cilindro correto. Se nenhum dos bracos esta na posic~ ao desejada, o driver deve emitir novos seeks sobre os dispositivos que ja completaram a transfer^ encia, e esperar ate a proxima interrupc~ ao para examinar em qual dispositivo o posicionamento do braco se completou.
Figura 5.3: Algoritmo de escalonamento menor seek primeiro (SSF) Quando a requisic~ ao corrente termina (cilindro 11), o disk driver tem que escolher qual sera a proxima requisic~ ao. Usando FCFS, ele ira para o cilindro 1, ent~ ao para o 36, e assim por diante. Este algoritmo requer movimentos do braco de 10, 35, 20, 18, 25, e 3, respectivamente, num total de 111 cilindros. Alternativamente, a proxima requisic~ ao pode ser manuseada a m de minimizar o tempo de seek. Dadas as requisic~ oes da Figura 5.3, a sequ^ encia 12, 9, 16, 1, 34, e 36, como mostrado na linha entalhada. Com esta sequ^ encia, os movimentos do braco s~ ao 1, 3, 7, 15, 33, e 2, num total de 61 cilindros. Este algoritmo, menor seek primeiro (SSF), diminuiu o total de movimentos do braco pela metade, comparado com o FCFS. Infelizmente, SSF tem um problema. Suponha mais requisic~ oes chegando enquanto as requisic~ oes da Figura 5.3 esta sendo processada. Por exemplo, se, apos chegar ao cilindro 16, uma nova requisic~ ao para o cilindro 8 esta presente. Esta requisic~ ao tera prioridade sobre o cilindro 1. Se a requisic~ ao for para o cilindro 13, o braco ira para o 13, ao inves de ir para o cilindro 1. Com disco muito carregados, o braco tende a permanecer no meio do disco a maior parte do tempo, prejudicando assim as requisic~ oes das extremidades. Requisic~ oes distantes do meio s~ ao em media mais demoradas, colocando o objetivo de m nima resposta no tempo e imparcialidade no acesso. Um algoritmo para reconciliar os objetivos con itantes entre a e ci^ encia e imparcialidade constituise em manter o movimento do braco na mesma direc~ ao ate n~ ao haver mais requisic~ oes pendentes naquela direc~ ao, e ent~ ao o movimento do braco e mudado. Este algoritmo, conhecido como algoritmo do elevador, requer o software mantenha 1 bit: o bit da direc~ ao corrente, UP ou DOWN . Quando a requisic~ ao termina, o disk driver testa o bit. Se e UP, o braco e movido para a proxima requisic~ ao pendente de posic~ oes mais altas, se houver. Se n~ ao ha requisic~ oes pendentes para posic~ oes mais altas, o bit de direc~ ao e revertido. Quando o bit e mudado para DOWN, o movimento sera para a proxima requisic~ ao de posic~ ao mais baixa, se houver.
46
5.4 E/S no Unix

Dispositivos no Unix podem ser do tipo bloco ou caracter. O interfaceamento com os dispositivos se da atraves do subsistema de arquivos. Cada dispositivo tem um nome id^ entico a nomes de arquivos (/dev/tty, /dev/console) e um respectivo i-node. i-nodes associados a dispositivos t^ em como tipo de arquivo \block" ou \character special", o que os distingue dos arquivos regulares. Cada dispositivo tem seu device driver associado. No Unix, um driver implementa as chamadas de sistema open, close, read, write e ioctl para o seu dispositivo, bem como o tratamento para as interrupc~ oes oriundas deste.
DCA/FEEC/UNICAMP 47
c 1996
Entrada e Sa da
E/S em MS-DOS 5.5]
Em dispositivos que operam em bloco, a transfer^ encia de dados entre o espaco de enderecamento de um processo e o dispositivo de da atraves de um bu er cache. A raz~ ao para tal e que tais dispositivos s~ ao lentos, sendo portanto a \bu erizac~ ao" um meio de aumentar a taxa de transfer^ encia de dados. Dispositivos do tipo caracter (terminais, por exemplo) s~ ao inerentemente rapidos e n~ ao necessitam deste recurso. A Figura 5.5 mostra o esquema basico de entrada e sa da no Unix. Quando um processo executa uma chamada de sistema open, por exemplo, o nucleo acessa o i-node do arquivo passado a chamada e descobre que e um arquivo associado a um dispositivo de E/S. Atraves de uma tabela de chaveamento de dispositivo, o nucleo obtem o endereco da rotina de open para este dispositivo. Uma vez iniciado o dispositivo, um campo na tabela de arquivos e adicionado, sendo o ndice deste campo (descritor) retornado ao processo. Uma chamada close faz com que o nucleo acesse o respectivo procedimento para o dispositivo, cuja identi cac~ ao e obtida na tabela de arquivos.
open close read write ioctl open close read mount umount write
Uma rotina denominada strategy perfaz as operac~ oes de leitura e escrita em tais dispositivos. Quando uma operac~ ao de leitura ou escrita e requisitada, o nucleo identi ca a rotina strategy de nida para o dispositivo, passando a mesma o endereco do cabecalho do bu er para onde os dados devem ser copiados, caso leitura, ou contendo os dados para escrita.
5.5 E/S em MS-DOS

Assim como Unix, MS-DOS tambem suporta dispositivos de E/S atraves de arquivos especiais de tipo bloco ou caracter. Parte dos drivers esta incorporada no arquivo io.sys, mas o usuario pode instalar drivers adicionais atraves de comandos device= no arquivo con g.sys. Todo driver em MS-DOS e composto de duas partes de codigo, uma para receber as requisic~ oes (o request handler ) do sistema operacional e outra parte para efetivar a operac~ ao de transfer^ encia de dados. Cada driver instalado e inserido no topo de uma lista ligada de drivers, e uma variavel interna do sistema aponta para o topo da lista. Desta forma, drivers instalados recentemente tem preced^ encia sobre drivers antigos. Em termos de dispositivos f sicos, muitos t^ em enderecos pre-de nidos na con gurac~ ao de hardware. A Tabela 5.1 mostra os enderecos de E/S e os vetores de interrupc~ ao alocados para alguns dos controladores do IBM PC. A atribuic~ ao de enderecos de E/S para dispositivos e feita por um decodi cador logico associado ao controlador. Alguns IBM PC-compat veis usam diferentes enderecos de E/S. relogio 040 - 043 8 teclado 060 - 063 9 porta serial secundaria 2F8 - 2FF 11 disco r gido 320 - 32F 13 impressora 378 - 37F 15 v deo monocromatico 380 - 3BF v deo colorido 3D0 - 3DF disco ex vel 3F0 - 3F7 14 porta serial primaria 3F8 - 3FF 12 Tabela 5.1: Alguns exemplos de controladores, os seus enderecos de E/S e seus vetores de interrupc~ ao no IBM PC
rotinas do cache de buffers
tabela de chaveamento (dispositivos orientados a caracter)
tabela de chaveamento (dispositivos orientados a bloco)
dispositivo
endereco E/S vetor int.
open close read write ioctl
open
close
strategy
driver
driver
gerenciador de interrupes
gerenciador de interrupes
vetor de interrupo interrupes dispositivo dispositivo dispositivo
Figura 5.5: Esquema basico de E/S no Unix Chamadas ioctl permitem o usuario operar tanto arquivos regulares quanto dispositivos do tipo caracter. Operac~ oes t picas s~ ao bloquear um arquivo, desligar o eco do terminal, ajustar taxa de transfer^ encia de modems e rebobinar uma ta. Para dispositivos do tipo bloco, chamadas read e write seguem o mesmo procedimento. Para tais dispositivos, na qual o driver tem que iteragir com as rotinas de bu er cache, o procedimento e outro.
48
c 1996
DCA/FEEC/UNICAMP
49
Entrada e Sa da
E/S em MS-DOS 5.5]
(5)
Problemas
processo (produtor) p~ oe informac~ ao em um bu er com capacidade limitada, enquanto outro processo (consumidor) remove elementos deste bu er. O bu er e um recurso compartilhado, e deve ser controlado de forma que nem o produtor possa inserir elementos quando o bu er esta cheio e nem o consumidor retire elementos de um bu er vazio. Esquematize uma soluc~ ao para este problema de sincronizac~ ao usando semaforos. (2) Medidas em um sistema indicam que umprocesso executa em media segundos antes de bloquear em uma operac~ ao de entrada e sa da. O tempo de chaveamento de contexto e segundos. Para um sistema escalonador usando round-robin com um quantum , de na uma formula para a e ci^ encia da CPU (raz~ ao entre tempo gasto com trabalho util sobre tempo total) em cada um dos casos seguintes: (a) = 1 (b) (c) (d) = (e) 0 (3) Cinco jobs (A, B, C, D, E) chegam a um centro de processamento quase ao mesmo tempo. Eles t^ em tempos estimados de execuc~ ao 10, 6, 2, 4 e 8 minutos, respectivamente, e prioridades (de nidas externamente) 3, 5, 2, 1, e 4, com 5 sendo a prioridade mais alta. Determine o tempo medio de execuc~ ao por processo para cada uma das seguintes pol ticas de escalonamento: (a) Round robin (b) Por prioridades (c) FCFS (d) Tarefas pequenas primeiro. (4) Considere um sistema de swapping na qual a memoria tem buracos de tamanhos 10K, 4K, 20K, ~ sucessivas para segmentos de 12K, 10K e 9K. Que buracos 18K, 7K, 9K, 12K e 15K. Ha requisicOes s~ ao ocupados quando a pol tica de alocac~ ao e: (a) First t? (b) Best t? (c) Next t?
T S Q Q Q > T S < Q < T Q Q S
(6)
(1) Um problema classico de sincronizac~ ao e conhecido como o problema produtor-consumidor. Um (7)
(8)
(d) Worst t (sempre ocupar o maior buraco dispon vel)? Considere um computador com 1M de memoria do usuario que executa um procedimento de compactac~ ao de memoria a cada segundo. Se e preciso 0.5 s para copiar um byte e o tamanho medio de um buraco e 40% do tamanho medio de um segmento, que frac~ ao do tempo total de CPU e gasta com compactac~ ao? Usando a tabela de paginas da Figura 3.5, d^ e os enderecos f sicos correspondentes aos enderecos virtuais: (a) 20 (b) 4100 (c) 8300 A listagem a seguir corresponde a um programa em assembly para um computador com paginas de 512 bytes. O programa esta localizado no endereco 1020, e o stack pointer esta em 8192 (com a pilha crescendo para 0). D^ e a sequ^ encia de paginas referenciadas por este programa, considerando que cada instruc~ ao ocupa 4 bytes (uma palavra). Tanto refer^ encias a dados quanto a instruc~ oes devem ser consideradas. Load palavra em 6144 no registrador 0 Push registrador 0 na pilha Call procedimento em 5120, empilhando endereco de retorno Subtract a constante imediata 16 do stack pointer Compare o par^ ametro atual com a constante imediata 4 Jump se igual para 5152. Um computador tem quatro page frames. O instante em que foram carregados, o instante da ultima refer^ encia e os estados dos bits R e M s~ ao indicados abaixo: Frame Carreg Refer R M 0 126 279 0 0 1 230 260 1 0 2 120 120 1 1 3 160 280 1 1
Qual pagina seria substitu da se a pol tica de troca adotada fosse: (a) FIFO? (b) NRU? (c) LRU? (d) Segunda chance? (9) Quanto tempo e necessario para carregar um programa de 64K do disco se o tempo medio de posicionamento e 30 ms, o tempo de rotac~ ao e 20 ms e as trilhas t^ em 32K quando o tamanho das paginas e
DCA/FEEC/UNICAMP 51
50
c 1996
(a) 2K? (b) 4K? As paginas est~ ao espalhadas aleatoriamente pelo disco. (10) Considere um disco de 1G de capacidade com blocos de tamanho 4K. Quanto espaco e necessario para manter a ger^ encia de espaco livre por mapa de bits? E por lista ligada de blocos? A partir de qual fator de ocupac~ ao uma estrategia passa a ser mais econ^ omica que a outra? (11) Um veri cador de sistema de arquivos construiu a seguinte tabela de consist^ encia de blocos:
Em uso: 1 0 1 0 0 1 0 1 1 0 1 0 0 1 0 Livre: 0 0 0 1 1 1 0 0 0 1 0 1 1 0 1
Ha algum erro de consist^ encia? Em caso a rmativo, estes erros s~ ao graves? Por qu^ e?
(12) Um driver de disco r gido recebe requisic~ oes para os cilindros 10, 22, 20, 2, 40, 6 e 38, nesta ordem.
O tempo de seek toma 6 ms por cilindro. Qual e o tempo gasto em posicionamento para atender estas requisic~ oes com as pol ticas de (a) FCFS (b) SSF e (c) elevador? Considere que o disco estava posicionado no cilindro 20, e para o elevador a direc~ ao inicial era crescente (para cima). (13) A rotina de manipulac~ ao de interrupc~ ao de relogio em um computador requer 2 ms para executar, incluindo-se chaveamento de contextos. O relogio trabalha a uma frequ^ encia de 60 Hz. Que frac~ ao do tempo de CPU e dedicada ao relogio?
52
c 1996

Apost So

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apost So

Caricato da

Copyright:

Formati disponibili

Universidade Estadual de Campinas ~o Faculdade de Engenharia Eletrica e de Computaca

1.1 1.2 1.3 1.4

3 Ger^ encia de Memoria

Cardozo, Magalh~ aes, Faina & Ricarte

Cardozo, Magalh~ aes, Faina & Ricarte

Cap tulo 1 Introduc~ ao

1.1 O que e um Sistema Operacional?

1.1.1 O Sistema Operacional como uma Maquina Virtual

Cardozo, Magalh~ aes, Faina & Ricarte

Historia dos Sistemas Operacionais 1.2]

1.1.2 O Sistema Operacional como um Gerenciador de Recursos

1.2 Historia dos Sistemas Operacionais

1.2.1 A Primeira Gerac~ ao (1945-1955): Valvulas e Plugs

1.2.2 A Segunda Gerac~ ao (1955-1965): Transistores e Processamento em Batch

1.2.3 A Terceira Gerac~ ao (1965-1980): Circuitos Integrados e Multiprogramac~ ao

1.2.4 A Quarta Gerac~ ao (1980-): Computadores Pessoais e Estac~ oes de Trabalho

Que eram capazes de gerenciar apenas um job por vez.

Cardozo, Magalh~ aes, Faina & Ricarte

Interpretador de Comandos (Shell) O interpretador de comando e um processo que perfaz a

Chamadas de Sistema (System Calls) Assim como o interpretador de comandos e a interface

1.3 De nic~ oes

Processos Um processo (as vezes chamado de tarefa ou de processo sequencial) e basicamente um

Sistemas Multitarefas e Multiusuarios Um sistema operacional multitarefa se distingue pela sua

Multiprogramac~ ao Multiprogramac~ ao e um conceito mais geral que multitarefa e denota um sistema

Cardozo, Magalh~ aes, Faina & Ricarte

Cardozo, Magalh~ aes, Faina & Ricarte

Concorr^ encia 2.2]

Cap tulo 2 Processos

2.2.1 Mutua Exclus~ ao Com Espera Ocupada

2.2 Concorr^ encia

Cardozo, Magalh~ aes, Faina & Ricarte

Comunicac~ ao Interprocessos 2.3]

2.3 Comunicac~ ao Interprocessos

2.2.2 Mutua Exclus~ ao com Espera Bloqueada

Compartilhamento de Dados Processos podem se comunicar atraves do compartilhamento de uma

Semaforos Nesta abordagem, o bloqueio ou reativac~ ao de processos n~ ao e realizada diretamente pelo

Chamada de Procedimentos Remotos Chamada de procedimentos remotos (RPC) e uma forma

2.4 Escalonamento de Processos

Executando qualquer um de seus procedimentos.

Cardozo, Magalh~ aes, Faina & Ricarte

Processos em Unix 2.5]

2.5 Processos em Unix

vaz~ ao: maximizar o numero de processos executados por hora.

2.6 Processos em MS-DOS

Cardozo, Magalh~ aes, Faina & Ricarte

Processos em MS-DOS 2.6]

Executando em Modo Usurio

chamada de sistema ou interrupo

Executando em Modo Ncleo

escalonado aguardando evento 3 evento Pronto

Cardozo, Magalh~ aes, Faina & Ricarte

Ger^ encia de Memoria

Ger^ encia com Permuta 3.2]

Cap tulo 3 Ger^ encia de Memoria

3.1.3 Multiprogramac~ ao com Partic~ oes Fixas

400K partio 2 partio 2

3.1 Ger^ encia Sem Permuta

3.1.2 Multiprogramac~ ao e Uso da Memoria

3.2 Ger^ encia com Permuta

Cardozo, Magalh~ aes, Faina & Ricarte

Ger^ encia de Memoria

Ger^ encia com Permuta 3.2]

3.2.1 Multiprogramac~ ao com Partic~ oes Variaveis