_apost_so
November 13, 2016 | Author: Renê Paiva | Category: N/A
Short Description
Download _apost_so...
Description
Universidade Estadual de Campinas Faculdade de Engenharia Eletrica e de Computaca~o
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? Hist oria dos Sistemas Operacionais Denic~oes Exemplos
1 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
2 Processos 2.1 2.2 2.3 2.4 2.5 2.6
Conceitos B asicos Concorr^encia Comunicac~ao Interprocessos Escalonamento de Processos Processos em Unix Processos em MS-DOS
8
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
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 Departamento de Engenharia de Computaca~ o e Automaca~o Industrial
3.1 3.2 3.3 3.4 3.5 3.6
Ger^encia Sem Permuta Ger^encia com Permuta Mem oria Virtual Algoritmos de Troca de P agina Ger^encia de Mem oria no UNIX Ger^encia de Mem oria 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 17 21 24 26 28
30 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
5 Entrada e Sa da 5.1 5.2 5.3 5.4 5.5
8 8 11 11 13 13
16
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
4 Sistema de Arquivos 4.1 4.2 4.3 4.4
1 2 4 5
30 31 35 37
39 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
1996 i
39 41 44 47 49
Cardozo, Magalh~aes, Faina & Ricarte
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Captulo 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 necess ario dada a discrep^ancia entre o tipo de informac~ao manipulada pelo homem e pela m aquina. A m aquina opera com cadeias de c odigos bin arios 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 usu ario.
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 execuca~o de programas aplicativos.
1.1 O que e um Sistema Operacional? A maioria de usu arios de computador t^em alguma experi^encia com sistemas operacionais, mas e dif cil denir precisamente o que e um sistema operacional. Parte do problema decorre do fato do sistema operacional realizar duas funco~es b asicas 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.
1.1.1 O Sistema Operacional como uma Maquina Virtual
A arquitetura (conjunto de instruco~es, organizac~ao de mem oria, E/S e estrutura de barramento) da maioria dos computadores a n vel de linguagem de m aquina e primitiva e dif cil de programar, especicamente para operaco~es 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 coleca~o de arquivos identicados por nomes simb olicos. O programa que esconde os detalhes de implementac~ao das abstrac~oes e o sistema operacional. A abstrac~ao apresentada ao usu ario pelo sistema operacional e simples e mais f acil de usar que o hardware original. Nesta vis~ao, a func~ao do sistema operacional e apresentada ao usu ario como uma maquina estendida ou maquina virtual que e mais f acil de programar que o hardware que a suporta. ii
c 1996
DCA/FEEC/UNICAMP
1
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
1.1.2 O Sistema Operacional como um Gerenciador de Recursos
Um computador moderno e composto de v arios subsistemas tais como processadores, mem orias, discos, terminais, tas magn eticas, 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 usu arios sejam atendidas da forma mais r apida e con avel poss vel. Um exemplo t pico e o compartilhamento da unidade central de processamento (CPU) entre as v arias tarefas (programas) em sistemas multiprogramados. O sistema operacional e o respons avel pela distribuic~ao de forma otimizada da CPU entre as tarefas em execuc~ao.
1.2 Historia dos Sistemas Operacionais Os sistemas operacionais t^em evolu do com o passar dos anos. Nas pr oximas sec~oes vamos apresentar de forma sucinta este desenvolvimento.
1.2.1 A Primeira Gerac~ao (1945-1955): Valvulas e Plugs
Ap os muitos esforcos mal sucedidos de se construir computadores digitais antes da 2a guerra mundial, em torno da metade da d ecada de 1940 alguns sucessos foram obtidos na construca~o de m aquinas de c alculo empregando-se v alvulas e rel es. Estas m aquinas eram enormes, ocupando salas com racks que abrigavam dezenas de milhares de v alvulas (e consumiam quantidades imensas de energia). Naquela epoca, um pequeno grupo de pessoas projetava, construia, programava, operava e dava manutenc~ao em cada m aquina. Toda programac~ao era feita absolutamente em linguagem de m aquina, muitas vezes interligando plugs para controlar func~oes b asicas da m aquina. Linguagens de programac~ao eram desconhecidas, assim como sistemas operacionais. Por volta de 1950 foram introduzidos os cart~oes perfurados aumentando a facilidade de programaca~o.
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 s erie), sendo empregados em atividades m ultiplas. Pela primeira vez, houve uma separaca~o clara entre projetistas, construtores, operadores, programadores e pessoal de manutenc~ao. Entretanto, dado seu custo ainda elevado, somente corporaco~es e universidades de porte detinham recursos e infraestrutura para empregar os computadores desta gerac~ao. Estas m aquinas 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 c alculos 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
2
Que eram capazes de gerenciar apenas um job por vez.
c 1996
Introduc~ao
Historia dos Sistemas Operacionais 1.2]
1.2.3 A Terceira Gerac~ao (1965-1980): Circuitos Integrados e Multiprogramac~ao
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 c alculos num ericos na ci^encia e engenharia. Do outro, haviam os computadores comerciais que executavam tarefas como ordenac~ao de dados e impress~ao de relat orios, sendo utilizados principalmente por instituic~oes nanceiras. A IBM tentou resolver este problema introduzindo a s erie System/360. Esta s erie consistia de m aquinas com mesma arquitetura2 e conjunto de instruc~oes. Desta maneira, programas escritos para uma m aquina da s erie executavam em todas as demais. A s erie 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 conitos de requisitos dos usu arios. 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 usu arios. Ele tamb em popularizou muitas t ecnicas 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 j a f^ora lido e armazenado em disco. Esta t ecnica foi chamada spool (simultaneous peripherical operation on line), sendo tamb em 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 r apidas abriu caminho para o time-sharing, uma variac~ao da multiprogramac~ao onde cada usu ario tem um terminal on-line e todos compartilham uma u nica CPU. Ap os o sucesso do primeiro sistema operacional com capacidade de time-sharing (o CTSS) desenvolvido no MIT3, um cons orcio envolvendo o MIT, a GE e o Laborat orio Bell foi formado com o intuito de desenvolver um projeto ambicioso para a epoca: um sistema operacional que suportasse centenas de usu arios on-line. O MULTICS (MULTiplexed Information and Computing Service) introduziu muitas id eias inovadoras, mas sua implementac~ao mostrou-se impratic avel para a d ecada de sessenta. O projeto MULTICS inuenciou os pesquisadores da Bell que viriam a desenvolver o UNIX uma d ecada depois.
1.2.4 A Quarta Gerac~ao (1980-): Computadores Pessoais e Estac~oes de Trabalho
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 usu arios individualmente. O aumento do potencial destas m aquinas criou um vast ssimo mercado de software a elas dirigido. Como requisito b asico, estes produtos (tanto aplicativos quanto o pr oprio sistema operacional) necessitavam ser \amig aveis", visando usu arios sem conhecimento aprofundado de computadores e sem intenc~ao de estudar muito para utiliz a-los. Esta foi certamente a maior mudanca em relac~ao ao OS/360 que 2 3
Por sinal, o termo arquitetura de computador foi introduzido pelos projetistas deste sistema. Massachussets Institute of Technology.
DCA/FEEC/UNICAMP
3
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
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 estaco~es de trabalho. O pr oximo 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 usu ario num processador, mesmo que sicamente o arquivo se encontre em outro processador. Sistemas operacionais de rede prov^eem ao usu ario 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. Contr ario aos sistemas operacionais de rede que s~ao largamente dispon veis comercialmente, sistemas operacionais distribu dos t^em sua utilizac~ao ainda restrita.
1.3 Denic~oes Nesta seca~o, alguns termos b asicos relativos a sistemas operacionais s~ao denidos. Nos cap tulos seguintes, os conceitos associados ser~ao aprofundados.
Processos Um processo ( as vezes chamado de tarefa ou de processo sequencial) e basicamente um
programa em execuc~ao. Ele e uma entidade ativa que compete por recursos oferecidos pelo sistema (acesso a discos, perif ericos, 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 instruco~es do programa), bloqueado (aguardando outros recursos | al em da CPU | n~ao dispon veis no momento), ou ativo (aguardando apenas CPU para executar).
Sistemas Multitarefas e Multiusuarios Um sistema operacional multitarefa se distingue pela sua
habilidade de suportar a execuc~ao concorrente de processos sobre um processador u nico, sem necessariamente prover forma elaborada de gerenciamento de recursos (CPU, mem oria, etc). Sistemas operacionais multiusu arios permitem acessos simult^aneos ao computador atrav es de dois ou mais terminais de entrada. Embora frequentemente associada com multiprogramac~ao, multitarefa n~ao implica necessariamente em uma operac~ao multiusu ario. Operac~ao multiprocessos sem suporte de multiusu arios pode ser encontrado em sistemas operacionais de alguns computadores pessoais avancados e em sistemas de tempo-real.
Multiprogramac~ao Multiprogramaca~o e um conceito mais geral que multitarefa e denota um sistema
operacional que prov^e gerenciamento da totalidade de recursos tais como CPU, mem oria, 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. Atrav es do uso da multiprogramac~ao e poss vel reduzir os per odos de inatividade da CPU e consequentemente aumentar a eci^encia do uso do sistema como um todo. O termo multiprogramac~ao denota um sistema operacional o qual em adic~ao 4
c 1996
Introduc~ao
Exemplos 1.4]
ao suporte de m ultiplos processos concorrentes, permite que instruc~oes e dados de dois ou mais processos disjuntos estejam residentes na mem oria principal simultaneamente.
Multiprocessamento Embora a maioria dos computadores disponha de uma u nica CPU que exe-
cuta instruc~oes uma a uma, certos projetos mais avancados incrementaram a velocidade efetiva de computac~ao permitindo que v arias instruc~oes fossem executadas ao mesmo tempo. Um computador com m ultiplos processadores que compartilhem uma mem oria principal comum e chamado um multiprocessador. O sistema que suporta tal congurac~ao e um sistema que suporta o multiprocessamento.
Interpretador de Comandos (Shell) O interpretador de comando e um processo que perfaz a
interface do usu ario 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, manipulaca~o de arquivos, e execuc~ao de programas s~ao solicitados atrav es do interpretador de comandos.
Chamadas de Sistema (System Calls) Assim como o interpretador de comandos e a interface
entre usu ario 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 rel ogio interno, operac~oes de entrada/sa da e comunicac~ao inter-processos.
Arquivos Uma das func~oes associadas a sistemas operacionais e esconder os detalhes de hardware do usu ario. O conceito de arquivos oferece um n vel de abstrac~ao que adequado para manipular grupos de dados armazenados em discos e perif ericos de entrada e sa da (I/O). Al em de suportar func~oes para transferir dados entre discos (ou perif ericos) e a aplicac~ao, o sistema operacional pode tamb em suportar func~oes para organizar os dados do disco em diretorios e para controlar o acesso a estes dados. Codigo Reentrante Um c odigo de um programa e dito ser reentrante quando um segundo processo
pode iniciar a execuc~ao deste c odigo mesmo que o c odigo esteja sendo executado por um outro processo.
1.4 Exemplos No restante desta apostila, os conceitos que ser~ao apresentados | ger^encia de processos e de mem oria, 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.
1.4.1 Unix
O j a 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 simplicada deste sistema em uma m aquina j a 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 simplicado viria a alcancar grande sucesso sob o nome de Unix. DCA/FEEC/UNICAMP
5
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Ap os 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 m aquinas da fam lia PDP-11. Como o esforco de transportar o c odigo desenvolvido em assembly era muito grande, o grupo decidiu desenvolver tamb em 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 usu arios de PDP-11, que eram na epoca principalmente universidades. Com o desenvolvimento de um compilador C port atil (por Steve Johnson, de Bell Labs), Unix pode ser transportado facilmente para outros sistemas computacionais. Em meados da d ecada de 1980, a AT&T (companhia que controlava Bell Labs) passou a comercializar sua vers~ao \ocial" de Unix. Em contraposic~ao a esta vers~ao, h a o sistema Unix desenvolvido (a partir da vers~ao para o PDP-11) na Universidade da Calif ornia em Berkeley, usualmente conhecido como Unix BSD (Berkeley Software Distribution). V arias 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 dene 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 denidos 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. H a ainda hoje distinc~ao entre sistemas produzidos pela Open Software Foundation (OSF, um cons orcio de empresas de computac~ao do porte da IBM, HP e DEC) e pela Unix International (UI, outro cons orcio liderado pela AT&T), al em de empresas que utilizam suas pr oprias 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 usu ario (shell) fornecer primitivas que permitem o desenvolvimento de programas complexos a partir de programas mais simples suportar estrutura hier arquica de arquivos ter formataca~o de arquivos baseada no conceito de stream (cadeia) de bytes ter interfaceamento simples e consistente com os dispositivos perif ericos ser multiusu ario/multiprogramado esconder a arquitetura do hardware, permitindo que um programa execute em m ultiplas plataformas.
Introduc~ao
Exemplos 1.4]
hardware ou software para este sistema. Desta forma, ela selecionou como plataforma de hardware
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 j a existia na epoca o processador 8086, com barramento externo de 16 bits, os perif ericos para o 8088 eram muito mais baratos, o que determinou a escolha nal. Anal 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 propriet ario 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 m aquina (64 KBytes de mem oria, 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 mem oria que produzia) e contratou o autor do programa, Tim Patterson, para fazer uma adaptac~ao r apida. 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 esquem aticos e c odigo b asico 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 reexo no software desenvolvido para ele est~ao o modelo de mem oria 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 mem oria f sica) estavam dispon veis como RAM, sendo o restante do espaco de enderecamento alocado a outras mem orias, como ROM e mem oria de v deo. Esta caracter stica trouxe reexos posteriores, quando nenhum programa rodando em MS-DOS podia ser maior que 640 KBytes.
1.4.2 MS-DOS
MS-DOS (MicroSoft Disk Operating System), provavelmente o sistema operacional com maior n umero de usu arios, foi desenvolvido de forma n~ao t~ao prossional. Quando a IBM decidiu lancar seu computador pessoal no in cio da d ecada de 1980, a empresa n~ao estava interessada no desenvolvimento de 6
c 1996
DCA/FEEC/UNICAMP
7
Processos
Cardozo, Magalh~aes, Faina & Ricarte
Concorr^encia 2.2]
ao m sem interrupc~ao para evitar inconsist^encias. Em situac~oes como estas, a parte do c odigo que o manipula o recurso compartilhado e uma regi~ao cr tica. O c odigo que implementa uma regi~ao cr tica deve obedecer a uma s erie de restric~oes:
dois processos n~ao podem estar simultaneamente executando regi~oes cr ticas referentes a um
Captulo 2 Processos
mesmo recurso compartilhado (garantia de m utua exclus~ao)
a garantia de m utua exclus~ao deve ser independente da velocidade relativa dos processos ou n umero 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.
2.1 Conceitos Basicos No cap tulo anterior denimos o conceito de processo | essencialmente, um programa em execuca~o. 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 passar a precisamente pela mesma sequ^encia de instruc~oes e fornecer a o mesmo resultado. Estas propriedades enfatizam a natureza sequencial de um processo. O processo sequencial e denido 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 usu ario, 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 mil esimos de segundos, dando ao usu ario a impress~ao de paralelismo. A ger^encia de atividades paralelas e dif cil de ser implementada com eci^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 execut aveis no computador, muitas vezes incluindo subsistemas do sistema operacional, est~ao organizados na forma de processos. Conceitualmente, cada processo tem uma CPU virtual pr opria. A posse da CPU real e passada periodicamente de processo a processo. Em sistemas multiprogramados, a velocidade de execuca~o 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 m aquina | 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.
2.2 Concorr^encia Em muitos sistemas operacionais, processos frequentemente compartilham outros recursos al em da CPU. Em muitos casos, o recurso s o pode atender a uma requisica~o por vez, e deve atend^e-la do princ pio 8
c 1996
V arios algoritmos de controle visando garantir as propriedades acima foram propostos. Estes algoritmos s~ao classicados 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 m utua 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 est a 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 identicador, e as duas func~oes que comp~oem o algoritmo de garantia de m utua exclus~ao possuem este identicador como par^ametro.
2.2.1 Mutua Exclus~ao Com Espera Ocupada
Nesta sec~ao analisaremos v arias propostas para garantir exclus~ao m utua 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 est a tentanto acessar uma regi~ao cr tica em execuca~o por outro processo permanece em espera ocupada, isto e, competindo pela CPU mas sem avancar no seu processamento.
Desabilitar Interrupc~oes A soluc~ao mais simples e o m etodo de desabilitar todas as interrupc~oes
quando se est a entrando na regi~ao cr tica, e reabilit a-las ao sair. Esta proposta n~ao e muito atrativa, pois d a ao processo usu ario poder de desabilitar todas as interrupc~oes, inclusive aquelas que permitem o n ucleo 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 est a atualizando vari aveis internas. Assim, desabilitar interrupc~oes e uma soluc~ao u til para o sistema operacional, mas n~ao para processos de aplicac~ao.
Variaveis LOCK Uma segunda tentativa leva-nos a uma soluc~ao por software. Considere, para cada
recurso compartilhado, uma vari avel 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 at e que seja 0. Embora pareca uma boa soluc~ao, o que ir a ocorrer se dois processos testam uma vari avel de valor 0 ao mesmo tempo? DCA/FEEC/UNICAMP
9
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Altern^ancia Estrita Esta proposta dene uma vari avel TURN que indica qual processo tem o direito
de acesso a regi~ao cr tica | ou seja, esta vari avel 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 (m odulo o n umero total de processos). Este algoritmo garante a m utua 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 at e que chegue novamente a sua vez. O que ocorre quando a frequ^encia de acesso for diferente entre os processos? i
i
i
Soluc~ao de Peterson Esta soluc~ao e obtida pela combinaca~o das id eias de vari aveis LOCK e TURN, criando-se tamb em uma soluc~ao por software para o problema. Ela evita os problemas individuais das soluc~oes anteriores, mas e pouco utilizada na pr atica por utilizar espera ocupada.
Instruc~ao TSL Esta proposta requer suporte de hardware. Ela utiliza uma instruca~o da forma TSL
(Test and Set Lock) presente em muitos processadores. Esta instruc~ao permite a implementac~ao de vari aveis LOCK cujo teste e atualizaca~o s~ao at^omicos (em outras palavras, a instruc~ao TSL e indivis vel mesmo frente a interrupc~oes de hardware ).
2.2.2 Mutua Exclus~ao com Espera Bloqueada
Ser~ao apresentados a seguir alguns mecanismos de garantia de m utua exclus~ao que bloqueiam os processos quando tentam executar uma regi~ao cr tica \ocupada". S~ao mais ecientes que os anteriores, posto que processos bloqueados n~ao competem pela CPU.
Sleep e Wakeup Um dos m etodos 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 atrav es da chamada wakeup. O m etodo e o mesmo que emprega vari aveis LOCK operadas por instruc~oes TSL, exceto que quando a vari avel 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 respons avel 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 situaca~o denominada deadlock.
Semaforos Nesta abordagem, o bloqueio ou reativaca~o de processos n~ao e realizada diretamente pelo
usu ario, mas atrav es vari aveis do tipo sem aforos, que contam o n umero de vezes que a operac~ao wakeup foi realizada. Duas operac~oes, DOWN e UP s~ao denidas. A operac~ao DOWN verica se o valor do sem aforo 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 sem aforo. Se um ou mais processos estiverem bloqueados sobre aquele sem aforo, um deles e escolhido pelo sistema para completar a operaca~o DOWN (emitindo-lhe um wakeup). As opera c~oes com sem aforos s~ao at^omicas ou indivis veis, implementadas com instruc~oes TSL.
Monitores Sem aforos tornam simples a proteca~o de recursos compartilhados, mas n~ao garantem que n~ao v a haver deadlocks : a troca na ordem da chamada das primitivas pode gerar uma situac~ao de bloqueio m utuo. Monitores s~ao uma proposta de mecanismo de sincronizac~ao de alto n vel. Um monitor e uma colec~ao de procedimentos, vari aveis 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
c 1996
Processos
Comunica ca~o Interprocessos 2.3]
a caracter stica de m utua 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 m utua exclus~ao, t^em aplicac~ao restrita pois raras s~ao as linguagens de programac~ao que os incorporam.
2.3 Comunicac~ao Interprocessos Muitos autores consideram os mecanismos de exclus~ao m utua 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 m utua exclus~ao e gerenciar a competic~ao entre os processos. Comunicac~ao, por sua vez, visa promover a cooperac~ao entre os processos.
Passagem de Mensagem Este m etodo de comunicac~ao entre processos usa duas chamadas de sis-
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 conte udo e interpretado unicamente pelos processos emissor e receptor da mensagem.
Compartilhamento de Dados Processos podem se comunicar atrav es do compartilhamento de uma a rea 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 m utua exclus~ao (tipicamente sem aforos) ou tornando as instruc~oes de leitura e gravac~ao at^omicas. Duas primitivas s~ao necess arias, STORE (que grava dados na posic~ao compartilhada especicada) e FETCH (que acessa dados da posic~ao compartilhada especicada).
Chamada de Procedimentos Remotos Chamada de procedimentos remotos (RPC) e uma forma
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 (atrav es 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, atrav es de uma rotina CALL RPC. Recebida a requisica~o, o servidor executa o servico e retorna os resultados ao cliente. O envio e recepc~ao de par^ametros e retornos se d a por troca de mensagens, que cam transparentes para o programador.
2.4 Escalonamento de Processos Quando mais de um processo est a ativo (pronto para executar), cabe ao sistema operacional decidir qual ter a 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. V arios crit erios devem ser observados por um algoritmo de escalonamento: progresso: garantir que cada processo tenha acesso a CPU 1
Executando qualquer um de seus procedimentos.
DCA/FEEC/UNICAMP
11
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
eci^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)
tempo de espera: minimizar o tempo de espera de servicos n~ao interativos (compilac~ao, impress~ao, etc)
vaz~ao: maximizar o n umero de processos executados por hora. E importante observar que alguns desses objetivos s~ao contradit orios. Se um algoritmo favorece o escalonamento de processos interativos certamento estar a 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 tamb em e passada a outro processo. O tamanho do quantum e cr tico nesta abordagem. Se for muito pequeno, diminui a eci^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.
Algoritmos com Prioridades O algoritmo Round Robin faz a consideraca~o que todos os proces-
sos s~ao de igual import^ancia. Certas aplicaco~es, 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 indenidamente, o escalonador pode diminuir a prioridade dos processos com o aumento de seu respectivo tempo de execuca~o | um processo conhecido como envelhecimento.
Multiplas Filas Este e um algoritmo que dene classes com prioridades. Processos na classe de
menor prioridade s~ao executados por um quantum processos na classe seguinte, por dois quanta na pr oxima 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 n umero 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 m edio de execuc~ao e conhecido a priori. O algoritmo dene que as tarefas menores devem ser executadas primeiro. Prova-se que esta pol tica minimiza o tempo m edio de espera dos jobs.
Algoritmo Policy-Driven Este algoritmo particiona a CPU de forma equ^anime entre os usu arios
(n~ao entre os processos). O algoritmo dene que se existirem usu arios ligados ao sistema, cada usu ario dever a receber 1 do poder da CPU. Para isto, o sistema deve manter informac~oes do tempo de CPU que cada usu ario j a disp^os desde que entrou no sistema, e do instante de tempo que cada usu ario ligou-se ao sistema. n
=n
12
c 1996
Processos
Processos em Unix 2.5]
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 usu arios, outros processos do n ucleo 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 m aquina, 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 a reas 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 atrav es de chamadas de sistema. Do ponto de vista pr atico, 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 identicado como \processo pai" e o processo criado por esta chamada e identicado como \processo lho". Para que um processo lho execute um programa diferente do processo pai, uma chamada do sistema exec deve ser invocada ap os o fork. Todo processo tem um u nico pai mas pode ter v arios lhos, determinando assim uma hierarquia de processos. Exceto pelo primeiro processo (processo 0, na raiz da hierarquia), qualquer outro processo e criado atrav es da chamada fork. O processo 0 e um processo especial criado quando da iniciaca~o do sistema (boot). Ap os 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 denido pelo seu texto correspondendo aos valores das suas vari aveis globais e estruturas de dados, os valores dos registros de m aquina usados, os valores armazenados no seu slot na tabela de processos e o conte udo das suas pilhas de usu ario e n ucleo. Quando o n ucleo decide executar um novo processo realiza-se uma mudanca de contexto. Quando da realizac~ao de uma mudanca de contexto o n ucleo salva informac~oes sucientes 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 usu ario para o modo n ucleo, o n ucleo salva as informac~oes necess arias para que o processo possa retornar ao modo usu ario e continuar a execuc~ao. Neste u ltimo 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 usu ario executando no modo n ucleo pronto ou bloqueado (dormindo). O n ucleo protege a sua consist^encia permitindo chaveamento de contexto apenas quando o processo transita do estado \executando no modo n ucleo" para o modo \bloqueado". O n ucleo tamb em eleva o n vel de execuca~o 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 usu ario de forma a que os processos n~ao monopolizem a CPU.
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 usu ario. Entretanto, h a 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 m aquina. Ao contr ario do que acontece em Unix, n~ao e poss vel executar processos independentes simultaneamente em uma mesma m aquina. Quando um processo lho e iniciado, o processo pai DCA/FEEC/UNICAMP
13
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
1
chamada de sistema ou interrupção
Executando em Modo Núcleo
Processos
Processos em MS-DOS 2.6]
um apontador para o PSP do processo corrente. 3. Carregar o c odigo bin ario na primeira posic~ao ap os o PSP. 4. Iniciar a execuc~ao do programa. Escalonamento da CPU tamb em e simples. Como s o h a um processo ativo, este processo ret em a posse da CPU o tempo todo, a n~ao ser quando um processo TSR toma o controle da execuca~o.
Executando em Modo Usuário
retorno
interrupção/retorno 2
escalonado aguardando evento
4
Bloqueado
3 evento Pronto
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 execut aveis bin arios, e h a correspondentemente dois tipos de processos. Um arquivo com extens~ao .com n~ao tem nenhum cabecalho e ocupa um u nico segmento combinando texto, dados e pilha, at e o limite m aximo de 64 KBytes. O conte udo do arquivo e uma imagem exata do c odigo execut avel. Embora o segmento n~ao possa ocupar mais do que 64 KBytes, o processo recebe para si toda a mem oria dispon vel. Uma tentativa de iniciar um novo processo lho nesta situac~ao iria falhar por falta de mem oria, a n~ao ser que o programador explicitamente libere a porca~o da mem oria que ele n~ao ir a usar para o sistema operacional com uma chamada do sistema. O outro tipo de arquivo execut avel 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 conte udo 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 Prex), que descreve informac~ao b asica 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 ser a invocada caso haja uma interrupc~ao do usu ario (Control-C). Normalmente, quando um processo encerra sua execuca~o, o espaco em mem oria 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 mant em sua imagem em mem oria, 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 atrav es da modicac~ao, pelo pr oprio processo do usu ario, de rotinas que ir~ao tratar interrupco~es 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 mem oria grande o suciente para o processo. Para um arquivo .exe, esta informac~ao est a contida no cabecalho para arquivos .com, toda a mem oria dispon vel e alocada para o processo. 2. Contruir o PSP nos primeiros 256 bytes da area alocada. Uma vari avel global do sistema mant em 14
c 1996
DCA/FEEC/UNICAMP
15
Ger^encia de Memoria
Cardozo, Magalh~aes, Faina & Ricarte
Ger^encia com Permuta 3.2]
processos em mem oria, a CPU dever a 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.
3.1.3 Multiprogramac~ao com Partic~oes Fixas
Captulo 3 Ger^encia de Memoria
Se adotarmos a estrat egia de admitir mais de um processo na mem oria por vez, devemos estabelecer uma estrat egia de organizac~ao da m em oria. A estrat egia mais simples consiste em dividir a mem oria 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 suciente para acomod a-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.
A parte do sistema operacional que gerencia a mem oria e chamada de gerenciador de memoria. Dentre outras tarefas, o gerenciador de mem oria monitora quais partes da mem oria est~ao em uso e quais est~ao dispon veis aloca e libera mem oria para os processos gerencia a permuta de processos entre mem oria principal e secund aria (quando a mem oria principal n~ao e capaz de abrigar todos os processos). Sistemas de ger^encia de mem oria podem ser divididos em duas classes: aqueles que mant^em os processos xos em mem oria prim aria e aqueles que movem processos entre a mem oria principal e secund aria (tipicamente disco) durante a execuc~ao, neste caso baseando-se em t ecnicas de swapping (permuta) ou paginaca~o.
partição 4
partição 3
partição 3
400K partição 2
3.1 Ger^encia Sem Permuta
partição 2
200K partição 1
3.1.1 Monoprogramac~ao
partição 1 100K
O esquema mais simples poss vel de ger^encia de mem oria consiste em ter-se somente um processo na mem oria durante toda a sua execuc~ao. O usu ario carrega um programa do disco (ou ta) para a mem oria, podendo este fazer uso de toda a m aquina. Se a mem oria for insuciente, 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 usu ario entra com um comando no terminal, e o sistema operacional carrega o programa requerido do disco para a mem oria 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 mem oria j a liberada pelo primeiro.
3.1.2 Multiprogramac~ao e Uso da Memoria
Embora a monoprogramac~ao seja usada em pequenos computadores, em grandes computadores com m ultiplos usu arios ela e proibitiva. Multiprogramac~ao, al em de suportar processos simult^aneos de diversos usu arios, tamb em 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 conte udo 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 estar a desocupada esperando pelo acesso ao disco durante 80% do tempo. Quando a multiprogramac~ao e usada, o percentual de utilizaca~o da CPU aumenta. A grosso modo, se a m edia dos processos utilizam CPU somente 20% do tempo que permanecem na mem oria, com 5 16
partição 4 700K
c 1996
sistema operacional
sistema operacional
(a)
(b)
Figura 3.1: Organizac~oes com partic~oes xas: (a) Partic~oes de mem oria xa com las de entrada separadas para cada partic~ao (b) partic~ao de mem oria 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 est a vazia, mas a la para a menor partic~ao est a cheia, como no caso das partic~oes 1 e 4 na Figura 3.1(a). Uma organizac~ao alternativa e manter uma la u nica 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 indesej avel gastar uma partic~ao grande com um processo pequeno, uma estrat egia mais ecaz e procurar em toda la de entrada a maior tarefa para a partic~ao liberada. Note que o u ltimo algoritmo discrimina os processos pequenos, quando e usualmente desej avel dar a eles o melhor tratamento, n~ao o pior.
3.2 Ger^encia com Permuta Num sistema operando em batch, a organizac~ao da mem oria em partic~oes xas e simples e efetiva. Quanto mais jobs estiverem na mem oria, mais a CPU estar a ocupada e n~ao h a raz~ao para usar algo mais complicado. Com time-sharing, a situac~ao e diferente: h a normalmente mais usu arios que mem oria DCA/FEEC/UNICAMP
17
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
para armazenar os seus processos, sendo ent~ao necess ario mover temporariamente processos para disco. Obviamente, para continuar sua execuc~ao, um processo movido para disco deve ser trazido novamente para a mem oria. Outro aspecto fundamental nesta abordagem de ger^encia e como controlar onde h a espaco dispon vel na mem oria. As duas estrat egias 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 Partico~es Variaveis Em princ pio, um sistema que utiliza swapping pode ser baseado em partico~es 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 mem oria. Na pr atica, partic~oes xas s~ao pouco atrativas quando a a rea de mem oria e escassa pois muita mem oria e perdida por programas muito menores que o tamanho da partic~ao. Assim sendo, um novo sistema de ger^encia de mem oria foi desenvolvido, chamado ger^encia com partic~oes variaveis. Quando partic~oes vari aveis s~ao usadas, o n umero e tamanho de processos na mem oria varia dinamicamente. A Figura 3.2 mostra como partic~oes vari aveis trabalham. Inicialmente, somente o processo A est a na mem oria. 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.
Ger^encia de Memoria
Ger^encia com Permuta 3.2]
para compactar toda a mem oria. Certos mainframes utilizam hardware especial para a compactac~ao da mem oria. Um ponto negativo neste m etodo de ger^encia e saber o quanto de mem oria alocar para um processo. Se os processos s~ao criados com um tamanho xo que permanece constante ao longo de sua execuca~o, ent~ao a alocac~ao e simples: aloca-se exatamente o necess ario ao tamanho do processo, nem mais nem menos. Na pr atica, os segmentos de dados e pilha de um processo tendem a crescer durante a sua execuca~o. Alocac~ao din^amica de mem oria 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 mem oria 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 est a adjacente a outro processo, o primeiro dever a ser movido para um buraco grande o suciente para armazen a-lo, ou um ou mais processos ter~ao que ser movidos para disco com o intuito de criar espaco na mem oria. Se o processo n~ao puder crescer na mem oria e a a rea do disco reservada para abrigar processos permutados estiver cheia, o processo deve ser terminado.
3.2.2 Ger^encia com Mapa de Bits
Com um mapa de bits, a mem oria e dividida em unidades de alocac~ao, desde um pequeno n umero de palavras at e 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 mem oria e o correspondente mapa de bits. A
B
C
8
C
C
C
C
B
B
.... 24
C 11111000 11111111 10011111
B
D 16
(a)
B E
A
sistema operacional (a)
A
A
sistema operacional
sistema operacional
(b)
(c)
sistema operacional (d)
D
D
D
sistema operacional
sistema operacional
sistema operacional
(e)
(f)
(b) A P
(g)
Figura 3.2: Organizac~ao com swapping: mudancas na alocac~ao de mem oria com processos chegando e deixando a mem oria (regi~oes escuras representam espaco n~ao usado) A principal diferenca entre partic~oes xas da Figura 3.1 e partico~es vari aveis da Figura 3.2 e que o n umero, a localizaca~o e o tamanho das partic~oes variam dinamicamente ao longo do tempo. A exibilidade de n~ao se ter um n umero xo de partic~oes aumenta a utilizac~ao da mem oria, mas tamb em complica a tarefa de alocar e liberar a mem oria, bem como gerenci a-la. E poss vel combinar todos os buracos disjuntos num u nico espaco dispon vel agrupando-se todos processos para um lado da mem oria. Est a t ecnica e conhecida como compactaca~o 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 mem oria e que pode copiar 1 Byte por s (1 MByte/s), gasta um segundo
18
c 1996
0
B 5
B
6
8
p
C
9 14
P 15 17
D B 18 19
P 20 25
P: processo B: buraco (c)
Figura 3.3: Organizac~ao com mapa de bits: (a) parte da mem oria com 5 processos e 3 buracos (as marcas mostram as unidades de alocac~ao da mem oria 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 mem oria requer somente 1 bit no mapa (3% da mem oria). Se a unidade de alocac~ao for escolhida grande, o mapa de bits ser a pequeno, mas mem oria consider avel pode ser desperdicada se o tamanho do processo n~ao for um m ultiplo exato da unidade de alocac~ao. DCA/FEEC/UNICAMP
19
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Ger^encia de Memoria
Memoria Virtual 3.3]
Um mapa de bits (ocupando uma porc~ao xa da mem oria) prov^e uma maneira simples de gerenciar mem oria, uma vez que o tamanho do mapa de bits depende somente do tamanho da mem oria 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 mem oria, o gerenciador de mem oria 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 pr atica.
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 mem oria, uma vez que um segmento livre tem de ser removido da lista de processos e inserido na lista de buracos. Novamente, a ineci^encia est a em se determinar poss veis fus~oes.
3.2.3 Ger^encia com Listas Encadeadas
3.2.4 Alocac~ao de Espaco para Permuta
Outra maneira de gerenciar a mem oria e manter uma lista de alocac~oes e segmentos de mem oria livre, onde um segmento e um processo ou um buraco entre dois processos. A mem oria da Figura 3.3(a) e representada na mesma gura (c) como uma lista encadeada de segmentos. Cada entrada da lista especica um buraco (B) ou um processo (P), contendo o endereco onde comeca, onde termina (ou tamanho do bloco), e um ponteiro para a pr oxima entrada da lista. Neste exemplo, a lista de segmentos e mantida ordenada por enderecos. A vantagem desse m etodo 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, v arios algoritmos podem ser usados para alocar mem oria, a m de criar ou permutar processos. Tais algoritmos s~ao evocados quando o gerenciador de mem oria necessita um segmento de mem oria de bytes. M
Algoritmo First-t E o algoritmo mais simples. O algoritmo procura ao longo da lista de segmentos
at e 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 mem oria n~ao usada (de tamanho ; ). First-t e um algoritmo r apido pois naliza a busca o mais cedo poss vel. M
N > M
M
N
M
Os algoritmos apresentados acima mant^em o rastreamento da mem oria principal. Assim, quando processos s~ao permutados do disco para a mem oria, o sistema pode alocar espaco em mem oria para eles. Em alguns sistemas, quando um processo est a na mem oria, nenhum espaco em disco e a ele reservado. Quando for movido da mem oria, espaco deve ser alocado na area de disco para abrig a-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 mem oria 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 mem oria d a 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 t ecnica e mais eciente que a anterior pois uma u nica alocac~ao de espaco em disco por processo e necess aria (lembre-se que um processo pode ser permutado v arias vezes durante a sua execuc~ao). Entretanto, uma area maior de disco deve ser reservada para swapping.
3.3 Memoria Virtual
pr oximo de . E um algoritmo lento e cria na mem oria buracos pequenos que dicilmente 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 alocar a o buraco 5, e o best t o buraco 18.
Desde o in cio da inform atica, o tamanho dos programas vem superando a quantidade de mem oria dispon vel para abrig a-los. A soluc~ao usualmente adotada era dividir o programa em partes, chamados overlays, que eram mantidas em disco e permutadas para a mem oria pelo sistema operacional. Overlays apresentavam um problema: a partic~ao do programa era deixada a cargo do programador. Um m etodo que foi desenvolvido para deixar o particionamento do programa a cargo do sistema operacional veio a ser conhecido como memoria virtual. A id eia b asica e que a combinac~ao do tamanho do programa, dados e pilha, pode exceder a quantia de mem oria f sica dispon vel. O sistema operacional mant em aquelas partes do programa correntemente em uso na mem oria principal e o resto no disco. Mem oria virtual pode tamb em trabalhar em um sistema com multiprogramac~ao. De fato, mem oria virtual e multiprogramac~ao est~ao intimamente relacionadas. Enquanto um programa est a esperando que parte de seu espaco de enderecamento seja trazido a mem oria, o programa e bloqueado, aguardando E/S. At e que a operac~ao de E/S seja completada, a CPU pode ser direcionada para outro processo.
Algoritmo Quick-t Este algoritmo mant em listas separadas para tamanhos comumente requeridos.
3.3.1 Paginac~ao
Algoritmo Next-t Este algoritmo trabalha da mesma forma que o rst-t, exceto que guarda a
posic~ao da lista onde o u ltimo buraco foi alocado. Da pr oxima vez que e chamado, o algoritmo comeca a procurar a partir deste ponto.
Algoritmo Best-t Este algoritmo procura pela lista inteira e toma o buraco de tamanho mais M
M
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 classicar 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 mem oria rapidamente se fragmentar a em um grande n umero de pequenos buracos n~ao utiliz aveis. 20
c 1996
A maioria dos sistemas com mem oria virtual usa uma t ecnica chamada paginac~ao. Em qualquer computador existe certo conjunto de enderecos de mem oria 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 mem oria virtual, o endereco virtual e colocado DCA/FEEC/UNICAMP
21
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Ger^encia de Memoria
diretamente no barramento de mem oria e causa uma palavra da mem oria f sica com mesmo endereco ser lida ou escrita. Quando mem oria virtual e usada, os enderecos de mem oria n~ao v~ao diretamente para o barramento de mem oria. Ao inv es disso, eles v~ao a unidade de ger^encia de mem oria (Memory Management Unit, MMU), onde um hardware espec co mapeia os enderecos virtuais nos enderecos da mem oria f sica como ilustrado na Figura 3.4.
Memoria Virtual 3.3] espaço de endereçamento virtual (tabela)
espaço de endereçamento real (físico)
0 2
0 0-4K
1 1
1 4-8K
2 6
2 8-12K
3
processador
0
3 12-16K
4 4
CPU endereço virtual
4 16-20K
5 memória
3
control. de disco
5 20-24K
6 X
6 24-28K
7
MMU
X
7 28-32K
8 X 9
barramento
5 10
endereço físico
X 11
Figura 3.4: A posic~ao e funca~o da MMU
7 12
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 at e 64 KBytes. Estes s~ao os enderecos virtuais. Este computador, entretanto, tem somente 32 KBytes de mem oria f sica, assim, embora programas de 64K possam ser escritos, eles n~ao podem ser carregados para a mem oria na sua totalidade para serem executados. Uma c opia completa de um n ucleo de imagem do programa, acima de 64K, deve estar presente no disco os pedacos podem ser trazidos para a mem oria pelo sistema a medida que se tornem necess arios. O espaco de enderecamento virtual e dividido em unidades chamadas paginas. As unidades correspondentes na mem oria f sica s~ao chamadas page frames. As p aginas e page frames s~ao sempre do mesmo tamanho. Neste exemplo elas s~ao de 4K, mas tamanhos de p aginas de 512 bytes, 1K, e 2K s~ao comumente usados. Com 64K de espaco de endereco virtual e 32K de mem oria f sica, temos 16 p aginas e 8 page frames. Transfer^encias entre mem oria e disco s~ao sempre feitas em unidades de p aginas. Quando o programa tenta acessar o endereco 0, o endereco virtual 0 e enviado para a MMU. Ela reconhece que este endereco cai na p agina 0 (0 a 4095), o qual, de acordo com seu mapeamento e a page frame n umero 2 (8192 at e 12287). Ele ent~ao transforma o endereco para 8192 e coloca o endereco 8192 no barramento. A tabela de mem oria 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 p agina n~ao mapeada provoca uma falta de p agina (page fault). Neste caso, o sistema operacional libera um page frame e escreve seu conte udo de volta no disco. Ele ent~ao busca a p agina referenciada para o page frame liberado, atualiza o mapa, e retorna a instruca~o interrompida.
3.3.2 Segmentac~ao
Paginaca~o prov^e uma t ecnica para implementaca~o de um grande espaco enderec avel numa mem oria f sica limitada. Este espaco de enderecamento e unidimensional, pois a posic~ao de mem oria e identicada por um u nico valor que vai de 0 at e um endereco m aximo. Esta caracter stica implica que programadores 22
c 1996
X
X: página ausente (em disco) 13
X 14
: página de 4 Kbytes
X 15 X
Figura 3.5: Relac~ao entre endereco virtual e endereco f sico de mem oria, dada pela tabela de paginas ser~ao respons aveis por ter de lembrar onde foram posicionadas areas de dados com func~oes muitas vezes distintas | por exemplo, para c odigo e para tabelas de dados. Al em disto, o crescimento de uma area al em do previsto pode levar a uma situac~ao de choque entre estas areas. Para algumas aplicac~oes, um espaco enderec avel bidimensional e mais conveniente. Esta alternativa e suportada atrav es do conceito de segmentac~ao, onde posic~oes de mem oria s~ao identicadas por um par (segmento, deslocamento). Esta abordagem de segmentac~ao interpreta o espaco de mem oria sob um ponto de vista mais pr oximo da l ogica 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 mem oria. Uma diferenca fundamental e que segmentos t^em dimens~oes distintas, e portanto a informac~ao sobre o comprimento de um segmento tamb em deve ser mantida. O fato de se trabalhar com partic~oes de tamanhos vari aveis implica que ap os um tempo de uso a fragmentac~ao ir a ocorrer, e pode ser necess ario 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 p aginas de tamanho xo, que s~ao trazidas para a mem oria de acordo com a demanda. Atrav es do uso de segmentos e poss vel compartilhar trechos de c odigo que s~ao comuns entre diversas aplicac~oes. Isto e u til, por exemplo, em sistemas de interfaces gr acas, onde grandes bibliotecas s~ao respons aveis pela ger^encia de sistemas de janelas. Al em disto, o uso de segmentos facilita tamb em a DCA/FEEC/UNICAMP
23
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
protec~ao de acesso a a reas da mem oria.
3.4 Algoritmos de Troca de Pagina Quando uma falta de p agina ocorre, o sistema operacional tem que escolher uma p agina para remover da mem oria a m de dar lugar a que ser a trazida do disco. Se a p agina a ser removida foi modicada enquanto estava na mem oria, ela deve ser reescrita no disco para manter a c opia em disco atualizada. Se, todavia, a p agina n~ao tiver sido alterada, a c opia do disco j a est a atualizada, n~ao sendo necess aria sua reescrita. A p agina a ser lida e simplesmente superposta a p agina retirada. Apesar de ser poss vel escolher uma p agina aleat oria para dar lugar a p agina em demanda, o desempenho do sistema e melhorado se for escolhida uma p agina pouco usada (referenciada). Se uma p agina muito usada e removida, ela provavelmente ter a de ser trazida de volta em breve, resultando um esforco adicional. Algoritmos ecientes de troca de p agina visam minimizar este esforco.
3.4.1 Troca O tima de Pagina
O melhor algoritmo de troca de p aginas e f acil de descrever mas imposs vel de implementar. No momento que ocorre uma falta de p agina, um certo conjunto de p aginas est a na mem oria. Uma dessas p aginas ser a referenciada em muitas das pr oxima instruco~es (a p agina contendo a instruc~ao). Outras p aginas n~ao ser~ao referenciadas antes de 10, 100, ou talvez 1000 instruco~es. Cada p agina pode ser rotulada com o n umero de instruc~oes que ser~ao executadas antes que a p agina seja inicialmente referenciada. O algoritmo da p agina otima simplesmente diz que a p agina com o maior r otulo deve ser removida, adiando-se o m aximo poss vel a pr oxima falta de p agina. O u nico problema com este algoritimo e que ele n~ao e realiz avel. No momento da falta de p agina, o sistema operacional n~ao tem como saber quando cada p agina ser a referenciada. No entanto, uma aplicaca~o a posteriori deste algoritmo e u til para comparar o desempenho de algoritmos realiz aveis com o melhor poss vel.
3.4.2 Troca da Pagina N~ao Recentemente Usada (NRU)
Para permitir que o sistema operacional colete estat sticas sobre quais p aginas est~ao sendo usadas e quais n~ao est~ao, muitos computadores com mem oria virtual t^em 2 bits associados a cada p agina. Um bit, R ou bit de refer^encia, e ativado pelo hardware em qualquer leitura ou escrita de p agina. O outro bit, M ou bit de modicac~ao, e ativado pelo hardware quando h a alteraca~o no conte udo de uma p agina. Uma vez que um bit foi ativado, ele permanece ativado at e 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 atrav es das rotinas de tratamento de faltas de p agina e de proteca~o. Quando um processo e iniciado, todas as suas entradas de tabela de p aginas s~ao marcadas como ausentes na mem oria. T~ao logo uma p agina seja referenciada, uma falta de p agina ocorrer a. O sistema operacional ent~ao ativa o bit R (em sua tabela interna), muda a entrada de tabela de p aginas para apontar para a p agina correta com modo READ ONLY e reinicia a instruca~o. Se a p agina e subsequentemente escrita, uma falta de proteca~o da p agina ocorrer a, pemitindo ao sistema operacional ativar o bit M e mudar o modo da p agina para READ/WRITE. Os bits R e M podem ser usados para construir um algoritmo de paginaca~o como se segue. Quando um processo e iniciado, ambos os bits de p agina para todas estas p aginas s~ao declarados 0 pelo sistema operacional. Periodicamente (a cada interrupca~o de rel ogio | tipicamente 20 mseg), o bit R e zerado, 24
c 1996
Ger^encia de Memoria
Algoritmos de Troca de Pagina 3.4]
para distinguir p aginas que n~ao foram referenciadas recentemente daquelas que tenham sido. Quando uma falta de p agina ocorre, o sistema operacional examina todas as p aginas e as classica em quatro categorias baseado nos valores correntes de seus bits RM : Classe 0 (00) n~ao referenciada, n~ao modicada. Classe 1 (01) n~ao referenciada, modicada.
Classe 2 (10) referenciada, n~ao modicada. Classe 3 (11) referenciada, modicada. Ainda que as p aginas na classe 1 parecam, a primeira vista, imposs veis de existir, elas ocorrem quando as p aginas da classe 3 t^em seu bit R zerado pela interrupc~ao do rel ogio. Interrupc~oes de rel ogio n~ao zeram o bit M porque esta informac~ao e necess aria para determinar se uma p agina ter a que ser reescrita no disco ou n~ao. O algoritimo N~ao Recentemente Usada (NRU) remove uma p agina aleat oria da classe n~ao vazia de numerac~ao mais baixa. A estrat egia impl cita neste algoritmo e que e melhor remover uma p agina modicada que n~ao foi referenciada pelo menos no u ltimo tick de rel ogio, que uma p agina n~ao modicada mas muito usada. As caracter sticas principais do NRU e que ele e f acil de entender, eciente de se implementar, e gera um desempenho que, enquanto certamente n~ao otimo, e geralmente tido como adequado.
3.4.3 Troca da Pagina FIFO
O algoritmo de paginac~ao First-In-First-Out (FIFO) e similar ao NRU. O sistema operacional mant em uma lista de todas as p aginas correntes na mem oria, sendo a p agina da cabeca da lista a mais velha e a p agina do m a instalada mais recentemente. Em uma falta de p agina, a p agina da cabeca e removida e a nova p agina acrescentada no m da lista. Uma simples modicac~ao no FIFO para evitar o problema da retirada de uma p agina muito usada e o algoritmo Segunda Chance. A id eia e primeiro examinar a p agina mais velha como uma v tima potencial. Se seu bit R e 0, a p agina e trocada imediatamente. Se o bit R e 1, o bit e zerado e a p agina e colocada no m da lista de p aginas, como se estivesse acabado de chegar a mem oria. Ent~ao a pesquisa continua. O que o Segunda Chance faz e procurar por uma p agina velha que n~ao tem sido referenciada no tick de rel ogio anterior. Se todas as p aginas tiverem sido referenciadas, o algoritmo degenera-se e torna-se simplesmente um FIFO.
3.4.4 Troca da Pagina Menos Recentemente Usada (LRU)
Uma boa aproximac~ao para o algoritmo otimo e baseada em uma observac~ao comum que as p aginas muito usadas nas u ltimas instruc~oes provavelmente ser~ao usadas nas pr oximas instruc~oes. Da mesma forma, p aginas que n~ao t^em sido usadas por um longo tempo provavelmente continuar~ao sem uso. Esta observac~ao sugere um algoritmo realiz avel: quando ocorre uma falta de p agina, retira-se a p agina que n~ao tem sido usada por um tempo longo. Esta estrat egia e chamada de Menos Recentemente Usada (Least Recently Used, LRU). Embora o algoritmo LRU seja teoricamente realiz avel, seu custo e alto. Para implementac~ao completa do LRU, e necess ario manter uma lista ligada de todas as p aginas em mem oria, com a p agina mais recentemente usada no in cio e a menos recentemente usada no nal. A diculdade e que a lista deve DCA/FEEC/UNICAMP
25
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
ser atualizada em toda refer^encia de mem oria. Encontrar a p agina 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, at e mesmo em hardware. Entretanto, h a outras maneiras de implementar LRU com um hardware especial. Vamos considerar o caminho mais simples primeiro. Este m etodo requer equipar o hardware com um contador de 64 bits, C, que e automaticamente incrementado ap os cada instruc~ao. Al em disso, cada entrada na tabela de p aginas deve tamb em ter um campo grande o bastante para conter o contador. Ap os cada refer^encia de mem oria, o valor corrente de C e armazenado na entrada da tabela de p aginas para a p agina referenciada. Quando ocorre uma falta de p agina, o sistema operacional examina todos os contadores na tabela de p aginas para achar o menor deles. A p agina correspondente e a menos recentemente usada. Agora vejamos um segundo algoritmo LRU, tamb em em hardware. Para uma m aquina 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 bin ario e menor, e a menos recentemente usada, a linha na qual o valor e o pr oximo 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 realiz aveis, eles s~ao dependentes de hardware especial, e s~ao de pouco uso para o projetista de sistema operacional construindo um sistema para uma m aquina que n~ao disp~oe deste hardware. Uma soluca~o que pode ser implementada em software faz-se necess aria. Uma possibilidade e o algoritmo chamado de N~ao Frequentemente Usada (NFU). O algoritmo NFU requer um contador em software associado a cada p agina, inicialmente zero. Em cada tick de rel ogio, o sistema operacional pesquisa todas as p aginas na mem oria. Para cada p agina, 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 p agina tem sido referenciada. Quando uma falta de p agina ocorre, a p agina com o menor contador e escolhida para substituic~ao. O principal problema com o NFU e que ele nunca esquece refer^encias anteriores. P aginas muito (e n~ao mais) refenciadas no comeco da execuc~ao de um programa permanecem com um contador alto at e o nal da execuc~ao. Felizmente, uma pequena modicaca~o no NFU faz com que este seja capaz de simular LRU muito bem (o algoritmo modicado e denominado Aging ). A modicac~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 p agina, a p agina de menor contador e removida. E obvio que a p agina que n~ao tenha sido referenciada por, digamos, quatro ticks de rel ogio ter a quatro zeros signicativos em seu contador, tendo assim um valor mais baixo que o contador de uma p agina que tenha sido referenciada nos quatro u ltimos ticks de rel ogio. Uma diferenca entre LRU e Aging e que no u ltimo os contadores t^em um n umero nito de bits (tipicamente 8). Portanto, n~ao podemos classicar as p aginas segundo refer^encias anteriores a capacidade do contador.
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 mem oria. Vers~oes atuais empregam o esquema de paginac~ao por 26
c 1996
Ger^encia de Memoria
Ger^encia de Memoria no UNIX 3.5]
demanda. Este esquema requer do hardware a possibilidade de reiniciar uma instruc~ao interrompida pela aus^encia de p agina cujo endereco foi referenciado na instruc~ao. Assim que a p agina e trazida para a mem oria, a instruc~ao interrompida e reiniciada. No esquema de paginac~ao por demanda, o espaco virtual de enderecamento e muito superior a quantidade de mem oria f sica dispon vel, sendo limitado apenas pelo capacidade de enderecamento virtual da MMU. O n ucleo mant em quatro estruturas principais para ns de ger^encia de mem oria: tabela de p aginas, tabela de frames, descritores de blocos e tabela de uso de swap. A tabela de p aginas tem como entrada o n umero da p agina. Deve-se notar que esta tabela tem dimens~ao xa pois a quantidade de p aginas e igual a dimens~ao f sica de mem oria dividida pelo tamanho da p agina. Cada entrada na tabela possui campos descrevendo, entre outras informac~oes, o endereco f sico de mem oria que cont em os dados referentes a p agina, a idade da p agina (i.e., por quantos ciclos esta p agina est a ativa na mem oria), os ags de refer^encia, modicac~ao, validade e protec~ao. A tabela de frames armazena dados adicionais a p agina, tais como o endereco f sico de mem oria que cont em os dados referentes a p agina, um contador de refer^encia indicando quantos processos compartilham esta p agina em mem oria, e o n umero do bloco alocado a p agina. Finalmente, a tabela de uso de swap e acessada tendo como ndice o dispositivo de swap e n umero do bloco neste dispositivo. Esta tabela armazena apenas um contador de refer^encia indicando quantas p aginas se utilizam deste bloco em disco. Deve-se notar que algumas informac~oes s~ao replicadas em tabelas distintas. Esta replicac~ao visa beneciar a eci^encia do esquema de paginac~ao, diminuindo o n umero de consultas as tabelas. O processo paginador remove da mem oria p aginas n~ao referenciadas pelos processos por um longo tempo. Quando executado, o processo vai montando uma lista de p aginas candidatas a permuta (Figura 3.6). O processo paginador zera o bit de refer^encia da p agina, como descrito na Sec~ao 3.4.2. Uma p agina e candidata a permuta quando seu contador de refer^encia foi zerado h a um determinado n umero de passadas do processo paginador. Se uma p agina candidata a permuta e novamente referenciada, a mesma e removida da lista. página referenciada (idade zerada) página pronta para swap página em
1
2
3
....
n
memória página não refenciada (idade aumentando)
página em swap-in
disco
swap-out
Figura 3.6: Fila de p aginas candidatas a permuta O processo paginador e ativado quando a quantidade de mem oria dispon vel atinge um limite m nimo. P aginas s~ao ent~ao removidas da mem oria e gravadas em disco at e que um limiar de mem oria livre seja atingido. Ao gravar uma p agina em disco, o processo paginador apaga o bit de validade da p agina e decrementa seu contador de refer^encia na tabela de frames. Se o contador de refer^encia vai a zero (indicando que um u nico processo estava utilizando a p agina), o n ucleo adiciona o campo da tabela de frames referente a p agina numa lista de p aginas livres. O conte udo de uma p agina na lista de p aginas livres continua v alido at e que o sistema associe a p agina a outro processo. Mesmo na lista de p aginas livres, uma p agina DCA/FEEC/UNICAMP
27
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
pode ser revalidada (sem necessidade de traz^e-la do disco) caso um processo torne a referenci a-la. Neste caso, a p agina e removida da lista de p aginas livres, tendo seu bit de validade reativado.
Ger^encia de Memoria
Ger^encia de Memoria em MS-DOS 3.6]
alocac~ao desejado | rst t, best t ou last t | e outro para indicar se a area de mem oria superior deve ou n~ao ser inclu da na busca por um bloco de mem oria livre.
3.6 Ger^encia de Memoria em MS-DOS A ger^encia de mem oria em MS-DOS apresenta um modelo razoavelmente complexo, em parte pela arquitetura de mem oria 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 est a relacionada com a caracter stica de compatibilidade de c odigo 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 mem oria, mantinha um esquema de enderecamento baseado em 16 bits a m de manter compatibilidade com c odigo desenvolvido para o 8080. Desta forma, foi introduzido o conceito de segmentos com o limite m aximo 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 (ap os 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 mant em 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 mem oria f sica | 16M para o 80286 e 4 GBytes para 80386 e posteriores. A mem oria acima de 1M e chamada de memoria estendida. MS-DOS n~ao pode fazer uso diretamente desta area de mem oria, 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 denidos. O sistema operacional suporta um esquema em software, atrav es de chamadas de sistemas que permitem a execuc~ao de programas em overlays. O outro esquema, em hardware, partiu de um cons orcio entre Lotus, Intel e Microsoft para desenvolver um esquema alternativo de mem oria. Este esquema foi denominado sistema de memoria expandida (EMS), que permitiu que mesmo um processador 8088 pudesse utilizar grandes mem orias f sicas. Neste caso, a mem oria est a sicamente alocada em placas de extens~ao de mem oria (desenvolvidas pela Intel), e pode ser acessada por aplicativos como Lotus 1-2-3 e o pr oprio MS-DOS. A placa de mem oria expandida cont em registros que mapeiam um espaco de enderecamento virtual de 640K para a mem oria sicamente maior, permitindo que programas trabalhassem com dados acima do limite de 640 KBytes. Em processadores 80386 e posteriores, o pr oprio hardware suporta o mecanismo de paginac~ao necess ario, e a mem oria estendida pode ser utilizada para simular a mem oria expandida sem necessidade de placas especiais. MS-DOS suporta chamadas do sistema para alocar e liberar blocos de mem oria, assim como para modicar o tamanho de um bloco j a alocado. H a tamb em um mecanismo para especicar o tipo de 28
c 1996
DCA/FEEC/UNICAMP
29
Sistema de Arquivos
Cardozo, Magalh~aes, Faina & Ricarte
Captulo 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 (atrav es de chamadas de sistema) para criar, ler, gravar e remover arquivos. Usu arios utilizam interativamente o sistema de arquivos (atrav es 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 conabilidade de seu sistema de arquivos. Do ponto de vista do usu ario, 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 identicados 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 ocupaca~o do espaco em disco e bom desempenho nas operac~oes sobre arquivos.
4.1 Interface do Sistema de Arquivos A maior parte dos sistemas operacionais traz a seguinte proposta para armazenagem de informaca~o: permitir aos usu arios denir objetos chamados arquivos, que podem armazenar programas, dados, ou qualquer outra informaca~o. Estes arquivos n~ao s~ao parte enderec avel de nenhum processo e o sistema operacional suporta operaco~es 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 especicar 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 c odigo especial para explicitar o tipo de perif erico. 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 usu ario deve especicar em qual dispositivo cada arquivo se encontra (exceto quando um dispositivo e default e for omitido). A maior parte dos sistemas operacionais suportam v arios tipos de arquivos | por exemplo, arquivos regulares, diret orios e arquivos especiais. Arquivos regulares cont em dados e programas do usu ario. Diret orios permitem identicar arquivos atrav es de nomes simb olicos (sequ^encia de caracteres ASCII). Arquivos especiais s~ao usados para especicar perif ericos tais como terminais, impressoras e unidades de ta. 30
c 1996
Projeto do Sistema de Arquivos 4.2]
Em muitos sistemas, arquivos regulares s~ao subdivididos em diferentes tipos em func~ao de sua utilizac~ao. Os tipos s~ao identicados 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 usu ario identicar o tipo de conte udo no arquivo. Em outros, o sistema operacional tem regras r gidas em relac~ao aos nomes | por exemplo, \o sistema n~ao executar a um arquivo a menos que sua extens~ao seja .BIN." Diretorios, os quais em muitos casos s~ao tamb em arquivos, permitem organizar os arquivos de um sistema. Um diret orio cont em tipicamente um registro por arquivo. Sistemas primitivos admitiam um u nico diret orio compartilhado por todos os usu arios, ou um u nico diret orio por usu ario. Os sistemas operacionais modernos permitem um n umero arbitr ario de diret orios por usu ario (em geral, formando uma hierarquia). Quando o sistema de arquivos e organizado como uma arvore de diret orios, algum meio se faz necess ario para especicar nomes de arquivos. Dois m etodos s~ao comumente empregados. No primeiro m etodo, cada arquivo e identicado pela sequ^encia de diret orios desde o diret orio raiz at e o arquivo (caminho absoluto). Nomes absolutos para caminhos sempre comecam na raiz e s~ao u nicos. Uma outra forma de especicar nomes de arquivos e atrav es de seu caminho relativo. E usado em conjunto com o conceito de diret orio de trabalho (ou diret orio corrente). Um usu ario pode designar um diret orio como diret orio corrente. Neste caso, todos os caminhos s~ao referenciados a partir do diret orio 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 est a associada a velocidade de rotac~ao do disco. Como estes tempos s~ao muito mais lentos que a velocidade de processamento, um acesso ineciente pode tornar a utilizac~ao do sistema demasiadamente baixa.
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 estrat egias 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 n umero de blocos n~ao necessariamente cont guos1. Quando blocos de tamanho xo s~ao adotados, e necess ario denir qual o tamanho do bloco. Uma unidade de alocac~ao grande, tal como um cilindro, implica que muitos arquivos, at e mesmo arquivos de 1 byte, dever~ao ocupar o cilindro inteiro. Por outro lado, usar uma unidade de alocac~ao pequena signica que cada arquivo ter a 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 ir a ler ou escrever em dois setores consecutivos, e trat a-los como uma unidade indivis vel. n
n
1
A mesma poltica esta presente no sistema de ger^encia de memoria entre a segmentac~ao pura e a paginac~ao.
DCA/FEEC/UNICAMP
31
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Sistema de Arquivos
A escolha da estrat egia de alocaca~o 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 organizaca~o.
Alocac~ao Cont gua Nesta estrat egia, a posic~ao inicial onde o arquivo est a armazenado no disco e seu
tamanho s~ao as u nicas informac~oes necess arias para permitir o acesso ao seu conte udo. A transfer^encia dos dados, uma vez que o posicionamento inicial j a tenha sido completado, e r apido, 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 ter a que ser movido no disco. Embora o problema seja o mesmo que ocorre em ger^encia de mem oria por segmentaca~o, neste caso o impacto no desempenho e muito maior.
Listas Ligadas de Blocos Quando a estrat egia de alocaca~o em blocos e adotada, uma primeira
possibilidade de se conectar os blocos de um mesmo arquivo e atrav es da manutenca~o de apontadores de um bloco para o pr oximo. Assim, em cada bloco a primeira palavra indica qual o pr oximo bloco da lista, e o restante e a area de dados. A grande vantagem desta estrat egia e evitar a fragmentac~ao que ocorre no uso de alocac~ao cont gua. No entanto, acessos a posico~es arbitr arias 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.
Listas Ligadas com Indice Nesta estrat egia, os apontadores para pr oximo bloco s~ao mantidos em um ndice (ou tabela) que e trazido a mem oria principal. Desta forma, percorrer uma lista de blocos para alcancar uma posica~o arbitr aria torna-se uma operaca~o r apida, que e realizada sem acessos ao disco. A desvantagem deste m etodo e que todo o ndice deve ser alocado a mem oria principal, o que pode ocupar um espaco consider avel de mem oria para discos com grande capacidade.
Nos Indices Neste caso, cada arquivo tem uma pequena tabela de ndices chamada de i-node que
mant em os enderecos em disco dos blocos que comp~oem o arquivo. Quando um arquivo e aberto pela aplicac~ao, o seu n o ndice e lido para a mem oria. Os enderecos dos primeiros blocos do arquivo s~ao mantidos no pr oprio i-node, de forma que o acesso a pequenos arquivos e eciente. Os u ltimos enderecos do i-node n~ao apontam diretamente para blocos de dados, mas para blocos contendo enderecos de outros blocos. Em geral, h a um apontador para enderecos indiretos simples (o bloco apontado cont em enderecos de blocos de dados), outro para enderecos indiretos duplos (o bloco apontado cont em 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 u ltimo n vel de acesso indireto.
Ger^encia de Espaco Livre Outra quest~ao importante para o projetista e como manter a informac~ao
sobre blocos livres no disco | informac~ao que ser a fundamental quando a aplicac~ao requisitar a escrita de dados em arquivos. Dois m etodos 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 t ecnica 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
32
c 1996
Projeto do Sistema de Arquivos 4.2] 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
410 312
654 318
597 873
1001001001011001 0000100100011000 0011001110100100 1000000100001001 0000000000001000
0100001100000011 1111000011000010 (b)
(a)
Figura 4.1: Organizac~ao de blocos livres: (a) blocos livres armazenados em lista ligada (b) um mapa de bits.
4.2.2 Estrutura de Diretorio
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 necess arias para prosseguir com as operac~oes de acesso ao arquivo. Estas informac~oes adicionais s~ao mantidas nos arquivos diret orios. A estrat egia de organizac~ao de arquivos em diret orios mais simples e manter um diret orio u nico. Assim, a localizac~ao de um arquivo reduz-se a procura neste u nico diret orio. Encontrado o registro do arquivo, tem-se o n umero de blocos do disco, posto que estes s~ao armazenados no pr oprio registro. Se o arquivo utiliza mais blocos de disco que o permitido no registro, o arquivo ter a registros adicionais no diret orio. Informac~oes usualmente mantidos s~ao nome, tipo, usuario (durante a busca, apenas os registros pertencentes ao usu ario corrente s~ao considerados), tamanho e contador de bloco (indica qual bloco est a em uso). Campos adicionais cont^em os n umeros dos blocos de disco que comp~oem o arquivo. Outra estrat egia e a organizac~ao de sistemas de diret orio em arvore (hier arquicos). Neste caso, todo diret orio (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 diret orio raiz, que e mantido em um lugar xo no disco. Ent~ao, procura-se pelo arquivo (diret orio) que e o primeiro componente do caminho, e neste diret orio procura pelo pr oximo componente, at e encontrar a entrada para o arquivo sendo aberto. Nomes de caminhos relativos s~ao pesquisados de forma id^entica, apenas partindo do diret orio de trabalho em vez de partir-se do diret orio raiz. Todos os diret orios t^em registros para . e .., criados juntamente com o diret orio, para indicar respectivamente o diret orio corrente e o diret orio pai. Nenhum mecanismo especial e necess ario para manipular estes nomes. N~ao raro, e conveniente que um mesmo arquivo (ou diret orio) pertenca simultaneamente a diferentes usu arios. A associac~ao entre um diret orio e um arquivo pertencente a outro diret orio 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 diret orio D1 deve tamb em ser visto por um diret orio D2. O link simb olico ser a uma entrada no diret orio 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
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Sistema de Arquivos
O Sistema de Arquivos do Unix 4.3]
Outra possibilidade depende da utilizaca~o de n os ndice para a organizaca~o de arquivos no disco. Neste caso, a entrada do diret orio armazena apenas o apontador para o n o ndice do arquivo compartilhado, e o n o ndice deve manter um contador de quantas refer^encias s~ao feitas ao arquivo (de modo a garantir consist^encia ap os operac~oes de remoca~o).
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 ter a 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 Conabilidade do Sistema de Arquivos
Blocos perdidos: 0 em ambos contadores, ou seja, blocos que n~ao ocorrem em nenhuma das tabelas.
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 conabilidade deste sistema.
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^e a 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 ter a efeito em seu respectivo bloco sobressalente. A soluc~ao em software requer que o usu ario 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 estrat egia engenhosa para tratar os blocos defeituosos, e importante se
proceder backups frequentes. Sistemas de arquivos em discos de pequena capacidade podem ser salvos em ta magn etica, por exemplo, tas padr~ao de 9 trilhas (com capacidade de 50 Megabytes por bobina) ou ta de 8 mm (com capacidade de at e 4 Gigabytes). Para discos de grande capacidade, salvar o conte udo 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 modicados deste o u ltimo backup completo. Num outro esquema, mais eciente, copia-se apenas aqueles arquivos que foram alterados desde o u ltimo backup. Para implementar este m etodo, o hor ario da u ltima duplicaca~o para cada arquivo deve ser mantida no disco.
4.2.4 Consist^encia do Sistema de Arquivos
Outro t opico envolvendo conabilidade e a consist^encia do sistema de arquivos. Muitos sistemas de arquivos l^eem blocos, modicam-nos, e os regravam mais tarde. Se o sistema falha antes que todos os blocos modicados 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 diret orio, ou blocos contendo a lista de blocos livres. Para vericar a consist^encia do sistema de arquivos, muitos sistemas operacionais utilizam programas utilit arios 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 utilit ario constr oi 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 utilit ario 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
A soluc~ao para blocos perdidos e simples: o vericador do sistema de arquivos acrescenta-os na lista de blocos livres.
Bloco livre e ocupado: 1 em ambos contadores. A soluc~ao tamb em e simples: remover o bloco da lista livre.
Blocos multiplamente livres: 0 no contador de blocos ocupados e um valor maior que 1 no contador
de blocos livres. A soluc~ao neste caso tamb em e simples: reconstruir a lista de blocos livres, eliminando-se as duplicac~oes.
Blocos multiplamente ocupados: 0 no contador de blocos livres e um valor maior que 1 no contador
de blocos ocupados. Este e o tipo de falha mais grave. A ac~ao apropriada do utilit ario e alocar um bloco livre, copiar o conte udo do bloco duplicado nele, e inserir a c opia 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 ser a informado para permitir ao usu ario examinar a falha.
4.3 O Sistema de Arquivos do Unix Todo arquivo no Unix System V cont em um u nico i-node. O i-node possui as informac~oes necess arias para um processo acessar um arquivo, tais como: propriet ario 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, atrav es deste, o n ucleo determina o i-node do arquivo. Um i-node existe estaticamente no disco e o n ucleo realiza a sua leitura para a mem oria quando necessita manipul a-lo. O i-node no disco cont em os seguintes campos (Figura 4.2):
identicador do dono do arquivo: dividido em dono individual e grupo tipo do arquivo: regular, diret orio, especial ou FIFO (pipes) permiss~ao de acesso instantes de acesso ao arquivo: u ltima modicac~ao, u ltimo acesso e u ltima modicac~ao ocorrida no i-node
n umero 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 n umeros para blocos. Os 10 primeiros DCA/FEEC/UNICAMP
35
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
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
ponteiro para blocos de dados
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 mem oria). write: escreve dados num arquivo (de um bu"er em mem oria). lseek: altera a posic~ao corrente de leitura/gravac~ao no arquivo. chdir: altera o diret orio corrente. chown: altera o usu ario 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 proprietário grupo do proprietário tamanho do arquivo data da criação data do último acesso data da última modificação
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 c odigo de boot. Ap os 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 c odigo especial nesta tabela. A Figura 4.3 ilustra a organizac~ao da FAT no MS-DOS. Figura 4.2: Estrutura de i-node
FAT
n umeros (blocos diretos) cont em n umeros para blocos de disco os tr^es n umeros 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 n ucleo 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 n umero de bloco no i-node ) e continua at e o n umero de bloco l ogico correspondente ao tamanho do arquivo. Quando da abertura de um arquivo, o sistema operacional utiliza o nome (path) do arquivo fornecido pelo usu ario para localizar os blocos do disco associados ao arquivo. O mapeamento do nome nos i-nodes est a associado a forma como o sistema de diret orio encontra-se organizado. A estrutura de diret orio usada no Unix e extremamente simples. Cada entrada cont em o nome do arquivo e o n umero do seu i-node. Todos os diret orios do Unix s~ao arquivos e podem conter um n umero arbitr ario destas entradas. Quando um arquivo e aberto, o sistema deve, atrav es do nome do arquivo, localizar os seus blocos no disco. Caso o nome do arquivo seja relativo, o n ucleo acessa primeiro o i-node associado ao diret orio corrente. Cada arquivo no Unix e identicado por um descritor de arquivos (um n umero inteiro). Descritores de arquivos identicam arquivos univocamente a n vel de processo, isto e, dois arquivos abertos pelo mesmo processo possuem descritores necessariamente diferentes. Rotinas do n ucleo do sistema operacional operam com estes descritores. As principais chamadas de sistema referentes ao sistema de arquivos s~ao: 36
c 1996
x
0
x
1
EOF
2
13
3
2
4
9
5
} tamanho do disco
8
6
FREE
7
4
8
12
9
3
10
FREE
11
EOF
12
EOF
13
EOF
14
BAD
15
6
8
4
5
9
12
10
3
13
2
Figura 4.3: Estrutura da FAT Cada entrada no diret orio 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 u ltima atualizac~ao ocupam dois bytes cada. Os dois u ltimos campos indicam o endereco do primeiro bloco (2 DCA/FEEC/UNICAMP
37
Cardozo, Magalh~aes, Faina & Ricarte
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
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.
Captulo 5 Entrada e Sada 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 tamb em prover uma interface entre os dispositivos e o resto do sistema, que seja simples e f acil de usar (se poss vel, a interface deve ser a mesma para todos os dispositivos). O c odigo de entrada e sa da representa uma frac~ao signicativa do total do sistema operacional. A forma como o sistema operacional gerencia E/S e o objeto deste cap tulo.
5.1 Princpios 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.
5.1.1 Dispositivos de E/S
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 pr oprio 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 enderec avel e n~ao aceita operaco~es 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 classicac~ao n~ao e perfeito. Alguns dispositivos n~ao s~ao enquadrados nele. Rel ogios, por exemplo, n~ao s~ao enderec aveis 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 suciente 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
c 1996
DCA/FEEC/UNICAMP
39
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
5.1.2 Controladores de Dispositivos
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 pr oprio 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, j a que o sistema operacional v^e o controlador, n~ao o dispositivo. Normalmente, minicomputadores e microcomputadores usam um barramento u nico (Figura 5.1) para comunicac~ao entre CPU e os controladores. Mainframes frequentemente usam um modelo diferente, no qual m ultiplos barramentos e computadores especializados de E/S, chamados canais de E/S, aliviam parte da carga da CPU. unidades de disco
impressora interface controlador-dispositivo
CPU
memória
controlador de disco
controlador de impressora
outros controladores
barramento
Figura 5.1: Um modelo para conex~ao da CPU, mem oria, 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 c odigo de correca~o de erro. O pre^ambulo e escrito quando o disco e formatado, e cont em o n umero 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 necess aria. O bloco de bytes e tipicamente primeiro montado, bit por bit, em um buer mantido no controlador. Ap os o checksum ter sido vericado e o bloco declarado livre de erro, ele pode ent~ao ser copiado para a mem oria principal. O controlador para o terminal CRT tamb em trabalha como um dispositivo serial de bits e em baixo n vel. Ele l^e da mem oria 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 tamb em gera os sinais para o feixe CRT fazer o retrace horizontal ap os ele ter terminado de esquadrinhar a linha, como tamb em sinais para fazer o retrace vertical ap os a tela toda ter sido esquadrinhada. Se n~ao tiv essemos 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 n umero de caracteres por linha e o n umero de linhas por tela, deixando o controlador tomar conta do direcionador do feixe de raios cat odicos. 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 Sada
Princpios do Software 5.2]
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 tamb em 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 obt em o resultado e o status do dispositivo pela leitura de um ou mais bytes de informac~ao nos registradores do controlador.
5.2 Princpios do Software Os objetivos gerais do software de E/S s~ao f aceis de serem estabelecidos. A id eia b asica e organizar o software como uma s erie de camadas, com as mais baixas escondendo peculiaridades do hardware e as mais altas mostrando-se simples para o usu ario.
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 modicar o programa para cada tipo de dispositivo. De prefer^encia, deve ser poss vel utilizar o programa sem recompil a-lo. Relacionado com a independ^encia do dispositivo est a 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 pr oximo 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 a s 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 at e que chegue uma interrupc~ao. O sistema operacional realiza as operac~oes de forma ass ncrona, mas para o usu ario 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 usu arios ao mesmo tempo. Outros dispositivos, como impressoras, devem ser dedicados a um u nico usu ario at e 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 eciente 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 usu ario. DCA/FEEC/UNICAMP
41
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
5.2.2 Manipuladores de Interrupc~oes
Princpios do Software 5.2]
5.2.4 Software de E/S Independente do Dispositivo
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 at e 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 atrav es do envio de uma mensagem. Em alguns sistemas, isto e conseguido fazendo-se um UP sobre um sem aforo. Seja qual for a forma adotada, o efeito da interrupc~ao e que o processo que estava previamente bloqueado dever a agora estar habilitado para execuc~ao.
5.2.3 Drivers de Dispositivos Todo o c odigo 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 requisico~es 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 est a desocupado no momento, a requisica~o 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 requisica~o para aco~es concretas. Para um disk driver, por exemplo, isto signica informar onde o bloco se encontra no disco, vericar se o motor est a girando, determinar se o braco est a posicionado no cilindro apropriado, e assim por diante. Em poucas palavras, o driver deve decidir quais operaco~es 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. Ap os o comando ou comandos terem sido emitidos, podem ocorrer duas situaco~es. Em muitos casos o device driver deve esperar at e que o controlador execute as operac~oes requisitadas. Se estas operac~oes forem lentas (envolvendo movimentos mec^anicos, por exemplo), o driver bloqueia at e que as operac~oes se completem. Em outros casos, entretanto, as operaco~es s~ao r apidas, situaca~o 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 necess ario e a operac~ao toda pode se completar em alguns microsegundos. Neste ponto, ap os a operaca~o ter sido completada, o driver deve vericar a ocorr^encia de erros. Se tudo estiver correto, ele passa os dados (o bloco lido, por exemplo) para a pr oxima camada do software de E/S. Finalmente, ele retorna alguma informaca~o de status de erros. Se alguma requisic~ao est a na la, uma delas pode agora ser selecionada e iniciada. Se nenhuma est a na la, o driver ca aguardando a pr oxima requisica~o. 42
Entrada e Sada
c 1996
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 eci^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 identicac~ao simb olica 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 b asica 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 usu ario. Uma quest~ao fundamental em um sistema operacional e como objetos tais como os arquivos e dispositivos de E/S s~ao identicados. O software independente do dispositivo se encarrega do mapeamento simb olico dos nomes dos dispositivos para os seus drivers apropriados. Relacionado ao nome est a a protec~ao. Como o sistema previne usu arios de acessar dispositivos que n~ao est~ao autorizados a acessar? Em muitos microcomputadores, n~ao h a nenhuma protec~ao. Em muitos mainframes e superminis, acessos a dispositivos de E/S pelos usu arios 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 v arios setores como um simples bloco l ogico. Deste modo, os n veis superiores somente negociam com dispositivos abstratos que usam o mesmo tamanho de bloco l ogico, 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 usu ario est a livre para ler ou escrever unidades arbitr arias. Para dispositivos de caracter, usu arios podem escrever dados no sistema mais r apido 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 magn eticas, 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
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Entrada e Sada
A manipulac~ao de erros tamb em e feita nesta camada. Um erro t pico e causado por um bloco do disco ruim e que n~ao pode mais ser lido. Ap os o driver tentar ler o bloco v arias vezes, ele informa ao software independente do dispositivo a raz~ao. O erro e ent~ao tratado. Se ocorreu num arquivo do usu ario, e suciente 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.
camada
funcionalidade
processos do usuário
executa operação de E/S
software independente do dispositivo
5.2.5 Software a Nvel do Usuario
drivers de dispositivos
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 usu ario, e at e mesmo com programas inteiros executando fora do n ucleo. Chamadas de sistema, incluindo chamadas do subsistema de E/S, s~ao normalmente feitas por procedimentos da biblioteca. Quando um programa em C cont em a chamada
gerenciadores de interrupção
bytes_lidos = fread(buffer, tam_item, n_itens, arquivo)
o procedimento da biblioteca fread ser a 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, h a 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 usu ario consiste de procedimentos da biblioteca. Outra importante categoria e o sistema spooling. Spooling e o modo de negociaca~o com os dispositivos dedicados de E/S em um sistema com multiprogramac~ao, tais como impressoras. Embora seja f acil permitir que algum processo do usu ario abra o arquivo especial associado a uma impressora, se o processo mantiver o arquivo aberto por v arias horas ent~ao nenhum outro processo poder a imprimir. Ao inv es disso, o que e feito e criar um processo especial, chamado daemon, e um diret orio 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 u nico 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 usu arios, o problema de se ter algu em monopolizando-os e eliminado. Spooling e tamb em 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 diret orio 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.
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 mem oria rotativa, tal como os discos r gidos e ex veis. Nas seco~es seguintes, descreveremos brevemente o hardware do disco, passando para os disk drivers a seguir.
5.3.1 Hardware do Disco
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 n umero de setores na circunfer^encia, tipicamente entre 8 a 32. Todos os setores cont^em o mesmo n umero de bytes, embora 44
Discos 5.3]
c 1996
dispositivos
requisição de E/S
identifição, proteção, bloqueio "bufferização" inicia registradores do dispositivo verifica status da operação desbloqueia o driver quando a operação de E/S se completa
executa fisicamente a operação de E/S
resposta da requisição
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 tamb em 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 m edio de acesso.
5.3.2 Software do Disco
Nesta sec~ao veremos algumas caracter sticas gen ericas 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.
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 estrat egia e poss vel: e prov avel que enquanto o braco est a executando um seek na metade de uma requisica~o, uma outra requisic~ao de disco pode ter sido gerada por outro processo. Muitos disk drivers mant em DCA/FEEC/UNICAMP
45
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
uma tabela, indexada pelo n umero 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 est a em progresso, novas requisico~es 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.
Entrada e Sada
E/S no Unix 5.4]
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 n umero de cilindros. posição inicial
posição inicial X 0 X 0
X 5
X X 10
X 15
X 20
25
X 5
X X 10
X 15
X 20
X 30
25
X 30
cilindro
cilindro
sequência de movimentos tempo sequência de movimentos
Figura 5.4: Escalonamento de requisic~oes no disco atrav es do algoritmo do elevador
tempo
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 ser a a pr oxima requisic~ao. Usando FCFS, ele ir a 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 pr oxima 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 est a sendo processada. Por exemplo, se, ap os chegar ao cilindro 16, uma nova requisic~ao para o cilindro 8 est a presente. Esta requisica~o ter a prioridade sobre o cilindro 1. Se a requisic~ao for para o cilindro 13, o braco ir a para o 13, ao inv es 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 m edia mais demoradas, colocando o objetivo de m nima resposta no tempo e imparcialidade no acesso. Um algoritmo para reconciliar os objetivos conitantes entre a eci^encia e imparcialidade constituise em manter o movimento do braco na mesma direc~ao at e 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 pr oxima requisic~ao pendente de posic~oes mais altas, se houver. Se n~ao h a requisic~oes pendentes para posic~oes mais altas, o bit de direca~o e revertido. Quando o bit e mudado para DOWN, o movimento ser a para a pr oxima requisic~ao de posic~ao mais baixa, se houver. 46
c 1996
Alguns controladores de disco suportam um modo do software para inspecionar o n umero 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 passar a sob a cabeca do pr oximo cilindro. Note que quando trilhas m ultiplas 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 v arios dispositivos, uma tabela de requisic~oes pendentes deve ser mantida para cada dispositivo separadamente. Quando algum dispositivo est a desocupado, um seek deve ser emitido para mover os seus bracos para o cilindro onde ser a necess ario (assumindo que o controlador permita seeks sobrepostos). Quando a transfer^encia corrente termina, um teste pode ser feito para vericar se algum dos dispositivos est~ao posicionados no cilindro correto. Se um ou mais est~ao, a pr oxima transfer^encia pode ser iniciada no dispositivo que j a est a no cilindro correto. Se nenhum dos bracos est a na posic~ao desejada, o driver deve emitir novos seeks sobre os dispositivos que j a completaram a transfer^encia, e esperar at e a pr oxima interrupc~ao para examinar em qual dispositivo o posicionamento do braco se completou.
5.4 E/S no Unix Dispositivos no Unix podem ser do tipo bloco ou caracter. O interfaceamento com os dispositivos se d a atrav es 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
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
Em dispositivos que operam em bloco, a transfer^encia de dados entre o espaco de enderecamento de um processo e o dispositivo de d a atrav es de um buer 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 r apidos e n~ao necessitam deste recurso. A Figura 5.5 mostra o esquema b asico de entrada e sa da no Unix. Quando um processo executa uma chamada de sistema open, por exemplo, o n ucleo acessa o i-node do arquivo passado a chamada e descobre que e um arquivo associado a um dispositivo de E/S. Atrav es de uma tabela de chaveamento de dispositivo, o n ucleo obt em 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 n ucleo acesse o respectivo procedimento para o dispositivo, cuja identicac~ao e obtida na tabela de arquivos. open close read write ioctl
open close read mount umount
write
rotinas do cache de buffers
tabela de chaveamento (dispositivos orientados a caracter)
open close read write ioctl
driver
close
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 n ucleo identica a rotina strategy denida 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 tamb em suporta dispositivos de E/S atrav es de arquivos especiais de tipo bloco ou caracter. Parte dos drivers est a incorporada no arquivo io.sys, mas o usu ario pode instalar drivers adicionais atrav es de comandos device= no arquivo cong.sys. Todo driver em MS-DOS e composto de duas partes de c odigo, 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 vari avel 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 pr e-denidos na congurac~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 decodicador l ogico associado ao controlador. Alguns IBM PC-compat veis usam diferentes enderecos de E/S.
endereco E/S vetor int.
rel ogio 040 - 043 8 teclado 060 - 063 9 porta serial secund aria 2F8 - 2FF 11 disco r gido 320 - 32F 13 impressora 378 - 37F 15 v deo monocrom atico 380 - 3BF v deo colorido 3D0 - 3DF disco ex vel 3F0 - 3F7 14 porta serial prim aria 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
strategy
driver
gerenciador de interrupções
E/S em MS-DOS 5.5]
dispositivo
tabela de chaveamento (dispositivos orientados a bloco)
open
Entrada e Sada
gerenciador de interrupções
vetor de interrupção interrupções dispositivo
dispositivo
dispositivo
Figura 5.5: Esquema b asico de E/S no Unix Chamadas ioctl permitem o usu ario 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 buer cache, o procedimento e outro. 48
c 1996
DCA/FEEC/UNICAMP
49
Entrada e Sada
Cardozo, Magalh~aes, Faina & Ricarte
(5)
E/S em MS-DOS 5.5]
(d) Worst t (sempre ocupar o maior buraco dispon vel)? Considere um computador com 1M de mem oria do usu ario que executa um procedimento de compactac~ao de mem oria a cada segundo. Se e preciso 0.5 s para copiar um byte e o tamanho m edio de um buraco e 40% do tamanho m edio de um segmento, que frac~ao do tempo total de CPU e gasta com compactac~ao? Usando a tabela de p aginas 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 p aginas de 512 bytes. O programa est a localizado no endereco 1020, e o stack pointer est a em 8192 (com a pilha crescendo para 0). D^e a sequ^encia de p aginas 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 u ltima refer^encia e os estados dos bits R e M s~ao indicados abaixo:
Problemas
(6)
(1) Um problema cl assico de sincronizac~ao e conhecido como o problema produtor-consumidor. Um
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 est a cheio e nem o consumidor retire elementos de um bu"er vazio. Esquematize uma soluc~ao para este problema de sincronizac~ao usando sem aforos. (2) Medidas em um sistema indicam que umprocesso executa em m edia segundos antes de bloquear em uma operaca~o de entrada e sa da. O tempo de chaveamento de contexto e segundos. Para um sistema escalonador usando round-robin com um quantum , dena uma f ormula para a eci^encia da CPU (raz~ao entre tempo gasto com trabalho u til 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 (denidas externamente) 3, 5, 2, 1, e 4, com 5 sendo a prioridade mais alta. Determine o tempo m edio 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 mem oria tem buracos de tamanhos 10K, 4K, 20K, ~ sucessivas para segmentos de 12K, 10K e 9K. Que buracos 18K, 7K, 9K, 12K e 15K. H a requisicOes s~ao ocupados quando a pol tica de alocac~ao e: (a) First t? (b) Best t? (c) Next t?
(7)
T
S
Q
Q
Q > T
S < Q < T Q
S
Q
50
c 1996
(8)
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 p agina seria substitu da se a pol tica de troca adotada fosse: (a) FIFO? (b) NRU? (c) LRU? (d) Segunda chance? (9) Quanto tempo e necess ario para carregar um programa de 64K do disco se o tempo m edio de posicionamento e 30 ms, o tempo de rotac~ao e 20 ms e as trilhas t^em 32K quando o tamanho das p aginas e DCA/FEEC/UNICAMP
51
Cardozo, Magalh~aes, Faina & Ricarte
Sistemas Operacionais
(a) 2K? (b) 4K? As p aginas est~ao espalhadas aleatoriamente pelo disco. (10) Considere um disco de 1G de capacidade com blocos de tamanho 4K. Quanto espaco e necess ario para manter a ger^encia de espaco livre por mapa de bits? E por lista ligada de blocos? A partir de qual fator de ocupaca~o uma estrat egia passa a ser mais econ^omica que a outra? (11) Um vericador 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
H a algum erro de consist^encia? Em caso armativo, 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 interrupca~o de rel ogio em um computador requer 2 ms para executar, incluindo-se chaveamento de contextos. O rel ogio trabalha a uma frequ^encia de 60 Hz. Que frac~ao do tempo de CPU e dedicada ao rel ogio?
52
c 1996
View more...
Comments
