Livro de Sistemas Operacionais Excelente

Notas sobre
Sistemas Operacionais
Peter Jandl Jr.
ii Jandl, Peter, Jr. Notas sobre Sistemas Operacionais/Peter Jandl Jr. Apostila 1. Sistemas operacionais: Computadores : Processamento de dados : 005.43 2004 Hist orico 1.1 Fev2004 Revis ao Geral. Threads. Escalonamento por prioridades. Escalonamento com m ultiplas las. 1.0 Ago1999 Vers ao Inicial.
(C) 2004 Prof. Peter Jandl Jr. Vers ao 1.1 Fevereiro/2004 A Este documento foi preparado utilizando L TEX 2 .
iii
O homem pode se tornar culto pela cultura dos outros, mas s o pode se tornar s abio pelas pr oprias experi encias. (Prov erbio Arabe)
iv
Sum ario
Pref acio 1 Introdu c ao 1.1 Denindo os sistemas operacionais . 1.2 Objetivos de um sistema operacional 1.3 Breve hist orico . . . . . . . . . . . . 1.3.1 O in cio . . . . . . . . . . . . 1.3.2 D ecada de 1940 . . . . . . . . 1.3.3 D ecada de 1950 . . . . . . . . 1.3.4 D ecada de 1960 . . . . . . . . 1.3.5 D ecada de 1970 e 1980 . . . . 1.3.6 D ecada de 1990 . . . . . . . . 1.3.7 D ecada de 2000 . . . . . . . . 1.4 Tipos de sistemas operacionais . . . 1.5 Recursos e ambiente operacional . . 1 3 3 6 7 7 7 9 11 13 14 15 15 17 21 21 22 23 24 24 25 28 29 30 30 31 32 32 33 33 36
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
2 Processos 2.1 O que e um processo computacional . . . . 2.1.1 Subdivis ao dos processos . . . . . . 2.2 Ocorr encia de processos . . . . . . . . . . . 2.2.1 Processos seq uenciais . . . . . . . . . 2.2.2 Processos Paralelos . . . . . . . . . . 2.3 Estado dos processos . . . . . . . . . . . . . 2.4 PCB e tabelas de processos . . . . . . . . . 2.4.1 PCB . . . . . . . . . . . . . . . . . . 2.4.2 Tabelas de processos . . . . . . . . . 2.5 Opera c oes sobre processos . . . . . . . . . . 2.6 Fun c oes do n ucleo de sistema operacional . 2.7 Competi c ao por recursos . . . . . . . . . . . 2.7.1 Regi oes cr ticas . . . . . . . . . . . . 2.7.2 C odigo reentrante . . . . . . . . . . 2.8 Protocolos de acesso . . . . . . . . . . . . . 2.8.1 Solu c ao com instru c oes TST ou TSL v
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
vi 2.8.2 Situa c oes de corrida . . . . . . . . . . . 2.8.3 Requisitos de um protocolo de acesso . . A solu c ao de Dekker . . . . . . . . . . . . . . . A solu c ao de Peterson . . . . . . . . . . . . . . Deadlocks . . . . . . . . . . . . . . . . . . . . . 2.11.1 Diagramas de processos e recursos . . . 2.11.2 Condi c oes para ocorr encia de deadlocks 2.11.3 Recupera c ao de deadlocks . . . . . . . . 2.11.4 Preven c ao de deadlocks . . . . . . . . . 2.11.5 Estados seguros e inseguros . . . . . . . 2.11.6 Algoritmo do banqueiro . . . . . . . . . Comunica c ao de processos . . . . . . . . . . . . 2.12.1 Buers e opera c oes de sleep e wakeup . 2.12.2 Sem aforos . . . . . . . . . . . . . . . . . 2.12.3 Mem oria compartilhada . . . . . . . . . 2.12.4 Outros mecanismos de IPC . . . . . . . Threads . . . . . . . . . . . . . . . . . . . . . . 2.13.1 Modelos de multithreading . . . . . . . . 2.13.2 Benef cios do uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SUMARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 40 40 43 45 46 49 50 51 51 53 53 54 57 58 60 62 64 64 67 68 69 69 71 72 73 74 76 77 79 80 83 84 87 89 89 92 95 97 99 101 103
2.9 2.10 2.11
2.12
2.13
3 Escalonamento de Processos 3.1 Objetivos do escalonamento . . . . . . . . . . . . . . . . . . 3.2 N veis de escalonamento . . . . . . . . . . . . . . . . . . . . 3.3 Escalonamento preemptivo e n ao preemptivo . . . . . . . . 3.4 Qualidade do escalonamento . . . . . . . . . . . . . . . . . . 3.5 Algoritmos de escalonamento . . . . . . . . . . . . . . . . . 3.5.1 Escalonamento FIFO (First In First Out ) . . . . . . 3.5.2 Escalonamento HPF (Highest Priority First ) . . . . 3.5.3 Escalonamento SJF (Shortest Job First ) . . . . . . . 3.5.4 Escalonamento HRN (Highest Response-Ratio Next ) 3.5.5 Escalonamento SRT (Shortest Remaining Time ) . . 3.5.6 Escalonamento RR (Round-Robin ) . . . . . . . . . . 3.5.7 Escalonamento MQ (Multilevel Queues ) . . . . . . . 3.5.8 Escalonamento MFQ (Multilevel Feedback Queues ) . 3.6 Compara c ao dos algoritmos de escalonamento . . . . . . . . 4 Gerenciamento de Mem oria 4.1 Primeiras considera c oes . . . . . . . . . 4.2 Multiprograma c ao . . . . . . . . . . . . 4.3 Organiza c ao da mem oria . . . . . . . . . 4.4 Deni c ao de gerenciamento de mem oria 4.5 Cria c ao de programas . . . . . . . . . . 4.5.1 Espa cos l ogicos e f sicos . . . . . 4.5.2 Compiladores (compilers ) . . . .
. . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
SUMARIO 4.5.3 Ligadores (linkers ) . . . . . . . . . . . 4.5.4 Carregadores (loaders ) . . . . . . . . . 4.5.5 Relocadores (swappers ) . . . . . . . . Mem oria virtual . . . . . . . . . . . . . . . . Modelos de gerenciamento de mem oria . . . . 4.7.1 Monoprogramado com armazenamento 4.7.2 Particionamento xo . . . . . . . . . . 4.7.3 Particionamento vari avel . . . . . . . . 4.7.4 Pagina c ao . . . . . . . . . . . . . . . . 4.7.5 Segmenta c ao . . . . . . . . . . . . . . 4.7.6 Pagina c ao versus Segmenta c ao . . . . 4.7.7 Pagina c ao e segmenta c ao combinadas 4.7.8 Tabelas de p aginas . . . . . . . . . . . 4.7.9 Algoritmos de troca de p aginas . . . . . . . . . . . . . . . . . . . real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii 107 110 111 113 118 118 120 122 123 128 131 132 134 139 143 143 145 145 148 150 152 152 153 154 155 156 160 165 167 171 173 178 181 184 186 192 195
4.6 4.7
5 Gerenciamento de I/O 5.1 M odulos de I/O . . . . . . . . . . . . . . . . . . . . . . . 5.2 Opera c ao de M odulos de I/O . . . . . . . . . . . . . . . 5.2.1 I/O Programado . . . . . . . . . . . . . . . . . . 5.2.2 I/O com interrup c oes . . . . . . . . . . . . . . . 5.2.3 I/O com Acesso Direto ` a Mem oria (DMA) . . . 5.3 Tipos de dispositivos de E/S . . . . . . . . . . . . . . . 5.3.1 Conex ao de Dados dos I/O . . . . . . . . . . . . 5.3.2 Tipos de Transfer encia de I/O . . . . . . . . . . 5.3.3 Conex oes ponto a ponto e multiponto com I/Os . 5.4 Dispositivos perif ericos t picos . . . . . . . . . . . . . . . 5.4.1 Unidades de disco . . . . . . . . . . . . . . . . . 5.4.2 Escalonamento de disco . . . . . . . . . . . . . . 5.4.3 Unidades de ta . . . . . . . . . . . . . . . . . . 5.4.4 Terminais . . . . . . . . . . . . . . . . . . . . . . 5.5 Sistemas de arquivos . . . . . . . . . . . . . . . . . . . . 5.5.1 Arquivos . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Diret orios . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Servi cos do sistema operacional . . . . . . . . . . 5.5.4 Implementa c ao L ogica . . . . . . . . . . . . . . . 5.5.5 Implementa c ao F sica . . . . . . . . . . . . . . . 5.5.6 Fragmenta c ao . . . . . . . . . . . . . . . . . . . . Bibliograa
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
viii
SUMARIO
Pref acio
Este texto representa a condensa c ao do material apresentado durante as aulas da disciplina Sistemas Operacionais, ministradas ao longo de meu trabalho no magist erio nos cursos de gradua c ao em An alise de Sistemas e Engenharia da Computa c ao. Como o pr oprio t tulo indica, s ao notas de aulas, organizadas num roteiro bastante tradicional, acompanhadas de diagramas, desenhos, coment arios e exemplos que tem como objetivo maior facilitar o entendimento do tema, t ao importante dentro da Ci encia da Computa c ao assim como em outros cursos correlatos, tais como Engenharia da Computa c ao, An alise de Sistemas e Sistemas de Informa c ao. Desta forma, n ao se pretendeu colocar como um estudo completo e detalhado dos sistemas operacionais, t ao pouco substituir a vasta bibliograa existente, mas apenas oferecer um texto de refer encia, onde sempre que poss vel s ao citadas outras fontes bibliogr acas. O Cap tulo 1 apresenta os Sistemas Operacionais, alguns conceitos importantes, um breve hist orico de sua evolu c ao e uma classica c ao de seus tipos. O Cap tulo 2 discute os processos computacionais, sua ocorr encia e as principais quest oes associadas ao seu controle. No Cap tulos 3 falamos sobre o escalonamento de processos enquanto que o Cap tulo 4 trata o gerenciamento de mem oria. Finalmente o Cap tulo 5 aborda o gerenciamento de dispositivos perif ericos. Que este material possa ser u til aos estudantes desta disciplina, despertando o interesse no tema e principalmente motivando um estudo mais profundo e amplo. O Autor
PREFACIO
Cap tulo 1
Introdu c ao
Neste cap tulo vamos apresentar os sistemas operacionais, seus objetivos e um breve hist orico de sua evolu c ao. Tamb em proporemos uma forma simples para sua classica c ao e forneceremos alguns outros conceitos importantes.
1.1
Denindo os sistemas operacionais
Desde sua cria c ao, os computadores sempre foram sistemas de elevada sostica c ao em rela c ao ao est agio tecnol ogico de suas epocas de desenvolvimento. Ao longo dos u ltimos 50 anos evolu ram incrivelmente e, embora tenham se tornado mais comuns e acess veis, sua populariza c ao ainda esconde sua tremenda complexidade interna. Neste sentido, os sistemas operacionais, em termos de suas origens e desenvolvimento, acompanharam a pr opria evolu c ao dos computadores. Deitel nos traz a seguinte deni c ao de sistema operacional: Vemos um sistema operacional como os programas, implementados como software ou rmware, que tornam o hardware utiliz avel. O hardware oferece capacidade computacional bruta. Os sistemas operacionais disponibilizam convenientemente tais capacidades aos usu arios, gerenciando cuidadosamente o hardware para que se obtenha uma performance adequada. [DEI92, p. 3] Nesta deni c ao surgem alguns novos termos explicados a seguir. O hardware e o conjunto de dispositivos el etricos, eletr onicos, opticos e eletromec anicos que comp oe o computador, sendo a m aquina f sica propriamente dita. O hardware, aparentemente identic avel pelos dispositivos ou m odulos que comp oe um sistema computacional, determina as capacidades deste sistema. O software e o conjunto de todos os programas de computador em opera c ao num dado computador. J a o rmware e representado por programas especiais armazenados de forma permanente no hardware do computador que 3
CAP ITULO 1. INTRODUC AO
permitem o funcionamento elementar e a realiza c ao de opera c oes b asicas em certos dispositivos do computador, geralmente associadas a alguns perif ericos e a execu c ao de outros programas tamb em especiais. Na Figura 1.1 podemos identicar o hardware como sendo os dispositivos f sicos, sua microprograma c ao e o rmware existente neste computador. Como exemplos de dispositivos existentes num sistema podemos citar os circuitos integrados de mem oria, as unidades de disco ex vel ou r gido e o processador do sistema, sendo este u ltimo um dispositivo microprogramado. O rmware geralmente vem acondicionado em circuitos de mem oria n ao vol atil (ROM, PROM ou EPROM) sendo os programas ali gravados escritos geralmente em linguagem de m aquina e destinados a execu c ao de opera c oes especiais tal como a auto-verica c ao inicial do sistema (POST ou power on self test ) e a carga do sistema operacional a partir de algum dispositivo adequado (bootstrap ). O software deste sistema ou os programas do sistema s ao representados pelo sistema operacional e todos os seus componentes (bibliotecas de fun c oes e programas utilit arios) al em de todos os outros programas acess orios do sistema, tais como editores de texto, programas gr acos, compiladores, interpretadores de comando (shells ), aplicativos de comunica c ao e ferramentas de administra c ao e manuten c ao do sistema. Os programas de aplica c ao s ao todos os demais software s, desenvolvidos com nalidades particulares, que s ao utilizados num dado sistema computacional sob suporte e supervis ao do sistema operacional, tais como planilhas eletr onicas, programas de correio eletr onico, navegadores (browsers), jogos, aplica c oes multim dia etc.
Figura 1.1: Hardware, software, rmware e o SO Por si s o, o hardware do computador dicilmente poderia ser utilizado diretamente e mesmos assim, exigindo grande conhecimento e esfor co para execu c ao de tarefas muito simples. Neste n vel, o computador somente e ca-
1.1. DEFININDO OS SISTEMAS OPERACIONAIS
paz de entender programas diretamente escritos em linguagem de m aquina. Al em disso, cada diferente tipo de computador possui uma arquitetura interna distinta que pode se utilizar de diferentes processadores que por sua vez requisitar ao diferentes linguagens de m aquina, tornando penosa e cansativa a tarefa dos programadores. Desta forma, e adequada a exist encia de uma camada intermedi aria entre o hardware e os programas de aplica c ao que pudesse n ao apenas oferecer um ambiente de programa c ao mais adequado mas tamb em um ambiente de trabalho mais simples, seguro e eciente. Um sistema operacional e um programa, ou conjunto de programas, especialmente desenvolvido para oferecer, da forma mais simples e transparente poss vel, os recursos de um sistema computacional aos seus usu arios, controlando e organizando o uso destes recursos de maneira que se obtenha um sistema eciente e seguro. Stallings, ao tratar dos objetivos e fun c oes dos sistemas operacionais, arma que: Um sistema operacional e um programa que controla a execu c ao dos programas de aplica c ao e atua como uma interface entre o usu ario do computador o hardware do computador. Um sistema operacional pode ser pensado como tendo dois objetivos ou desempenhando duas fun c oes: conveni encia, pois faz o sistema computacional mais conveniente de usar; e eci encia, pois permite que os recursos do sistema computacional sejam usados de maneira eciente. [STA96, p. 222] Silberschatz utiliza praticamente a mesma deni c ao, indicando que um sistema operacional e um ambiente intermedi ario entre o usu ario e o hardware do computador no qual programas podem ser executados de forma conveniente e eciente [SG00, p. 23]. Davis [DAV91], Shay [SHA96] e outros tamb em apresentam id eias semelhantes. Tanenbaum, por sua vez, dene um sistema operacional atrav es de uma otica ligeiramente diferente: O mais fundamental de todos os programas do sistema e o sistema operacional que controla todos os recursos computacionais e prov e uma base sobre a qual programas de aplica c ao podem ser escritos. [TAN92, p. 1] Os sistemas operacionais s ao uma camada de software que envolve os componentes f sicos de um computador, intermediando as intera c oes entre estes componentes e os usu arios ou os programas dos usu arios. Neste sentido e apropriado considerar que os sistemas operacionais podem ser vistos como uma extens ao do pr oprio computador ou como gerenciadores dos recursos existentes neste computador.
Ao inv es de lidar com a complexidade inerente ao hardware, o sistema operacional oferece a funcionalidade dispon vel no hardware atrav es de uma interface de programa c ao orientada a opera c ao de cada tipo de recurso, proporcionado n ao apenas transpar encia, mas tamb em isolando o hardware das aplica c oes. Assim temos que o comportamento do sistema operacional e como uma extens ao do pr oprio hardware ou como uma m aquina virtual, que possui caracter sticas diferentes da m aquina f sica real. Imaginando que m ultiplos programas em execu c ao desejem fazer uso dos diversos recursos do hardware, n ao e razo avel que o controle destes recursos seja transferido aos programadores pois isto acrescentaria uma sobrecarga desnecess aria a cada programa, sem que fosse poss vel otimizar o uso dos recursos. Al em disso, erros ou omiss oes, mesmo que involunt arias, poderiam provocar erros de dimens oes catastr ocas, acarretando perda de grandes quantidades de dados, viola c oes importantes de seguran ca etc. O sistema operacional deve se encarregar de controlar os recursos do computador, garantindo seu uso adequado, buscando tamb em otimizar tal uso objetivando um melhor eci encia do sistema, assim sendo, o sistema operacional se comporta como gerente dos recursos do computador.
1.2
Objetivos de um sistema operacional
A despeito do tipo, sostica c ao ou capacidades do computador, um sistema operacional deve atender aos seguintes princ pios: 1. Oferecer os recursos do sistema de forma simples e transparente; 2. Gerenciar a utiliza c ao dos recursos existentes buscando seu uso eciente em termos do sistema; e 3. Garantir a integridade e a seguran ca dos dados armazenados e processados no sistema e tamb em de seus recursos f sicos. Al em destes objetivos, um sistema operacional tamb em deve proporcionar uma interface adequada para que ele possa ser utilizado pelos seus usu arios. Historicamente as primeiras interfaces dos sistemas operacionais eram baseadas em um conjunto de palavras-chave (comandos) e mensagens de di alogo que permitiam a execu c ao de tarefas e a comunica c ao entre homem (o operador) e m aquina. Estes comandos e mensagens deniam a Interface Humano-Computador (IHC) daquele sistema. Atualmente as interfaces baseadas em modo texto est ao em desuso, sendo substitu das por interfaces gr acas mais modernas e simples que buscam facilitar a utiliza c ao do computador atrav es de sua apar encia atraente e uso intuitivo.
1.3. BREVE HISTORICO
1.3
Breve hist orico
O desenvolvimento dos sistemas operacionais pode ser melhor observado e compreendido quando acompanhamos a hist oria do pr oprio computador. No breve resumo que segue pretende-se enfocar os principais eventos e movimentos relacionados ao desenvolvimento destas m aquinas.
1.3.1
O in cio
Por volta de 1643, Blaise Pascal projeta e constr oi uma m aquina de calcular mec anica, que deu origem as calculadores mec anicas utilizadas at e meados do s eculo XX. No nal do s eculo XVIII, Joseph-Marie Jacquard constr oi um tear que utiliza cart oes de papel ao perfurado para determinar o padr ao a ser desenhado no tecido, criando a primeira m aquina program avel. Charles Babbage constr oi em 1822 a m aquina de diferen cas e depois, partindo das id eias de Jacquard, projeta a m aquina anal tica, a qual n ao foi terminada. Recentemente comprovou-se que suas id eias eram corretas, sendo ele hoje reconhecido como pai do computador moderno. Em 1870 e constru do uma m aquina anal ogica para previs ao de mar es por Willian Thomson, que origina os computadores anal ogicos. Em 1890 o Censo Americano utiliza com grande sucesso as m aquinas de tabular de Herman Hollerith, que funda em 1896 a Tabulating Machine Company. Alguns anos depois esta companhia se transformaria na IBM (International Business Machines ). Na d ecada de 30 come cam a surgir, em diferentes pontos do mundo, projetos de m aquinas eletromec anicas e eletr onicas de calcular: 1934 M aquina eletromec anica program avel do engenheiro Konrad Zuse. 1935 In cio do projeto da m aquina eletr onica ABC, baseada em v alvulas, para resolu c ao de sistemas, proposta pelo f sico John Vicent Atanasoft. 1937 John Von Neumann, matem atico h ungaro, prop oe uma arquitetura gen erica para o computador, utilizada at e hoje (veja Figura 1.2). 1939 Desenvolvida a primeira calculadora eletromec anica dos laborat orios Bell. As descobertas da epoca motivaram cientistas de diversas especialidades a trabalhar no desenvolvimento dos ent ao chamados c erebros eletr onicos.
1.3.2
D ecada de 1940
Os primeiros computadores eram realmente grandes m aquinas de calcular. Compostas por circuitos baseados em rel es e outros dispositivos eletromec anicos, estas m aquinas eram muito grandes, lentas, consumiam muita
energia el etrica e eram de dif cil opera c ao. Esta tecnologia foi progressivamente substitu da pelas v alvulas eletr onicas, um pouco mais con aveis e r apidas, embora muito mais caras. Com isso os computadores da epoca eram car ssimos, restringindo seu uso ` a organismos militares, ag encias governamentais e grandes universidades. O uso do computador era claramente experimental. Um dos primeiros sistemas program aveis constru dos foi o computador eletromec anicos Mark I, projetado em conjunto pela IBM e pela Universidade de Harvard, apresentado em 1944. Em 1946 o Ex ercito Americano revela seu computador eletr onico digital, o ENIAC, utilizado para c alculos de bal stica externa, que vinha sendo utilizado a alguns anos.
Figura 1.2: Arquitetura de Von Neumann O uso destes sistemas exigia um grande grau de conhecimento de sua arquitetura e funcionamento. Os engenheiros exerciam o papel de programadores, determinando quais m odulos deveriam ser interligados e em que ordem. Um grupo de t ecnicos treinados, de posse de esquemas de liga c ao, realizavam a conex ao de tais m odulos, de forma que a m aquina pudesse ser energizada e os c alculos realizados. Nesta epoca o computador n ao era program avel pois seu hardware era modicado para cada tipo de problema diferente, o que representava uma tarefa complexa e delicada. Nesta d ecada o matem atico Von Neumann prop os a constru c ao de sistema computacional baseada numa arquitetura composta por tr es blocos b asicos (Figura 1.2) onde a seq u encia de passos a ser executada pela m aquina fosse armazenada nela pr opria sem necessidade de modica c ao de seu hardware. O computador de Von Neumann era uma m aquina gen erica, cujo bloco processador seria capaz de realizar um conjunto de opera c oes matem aticas e l ogicas al em de algumas opera c oes de movimenta c ao de dados entre os blocos da m aquina. Estas opera c oes, chamadas de instru c oes, seriam armazenadas no bloco mem oria enquanto o bloco de dispositivos de E/S (Entrada e Sa da) ou I/O (Input and Output ) seria respons avel pela entrada e sa da dos dados, instru c oes e controle do sistema. A seguir temos a Figura 3 representando o esquema b asico de funcionamento dos processadores. Ap os ligado, um processador efetua um ciclo de busca por uma instru c ao na mem oria (fetch ), a qual e decodicada
do ciclo seguinte (decode ), que determina quais as a c oes necess arias para sua execu c ao no u ltimo ciclo (execute ). Ap os a execu c ao repetem-se os ciclos de busca, decodica c ao e execu c ao indenidamente. A repeti c ao desta seq u encia s o e interrompida atrav es da execu c ao de uma instru c ao de parada (halt ) ou pela ocorr encia de um erro grave.
Figura 1.3: Funcionamento b asico dos processadores Assim sendo, um mesmo hardware poderia resolver diferentes tipos de problemas sem necessidade de qualquer modica c ao, bastando que uma seq u encia adequada de instru c oes fosse carregada no computador. Com isto nascem os conceitos de programa, computador program avel e com eles a programa c ao de computadores. Apesar de todas as restri c oes tecnol ogicas da epoca, as id eias de Von Neumann revolucionaram a constru c ao dos computadores e ditaram a nova dire c ao a ser seguida.
1.3.3
D ecada de 1950
A descoberta do transistor deu novo impulso ` a eletr onica e aos computadores. Apesar de seu custo ainda alto, j a era poss vel fabricar e vender computadores para grandes empresas e organismos governamentais, tanto que em 1951 surge o primeiro computador comercial, o Univac-I (Universal Automatic Computer ) e em 1953 a IBM lan ca seu primeiro computador digital, o IBM 701. Para program a-los ainda era necess ario conhecer detalhes sobre seus circuitos e sobre o funcionamento de seus dispositivos. Tais exig encias faziam que os computadores s o pudessem ser utilizados por especialistas em eletr onica e programa c ao. Mesmo tais especialistas tinham diculdade em lidar com diferentes computadores, dado que cada computador possu a uma estrutura e funcionamento particulares. A programa c ao era feita em assembly, ou seja, diretamente em linguagem de m aquina. Com a evolu c ao dos computadores, tornou-se necess ario criar pequenos programas que os controlassem na execu c ao de tarefas cotidianas, tais como acionar certos dispositivos em opera c oes repetitivas ou mesmo
10
simplicar a execu c ao de novos programas. Surgiram assim os primeiros sistemas operacionais. O uso individual do computador (conceito de open shop ) era pouco produtivo, pois a entrada de programas constitu a uma etapa muito lenta e demorada que na pr atica representava o computador parado. Para otimizar a entrada de programas surgiram as m aquinas leitoras de cart ao perfurado (semelhantes as m aquinas de tabular constru das por Herman Hollerith) que aceleravam muito a entrada de dados. Os programadores deveriam ent ao escrever seus programas e transcrev e-los em cart oes perfurados. Cada programa e seus respectivos dados eram organizados em conjuntos denominados jobs que poderiam ser processados da seguinte forma: os v arios jobs de diferentes usu arios eram lidos por uma m aquina leitora de cart oes que gravava os dados numa ta magn etica. Esta ta era levada para o computador propriamente dito que lia os jobs, um a um, gravando uma outra ta magn etica com os resultados de cada job. Esta ta de sa da era levada a outro m aquina que lia a ta e imprimia as listagens, devolvidas aos usu ario juntamente com seus cart oes.
Figura 1.4: Sistema Univac, 1951 (processamento em lote - batch ) Apesar da natureza seq uencial do processamento, para os usu arios era como se um lote de jobs fosse processado a cada vez, originando o termo processamento em lote (batch processing ). Os sistemas batch viabilizaram o uso comercial dos computadores, epoca em que grandes fabricantes de computadores come cam a surgir. Ainda na d ecada de 50 surgiram a primeira linguagem de programa c ao de alto n vel (o IBM FORTRAN - Formula Translator - em 1957), a primeira unidade de disquetes comercialmente dispon vel no modelo IBM 305 e os mecanismos de interrup c ao implementados diretamente no hardware dos processadores. Em 1959 a DEC (Digital Equipment Corporation ) apresenta seu minicomputador, o PDP-I, que fez grande sucesso comercial, originando uma grande linha de equipamentos.
11
1.3.4
D ecada de 1960
Buscando uma utiliza c ao mais eciente e segura dos computadores, os sistemas operacionais foram se tornando cada vez mais complexos, passando a administrar os recursos do computador de forma cada vez mais sosticada. Ao mesmo tempo em que se buscava um uso mais eciente e seguro do computador, estudavam-se alternativas para que pessoas menos especializadas nos aspectos construtivos da m aquina pudessem utilizar o computador, se concentrando em suas verdadeiras tarefas e ampliando as possibilidades de uso dos computadores. Nesta d ecada aparece o COBOL (Commom Business Oriented Language ), linguagem de programa c ao especialmente desenvolvida para o Pent agono americano para auxiliar o desenvolvimento de sistemas comerciais. Em 1961 a Farchild inicia a comercializa c ao dos primeiros circuitos integrados. Em 1963 a DEC introduz o uso de terminais de v deo e no ano seguinte surge o mouse. Um dos primeiros avan cos ocorridos na d ecada de 60 foi a utiliza c ao da multiprograma c ao. Segundo Deitel: Multiprograma c ao e quando v arios jobs est ao na mem oria principal simultaneamente, enquanto o processador e chaveado de um job para outro job fazendo-os avan carem enquanto os dispositivos perif ericos s ao mantidos em uso quase constante. [DEI92, p. 4] Enquanto o processamento chamado cient co era muito bem atendido pelo processamento em lote comum o mesmo n ao acontecia com processamento dito comercial. No processamento cient co ocorre a execu c ao de grande quantidade de c alculos com quantidades relativamente pequenas de dados, mantendo o processador ocupado na maior parte do tempo sendo que o tempo gasto com I/O (entrada e sa da) era insignicante, da este comportamento ser chamado CPU Bounded. J a no processamento comercial o processador permanece bastante ocioso dado que os c alculos s ao relativamente simples e o uso de I/O e freq uente dada a quantidade de dados a ser processada, temos um comportamento I/O Bounded. A multiprograma c ao permitiu uma solu c ao para este problema atrav es da divis ao da mem oria em partes, chamadas parti c oes, onde em cada divis ao um job poderia ser mantido em execu c ao. Com v arios jobs na mem oria o processador permaneceria ocupado o suciente para compensar o tempo das opera c oes mais lentas de I/O. A utiliza c ao de circuitos integrados na constru c ao de computadores comerciais e a cria c ao de fam lias de computadores compat veis iniciadas com o IBM System/360 inaugurou uma nova era na computa c ao e a expans ao de sua utiliza c ao. Outra t ecnica utilizada era o spooling (simultaneous peripheral operation on line ), isto e, a habilidade de certos sistemas operacionais em ler novos jobs de cart oes ou tas armazenado-os em uma area tempor aria
12
Figura 1.5: Parti c oes de mem oria num sistema multiprogramado do disco r gido interno para uso posterior quando uma parti c ao de mem oria fosse liberada [TAN92, p. 9]. Apesar destas novas t ecnicas, os sistemas da epoca operavam basicamente em lote. Assim, enquanto satisfaziam as necessidades mais comuns de processamento comercial e cient co, n ao ofereciam boas condi c oes para o desenvolvimento de novos programas. Num sistema em lote, a corre c ao de um problema simples de sintaxe poderia levar horas devido a rotina imposta: prepara c ao dos cart oes, submiss ao do job no pr oximo lote e a retirada dos resultados v arias horas ou at e mesmo dias depois. Tais problemas associados ao desenvolvimento de software motivaram a concep c ao de sistemas multiprogramados, isto e, sistemas que permitissem o uso simult aneo do computador por diversos usu arios atrav es do pseudoparalelismo. O pseudoparalelismo poderia ser obtido com o chaveamento do processador entre v arios processos que poderiam atender os usu arios desde que fossem dotados de interfaces interativas. A id eia central destes sistemas era dividir o poder computacional de um computador entre seus v arios usu arios, fornecendo uma m aquina virtual para cada um destes. Esta m aquina virtual deveria passar a impress ao de que o computador estava integralmente dispon vel para cada usu ario, mesmo que isto n ao fosse verdade. Nestes sistemas, denominados de sistemas em tempo repartido (time sharing systems ), o tempo do processador era dividido em pequenos intervalos denominados quanta de tempo ou janelas temporais, como ilustra a (Figura 1.6). Tais quanta de tempo eram distribu dos seq uencialmente entre os processos de cada usu ario, de forma que a espera entre os intervalos fosse impercept vel para os usu arios. Depois que um quanta de tempo era distribu do para cada processo, se iniciava um novo ciclo de trabalho. A um dado processo seriam concedidos tantos quanta de tempo quanto necess ario mas apenas um a cada ciclo. Com isto, a capacidade de processamento da 1 m aquina cava dividida entre os usu arios do sistema a raz ao de n , onde n e o n umero de usu arios do sistema. O mecanismo central de funcionamento destes sistemas e a interrup c ao. Uma interrup c ao e uma forma de parar a execu c ao de um programa qual-
13
quer, conduzindo o processador a execu c ao de uma outra rotina, previamente especicada que ap os ser executada por completo, permite o retorno ao programa original, sem preju zo para execu c ao do primeiro. Os sistemas em tempo repartido tamnb em criaram as necessidades dos mecanismos de identica c ao de usu ario (userid e password ), dos mecanismos de in cio e t ermino de sess ao de trabalho (login ou logon ), da exist encia de contas de usu ario, etc.
Figura 1.6: Ciclo de trabalho em sistemas de tempo repartido Um dos processos de cada usu ario poderia ser um interpretador de comandos (shell ) que representaria a interface do computador para o usu ario. Inicialmente estas interfaces eram implementadas como linhas de comando em terminais de teletipo e depois em terminais de v deo. Como utilizavam exclusivamente caracteres tamb em s ao conhecidas como interfaces em modo texto. As maiores diculdades que surgiram durante o desenvolvimento destes sistemas foram a solu c ao dos problemas associados ao compartilhamento dos recursos, ` a organiza c ao dos usu arios e das tarefas do sistema, al em dos mecanismos de seguran ca e privacidade.
1.3.5
D ecada de 1970 e 1980
Estas d ecadas s ao marcadas especialmente pelo crescimento em tamanho, sostica c ao e complexidade dos sistemas computacionais. Aparece o termo mainframe (computador principal) e tornam-se cada vez mais comuns os centros de processamento de dados (CPDs) corporativos de uso privativo e bureaus de processamento de dados que vendiam servi cos para terceiros. Surge o primeiro microprocessador comercial integrado em um u nico chip, o Intel 4004 em 1971. Na d ecada de 70 come cam a surgir pequenos computadores destinados ao uso pessoal ou dom estico, come cando pelos microcomputadores da Xerox em Palo Alto em 1973, o Altair 8.800 destinado ao consumo em massa em 1974, o IBM 5100 em 1975 e o sucesso de vendas do Apple 2 lan cado em 1976. Come cam a ser desenvolvidas as primeiras aplica c oes comerciais dos microcomputadores. A d ecada de 80 viu o surgimento da gera c ao do microcomputadores, o boom dos sistemas desktop a partir do lan camento do IBM-PC (Personal Computer) em 1981 e o desenvolvimento de uma enorme ind ustria de hard-
14
ware, software e servi cos originadas nestes eventos. Na mesma d ecada de 80 surgem empresas especializadas em arquiteturas de alto desempenho e s ao desenvolvidos os primeiros supercomputadores tais como os modelos 1-A ou X-MP da Cray Research.
1.3.6
D ecada de 1990
Esta d ecada e marcada pelas esta c oes de trabalho (workstations ), pela computa c ao pessoal port atil e pela interoperabilidade. Disp oe-se de microcomputadores cujo poder de processamento e maior do que os mainframes da d ecada de 1970. Os supercomputadores, fabricados quase que artesanalmente, come cam a ser tornar m aquinas fant asticas, tal como o Cray Y-MP capaz de processar at e 2.667 GFlops1 [NCA04]. Tais equipamentos s ao frequentemente empregados para simula c oes complexas, tais como as requeridas pela metereologia, astrof sica, f sica at omica, farmac eutica, engenharia entre outras. Os notebooks, palmtops e PDAs (personal digital assistents ) representam o m aximo em portabilidade e exibilidade, e est ao grandemente incorporados no cotidiano de executivos, prossionais de design, vendedores e outros prossionais liberais, mesmo aqueles cuja atividade m n ao e a inform atica. Mesmo estes pequenos aparelhos possuem vers oes simplicadas de sistemas operacionais, permitindo que uma gama maior de servi cos e funcionalidades sejam oferecidas. Al em disso a eletr onica embarcada come ca a ser tornar presente em autom oveis e utens lios dom esticos, al em das tradicionais aplica c oes industriais. Ferramentas de desenvolvimento r apido (RAD tools), ferramentas CASE sosticadas para modelagem de dados e sistemas, complexos sistemas de CAD-CAE-CAM (Computer Aided Design, Engineering ou Manufacturing). Internet. Sistemas de correio eletr onico, grupos de discuss ao, educa c ao ` a dist ancia, multim dia, ATM, Java, Corba, sistemas distribu dos, processamento vetorial, processamento paralelo etc. In umeras tecnologias de projeto, desenvolvimento, aplica c ao, integra c ao e interoperabilidade, adicionando diversidade, novas necessidades e maior complexidade aos sistemas operacionais contempor aneos. Com isto, alguns milh oes de linhas de programa s ao necess arias para a cria c ao de um sistema operacional que atenda em parte tais necessidades, sendo necess ario adapt a-los aos mais diversos tipos de aplica c ao e usu ario. E para dar suporte a tremenda complexidade destes programas, a ind ustria de hardware vem continuamente desenvolvendo novos processadores tamb em com velocidade cada vez maior, circuitos de mem oria de maior capacidade
A capacidade de processamento computacional (computer power ) e usualmente medida em termos do n umero de opera c oes em ponto utuante completas por segundo (Flops).
1
1.4. TIPOS DE SISTEMAS OPERACIONAIS
15
Figura 1.7: Servidor, workstation e notebook e velocidade bem como dispositivos perif ericos cada vez mais sosticados, tudo atrav es das novas tecnologias.
1.3.7
D ecada de 2000
A supercomputa c ao se torna superlativa. Exemplos disso s ao os novos sistemas da IBM e da Cray Research, conhecidos como IBM BlueSky e Cray X1 (Figura 1.8) que, respectivamente, tem capacidades de processamento de 6.323 TFlops [NCA04] e 52.4 TFlops [CRA04]. Gra cas ` a pesquisa e a evolu c ao dos sistemas distribu dos, tal como as t ecnicas de grid computing, o emprego de clusters (agrupamentos) de computadores geogracamente dispersos e interligados atrav es da Internet ou conectados atrav es de redes locais de alto desempenho tamb em vem se tornando mais comum, como alternativa mais econ omica e de desempenho semelhante aos supercomputadores. O desenvolvimento e miniaturiza c ao de novos componentes eletr onicos em adi c ao e a utiliza c ao de novos processos de fabrica c ao associados ` a grande expans ao das redes digitais de telefonia m ovel permitem que muitos milh oes de usu arios se beneciem de equipamentos que somam as caracter sticas de telefones port ateis com PDAs cada vez mais sosticados. Os computadores dedicados e os de uso gen erico est ao se tornando cada vez mais populares em contraste com as necessidades e exig encias mais sosticadas de seus usu arios. O n umero de usu arios de computador tamb em cresce vertiginosamente, impulsionando os fabricantes a criarem novos produtos, servi cos e solu c oes. Com tudo isso a computa c ao e, sem d uvida alguma, imprescind vel como ferramenta para o homem moderno, tornando o desenvolvimento cont nuo dos sistemas operacionais uma tarefa essencial.
1.4
Tipos de sistemas operacionais
Identicamos atrav es da hist oria dos sistemas operacionais alguns tipos de sistemas operacionais, os quais s ao comparados segundo alguns aspectos considerados importantes como pode ser visto na Tabela 1.1.
16
Figura 1.8: Supercomputador Cray X1 Tabela 1.1: Tipos de sistemas operacionais Tipo de SO Interativo Tempo de Produtividade Multiusu ario Resposta (Throughput) Open Sim Baixo Baixa N ao Shop Irregular Batch N ao Alto M edia Alta Sim Simples Regular Batch com N ao Alto M edia Alta Sim Spooling Regular Tempo Sim Baixo M edia Sim Repartido Previs vel Tempo Sim Baixo M edia Sim Real Previs vel
A interatividade e o aspecto que considera se o usu ario utiliza diretamente o sistema computacional, podendo receber as respostas deste, sem intermedia c ao e dentro de intervalos de tempo razo aveis. O tempo de resposta (response time ) e, desta forma, uma medida de interatividade, que representa o intervalo de tempo decorrido entre um pedido ou solitica c ao de processamento (por exemplos, a entrada de um comando ou execu c ao de um programa) e a resposta produzida pelo sistema (realiza c ao das opera c oes solicitadas ou naliza c ao do programa ap os sua execu c ao completa). Tempos de resposta da ordem de alguns segundos conguram sistemas interativos, embora sejam admitidas esperas mais longas. Por exemplo, uma resposta produzida num intervalo de 30 segundos pode ser considerada normal levando-se em conta a natureza e complexidade da opera c ao solicitada. Embora normal, intervalos desta ordem de grandeza ou superiores tornam enfadonho e cansativo o trabalho com computadores.
1.5. RECURSOS E AMBIENTE OPERACIONAL
17
O tempo de rea c ao (reaction time ) tamb em e outra medida de interatividade a qual considera o tempo decorrido entre a solicita c ao de uma a c ao e seu efetivo processamento. J a a produtividade (throughput ) e uma medida de trabalho relativa do sistema, expressa usualmente em tarefas completas por unidade de tempo, ou seja, e uma medida que relaciona o trabalho efetivamente produzido e o tempo utilizado para realiza c ao deste trabalho. Unidades poss veis do throughput s ao: programas por hora, tarefas por hora, jobs por dia etc. A produtividade n ao deve ser confundida com o desempenho bruto do processador do sistema (sua capacidade de processamento), pois depende muito da arquitetura do sistema e do sistema operacional o quanto desta capacidade e efetivamente convertida em trabalho u til e o quanto e dispendida nas tarefas de controle e ger encia do pr oprio sistema computacional. Podemos notar que dentre estas medidas de performance (existem ainda diversas outras), algumas s ao orientadas ao usu ario, tal como o tempo de resposta ou o tempo de rea c ao; enquanto outras s ao orientadas ao sistema em si, tal como a taxa de utiliza c ao do processador ou a produtividade [DEI92, p. 423].
1.5
Recursos e ambiente operacional
O hardware do computador, ou seja, sua parte f sica, determina suas capacidades brutas, isto e, seus verdadeiros limites. Todos os elementos funcionais do computador s ao considerados recursos do sistema computacional e s ao, geralmente, representados pelos dispositivos que o comp oe e que podem ser utilizados pelos usu arios, ou seja: monitores de v deo, teclado, mouse, mesas digitalizadoras, portas de comunica c ao serial e paralela, placas de rede ou comunica c ao, impressoras, scanners, unidades de disco ex vel ou r gido, unidades de ta, unidades leitoras/gravadoras de CD, DVDs etc. O sistema operacional aparece como uma camada sobre o hardware e rmware, mas simultaneamente envolt oria deste. O sistema operacional est a sobre o hardware e rmware pois deles depende para sua pr opria execu c ao. Ao mesmo tempo e uma camada envolt oria pois pretende oferecer os recursos do computador ao usu ario do sistema minimizando os aspectos de como s ao tais dispositivos ou como ser ao feitas as opera c oes que os utilizam. Desta forma o sistema operacional, atrav es de sua interface, dene uma nova m aquina que e a combina c ao de um certo hardware com este sistema operacional. O conjunto de hardware e sistema operacional, usualmente chamado de plataforma ou ambiente operacional, e aparentemente capaz de realizar tarefas de um modo espec co ditado pela pr opria interface. Note que o ambiente operacional e distinto do hardware, pois o hardware do computador, por si s o, n ao e capaz de copiar um determinado arquivo de uma unidade
18
de disco r gido para uma unidade de disquete. Para realizar esta c opia, uma s erie procedimentos devem ser executados, indo desde o acionamento das unidades utilizadas, passando pela localiza c ao das partes do arquivo origem e das areas dispon veis no disquete de destino, at e a transfer encia efetiva dos dados. Atrav es da interface do sistema operacional, tal a c ao poderia ser poss vel atrav es de um comando fornecido dentro de um console (uma interface de modo texto, tal como mostra a Figura 1.9, por exemplo: copy so.dvi a:\ ou, se dispusermos de uma interface gr aca (Figura 1.10), atrav es de uma opera c ao visual frequentemente denominada arrastar e soltar (drag and drop ) devido as a c oes realizadas com o mouse.
Figura 1.9: Interface em modo texto (linha de comando ou console) Enquanto o hardware isolado n ao permitia a realiza c ao direta da tarefa de copiar um arquivo, atrav es do sistema operacional temos a impress ao de que o computador se tornou capaz de realizar a tarefa desejada atrav es do comando dado ou da opera c ao visual efetuada, sem a necessidade do conhecimento de detalhes de como a tarefa e verdadeiramente realizada. A aparentemente expans ao das capacidades do hardware do computador e, na verdade, uma simplica c ao obtida atrav es da automatiza c ao da tarefa atrav es de sua programa c ao no sistema operacional. O hardware e realmente o realizador da tarefa, enquanto o sistema operacional apenas intermedia esta opera c ao atrav es de sua interface. Observamos que a cria c ao de uma interface, gr aca ou n ao, para um sistema operacional e extremamente importante 2 , pois determinam a cria c ao de um ambiente operacional consistente. Tais possibilidades s ao bastante atraentes, pois se cada sistema operacional tem a capacidade de transformaro hardware de um computador em um determinado ambiente operacional, isto eq uivale a dizer que computadores diferentes, dotados de um mesmo sistema operacional, oferecer ao transperentemente um ambiente operacional
1.5. RECURSOS E AMBIENTE OPERACIONAL
19
Figura 1.10: Interface gr aca id entico, ou seja, se comportar ao como se fossem m aquinas de um mesmo tipo. Por exemplo, o emprego de uma distribui c ao do Linux em microcomputadores baseados em processadores na Intel oferece o mesmo ambiente que workstations IBM utilizando este mesmo sistema operacional. Esta possibilidade propicia as seguintes vantagens: 1. Determina c ao de um ambiente de trabalho equivalente para os usu arios, que podem desconhecer as diferen cas entre os diversos computadores dotados de um mesmo sistema operacional (plataforma de opera c ao). 2. Cria c ao de um ambiente de desenvolvimento semelhante, onde outros programas podem ser desenvolvidos, testados e utilizados em diferentes computadores dotados de um mesmo SO, com a conseq uente cria c ao de uma plataforma de desenvolvimento. 3. Redu c ao das necessidades de treinamento e acelera c ao do processo de familiariza c ao e aprendizado no novo ambiente. Para estudarmos os sistemas operacionais devemos primeiro no familiarizar com o conceito de processo, fundamental para uma compreens ao mais ampla dos problemas envolvidos e de suas solu c oes. Depois ser ao estudadas a administra c ao da execu c ao dos programas no sistema, o gerenciamento de mem oria e tamb em dos dispositivos de entrada e sa da.
2 O projeto de interfaces consistentes, convenientes e uso simplicado, bem como sua avalia c ao, e uma disciplina compreendida como IHC ou Interface Humano-Computador.
20
Cap tulo 2
Processos
O estudo e o desenvolvimento dos sistemas operacionais requer a compreens ao de um conceito fundamental: processo computacional. Veremos que os processos computacionais constituem a unidade b asica de administra c ao de um sistema e, que junto deste importante conceito, surgem uma s erie de problemas que devem ser adequadamente equacionados dentro de qualquer sistema operacional.
2.1
O que e um processo computacional
Um processo computacional ou simplesmente processo pode ser entendido como uma atividade que ocorre em meio computacional, usualmente possuindo um objetivo denido, tendo dura c ao nita e utilizando uma quantidade limitada de recursos computacionais. Esta deni c ao traz algumas implica c oes: apenas as atividades que acontecem num sistema computacional s ao compreendidas como sendo processos computacionais. Outro ponto importante e a dura c ao nita, pois isto implica que um processo computacional, por mais r apido ou curto que possa ser tem sempre uma dura c ao maior que zero, ou seja, n ao existem processos instant aneos. Al em disso, um processo utiliza ao menos um dos recursos computacionais existentes para caracterizar seu estado. Simplicando, podemos entender um processo como um programa em execu c ao, o que envolve o c odigo do programa, os dados em uso, os registradores do processador, sua pilha (stack ) e o contador de programa al em de outras informa c oes relacionadas a sua execu c ao. Desta forma, temos que a impress ao de um documento e um processo computacional assim como a c opia de um arquivo, a compila c ao de um programa ou a execu c ao de uma rotina qualquer. Todas as atividades, manuais ou autom aticas, que ocorrem dentro de um computador podem ser descritas como processos computacionais. Atualmente quase todos os computadores s ao capazes de realizar diversas 21
22
CAP ITULO 2. PROCESSOS
tarefas ao mesmo tempo, onde cada uma destas tarefas pode representar um ou mesmo mais processos. Para funcionarem desta forma tais computadores s ao multiprogramados, ou seja, o processador e chaveado de processo em processo, em pequenos intervalos de tempo, isto e, o processador executa um programa durante um pequeno intervalo de tempo, para depois executar outro programa por outro pequeno intervalo de tempo e assim sucessivamente. Num instante de tempo qualquer, o processador estar a executando apenas um dado programa, mas durante um intervalo de tempo maior ele poder a ter executado trechos de muitos programas criando a ilus ao de paralelismo. Este comportamento e, algumas vezes, chamado de paralelismo virtual ou pseudoparalelismo. Em computadores com dois ou mais processadores e poss vel a exist encia de paralelismo verdadeiro pois cada processador pode executar um processo independentemente. A administra c ao de v arios diferentes programas em execu c ao concomitante e o que permite o funcionamento eciente dos computadores modernos, ao mesmo tempo conferindo-lhe complexa organiza c ao e estrutura pois tal administra c ao n ao e simples e requer a considera c ao de muitos fatores e situa c oes diferentes, mesmo que improv aveis. O termo processo (process ) e muitas vezes substitu do pelo termo tarefa (task ) e pode assumir um dos seguintes signicados: um programa em execu c ao; uma atividade ass ncrona; o esp rito ativo de um procedimento; uma entidade que pode utilizar um processador ou uma unidade que pode ser despachada para execu c ao.
2.1.1
Subdivis ao dos processos
Outro ponto importante e que os processos computacionais podem ser divididos em sub-processos, ou seja, podem ser decompostos em processos componentes mais simples que o processo como um todo, o que permite um detalhamento da realiza c ao de sua tarefa ou do seu modo de opera c ao. Esta an alise aprofundada dos processos atrav es de sua decomposi c ao em subprocessos pode ser feita quase que indenidamente, at e o exagerado limite das micro-instru c oes do processador que ser a utilizado. O n vel adequado de divis ao de um processo e aquele que permite um entendimento preciso dos eventos em estudo, ou seja, depende do tipo de problema em quest ao e tamb em da solu c ao pretendida. Processos tipicamente tamb em podem criar novos processos. O processo criador e chamado de processo-pai (parent process ) enquanto os processos
2.2. OCORRENCIA DE PROCESSOS
23
criados s ao denominados de processos lhos (child process ). Um processolho tamb em pode criar novos processos, permitindo a cria c ao de arvores de processos hierarquicamente relacionados, como exemplicado na Figura 2.1.
Figura 2.1: Subdivis ao de um processo
2.2
Ocorr encia de processos
importante estudarmos os processos computacionais porque a raz E ao de ser dos computadores e a realiza c ao de certas atividades de maneira mais r apida e con avel do que seria poss vel para o homem. Como cada processo precisa de recursos para ser executado e conclu do, a ocorr encia de processos signica a utiliza c ao de recursos do computador. Sendo assim, para que um sistema operacional possa cumprir com seu papel de gerente de recursos de um sistema computacional e fundamental um entendimento mais profundo dos processos computacionais e de suas particularidades como forma efetiva de criar-se sistemas operacionais capazes de lidar com as exig encias dos processos em termos de recursos. Um crit erio muito importante de an alise dos processos computacionais e aquele que considera os processos segundo sua ocorr encia, isto e, a observa c ao de seu comportamento considerando o tempo. Neste caso ter amos os seguintes tipos de processos: Seq uenciais S ao aqueles que ocorrem um de cada vez, um a um no tempo, serialmente, como que de forma exclusiva. Paralelos aqueles que, durante um certo intervalo de tempo, ocorrem simultaneamente, ou seja, aqueles que no todo ou em parte ocorrem ao mesmo tempo.
24
2.2.1
Processos seq uenciais
Dados que os processos seq uenciais s ao aqueles que ocorrem um de cada vez no tempo, como numa s erie de eventos (veja Figura 2.2), temos que para um dado processo, todos os recursos computacionais est ao dispon veis, ou seja, como s o ocorre um processo de cada vez, os recursos computacionais podem ser usados livremente pelos processos, n ao sendo disputados entre processos diferentes, mas apenas utilizados da maneira necess aria por cada processo.
Figura 2.2: Diagrama-exemplo de processos seq uenciais Esta aparente situa c ao de simplicidade esconde um outro fato alarmante: como e muito improv avel que um processo utilize mais do que alguns poucos recursos do sistema, todos os demais recursos n ao utilizados car ao ociosos por todo o tempo de execu c ao deste processo. No geral, com a execu c ao de um u nico processo, temos que a ociosidade dos diversos recursos computacionais e muito alta, sugerindo que sua utiliza c ao e pouco efetiva, ou, em outros termos, invi avel economicamente.
2.2.2
Processos Paralelos
Os processos paralelos s ao aqueles que, durante um certo intervalo de tempo, ocorrem simultaneamente, como mostra Figura 2.3. Se consideramos a exist encia de processos paralelos, ent ao estamos admitindo a possibilidade de que dois ou mais destes processos passem, a partir de um dado momento, a disputar o uso de um recurso computacional particular.
Figura 2.3: Diagrama-exemplo de processos paralelos Considerando tal possibilidade de disputa por recursos e tamb em sua natureza, os processos paralelos podem ser classicados nos seguintes tipos:
2.3. ESTADO DOS PROCESSOS
25
Independentes Quando utilizam recursos completamente distintos, n ao se envolvendo em disputas com outros processos. Concorrentes Quando pretendem utilizar um mesmo recurso, dependendo de uma a c ao do sistema operacional para denir a ordem na qual os processos usar ao o recurso. Cooperantes Quando dois ou mais processos utilizam em conjunto um mesmo recurso para completarem uma dada tarefa. Como n ao se pode prever quais os tipos de processos que existir ao num sistema computacional, o sistema operacional deve estar preparado para administrar a ocorr encia de processos paralelos concorrentes em quantidade, ou seja, dever a assumir a complexidade de administrar e organizar a coexist encia de in umeros processos diferentes disputando todos os tipos de recursos instalados no sistema. Apesar da maior complexidade, a exist encia de processos paralelos permitem o melhor aproveitamento dos sistemas computacionais e mais, atrav es do suporte oferecido pelo sistema operacional passa a ser poss vel a explora c ao do processamento paralelo e da computa c ao distribu da.
2.3
Estado dos processos
Dado que um processo pode ser considerado como um programa em execu c ao, num sistema computacional multiprogramado poder amos identicar tr es estados b asicos de exist encia de um processo: Pronto (Ready ) Situa c ao em que o processo est a apto a utilizar o processador quando este estiver dispon vel. Isto signica que o processo pode ser executado quando o processador estiver dispon vel. Execu c ao (Running ) Quando o processo est a utilizando um processador para seu processamento. Neste estado o processo tem suas instru c oes efetivamente executadas pelo processador. Bloqueado (Blocked ) Quando o processo est a esperando ou utilizando um recurso qualquer de E/S (entrada e sa da). Como o processo dever a aguardar o resultado da opera c ao de entrada ou sa da, seu processamento ca suspenso at e que tal opera c ao seja conclu da. Durante o ciclo de vida de um processo, isto e, desde seu in cio at e seu encerramento, podem ocorrer diversas transi c oes entre os estados relacionados, como ilustra a Figura 2.4. Devemos observar que entre os tr es estados b asicos existem quatro transi c oes poss veis, isto e, quatro situa c oes de modica c ao de estado que correspondem ` a a c oes espec cas do sistema operacional com rela c ao ao processos: Despachar (Dispatch ), Esgotamento
26
(TimeRunOut ), Bloqueio (Block ) e Reativar (Awake ). Al em destas quatro transi c oes existe outras duas correspondentes a Cria c ao (Create ) e Finaliza c ao (Terminate ) do processo.
Figura 2.4: Diagrama-exemplo de processos paralelos Quando solicitamos a execu c ao de um programa, o sistema operacional cria (Create ) um processo atribuindo a este um n umero de identica c ao ou seu PID (Process Identier ), um valor inteiro que servir a para distinguir este processo dos demais. Ap os a cria c ao, o processo e colocado no nal de uma la onde existem apenas processos prontos, ou seja, o estado inicial de um processo e denido como sendo o estado Pronto (Ready ). Quando todos os processos existentes nesta la, ou seja, criados anteriormente, j a tiverem utilizado seu quantum (fra c ao de tempo do processador), o sistema operacional acionar a uma rotina especial para Despachar (Dispatch ) o processo, ou seja, para efetivamente colocar o processo em execu c ao. Nesta situa c ao ocorrer a uma transi c ao do estado do processo de Pronto para Execu c ao (Running ). Quando a fra c ao de tempo destinada ao processo se esgotar, ocorrer a uma interrup c ao que devolver a o controle para o sistema operacional, fazendo-o acionar uma rotina especial (TimeRunOut ) para retirar o processo do processador e recoloc a-lo na la de processos prontos. Esta e transi c ao do estado Execu c ao para o estado Pronto. Nos casos em que o processo deseje utilizar algum dispositivo de entrada/sa da, ou seja, efetuar uma opera c ao de I/O, na solicita c ao deste recurso o pr oprio processo sair a do estado de Execu c ao entrando voluntariamente no estado Bloqueado (Blocked ) para utilizar ou esperar pela disponibilidade do recurso solicitado. Ao nalizar o uso do recurso, o sistema operacional recolocar a o processo na lista de processos prontos, atrav es da transi c ao denominada Reativa c ao ou Awake, que faz com que o processo passe do estados Bloqueado para Pronto. A Tabela 2.1 mostra resumidamente as opera c oes de transi c ao de estado dos processos, indicando os respectivos estados inicial e nal.
2.3. ESTADO DOS PROCESSOS
27
Tabela 2.1: Opera c oes de transi c ao de estado dos processos Opera c ao de Estado Estado Transi c ao Inicial Final Create() Ready Dispatch(PID) Ready Running TimeRunOut(PID) Running Ready Block(PID) Running Blocked Awake(PID) Blocked Ready Devemos destacar que a transi c ao do estado Execu c ao (Running ) para Bloqueado (Blocked ) eau nica causada pelo pr oprio processo, isto e, volunt aria, enquanto as demais s ao causadas por agentes externos (entidades do sistema operacional). Outro ponto importante e que os estados Pronto (Ready ) e Execu c ao (Running ) s ao estados considerados ativos enquanto que o estado Bloqueado (Blocked ) e tido como inativo. Num sistema em tempo repartido a entidade que coordena a utiliza c ao do processador por parte dos processos e o escalonador (scheduler ). O scheduler e uma fun c ao de baixo n vel, que se utiliza de um temporizador (timer ) do sistema para efetuar a divis ao de processamento que, em u ltima inst ancia e uma mera divis ao de tempo. Sendo assim est a intimamente ligada ao hardware do computador. Regularmente, a cada intervalo de tempo xo ou vari avel, este temporizador dispara uma interrup c ao (um mecanismo especial de chamada de rotinas) que ativa uma rotina que corresponde ao escalonador do sistema. Esta rotina realiza algumas opera c oes com os registradores do processador que forma que o resultado seja o chaveamento do processador para o pr oximo processo na la de processos em estado Pronto (Ready ). Ao encerrar-se esta interrup c ao o novo processo em execu c ao e aquele preparado pelo escalonador. Praticamente todas as outras fun c oes do sistema operacional s ao acionadas por chamadas expl citas ou impl citas de suas pr oprias fun c oes (chamadas de sistema ou system calls ) enquanto outras entidades do pr oprio sistema operacional assumem a forma de processos que tamb em compartilham o processamento. Neste sentido, as interrup c oes s ao um mecanismo important ssimo para que os sistemas possa alcan car melhores n veis de produtividade, pois permitem que perif ericos do sistema possam trabalhar de forma independente, caracterizando a execu c ao de atividades em paralelo num sistema computacional. De forma simplicada podemos dizer que o escalonador e a interrup c ao do temporizador do sistema se relacionam da seguinte maneira: 1. O processador empilha o program counter e tamb em o conte udo dos regsitradores do processador.
28
Figura 2.5: Representa c ao do escalonamento de processos 2. O processador carrega um novo valor para o program counter a partir do vetor de interrup c ao onde existe uma rotina que realizar a a troca de processos em execu c ao. 3. Rotina modica estado do processo cuja execu c ao foi interrompida (o processo atual) para Pronto (Ready ). 4. O conte udo dos registradores e o program counter empilhados s ao copiados para uma area de controle pr opria do processo interrompido (cada processo tem tal area de controle, como veremos na se c ao 2.4.1), preservando o contexto do processo interrompido.. 5. Rotina consulta escalonador para determinar qual ser a o pr oximo processo a ser executado (qual o processo que utilizar a processador). 6. Rotina copia o conte udo dos registradores e do program counter armazenado na area de controle do processo para a pilha, restaurando o contexto deste processo e, assim, alterando a seq u encia de retorno da interrup c ao. 7. O temporizador e reprogramado. 8. A rotina e nalizada e, com isso, encerrando a interrup c ao. 9. Processador restaura seus registradores e o program counter com base nos conte udo da pilha, passando a continuar a execu c ao de um processo que tinha sido interrompido em um momento anterior.
2.4
PCB e tabelas de processos
Quando o modelo de administra c ao de processos e adotado em um sistema operacional, para que este possa efetivamente controlar os processos existentes em um sistema, e comum a cria c ao e manuten c ao de uma tabela para a organiza c ao das informa c oes relativas aos processos chamada de tabela
2.4. PCB E TABELAS DE PROCESSOS
29
de processos. Esta tabela e usualmente implementada sob a forma de um vetor de estruturas ou uma lista ligada de estruturas. Para cada processo existente existe uma entrada correspondente nesta tabela, ou seja, um elemento da estrutura destinado a armazenar os dados relativos ao respectivo processo, como mostra a Figura 2.6. Tal estrutura, projetada para armazenar as informa c oes, recebe o nome de PCB.
2.4.1
PCB
O PCB (Process Control Block ou Process Descriptor ) e uma estrutura de dados que mant em a representa c ao de um processo para o sistema operacional. O PCB cont em todas as informa c oes necess arias para a execu c ao do mesmo possa ser iniciada, interrompida e retomada conforme determina c ao do sistema operacional, sem preju zo para o processo. Apesar de ser dependente do projeto e implementa c ao particulares do sistema operacional, geralmente o PCB cont em as seguintes informa c oes: identica c ao do processo (PID); estado corrente do processo; ponteiro para o processo pai (parent process ); lista de ponteiros para os processos lho (child processes ); prioridade do processo; lista de ponteiros para as regi oes alocadas de mem oria; informa c oes sobre hor ario de in cio, tempo utilizado do processador; estat sticas sobre uso de mem oria e perif ericos; c opia do conte udo do contador de programa (program counter ); c opia do conte udo dos registradores do processador; identicador do processador sendo utilizado; informa c oes sobre diret orios raiz e de trabalho; informa c oes sobre arquivos em uso; permiss oes e direitos. A Figura 2.6 ilustra uma tabela de processos e os PCB associados.
30
Figura 2.6: Organiza c ao de uma tabela de processos
2.4.2
Tabelas de processos
2.5
Opera c oes sobre processos
Considerando os estados poss veis dos processos e as necessidades dos sistema operacional, temos que dispor das seguintes opera c oes a serem realizadas sobre os processos: cria c ao (create ) destrui c ao (destroy ) suspens ao (suspend ou wait ) retomada (resume ) troca de prioridade bloqueio (block ) ativa c ao (activate ) execu c ao (execute ou dispatch ) comunica c ao inter-processo A cria c ao de um processo envolve algumas outras opera c oes particulares: identica c ao do processo (determina c ao do PID)
2.6. FUNC OES DO NUCLEO DE SISTEMA OPERACIONAL inser c ao do processo na lista de processos conhecidos do sistema determina c ao da prioridade inicial do processo cria c ao do PCB aloca c ao inicial dos recursos necess arios
31
2.6
Fun c oes do n ucleo de sistema operacional
Todas as opera c oes que envolvem os processos s ao controladas por uma parte do sistema operacional denominada n ucleo (core ou kernel ). Apesar do n ucleo n ao representar a maior parte do sistema operacional, e a parcela mais importante e mais intensivamente utilizada, tanto que ca permanentemente alocada na mem oria prim aria do sistema. Uma das mais importantes fun c oes do n ucleo do sistema operacional e o gerenciamento das interrup c oes, pois em grandes sistemas, um grande n umero delas e constantemente dirigida ao processador e seu efetivo processamento determina qu ao bem ser ao utilizados os recursos do sistema e, consequentemente, como ser ao os tempos de resposta para os processos dos usu arios. O n ucleo de um sistema operacional constr oi, a partir de uma m aquina f sica dotada de um ou mais processadores, n m aquinas virtuais, onde cada m aquina virtual e designada para um processo. Tal processo, dentro de certos limites impostos pelo sistema operacional, controla sua m aquina virtual de modo a realizar suas tarefas. Resumidamente, o n ucleo de um sistema operacional deve conter rotinas para que sejam desempenhadas as seguintes fun c oes: gerenciamento de interrup c oes manipula c ao de processos (cria c ao, destrui c ao, suspens ao, retomada etc.) manipula c ao dos PCBs (Process Control Blocks ) troca de estados dos processos (execu c ao, timerunout e ativa c ao) intercomunica c ao de processos sincroniza c ao de processos gerenciamento de mem oria gerenciamento de dispositivos de E/S suporte a um ou mais sistemas de arquivos
32
CAP ITULO 2. PROCESSOS suporte ` a fun c oes de administra c ao do sistema
Devido ao uso intensivo destas rotinas, e comum que boa parte delas sejam programadas diretamente em assembly, permitindo assim grande otimiza c ao e, portanto, a maior eci encia poss vel em sua execu c ao.
2.7
Competi c ao por recursos
Quando armamos que existir ao dois ou mais processos em execu c ao paralela estamos admitindo a possibilidade de que alguns destes processos solicitem a utiliza c ao de um mesmo recurso simultaneamente. Conforme o tipo de recurso requisitado e tamb em as opera c oes pretendidas, e desej avel que ocorra o compartilhamento de tal recurso ou, como e mais frequente, que seja exigido o uso individual e organizado de recurso. Obviamente o processo que recebe o direito de usar primeiramente o recurso e favorecido em rela c ao aos demais, transformando tal situa c ao numa competi c ao pelos recursos do sistema. A exig encia de uso individual ou a possibilidade de compartilhamento caracterizam duas situa c oes importantes: o c odigo reentrante e as regi oes cr ticas, que ser ao tratadas nas se c oes seguintes.
2.7.1
Regi oes cr ticas
Quando um dado recurso computacional s o pode ser utilizado por um u nico processo de cada vez, dizemos que este recurso determina uma regi ao cr tica (ou critical section ), como representado na Figura 2.7. Sendo assim uma regi ao cr tica pode ser uma rotina de software especial ou um dispositivo de hardware ou uma rotina de acesso para um certo dispositivo do hardware.
Figura 2.7: Representa c ao de uma regi ao cr tica Segundo Guimar aes:
2.8. PROTOCOLOS DE ACESSO Uma regi ao cr tica e, no fundo, uma forma de administrar a concess ao e devolu c ao de um recurso comum. [GUI86, p. 81]
33
A situa c ao que se deseja e a exclus ao m utua, ou seja, quando um processo qualquer utiliza a regi ao cr tica, todos os demais, sejam quais forem, s ao exclu dos, isto e, cam impossibilitados de utiliz a-la. Apenas quando a regi ao cr tica for liberada e que um outro processo ter a acesso a mesma e tamb em de forma exclusiva. Os processos de desejam utilizar uma regi ao cr tica s ao, portanto, processos paralelos concorrentes. Quando acidentalmente acontece o acesso de um ou mais processos enquanto regi ao cr tica est a ocupada ou quando dois ou mais processo adentram a regi ao cr tica simultaneamente, dizemos estar ocorrendo um acesso simult aneo. Tal situa c ao geralmente conduz a perda de dados de um ou mais dos processos participantes e, as vezes, o comprometimento da estabilidade do sistema como um todo. Para prevenir que mais de um processo fa ca uso de uma regi ao cr tica, n ao e razo avel que tal controle seja realizado pelos pr oprios processos, pois erros de programa c ao ou a c oes mal intencionadas poderiam provocar preju zos aos usu arios ou comprometer a estabilidade do sistema. Assim, o sistema operacional implementa uma rotina de tratamento especial denominada protocolo de acesso (se c ao 2.8) que, al em de determinar os crit erios de utiliza c ao do recurso, resolve as situa c oes de competi c ao bem como a organiza c ao de uma eventual lista de espera no caso de disputa do recurso por processos concorrentes.
2.7.2
C odigo reentrante
Em contrante com as regi oes cr ticas, quando uma certa rotina de software pode ser utilizada simultaneamente por uma quantidade qualquer de processos, dizemos que esta rotina e um bloco de c odigo reentrante ou c odigo p ublico (ou ainda public code ), como ilustrado na Figura 2.8. O c odigo reentrante e uma situa c ao bastante desej avel, pois representa um compartilhamento ben eco para o sistema, onde um mesmo recurso e utilizado por diversos processos, aumentando a eci encia do sistema como um todo.
2.8
Protocolos de acesso
Um protocolo de acesso (access protocol ) e composto por uma rotina de entrada e uma outra de sa da. A rotina de entrada determina se um processo pode ou n ao utilizar o recurso, organizando um la de espera (espera inativa) ou apenas bloqueando a entrada do processo (espera ativa). A rotina de sa da e executada ap os o uso do recurso, sinalizando que este se encontra
34
Figura 2.8: Representa c ao de c odigo reentrante
desocupado, ou seja, causando a libera c ao do recurso para outro processo em espera ou bloqueado. N ao se pode denir o acesso ` a recursos unicamente pela atribui c ao de prioridades xas, pois podem ocorrer situa c oes onde um processo de prioridade mais baixa n ao consegue utilizar a regi ao cr tica dado que sempre existem processos de maior prioridade, congurando um problema de prioridade est atica. Existem tamb em as situa c oes de bloqueio simult aneo, onde os v arios processos que est ao em disputa pelo uso recurso s ao bloqueados de modo tal que o recurso continue sem uso, ou ainda de adiamento innito, onde um processo e sistem atica e indenidamente bloqueado de utilizar o recurso. Todas estas situa c oes tamb em s ao inaceit aveis. Devemos ainda considerar que o sistema operacional gerencia diferentes tipos de recursos computacionais, isto e, controla dispositivos com caracter sticas bastante diferenciadas em termos de velocidade, capacidade e, principalmente utiliza c ao. O processador possui certas caracter sticas enquanto a mem oria possui outras. Acontece o mesmo quando avaliamos a funcionalidade de unidades de disco e ta, impressoras, portas de comunica c ao e outros dispositivos que podem ser interligados a um sistema computacional. Desta forma o tratamento ideal que deve ser dado a uma impressora n ao pode ser aceit avel para um outro tipo de dispositivo. Torna-se obvio que o controle destes diferentes dispositivos por si s o adiciona uma razo avel complexidade aos sistemas operacionais, mas quando consideramos que diferentes processos computacionais far ao uso distinto e imprevis vel destes recursos, tal complexidade e as inerentes diculdades aumentam tremendamente, exigindo especial aten c ao durente o projeto do sistema. O sistema operacional deve dispor de um protocolo de acesso diferente para cada tipo de recurso devido suas caracter sticas pr oprias, as quais devem ser respeitadas durente sua utiliza c ao. Quando tais caracter sticas s ao
2.8. PROTOCOLOS DE ACESSO
35
entendidas e tratadas da forma adequada podemos obter situa c oes que favore cam o desempenho global do sistema. De modo resumido, as caracter sticas desej aveis de um protocolo de acesso est ao relacioandas na Tabela 2.2 Tabela 2.2: Fun c oes de um protocolo de acesso Garantir Evitar Exclus ao M utua Acesso Simult aneo Bloqueio M utuo ou Simult aneo Adiamento Indenido Prioridade Est atica Na Figura 2.9 temos um exemplo simplicado de um protocolo de acesso, com destaque as suas partes de entrada e sa da. Aparentemente o problema parece resolvido, mas em situa c oes de corrida, isto e, nas situa c oes onde dois ou mais processos procuram acessar um recurso simultaneamente (ou algo pr oximo a isto), pode ocorrer uma viola c ao do desejado acesso exclusivo: se dois processos executarem o teste da vari avel de controle X antes que um deles consiga fazer com que X = 0, ent ao ambos utilizar ao a regi ao cr tica. Mesmo considerando que, na verdade, os processos n ao est ao sendo executados paralelamente, se o primeiro deles e interrompido ap os o teste, mas antes da altera c ao da vari avel de controle, ent ao qualquer outro poder a adentrar a regi ao cr tica. Quando o primeiro tem retomada sua execu c ao, ele continuar a seu processamento usando a regi ao cr tica, mesmo que esteja ocupada, pois j a realizou o teste da vari avel de controle, provocando os problemas descritos.
Figura 2.9: Protocolo de acesso simples O protocolo exemplicado necessita de 2 a 4 instru c oes para ser implementado numa m aquina convencional (vide Exemplo 2.1), portanto pode ocorrer uma interrup c ao de um dos processos durante a execu c ao do trecho antes da atualiza c ao da vari avel X.
36 La co: LDA X BZ La co CLR X . . .
CAP ITULO 2. PROCESSOS ; Carrega o acumulador com X ; Se zero repete o teste ; Zera vari avel X ; Entra na RC
Exemplo 2.1 C odigo assembly de protocolo de acesso ineciente Uma an alise cuidadosa permite ver que X, uma vari avel comum aos processos, tamb em deveria ser usada de forma exclusiva, ou seja, tamb em constitui uma regi ao cr tica e, assim, apenas adiou-se o problema de um n vel. A modica c ao do protocolo exemplicado utilizando-se uma instru c ao de troca, isto e, uma instru c ao que efetua a movimenta c ao de conte udo entre dois registradores distintos, permite resolver o problema, como ilustrado no Exemplo 2.2. La co: CLR A EXA X BZ La co . . . . . . . . . ; Zera o acumulador ; Troca acumulador com X ; Se zero repete o teste ; Entra na RC
; Sai da RC MVI A,1 ; Coloca um no acumulador EXA X ; Troca acumulador com X
Exemplo 2.2 Protocolo de acesso funcional com instru c ao EXA
2.8.1
Solu c ao com instru c oes TST ou TSL
O uso de instru c oes de troca levou alguns fabricantes a criarem uma instru c ao especial denominada TST (Test and Set ) ou TSL (Test and Set Lock ). As instru c oes TST ou TSL foram primeiramente implementadas no nal da d ecada de 1950 e introduzidas na linha IBM/360. Tais instru c oes realizavam duas opera c oes atomicamente, isto e, de forma indivis vel, n ao podendo ser interrompida durante sua execu c ao, permitindo assim resolver os problemas de exclus ao m utua encontrados at e ent ao. As opera c oes realizadas atrav es de uma instru c ao TST s ao ilustradas abaixo: TST(v, x) Equivale ` a: v ? x ? x 1 ; copia valor de x para v ; seta valor de x para 1
Com isto poder amos implementar um protocolo de acesso eciente atrav es da constru c ao de duas primitivas de exclus ao m utua como indicado
2.8. PROTOCOLOS DE ACESSO abaixo: Enter Region: TSL reg, flag CMP reg, #0 JNZ Enter Region RET Leave Region: MOV flag, #0 RET ; ; ; ;
37
copia flag p/ reg e a seta para 1 compara flag com zero se n~ ao zero loop (travado) retorna, i.e., entrou na RC
; armazena zero na flag ; retorna, i.e., saiu da RC
Exemplo 2.3 Protocolo de acesso eciente com instru c ao TST Apesar da solu c ao oferecida pelas instru c oes TST, o problema da exclus ao m utua n ao estava completamente resolvido, pois tais instru c oes s o resolvem tal quest ao em sistemas dotados de um u nico processador. Embora na epoca n ao se pretendesse construir computadores dotados de m ultiplos processadores, percebia-se que tais instru c oes eram apenas um solu c ao parcial e tempor aria.
2.8.2
Situa c oes de corrida
Dizemos existir uma situa c ao de corrida quando a execu c ao de dois ou mais processos se d a, de tal forma, que tais processos solicitam o uso de uma regi ao cr tica simultaneamente ou praticamente nesta condi c ao. As situa c oes de corrida exigem protocolos de acesso extremamente bem elaborados para evitarmos o acesso simult aneo ou o bloqueio m utuo. Para ilustrar o que s ao as situa c oes de corrida, imaginemos um sistema multiusu ario que disp oe de v arios de terminais, onde cada terminal e monitorado por um processo especial que necessita efetuar a contagem das linhas de texto enviadas pelos usu arios. A contagem do total das linhas de texto e mantida atrav es de uma vari avel global de nome linesEntered. Assumamos que cada terminal em uso seja representado por um processo que possui uma c opia da rotina exibida no Exemplo 2.4 a qual atualiza o n umero de linhas de texto enviadas por cada terminal: LOAD linesEntered ADD 1 STORE linesEntered Exemplo 2.4 Rotina local de contagem de linhas Imaginando que o valor corrente de linesEntered e 21687 quando um processo executa as instru c oes LOAD e ADD, sendo interrompido pelo sistema operacional e, assim, deixando a valor 21688 no acumulador. Se um segundo
38
processo executa a rotina de forma completa, como o valor 21688 ainda n ao foi armazenado em mem oria, o valor 21697 ser a utilizado novamente resultando em 21688. Quando o primeiro processo retomar sua execu c ao o valor 21688, presente no acumulador ser a armazenado novamente. Concluimos que o sistema perdeu o controle do n umero de linhas enviado pois o valor correto deveria ser 21689! Isto ocorreu porque dois processos acessaram simultaneamente a regi ao cr tica delimitada pelas opera c oes realizadas sobre a vari avel global linesEntered. Para evitar-se este problema cada processo deveria ter recebido acesso exclusivo ` as opera c oes sobre a vari avel linesEntered que e uma regi ao cr tica. Embora o problema de controle de linhas de texto enviadas pare ca in util, imagine que a contagem se rera a pe cas produzidas numa f abrica que conta com diversas linhas de produ c ao: ao nal de um per odo n ao se saberia com certeza quantas pe cas foram produzidas, sendo necess ario cont a-las no estoque. O mesmo vale para um sistema de controle de estoque, num problema semelhante envolvendo a contagem da retirada de pe cas. Quando um n umero m nimo e atingido, se faz necess aria a compra de pe cas para que a produ c ao n ao seja interrompida pela falta das mesmas. Se a opera c ao de retirada n ao e contabilizada corretamente torna-se prov avel que a produ c ao seja interrompida por falta de pe cas. Numa institui c ao nanceira, o mesmo tipo de problema poderia se reetir no saldo da conta corrente de um cliente, onde dependendo da ordena c ao dos eventos, um d ebito ou um cr edito poderiam deixar de ser efetuados, prejudicando a institui c ao ou o cliente. Torna-se claro que todas estas s ao situa c oes inadmiss veis. Percebemos ser muito importante que um sistema operacional ofere ca mecanismos de controle adequado para seus recursos e tamb em oferecendo suporte para o desenvolvimento de aplica c oes. Como o problema do acesso exclusivo tamb em pode surgir em decorr encia de aplica c oes com m ultiplos usu arios ou que apenas compartilhem dados de maneira especial, seria conveniente dispor-se de primitivas de controle para que os pr oprios programadores realizassem, com seguran ca, tal tarefa. Tais primitivas de programa c ao poderiam ser EnterMutualExclusion e ExitMutualExclusion, que respectivamente signicam a indica c ao de entrada e sa da de uma regi ao cr tica. Tais primitivas poderiam ser utilizadas como mostra o Exemplo 2.5, que resolve o problema de acesso ` a vari avel global linesEntered. As primitivas EnterMutualExclusion e ExitMutualExclusion correspondem a implementa c ao das regi oes de entrada e sa da de um protocolo de acesso gen erico. Tamb em poderiam ser utilizadas as instru c oes TST nesta implementa c ao ou usadas outras solu c oes mais elegantes, tais como a de Dekker (se c ao 2.9) ou de Peterson (se c ao 2.10).
2.8. PROTOCOLOS DE ACESSO
39
program ExclusaoMutua; { Vari avel global para contagem das linhas } var linesEntered: integer; { Procedimento correspondente ao primeiro terminal } procedure ProcessoUm; begin while true do begin LeProximaLinhaDoTerminal; EnterMutualExclusion; linesEntered := linesEntered + 1; ExitMutualExclusion; ProcessaALinha; end; end; { Procedimento correspondente ao segundo terminal } procedure ProcessoDois; begin while true do begin LeProximaLinhaDoTerminal; EnterMutualExclusion; linesEntered := linesEntered + 1; ExitMutualExclusion; ProcessaALinha; end; end; { Programa principal: ativa c~ ao dos terminais } begin linesEntered := 0; parbegin ProcessoUm; ProcessoDois; parend; end. Exemplo 2.5 Uso de primitivas de exclus ao m utua
40
2.8.3
Requisitos de um protocolo de acesso
Antes de nos concentrarmos em outras solu c oes para o problema da exclus ao m utua, e interessante analisar os requisitos desej aveis para um protocolo de acesso eciente, os quais podem ser expressos atrav es dos postulados de Dijkstra [GUI86, p. 78]: 1. A solu c ao n ao deve impor uma prioridade est atica entre os processos que desejem acessar a regi ao cr tica. 2. A u nica hip otese que pode ser feita quanto a velocidade de execu c ao dos processos paralelos e que ela e n ao nula e, em particular, quando um processo acessa um regi ao cr tica ele sempre a libera depois de um tempo nito. 3. Se um processo e bloqueado fora da regi ao cr tica, isto n ao deve impedir que outros processos acessarem a regi ao cr tica. 4. Mesmo em improv aveis situa c oes de corrida, s ao inaceit aveis as situac oes de bloqueio m utuo ou acesso simult aneo de processos em uma regi ao cr tica.
2.9
A solu c ao de Dekker
At e 1964 n ao se conhecia uma solu c ao geral considerada satisfat oria para o problema de exclus ao m utua, excetuando-se os mecanismos de hardware implementados pelas instru c oes de troca e TTST. Neste ano o matem atico holand es T. J. Dekker prop os uma solu c ao para o problema de exclus ao m utua de dois processos, a qual n ao necessitava instru c oes especiais implementadas pelo hardware, ou seja, uma solu c ao que utilizava apenas os recursos comuns das linguagens de programa c ao. A engenhosa solu c ao baseia-se em uma vari avel de controle para cada processo envolvido, no caso Avez e Bvez. Cada processo possui uma vers ao ligeiramente diferente do algoritmo do protocolo de acesso, pois cada uma das vari aveis de controle s o s ao alteradas pelos processos as quais pertencem. Al em destas vari aveis de controle individual, existe uma outra para determina c ao de prioridade (Pr), que pode ser manipulada por todos os processos envolvidos mas apenas ap os o uso da regi ao cr tica. Esta elegante solu c ao tornou-se conhecida como solu c ao de Dekker para exclus ao m utua de dois processos e e ilustrada na Figura 2.10. O uxograma ilustrado na Figura 2.10 representa apenas o algoritmo da solu c ao de Dekker correspondente ao processo A. Para obtermos a vers ao deste uxograma correspondente ao processo B, devemos substituir as ocorr encias da vari avel Avez por Bvez e vice-versa e depois as ocorr encias de B por A e vice-versa. O funcionamento correto desta solu c ao implica na
DE DEKKER 2.9. A SOLUC AO
41
Figura 2.10: Algoritmo de Dekker para exclus ao m utua de 2 processos utiliza c ao destes dois algoritmos, cada um destinado a um dos processos envolvidos. Mesmo em situa c oes de corrida, a solu c ao garante a exclus ao m utua, evitando o adiamento indenido, a prioridade est atica e o acesso simult aneo. Para demonstrarmos uma aplica c ao da solu c ao de Dekker, temos no Exemplo 2.6 uma sugest ao para a resolu c ao do problema de contagem das linhas enviadas pelos terminais usando a nota c ao de paralelismo Pascal. A solu c ao proposta por Dekker apresenta as seguintes vantagens: e particularmente elegante, pois n ao necessita de instru c oes especiais no hardware ; um processo fora de sua regi ao cr tica n ao impede (n ao bloqueia) outro processo de adentr a-la; e um processo que deseja entrar na regi ao cr tica o far a sem a possibilidade de adiamento innito. Em contrapartida esta solu c ao possui algumas desvantagens que s ao: torna-se complexa para um n umero maior de processos pois exige a introdu c ao de novas opera c oes de teste a cada processo adicionado; e de dif cil implementa c ao pois necessita uma rotina diferente para cada processo; e imp oe uma espera ativa ou espera ocupada, isto e, o processo bloqueado continua consumido tempo do processador na area de entrada do protocolo de acesso para vericar a possibilidade de entrada na regi ao cr tica.
42
program ExclusaoMutuaDekker; { Globais para contagem das linhas e prioridade } var linesEntered: integer; processo: integer; procedure ProcessoUm; { Primeiro terminal } begin while true do begin LeProximaLinhaDoTerminal; while processo = 2 do; { espera RC livre } { Regi~ ao Cr tica } linesEntered := linesEntered + 1; { Fim da Regi~ ao Cr tica } processo := 2; ProcessaALinha; end; end; procedure ProcessoDois; { Segundo terminal } begin while true do begin LeProximaLinhaDoTerminal; while processo = 1 do; { espera RC livre } { Regi~ ao Cr tica } linesEntered := linesEntered + 1; { Fim da Regi~ ao Cr tica } processo := 1; ProcessaALinha; end; end; { Programa principal: ativa c~ ao dos terminais } begin linesEntered := 0; processo := 1; { valor arbitrariamente escolhido } parbegin ProcessoUm; ProcessoDois; parend; end. Exemplo 2.6 Solu c ao do problema dos terminais atrav es de Dekker
DE PETERSON 2.10. A SOLUC AO
43
Dijkstra generalizou a solu c ao de Dekker para n processos em 1965 e, como era de se esperar, a generaliza c ao mostrou-se bem mais complicada. Donald Knuth aperfei coou ainda mais a solu c ao geral de Dijkstra, eliminando a possibilidade de adiamento innito. Visto a introdu c ao de instru c oes tipo TST o interesse nestas solu c oes e apenas hist orico.
2.10
A solu c ao de Peterson
Outras maneiras de implementar-se primitivas de exclus ao m utua seria atrav es da utiliza c ao do algoritmo de G. L. Peterson, publicado em 1981, que representa uma solu c ao mais simples que a solu c ao de Dekker. A solu c ao de Peterson, como colocado na Listagem 9, se baseia na deni c ao de duas primitivas de exclus ao m utua, utilizadas pelos processos que desejam utilizar a regi ao cr tica. Tais primitivas s ao as fun c oes enter region() e leave region() que, respectivamente, devem ser utilizadas para sinalizar a entrada do processo na regi ao cr tica e sua sa da da mesma. #define FALSE 0 #define TRUE 1 #define N 2 int turn; int interested[N]; void enter region(int process) { int other = 1 - process; interested[process] = TRUE; turn = process; while (turn==process && interested[other]==TRUE); } void leave region(int process) { interested[process] = FALSE; } Exemplo 2.7 Solu c ao de Peterson para exclus ao m utua de 2 processos Note tamb em o uso de um vetor contendo a sinaliza c ao de interesse dos processo em utilizar a regi ao cr tica. No exemplo e dado a solu c ao para dois processos, que simplica a determina c ao de interesse por parte dos demais processos. Na solu c ao proposta por Peterson temos que as fun c oes enter region() e leave region() s ao equivalentes as primitivas EnterMutualExclusion e
44
ExitMutualExclusion respectivamente. Tal solu c ao e bastante simples e pode ser facilmente implementada para n processos diferentes pois a mesma rotina serve a todos os processos. Sua u nica desvantagem e que imp oe uma espera ocupada, tal como na solu c ao de Dekker ou atrav es do uso de instru c oes TST. Os sistemas operacionais Microsoft Windows 9x/2000 oferecem um mecanismo eciente e relativamente simples para o controle de acesso ` a regi oes cr ticas, baseado numa estrutura especial designada Critical Section e algumas primitivas de controle [CAL96, p. 224]: InitializeCriticalSection, que prepara o uso de uma regi ao cr tica; EnterCriticalSection, que corresponde a solicita c ao de uso da regi ao cr tica (regi ao de entrada do protocolo de acesso); LeaveCriticalSection, que corresponde a naliza c ao do uso da regi ao cr tica (regi ao de sa da do protocolo de acesso); e DeleteCriticalSection, que elimina as estruturas de controle declaradas para uma regi ao cr tica. Tal mecanismo pode ser utilizado como sugerido no Exemplo 2.8, o qual est a expresso na linguagem ObjectPascal do Borland Delphi. { declara c~ ao da vari avel especial de controle } Section: TRTLCriticalSection; { inicializa c~ ao da vari avel de controle } InitializeCriticalSection(Section); { sinaliza c~ ao de entrada na regi~ ao cr tica } EnterCriticalSection(Section); { c odigo da regi~ ao cr tica e posicionado aqui } { sinaliza c~ ao de sa da na regi~ ao cr tica } LeaveCriticalSection(Section); { libera c~ ao da vari avel de controle } DeleteCriticalSection(Section); Exemplo 2.8 Mecanismo de exclus ao m utua no MS-Windows 9x/2000 A declara c ao da vari avel especial de controle deve ser global, enquanto que a inicializa c ao e libera c ao desta vari avel deve ocorrer respectivamente
2.11. DEADLOCKS
45
antes de qualquer uso da regi ao cr tica e ap os a naliza c ao de tal uso por diferentes processos da aplica c ao (no caso threads da aplica c ao). O c odigo reconhecido como regi ao cr tica deve ser posicionado entre as primitivas de sinaliza c ao de entrada e sa da da regi ao cr tica, sendo utilizado por todos as rotinas que possam estar em execu c ao concomitante. Esta solu c ao resolve problemas de exclus ao m utua originados por processos de uma mesma aplica c ao, ou seja, threads de um mesmo programa. Para sincroniza c ao de rotinas de programas diferentes deve ser utilizado outro mecanismo, denominado Mutexes no MS-Windows 9x, cujo funcionamento e semelhante aos sem aforos (veja a se c ao 2.12.2). Sem aforos, Sem aforos Contadores e Contadores de eventos s ao outros tipos de solu c ao de podem solucionar problemas de exclus ao m utua. Algumas destas alternativas ser ao vistas mais a frente, quando tratarmos da comunica c ao inter-processos (se c ao 2.12).
2.11
Deadlocks
Em sistema multiprogramado, o termo deadlock, ou seja, bloqueio perp etuo ou impasse, signica um evento que jamais ir a ocorrer [DEI92, TAN92, SGG01]. Dizemos que um processo est a em deadlock quando espera por um evento particular que jamais acontecer a. Igualmente dizemos que um sistema est a em deadlock quando um ou mais processos est ao nesta situa c ao. Segundo Tanenbaum: Um conjunto de processos est a num bloqueio perp etuo quando cada processo do conjunto est a esperando por um evento que apenas outro processo do conjunto pode causar. [TAN92, p. 242] Observemos a Figura 2.11, onde temos ilustrado um deadlock que pode ocorrer em duas linhas de trens cujas interse c oes n ao s ao compartilh aveis. Problemas semelhantes podem ocorrer no tr ansito de uma metr opole. Um bloqueio perp etuo pode ocorrer de diferentes maneiras: Quando um processo e colocado em espera por algo e o sistema operacional n ao inclui qualquer previs ao para o atendimento desta espera dizemos que ocorreu o bloqueio perp etuo de um processo u nico (oneprocess deadlock ). Quando se forma uma cadeia sucessiva de solicita c oes de recursos que culminam num arranjo circular, onde um processo A, que det em um recurso R1, solicita um recurso R2 alocado para um processo B, que por sua vez est a solicitando o recurso R1, em uso por A (veja a Figura 2.15). Como nenhum processo de disp oe a, voluntariamente, liberar o recurso que aloca, congura-se uma situa c ao de bloqueio perp etuo.
46
Figura 2.11: Representa c ao de um deadlock Independentemente do tipo, os deadlocks causam preju zos s erios ao sistema, pois mesmo num one-process deadlock, recursos cam alocados desnecessariamente, o que signica que restar ao menos recursos para os demais processos. Nos deadlocks circulares, al em da aloca c ao desnecess aria de recursos, podem ser formadas las de esperas pelos recursos envolvidos, deteriorando o tempo de resposta do sistema, podendo at e causar situa c oes de instabilidade ou crash do sistema operacional. Quando um processo e bloqueado indenidamente, cando em espera por um recurso, dizemos que est a ocorrendo um adiamento indenido ou bloqueio indenido (respectivamente indenite postponement, indenite blocking ). Como um processo nessa situa c ao n ao pode prosseguir com sua a execu c ao devido a aus encia de recursos, tamb em dizemos que ele est a em starvation (isto e, estagnado ). A maioria dos problemas que culminam com os deadlocks est ao relacionados com recursos dedicados, isto e, com recursos que devem ser utilizados serialmente, ou seja, por um processo de cada vez [DEI92, p. 156].
2.11.1
Diagramas de processos e recursos
O estudo dos bloqueios perp etuos pode ser bastante facilitado atrav es da utiliza c ao de diagramas especiais denominados diagramas de aloca c ao de recursos ou diagramas de processo versus recursos ou ainda grafos de aloca c ao de recursos [SGG01, p. 162]. Nestes diagramas existem apenas duas entidades, processos e recursos, interligadas por arcos direcionados. Os processos s ao representados atrav es de quadrados ou ret angulos. Os recursos s ao representados atrav es de circunfer encias. Os arcos direcionados unindo processos e recursos s ao usados com dois signicados distintos: requisi c ao de recursos e aloca c ao de recursos. Na Figura 2.12 temos os elementos construtivos poss veis deste tipo de
2.11. DEADLOCKS diagrama.
47
Figura 2.12: Elementos do Diagrama de Processos x Recursos Recursos capazes de ser compartilhados podem ser representados por pequenas circunfer encias, dispostas dentro do recurso compartilh avel, uma para cada unidade de sua capacidade de compartilhamento. Assim, atrav es destes tr es elementos (ret angulos, circunfer encias e arcos) podemos representar uma innidade de diferentes situa c oes envolvendo processos, seus pedidos de recursos (requests) e a aloca c ao de recursos determinada pelo sistema operacional (grants). Ao mesmo tempo, temos que s ao proibidas as constru c oes ilustradas na Figura 2.13, isto e, processos requisitando ou alocando outros processos e, da mesma forma, recursos requisitando ou alocando outros recursos.
Figura 2.13: Situa c oes proibidas no diagrama de processos e recursos Usualmente n ao se ilustram o uso de mem oria e processador por parte dos processos, de modo que passam a n ao existir processos isolados, isto e, processos que n ao estejam utilizando algum outro tipo de recurso. Na Tabela 2.3 est ao relacionados os recursos do sistema, os processos alocados os processos requisitantes destes recursos. Atrav es da Tabela 2.3 podemos construir o diagrama de processos e recursos ilustrado na Figura 2.14. Neste exemplo, embora exista disputa por recursos (processos B e E requisitam o uso do recurso W), n ao existe nenhum caminho fechado, ou seja, n ao existe qualquer deadlock, sendo assim este diagrama pode ser reduzido: 1. D naliza o uso de Z. 2. Com Z livre, C libera W para alocar Z.
48
Tabela 2.3: Exemplo de aloca c ao e requisi c ao de recursos Recurso Processo Processo(s) Alocado Requisitante X A Y B A W C B, E Z D C
Figura 2.14: Diagrama de processos e recursos da Tabela 2.3
3. Com W livre, ou B ou E poder ao aloc a-lo. Se B for favorecido nesta disputa, alocando W, embora E permane ca em espera, Y ser a liberado. 4. Com Y livre, A libera X para alocar Y. 5. N ao surgindo novos processos, B libera W. 6. Com W livre, E pode prosseguir sua execu c ao. A redu c ao, independentemente do tempo que os processos utilizar ao os recursos alocados, mostra que tais processos ser ao atendidos dentro de um intervalo de tempo menor ou maior. A despeito de quest oes relacionadas com desempenho, esta a situa c ao desej avel em um sistema. Diferentemente, a aloca c ao e requisi c ao de recursos em um sistema pode congurar um deadlock. Utilizando o diagrama de aloca c ao de recursos, poder amos representar um deadlock envolvendo dois processos e dois recursos, como ilustra a Figura 2.15. Atrav es destes diagramas, ca clara a situa c ao da forma c ao de uma cadeia circular (um caminho fechado) ligando uma sequ encia de requisi c oes e aloca c oes de recursos do sistema por parte de um grupo de processos.
2.11. DEADLOCKS
49
Figura 2.15: Representa c ao de deadlock envolvendo 2 processos
2.11.2
Condi c oes para ocorr encia de deadlocks
Coman, Elphick e Shoshani (1971) armam que existem quatro condi c oes para a ocorr encia de um deadlock : 1. Os processos exigem controle exclusivo dos recursos que solicitam (condi c ao de exclus ao m utua). 2. Os processos mant em alocados recursos enquanto solicitam novos recursos (condi c ao de espera por recurso) 3. Os recursos n ao podem ser retirados dos processos que os mant em alocados enquanto estes processos n ao nalizam seu uso (condi c ao de aus encia de preemptividade). 4. Forma-se uma cadeia circular de processos, onde cada processo solicita um recurso alocado pelo pr oximo processo na cadeia (condi c ao de espera circular). Segundo Tanenbaum [TAN92, p. 245] existem basicamente quatro alternativas para o tratamento dos bloqueios perp etuos, ou seja, quatro estrat egias b asicas para resolvermos os problemas dos deadlocks : 1. Ignorar o problema (algoritmo da avestruz) Apesar de n ao parecer uma solu c ao para o problema, devem ser consideradas a possibilidade de ocorr encia dos deadlocks e os custos computacionais associados ao seu tratamento. A alternativa mais simples realmente e ignorar o problema e conviver com a possibilidade de sua ocorr encia. Os sistemas UNIX utilizam esta aproxima c ao favorecendo aspectos de performance em situa c oes mais comuns. 2. Detec c ao e recupera c ao dos deadlocks Outra alternativa e permitir que os bloqueios ocorram, procurandose detect a-los e recuper a-los. Deve-se utilizar algum algoritmo que produza um diagrama de aloca c ao de recursos, analisando em busca
50
CAP ITULO 2. PROCESSOS de caminhos fechados (deadlocks ) utilizando alguma t ecnica de recupera c ao. Estes algoritmos especiais, que apesar da sobrecarga que provocam, podem evitar maiores transtornos no sistema possibilitando que na ocorr encia dos deadlocks estes sejam descobertos e eliminados. 3. Preven c ao din amica Os deadlocks podem ser prevenido atrav es de procedimentos cuidadosos de aloca c ao que analisam constantemente a possibilidade de forma c ao de cadeias circulares. Tais algoritmos tamb em s ao complexos e acabam por onerar o sistema computacional. 4. Preven c ao estrutural Os deadlocks podem ser estruturalmente eliminados de um sistema atrav es da nega c ao de uma ou mais das quatro condi c oes de ocorr encia. Para isto devem ser tratadas as condi c oes de Coman et al., o que e resumidamente apresentado na Tabela 2.4 abaixo.
Tabela 2.4: Condi c oes de Coman et al. para preven c ao de deadlocks Condi c ao Aproxima c ao Exclus ao Colocar todos os recursos do sistema em spool. M utua Reten c ao Exigir a aloca c ao inicial de todos os recursos e Espera necess arios. Aus encia de Retirada de recursos dos processos. Preemptividade Espera Ordena c ao num erica dos pedidos de recursos. Circular
2.11.3
Recupera c ao de deadlocks
Ainda que os deadlocks ocorram, dentro de certas circunst ancias e poss vel resolv e-los, isto e, recuper a-los ou elimin a-los, utilizando algumas t ecnicas: 1. Recupera c ao atrav es de preemp c ao Retirando-se algum recurso envolvido no bloqueio perp etuo do processo que o aloca permite a quebra do caminho fechado e conseq uente solu c ao do deadlock. O problema reside que nem sempre um recurso pode ser retirado de um processo sem efeitos colaterais prejudiciais a este processo. 2. Recupera c ao atrav es de opera c oes de rollback Exige a implementa c ao de checkpoints, isto e, um mecanismo de armazenamento de estados seguros do sistema atrav es da c opia dos estados
2.11. DEADLOCKS
51
individuais dos processos em arquivos especiais. Isto possibilita que tais estados sejam retomados a partir daquele ponto. Esta solu c ao, al em da dif cil implementa c ao, exige muitos recursos e tem elevado custo computacional, embora resolva bem o problema. 3. Recupera c ao atrav es de elimina c ao de processos Esta e maneira mais simples, embora tamb em a mais dr astica. Um ou mais dos processos identicados como envolvidos no bloqueio perp etuo podem ser sumariamente eliminados, de modo que o bloqueio seja resolvido. Enquanto alguns processos podem ser seguramente reiniciados (p.e., uma compila c ao), procedimentos de atualiza c ao em bancos de dados nem sempre podem ser interrompidos e reiniciados. A elimina c ao de processos que n ao podem ser simplesmente reiniciados pode provocar preju zos ao sistema.
2.11.4
Preven c ao de deadlocks
A preven c ao de deadlocks e a estrat egia preferencialmente adotada pelos projetistas de sistemas, adotando-se uma pol tica que assume o custo da preven c ao como alternativa aos preju zos poss veis da ocorr encia dos deadlocks e de sua elimina c ao. Para prevenir-se a ocorr encia dos deadlocks podem ser adotadas uma ou mais das seguintes estrat egias, tal como proposto por Havender (1968): 1. Um processo s o pode solicitar um recurso se liberar o recurso que det em. 2. Um processo que t em negado o pedido de recurso adicional deve liberar o recursos que atualmente det em. 3. Se a solicita c ao de recursos ocorrer em ordem linear ascendente, a espera circular n ao consegue se formar. Mesmo com as quatro condi c oes estando presentes, e poss vel evitar-se a ocorr encia dos deadlocks utilizando-se o algoritmo do banqueiro de Dijkstra (65). Antes disto devemos diferenciar estados seguros e inseguros.
2.11.5
Estados seguros e inseguros
A maioria dos algoritmos conhecidos para preven c ao de deadlocks se baseia no conceito de estado seguro. Um estado seguro e aquele em que existe garantia que todos os processos poder ao ser nalizados considerando (1) suas necessidades em termos de recursos e (2) os recursos efetivamente dispon veis no sistema [DEI92, p. 166] [TAN92, p. 254]. Desta forma os recursos cedidos aos processos ser ao devolvidos ao sistema para serem alocados para outros processos, numa seq u encia de estados seguros (veja a Figura 2.16).
52
Figura 2.16: Seq u encia de estados seguros
Por outro lado, um estado considerado como inseguro e aquele em n ao existe a garantia de devolu c ao dos recursos devidos pois o processo n ao recebe todos os recursos de que necessita n ao devolvendo ao sistema aqueles eventualmente j a alocados [DEI92, p. 166] [TAN92, p. 254]. Esta situa c ao e ilustrada na Figura 2.17, partindo da mesma situa c ao inicial colocada na Figura 25. A maior conseq u encia de um estado inseguro e que existem grandes chances de ocorrer um deadlock a partir desta situa c ao sendo por isso necess ario evit a-lo.
Figura 2.17: Seq u encia de estados inseguros
A ocorr encia de um estado inseguro, bem como de um estado seguro, depende estritamente da ordem com os recursos dispon veis s ao alocados e liberados pelos processos envolvidos. O sistema operacional, portanto, deve analisar se pode ou n ao atender plenamente as necessidades de um processo antes de ceder recursos que n ao poder ao ser devolvidos.
DE PROCESSOS 2.12. COMUNICAC AO
53
2.11.6
Algoritmo do banqueiro
O algoritmo do banqueiro, proposto por Dijkstra em 1965, e uma solu c ao cl assica no estudo dos sistemas operacionais que visa ilustrar as quest oes associadas a concess ao de recursos aos processos e as conseq u encias poss veis destas concess oes [DEI92, p. 167] [TAN92, p. 256]. Este algoritmo efetua um mapeamento dos recursos e processos de forma a considerar, a cada pedido de uso de um recurso, se tal aloca c ao leva a um estado seguro ou n ao. Se o estado seguinte e seguro, o pedido e concedido, caso contr ario tal solicita c ao e adiada at e que possa conduzir a um estado seguro. Na pr atica, o problema desta solu c ao e que cada processo deve especicar, inicialmente, a quantidade m axima de cada recurso que pretenda utilizar. Al em disso, a quantidade de processos varia a cada instante em sistemas reais. Se um novo processo conduzir a um estado inseguro, sua cria c ao dever a ser adiada, o que tamb em pode gerar um deadlock. Outro ponto e que a quantidade de recursos pode variar (geralmente diminuir com falhas no sistema) aumentado muito a complexidade desta solu c ao e, portanto, sua aplica c ao pr atica.
2.12
Comunica c ao de processos
A comunica c ao entre processos ou comunica c ao inter-processo (IPC ou Inter Process Communication ) e uma situa c ao comum dentro dos sistemas computacionais que ocorre quando dois ou mais processos precisam se comunicar, isto e, quando os processos devem compartilhar ou trocar dados entre si. A comunica c ao entre processos pode ocorrer em v arias situa c oes diferentes tais como: redirecionamento da sa da (dos resultados) de um comando para outro, envio de arquivos para impress ao, transmiss ao de dados atrav es da rede, transfer encia de dados entre perif ericos, etc. Tal comunica c ao se d a, geralmente, atrav es da utiliza c ao de recursos comuns aos processos envolvidos na pr opria comunica c ao. Como n ao e razo avel que tal comunica c ao envolva mecanismos de interrup c ao devido a sua complexidade e limita c oes de performance, as interrup c oes s ao reservadas para a administra c ao do sistema em si. Para a comunica c ao inter-processo e necess ario algum mecanismo bem estruturado. Veremos alguns mecanismos poss veis para a comunica c ao de processos destacando-se: Buers
54 Sem aforos Mem oria Compartilhada
2.12.1
Buers e opera c oes de sleep e wakeup
Um problema t pico e o do produtor-consumidor, onde dois processos distintos compartilham um buer, uma area de dados de tamanho xo que se comporta como um reservat orio tempor ario [DEI92, p. 90] [TAN92, p. 39]. O processo produtor coloca informa c oes no buer enquanto o processo consumidor as retira de l a. Se o produtor e o consumidor s ao processos seq uenciais, a solu c ao do problema e simples, mas caso sejam processos paralelos passa a existir uma situa c ao de concorr encia. Mesmo nos casos onde existam m ultiplos produtores ou m ultiplos consumidores o problema encontrado e basicamente o mesmo. Este e um problema cl assico de comunica c ao inter-processo, tais como os problemas do jantar dos l osofos e do barbeiro dorminhoco discutidos em detalhes por Tanenbaum [TAN92, p. 56]. Programas que desejam imprimir podem colocar suas entradas (nomes dos arquivos a serem impressos ou os arquivos de impress ao propriamente ditos) em uma area de spooling, denominada de printer spool. Um outro processo (tipicamente um daemon de impress ao) verica continuamente a entrada de entradas no spool, direcionando-as para uma ou mais impressoras existentes quando estas se tornam ociosas, com isto retirando as entradas claro que a da area de spool. E area reservada para o spool e nita e que as velocidades dos diversos produtores (programas que desejam imprimir) pode ser substancialmente diferente das velocidades dos consumidores (das diferentes impressoras instaladas no sistema). A mesma situa c ao pode ocorrer quando diversos processos utilizam uma placa de rede para efetuar a transmiss ao de dados para outros computadores. Os processos s ao os produtores, enquanto o hardware da placa e seu c odigo representam o consumidor. Em fun c ao do tipo de rede e do tr afego, temos uma forte limita c ao na forma que a placa consegue consumir (transmitir) os dados produzidos pelos programas e colocados no buer de transmiss ao. Existem outras situa c oes semelhantes, o que torna este problema um cl assico dentro do estudo dos sistemas operacionais. Na Figura 2.18 temos um esquema do problema produtor-consumidor. Tanto o buer como a vari avel que controla a quantidade de dados que o buer cont em s ao regi oes cr ticas, portanto deveriam ter seu acesso limitado atrav es de primitivas de exclus ao m utua, desde que isto n ao impusesse esperas demasiadamente longas aos processos envolvidos. Dado que o buer tem um tamanho limitado e xo podem ocorrer problemas tais como:
55
Figura 2.18: Problema do produtor-consumidor o produtor n ao pode colocar novas informa c oes no buer porque ele j a est a cheio; ou o consumidor n ao pode retirar informa c oes do buer porque ele est a vazio. Nestes casos tanto o produtor como o consumidor poderiam ser adormecidos, isto e, ter sua execu c ao suspensa, at e que existisse espa co no buer para que o produtor coloque novos dados ou existam dados no buer para o consumidor possa retir a-los. Uma tentativa de solu c ao deste problema utilizando as primitivas sleep (semelhante a uma opera c ao suspend ) e wakeup (semelhante a uma opera c ao resume ) pode ser vista no Exemplo 2.9. A solu c ao dada e considerada parcial pois pode ocorrer que um sinal de wakeup seja enviado a um processo que n ao esteja logicamente adormecido, conduzindo os dois processos a um estado de suspens ao que permanecer a indenidamente, como indicado na seq u encia de etapas a seguir. 1. O buer se torna vazio. 2. O consumidor l e contador=0. 3. O escalonador interrompe o consumidor. 4. O produtor produz novo item e o coloca no buer. 5. O produtor atualiza vari avel contador=1. 6. O produtor envia sinal wakeup para consumidor pois contador=1. 7. O sinal de wakeup e perdido pois o consumidor n ao est a logicamente inativo. 8. O consumidor e ativado, continuando execu c ao, pois considera que contador=0. 9. O consumidor se coloca como inativo atrav es de um sleep.
56 #define FALSE 0 #define TRUE 1 #define N 100 int contador = 0;
void produtor(void) { int item; while (TRUE) { produzir item(&item); if (contador == N) sleep(); colocar item(item); contador++; if (contador == 1) wakeup(consumidor); } } void consumidor (void) { int item; while (TRUE) { if (contador == 0) sleep(); remover item(&item); contador--; consumir item(item); if (contador == N-1) wakeup(produtor); } } Exemplo 2.9 Solu c ao parcial do problema produtor-consumidor 10. O produtor continuar a produzindo. 11. O buer car a cheio pois consumidor est a inativo, fazendo que o produtor se coloque como inativo com outro sleep. 12. Ambos os processos permanecer ao para sempre inativos. A perda de um sinal wakeup acontece devido ao uso irrestrito da vari avel contador. A primeira solu c ao encontrada para este problema foi adicionar uma ag que sinalizasse a situa c ao de envio de um sinal wakeup para um processo ativo. Tal ag se denomina (wakeup waiting ag ). Em qualquer tentativa de adormecer, o processo deve antes vericar esta ag, ocorrendo o seguinte: se flag=0, o processo adormece; e
DE PROCESSOS 2.12. COMUNICAC AO se flag=1, o processo permanece ativo e faz flag=0.
57
Esta improvisada solu c ao resolve o problema as custas de uma ag para processo envolvido no problema, mas e necess ario destacar que o problema continua a existir, apenas de maneira mais sutil.
2.12.2
Sem aforos
Para resolver o problema produtor-consumidor, Dijkstra prop os tamb em em 1965 a utiliza c ao de vari aveis inteiras para controlar o n umero de sinais wakeup para uso futuro [DEI92, p. 89]. Estas vari aveis foram denominadas sem aforos, e sobre elas estabeleceu-se duas diferentes opera c oes: P (conhecida tamb em como Down) e V (conhecida tamb em como Up), que s ao generaliza c oes das opera c oes sleep e wakeup e funcionam como mostra a Tabela 2.5. Tabela 2.5: Opera c oes P() e V() sobre sem aforos Opera c ao P(X) ou Down(X) Verica se o valor do sem aforo X e positivo (X>0). Caso armativo decrementa X de uma unidade (ou seja, consome um sinal de wakeup ). Caso negativo envia sinal de sleep, fazendo inativo o processo. Opera c ao V(X) ou Up(X) Incrementa o valor do sem aforo X de uma unidade. Existindo processos inativos, na ocorr encia uma opera c ao down, um deles e escolhido aleatoriamente pelo sistema para ser ativado (sem aforo retornar a a zero, i.e., X=0). A implementa c ao de sem aforos em linguagem C poderia ser realizada como esquematizada no Exemplo 2.10. Ambas a opera c oes devem ser realizadas como transa c oes at omicas, isto e, de forma indivis vel, de forma que enquanto uma opera c ao esteja em andamento com um dado sem aforo, nenhuma outra seja efetuada, garantindo-se a consist encia dos valores das vari aveis sem aforo. A utiliza c ao de sem aforos permite a sincroniza c ao de v arios processos, ou seja, num ambiente onde existem diversos processos paralelos competindo por recursos, o uso de sem aforos garante que um dado recurso seja utilizado de forma seq uencial, ou seja, de forma exclusiva. Os sem aforos e as opera c oes sobre eles s ao usualmente implementadas como chamadas do sistema operacional, e representam uma solu c ao para
58 typedef int semaforo; void P(semaforo *s) { if(*s > 0) { s = *s - 1; } else { sleep(); } } void V(semaforo *s) { if (ExisteProcessoEsperando(s)) { AtivaProcessoEsperando(s); } else { s = *s + 1; } }
Exemplo 2.10 Implementa c ao de opera c oes P() e V() sobre sem aforos o problema de perda de sinais de wakeup visto no problema produtorconsumidor. Sendo regi oes cr ticas, sua implementa c ao utiliza instru c oes tipo TST e, embora provocando um espera ativa, s ao opera c oes extremamente r apidas, muito mais ecientes que o uso de outras solu c oes que utilizem tais instru c oes ou as solu c oes de Dekker ou Peterson. Sem aforos iniciados com valor 1 s ao conhecidos como sem aforos bin arios [TAN92, p. 42], que permitem que apenas um dentre n processos utilize um dado recurso, ou seja, garantem o uso individual deste recurso atrav es da exclus ao m utua. Os sem aforos s ao freq uentemente utilizados para sincroniza c ao de processos, ou seja, s ao utilizados para garantir a ocorr encia de certas seq u encias de eventos ou para impedir que outras seq u encias nunca ocorram ou para que ocorram de uma forma espec ca. No Exemplo 2.11 temos uma poss vel solu c ao para o problema do produtor consumidor utilizando sem aforos. Consideramos que as opera c oes P() e V() foram implementadas como ilustrado no Exemplo 2.10 e inclu das no programa atrav es do cabe calho declarado.
2.12.3
Mem oria compartilhada
A mem oria compartilhada e um mecanismo freq uentemente utilizado para a comunica c ao entre processos diferentes onde uma regi ao de mem oria e reservada para uso comum dos processos envolvidos na comunica c ao. A area de mem oria reservada para os processo e semelhante a um buer, mas nesta situa c ao todos os processos envolvidos podem escrever e ler neste
59
#include "semforos.h" #define FALSE 0 #define TRUE 1 #define N 100 typedef int semaforo; semaforo mutex = 1; semaforo vazio = N; semaforo cheio = 0; void produtor(void) { int item; while (TRUE) { produzir item(&item); p(&vazio); p(&mutex); colocar item(item); v(&mutex); v(&cheio); } } void consumidor(void) { int item; while (TRUE) { p(&cheio); p(&mutex); remover item(&item); v(&mutex); v(&vazio); consumir item(item); } } Exemplo 2.11 Solu c ao do problema produtor-consumidor com sem aforos
60
buer. Como dois processo n ao podem acessar simultaneamente esta regi ao de mem oria, embora compartilhada seu uso deve ser serializado, ou seja, um processo de cada vez deve utilizar a regi ao de mem oria destinada a comunica c ao entre eles. Para obter-se isso, associa-se um sem aforo com valor inicial 1 ` a regi ao de mem oria. Todo os processos, antes de usarem a area de mem oria devem acionar uma opera c ao P(). Ao nalizar o uso dever ao acionar uma opera c ao V(), garantindo seu uso exclusivo. De forma geral, a solu c ao e semelhante aquela do problema de produtores e consumidores, aplicada a n processos que podem tanto ler ou escrever numa regi ao de mem oria espec ca, sendo freq uentemente utilizada para passagem de mensagens entre processos.
2.12.4
Outros mecanismos de IPC
Contadores de eventos Reed e Kanodia propuseram em 1979 uma outra solu c ao para o problema de produtor-consumidor sem a necessidade de obter-se a exclus ao m utua, tal como na solu c ao que utiliza sem aforos. Esta solu c ao utiliza uma vari avel especial denominada contador de eventos (event counters ) que possui tr es opera c oes denidas como mostra a Tabela 2.6 Tabela 2.6: Opera c oes sobre contadores de eventos Opera c ao Descri c ao read(E) Retorna o valor corrente de E. advance(E) Incrementa, atomicamente, o valor de E de uma unidade. await(E, v) Espera que E tenha valor igual ou superior a v. poss E vel solucionar-se o problema utilizando os contadores de eventos e suas opera c oes, de forma semelhante ao uso de sem aforos. Monitores Tanto os sem aforos como os contadores de eventos podem resolver uma s erie de problemas, mas seu uso deve ser cuidadoso para que n ao provoque situa c oes desastrosas. A invers ao de dois sem aforos, (por exemplo, mutex e vazio na solu c ao do problema produtor-consumidor usando sem aforos) pode provocar um bloqueio perp etuo, ou seja, faz com que uma dada tarefa pare de ser executada, degradando o sistema e podendo causar at e mesmo sua instabilidade. Para que tais problemas pudessem ser resolvidos mais facilmente Hoare (1974) e Hansem (1975) propuseram o conceito demonitor: uma cole c ao de procedimentos, vari aveis e estruturas agrupados num m odulo ou pacote especial. Segundo Guimar aes:
DE PROCESSOS 2.12. COMUNICAC AO Monitor e um conjunto de procedimentos que operam sobre vari aveis comuns a v arios processos. Um procedimento do monitor corresponde a uma regi ao cr tica. Um monitor corresponde, portanto, a um conjunto de regi oes cr ticas operando sobre as mesmas vari aveis comuns. [GUI86, p. 88]
61
Processos podem acessar os procedimentos e fun c oes de um monitor embora n ao possam utilizar diretamente a estrutura interna de seus dados [TAN92, p. 45], num arranjo muito semelhante a utiliza c ao da interface de um objeto, sem acesso aos seus campos privativos. No Exemplo 2.12, temos a declara c ao de um monitor numa nota c ao semelhante ao Pascal. Monitor Exemplo; { declara c~ ao de vari aveis } emUso : boolean; livre : condition; procedure AlocaRecurso; begin if emUso then wait(livre); emUso := true; end; procedure LiberaRecurso; begin emUso := false; signal(livre); end; begin emUso := false; { inicializa c~ ao } end; end monitor. Exemplo 2.12 Exemplo de monitor Esta solu c ao se baseia na introdu c ao de vari aveis de condi c ao e de duas opera c oes especiais sobre elas: AlocaRecurso e LiberaRecurso. Quando um monitor descobre que uma opera c ao n ao e poss vel, ele efetua uma opera c ao wait sobre uma certa vari avel de condi c ao, provocando o bloqueio do processo que utilizou o monitor. Isto permite que outro processo, anteriormente bloqueado utilize o recurso. Este processo, ou ainda outro, pode efetuar uma opera c ao de signal sobre aquela vari avel de condi c ao, saindo imediatamente do monitor. Um dos processos em espera pela condi c ao, ao ser ativado pelo escalonador poder a ent ao prosseguir com o trabalho.
62
Apesar de serem semelhantes as opera c oes de sleep e wakeup, vistas na se c ao 2.12.1, atrav es dos monitores os problemas ocorridos em situa c oes de corrida n ao se repetem dado a garantia de exclus ao m utua sobre as opera c oes nas vari aveis de condi c ao internas dos pr oprios monitores. Al em disso, as opera c oes wait e signal s o podem ser utilizadas internamente aos procedimentos e fun c oes dos monitores. Os monitores s ao um conceito de programa c ao. Enquanto que os sem aforos podem ser implementados diretamente em C ou Pascal, com uso de algumas rotinas assembly, a implementa c ao de monitores e um pouco mais complexa, exigindo do compilador primitivas de exclus ao m utua.
2.13
Threads
Como vimos, cada processo conta com uma estrutura de controle razoavelmente sosticada. Nos casos onde se deseja realizar duas ou mais tarefas simultaneamente, o solu c ao trivial a disposi c ao do programador e dividir as tarefas a serem realizadas em dois ou mais processos. Isto implica na cria c ao de manuten c ao de duas estruturas de controle distintas para tais processos, onerando o sistema, e complicando tamb em o compartilhamento de recursos, dados serem processos distintos. Uma alternativa ao uso de processos comuns e o emprego de threads. Enquanto cada processo tem um u nico uxo de execu c ao, ou seja, s o recebe a aten c ao do processador de forma individual, quando um processo e divido em threads, cada uma das threads componentes recebe a aten c ao do processador como um processo comum. No entanto, s o existe uma estrutura de controle de processo para tal grupo, o espa co de mem oria e o mesmo e todos os recursos associados ao processo podem ser compartilhados de maneira bastante mais simples entre as suas threads componentes. Segundo Tanebaum, as threads foram inventadas para permitir a combina c ao de paralelismo com exeu c ao seq uencial e chamadas de sistema bloqueantes [TAN92, p. 509]. Na Figura 2.19 representamos os uxos de execu c ao de um processo comum e de outro, divido em threads.
Figura 2.19: Processos e threads
2.13. THREADS
63
Desta forma, as threads podem ser entendidas como uxos independentes de execu c ao pertencentes a um mesmo processo, que requerem menos recursos de controle por parte do sistema operacional. Assim, as threads s ao o que consideramos processos leves (lightweight processes ) e constituem uma unidade b asica de utiliza c ao do processador [TAN92, p. 508] [SGG01, p. 82]. Sistemas computacionais que oferecem suporte para as threads s ao usualmente conhecidos como sistemas multithreading. Como ilustrado na Figura 2.20, os sistemas multithreading podem suportar as threads segundo dois modelos diferentes: User threads As threads de usu ario s ao aquelas oferecidas atrav es de bibliotecas espec cas e adicionais ao sistema operacional, ou seja, s ao implementadas acima do kernel (n ucleo do sistema) utilizando um modelo de controle que pode ser distinto do sistema operacional, pois n ao s ao nativas neste sistema. Kernel threads As threads do sistema s ao aquelas suportadas diretamente pelo sistema operacional e, portanto, nativas.
Figura 2.20: Threads de usu ario e de kernel Em sistemas n ao dotados de suporte a threads nativamente, o uso de bibliotecas de extens ao permite a utiliza c ao de pseudo-threads. Exemplos de bibliotecas de suporte threads de usu ario s ao o PThreads do POSIX ou o C-threads do sistema operacional Mach. Atrav es de tais biblioteca s ao oferecidos todos os recursos necess arios para a cria c ao e controle das threads. Usualmente os mecanimos de cria c ao de threads de usu ario s ao bastante r apidos e simples, mas existe uma desvantagem: quando uma thread e bloqueada (por exemplo, devido ao uso de recursos de I/O), as demais threads freq uentemente tamb em s ao devido ao suporte n ao nativo. Quando o suporte e nativo, a cria c ao das threads e usualmente mais demorada, mas n ao ocorrem os inconveniente decorrentes do bloqueio de uma ou mais threads em rela c ao ` as demais.
64
2.13.1
Modelos de multithreading
A forma com que as threads s ao disponibilizadas para os usu arios e o que denominamos modelos de multithreading. Como mostra a Figura 2.21, s ao comuns tr es modelos distintos: Modelo n para um. Este modelo e empregado geralmente pelas bibliotecas de suporte de threads de usu ario, onde as v arias threads do usu ario (n) s ao associadas a um u nico processo suportado diretamente pelo sistema operacional. Modelo um para um. Modelo simplicado de multithreading verdadeiro, onde cada threads do usu ario e associada a uma thread nativa do sistema. Este modelo e empregado em sistemas operacionais tais como o MS-Windows NT/2000 e no IBM OS/2. Modelo n para m. Modelo mais sosticado de multithreading verdadeiro, onde um conjunto de threads do usu ario n e associado a um conjunto de threads nativas do sistema, n ao necess ariamente do mesmo tamanho (m). Este modelo e empregado em sistemas operacionais tais como o Sun Solaris, Irix e Digital UNIX.
Figura 2.21: Modelos de multithreading
2.13.2
Benef cios do uso
A utiliza c ao das threads pode trazer diversos benef cios para os programas e para o sistema computacional em si [SGG01, p. 83]: Melhor capacidade de resposta, pois a cria c ao de uma nova thread e substancialmente mais r apida do a cria c ao de um novo processo. Compartilhamento de recursos simplicado entre as threads de um mesmo processo, que e a situa c ao mais comum de compartilhamento e comunica c ao inter-processos.
2.13. THREADS
65
Economia, pois o uso de estruturas de controle reduzidas em compara c ao ao controle t pico dos processos, desoneramos o sistema. Al em disso o compartilhamento de recursos simplicado leva tamb em a economia de outros recursos. Permitem explorar mais adequadamente as arquiteturas computacionais que disp oem de m ultiplos processadores.
66
Cap tulo 3
Escalonamento de Processos
O escalonamento de processadores e a forma com os processadores existentes num sistema computacional s ao utilizados para efetuar o processamento, isto e, e como os processos s ao distribu dos para execu c ao nos processadores. Tanenbaum prop oe a seguinte deni c ao: Quando mais de um processo e execut avel, o sistema operacional deve decidir qual ser a executado primeiro. A parte do sistema operacional dedicada a esta decis ao e chamada escalonador ( scheduler) e o algoritmo utilizado e chamado algoritmo de escalonamento ( scheduling algorithm). [TAN92, p. 62] Por sua vez, Deitel coloca que: A designa c ao de processadores f sicos para processos permite aos processos a realiza c ao de trabalho. Esta designa c ao e uma tarefa complexa realizada pelo sistema operacional. Isto e chamado escalonamento do processador ( processor scheduling). [DEI92, p. 287] Simplicando, podemos armar que num sistema onde s o exista um u nico processador, o escalonamento representa a ordem em que os processos ser ao executados. A forma com que se d a o escalonamento e, em grande parte, respons avel pela produtividade e eci encia atingidas por um sistema computacional. Mais do que um simples mecanismo, o escalonamento deve representar uma pol tica de tratamento dos processos que permita obter os melhores resultados poss veis num sistema. 67
68
CAP ITULO 3. ESCALONAMENTO DE PROCESSOS
3.1
Objetivos do escalonamento
O projeto de um escalonador adequado deve levar em conta uma s erie de diferentes necessidades, ou seja, o projeto de uma pol tica de escalonamento deve contemplar os seguintes objetivos: Ser justo: todos os processos devem ser tratados igualmente, tendo possibilidades id enticas de uso do processador, devendo ser evitado o adiamento indenido. Maximizar a produtividade (throughput ): procurar maximizar o n umero de tarefas processadas por unidade de tempo. Ser previs vel: uma tarefa deveria ser sempre executada com aproximadamente o mesmo tempo e custo computacional. Minimizar o tempo de resposta para usu arios interativos. Maximizar o n umero poss vel de usu arios interativos. Minimizar a sobrecarga (overhead ): recursos n ao devem ser desperdicados embora algum investimento em termos de recursos para o sis tema pode permitir maior eci encia. Favorecer processos bem comportados : processos que tenham comportamento adequado poderiam receber um servi co melhor. Balancear o uso de recursos: o escalonador deve manter todos os recursos ocupados, ou seja, processos que usam recursos sub-utilizados deveriam ser favorecidos. Exibir degrada c ao previs vel e progressiva em situa c oes de intensa carga de trabalho. Como pode ser visto facilmente, alguns destes objetivos s ao contradit orios, pois dado que a quantidade de tempo dispon vel de processamento (tempo do processador) e nita, assim como os demais recursos computacionais, para que um processo seja favorecido outro deve ser prejudicado. O maior problema existente no projeto de algoritmos de escalonamento est a associado a natureza imprevis vel dos processos, pois n ao e poss vel prevermos se um dado processo utilizar a intensamente o processador, ou se precisar a grandes quantidades de mem oria ou se necessitar a numerosos acessos aos dispositivos de E/S.
3.2. N IVEIS DE ESCALONAMENTO
69
3.2
N veis de escalonamento
Existem tr es n veis distintos de escalonamento em um sistema computacional quando se considera a freq u encia e complexidade das opera c oes envolvidas. Escalonamento de alto n vel Chamado tamb em de escalonamento de tarefas, corresponde a admiss ao de processos, isto e, a determina c ao de quais tarefas passar ao a competir pelos recursos do sistema. Uma vez admitidas, as tarefas transformam-se em processos. Correspondem a rotinas de alto n vel oferecidas pelas APIs do sistema operacional. Escalonamento de n vel intermedi ario Corresponde a determina c ao de quais processos existentes competir ao pelo uso do processador (processos ativos). Este n vel de escalonamento e respons avel por administrar a carga do sistema, utilizando-se de primitivas de suspens ao (suspend ) e ativa c ao (resume ou activate ). Correspondem a rotinas internas do sistema operacional. Escalonamento de baixo n vel Rotinas que determinam qual processos, dentre os processos ativos, ser a o pr oximo processo que efetivamente utilizar a o processador. Estas tarefa s ao executadas pelo dispatcher, usualmente uma rotina escrita diretamente em linguagem de m aquina que se encontra permanentemente na mem oria principal. Os n veis de escalonamento alto, intermedi ario e baixo tamb em s ao conhecidos respectivamente como escalonamento de longo prazo, m edio prazo e curto prazo. O escalonamento de alto n vel ou de longo prazo ocorre menos freq uentemente num sistema enquanto o escalonamento de baixo n vel ou de curto prazo ocorre constantemente, dado que representa a troca de contexto e o chaveamento do processador entre os processos ativos. Considerando assim os n veis de escalonamento e as opera c oes de suspens ao (suspend ou sleep ) e ativa c ao (resume, wakeup ou activate ), o mapa de estados dos processos pode ser representado de maneira mais completa como ilustrado na Figura 3.2
3.3
Escalonamento preemptivo e n ao preemptivo
Um algoritmo de escalonamento e dito n ao preemptivo quando temos que o processador designado para um certo processo n ao pode ser retirado deste at e que o processo seja nalizado (completion). Analogamente, um algoritmo de escalonamento e considerado preemptivo quando o processador designado para um processo pode ser retirado deste em favor de um outro processo.
70
Figura 3.1: N veis de escalonamento
Algoritmos preemptivos s ao mais adequados para sistemas em que m ultiplos processos requerem aten c ao do sistema, ou seja, no caso de sistemas multiusu ario interativos (sistemas em tempo repartido) ou em sistema de tempo real. Nestes casos, a preemptividade representa a troca do processo em execu c ao, assim sendo, para que o processador seja retirado de um processo, interrompendo seu trabalho, e designado a outro processo, anteriormente interrompido, e fundamental que ocorra a troca de contexto dos processos. Tal troca exige que todo o estado de execu c ao de um processo seja adequadamente armazenado para sua posterior recupera c ao, representando uma sobrecarga computacional para realiza c ao desta troca e armazenagem de tais dados. Usualmente os algoritmos preemptivos s ao mais complexos dada a natureza imprevis vel dos processos. Por sua vez, os algoritmos n ao preemptivos s ao mais simples e adequados para o processamento n ao interativo, semelhante aos esquemas de processamento em lote dos sistemas batch. Embora n ao proporcionando interatividade, s ao geralmente mais ecientes e previs veis quanto ao tempo de entrega de suas tarefas.
3.4. QUALIDADE DO ESCALONAMENTO
71
Figura 3.2: Mapa de estados dos processos Existem tamb em algoritmos de escalonamento cooperativo, onde os processos n ao s ao interrompidos, mas a preemp c ao ocorre em duas situa c oes bem denidas: quando o processo efetua uma opera c ao de I/O e quando o processo e nalizado [SGG01, p. 97]. Tamb em e poss vel que um processo ceda o processador, volunt ariamente, em favor de outros processos. Neste caso, o processo educado poderia executar uma chamada a uma fun c ao yeld (dar prefer encia), como no caso do MS-Windows 3.1. A preemp c ao volunt aria pode auxiliar numa distribui c ao mais equitativa da capacidade de processamento do sistema, mas conta com a generosidade do programador, nem sempre dispon vel. A preemptividade de certos algoritmos se baseia no fato de que o processador e, naturalmente, um recurso preemptivo, ou seja, um recurso que pode ser retirado de um processo e posteriormente devolvido sem preju zo. O mesmo acontece com a mem oria. Por outro lado, outros tipos de recursos n ao podem sofrer preemp c ao, tais como impressoras e at e mesmo arquivos, dado que muitas vezes n ao podem ser retirados de um processo sem que ocorra preju zo para este.
3.4
Qualidade do escalonamento
Existem v arias crit erios que permitem a avalia c ao da qualidade do servi co oferecido por um algoritmo de escalonamento [SGG01, p. 98]: uso do processador, throughput, tempo de resposta e tempo de perman encia. O tempo de perman encia, tempo de retorno ou turnaround time, e um crit erio simples dado pela soma do tempo de espera com o tempo de servi co ou tempo de execu c ao:
72
tp = tpermanencia = tespera + tservico
(3.1)
Em geral deseja-se que o tempo de perman encia seja o menor poss vel. Na Figura 3.3 temos uma representa c ao gr aca do tempo de perman encia.
Figura 3.3: Representa c ao gr aca do tempo de perman encia Uma outra forma de avaliar-se o escalonamento e utilizando-se o tempo de perman encia normalizado (tpn), ou seja, a raz ao entre o tempo de perman encia (tp) e o tempo de servi co (ts): tpn = tpermanencia tespera + tservico = tservico tservico (3.2)
Se a espera for zero, o que constitui o melhor caso poss vel, teremos que o tempo de perman encia normalizado de um processo ser a 1 (um). Assim sendo, valores maiores do que este indicam um pior servi co oferecido pelo algoritmo de escalonamento.
3.5
Algoritmos de escalonamento
Existem v arios algoritmos que s ao utilizados para a realiza c ao do escalonamento de baixo n vel ou de curto prazo. Em todos eles, o principal objetivo e designar o processador para um certo processo dentre v arios processos existentes, otimizando um ou mais aspectos do comportamento geral do sistema. Stallings categoriza os escalonadores como [STA92, p. 356]: 1. Orientados ao usu ario: quando procuram otimizar os tempos de resposta e perman encia al em da previsibilidade. 2. Orientados ao sistema: quando enfatizam a produtividade, a taxa de utiliza c ao da processador, o tratamento justo e o balanceamento do uso de recursos. Ser ao abordados os seguintes algoritmos de escalonamento: First In First Out
3.5. ALGORITMOS DE ESCALONAMENTO Highest Priority First Shortest Job First Highest Response-Ratio Next Shortest Remaining Time Round Robin Multilevel Queues Multilevel Feedback Queues
73
3.5.1
Escalonamento FIFO (First In First Out )
a forma mais simples de escalonamento tamb E em conhecido como FCFS (First Come First Served ), ou primeiro a chegar, primeiro a ser servido. No escalonamento FIFO os processos prontos (ou jobs ) s ao colocado numa la organizada por ordem de chegada, o que corresponde dizer que sua fun c ao de sele c ao e min(tchegada ), como mostra a Figura 3.4. Com esta fun c ao de sele c ao, seleciona-se dentre os processos na la de espera aquele com menor tempo de chegada. Tal processo recebe o uso do processador at e que seja completado (completion ), ou seja, o processo permanece em execu c ao at e que seja nalizado, de forma que os demais processos na la quem esperando por sua oportunidade de processamento. Assim sendo, o escalonamento FIFO e um algoritmo n ao preemptivo, pois os processos em execu c ao n ao s ao interrompidos.
Figura 3.4: Escalonamento FIFO (First In First Out ) Embora d e igual tratamento a todos os processos, ocorre que processos de pequena dura c ao n ao s ao favorecidos pois tem seu tempo de resposta fortemente inuenciado pelos processos a serem processados primeiramente, ou seja, o tempo de resposta aumenta consideravelmente em fun c ao da quantidade de processos posicionados a frente e tamb em pela dura c ao destes. Outro ponto e que processos importantes podem car a espera devido ` a execu c ao de outros processos menos importantes dado que o escalonamento
74
FIFO n ao concebe qualquer mecanismo de distin c ao entre processos (por exemplo, processos com diferentes n veis de prioridade). Avaliemos o exemplo ilustrado pela Tabela 3.1, onde quatro processos A, B, C e D com tempos de processamento distintos, respectivamente 3, 35, 12 e 4 segundos, s ao escalonados conforme sua chegada pelo sistema operacional. Tabela 3.1: Exemplo de la de processos sob escalonamento FIFO Processo tchegada tservico tespera tperm tpn A 0 3 0 3 1.00 B 1 35 2 37 1.06 C 2 12 36 48 4.00 D 3 4 47 51 12.75 M edias 21.25 34.75 4.7 Podemos perceber que, em fun c ao de como ocorreu o escalonamento, o menor processo obteve o pior servi co, num esquema de escalonamento que tende a ter tempos m edios de resposta maiores quanto maior o n umero de processos em espera. Esta forma de escalonamento, semelhante aos sistemas de processamento em lote (batch systems ) n ao e utilizada como esquema principal de escalonamento, mas como forma auxiliar de escalonamento para processamento de las batch.
3.5.2
Escalonamento HPF (Highest Priority First )
O escalonamento HPF (Highest Priority First ) ou escalonamento por prioridades e uma variante do escalonamento FIFO onde os processos em espera pelo processador s ao organizados numa la segundo sua prioridade, sendo colocados a frente os processos jobs de maior prioridade, isto e, sua fun c ao de sele c ao e max(prioridade), favorecendo os processos considerados mais importantes [TAN92, p. 64] [SGG01, p. 105]. Ap os iniciados, os processos n ao s ao interrompidos, ou seja, e uma forma de escalonamento n ao preemptivo, oferecendo como a vantagem de proporcionar tempos m edios de espera menores para processos priorit ario. Na Figura 3.5 temos uma representa c ao deste tipo de escalonamento.
Figura 3.5: Escalonamento HPF (Highest Priority First )
3.5. ALGORITMOS DE ESCALONAMENTO
75
A prioridade e, em geral, representada por um n umero inteiro, no entanto n ao existe consenso em denir prioridade maiores como n umeros maiores (indicando sua maior import ancia) ou o inverso (indicando sua ordem preferencial). A prioridade pode ser denida interna ou externamente ao sistema. Quando determinada internamente, o sistema pode utilizar diversos fatores, tais como quantidade de mem oria necess aria, estimativas do tempo de servi co e outros elementos para calcular a prioridade. Notemos que o tempo de processamento de um job n ao pode ser determinado antes de seu processamento, sendo necess ario o uso de estimativas feitas pelo usu ario ou pelo programador, as quais s ao com freq u encia pouco precisas. No caso de prioridade externamente, a mesma e simplesmente atribu da ao processo pelo operador ou pelo programador, de maneira emp rica. Avaliemos o mesmo exemplo utilizado para o escalonamento FIFO, onde quatro processos A, B, C e D com tempos de processamento distintos, respectivamente 3, 35, 12 e 4 segundos, s ao escalonados conforme suas prioridades, denidas externamente, como mostra a Tabela 3.2. Tabela 3.2: Exemplo de la de processos sob escalonamento HPF Processo tchegada prio tservico tespera tperm tpn A 0 4 3 0 3 1.00 C 2 1 12 1 13 1.08 B 1 2 35 14 49 1.4 D 3 3 4 47 51 12.75 M edias 15.5 29.00 4.06 Podemos perceber que, dado o escalonamento ordenar os processos segundo sua prioridade, alguns processos podem ser prejudicados em fun c ao de outros de maior prioridade, pois se processos grande s ao executados primeiro ocorre uma degrada c ao signicativa para os demais processos. Observe tamb em que o processo A, embora tenha prioridade mais baixa que os demais, come cou a ser executado antes devido ao seu tempo de chegada, n ao sendo interrompido com a chegada de processos de maior prioridade, pois este algoritmo n ao e preemptivo. Por outro lado, devemos considerar tamb em que um processo de prioridade relativamente baixa pode ter sua execu c ao adiada indenidamente pela chegada cont nua de processos de maior prioridade (indenite postponement ), ou seja pode sofrer de estagna c ao (starvation ). No caso do HPF, existe uma solu c ao, relativamente simples, para a solu c ao do problema da estagna c ao denominada aging (envelhecimento). Tal solu c ao consistem em progressivamente aumentar a prioridade dos processos que aguardam na la a medida que o tempo passa, ou seja, como forma de compensar a espera e evitar a estagna c ao, processos poderiam ter sua prioridade incrementada at e que sejam executados [SGG01, p. 103].
76
Conforme as prioridades e os processos, os resultados apresentados por este algoritmo poderiam tanto aproxim a-lo do escalonamento FIFO como apresentar resultados de qualidade melhores. No caso, os resultados exibidos foram um pouco melhores. Na verdade sua maior qualidade est a na execu c ao seletiva de jobs conforme sua prioridade calculada ou atribu da. Da mesma forma que no escalonamento FIFO, o escalonamento HPF n ao e utilizado como esquema principal de escalonamento, mas como forma auxiliar de escalonamento para processamento de las batch.
3.5.3
Escalonamento SJF (Shortest Job First )
O escalonamento SJF (Shortest Job First ) ou menor job primeiro, tamb em e conhecido como SPF (Shortest Process First ) ou menor processo primeiro. um caso especial do HPF, onde o tempo de servi E co e tomado como prioridade, ou seja, os processos em espera pelo processador s ao organizados numa la segundo seu tempo de execu c ao, sendo colocados a frente os menores processos jobs, isto e, sua fun c ao de sele c ao e min(tservico ), favorecendo os processos que podem ser nalizados intervalos de tempo menores. Ap os iniciados, os processos n ao s ao interrompidos, ou seja, e uma forma de escalonamento n ao preemptivo, mas mesmo assim oferece a vantagem de proporcionar tempos m edios de espera menores do aqueles obtidos num esquema FIFO. Na Figura 3.6 temos uma representa c ao deste tipo de escalonamento.
Figura 3.6: Escalonamento SJF (Shortest Job First ) O grande problema deste esquema de escalonamento e que o tempo de processamento de um job n ao pode ser determinado antes de seu processamento, sendo necess ario o uso de estimativas feitas pelo usu ario ou pelo programador, as quais s ao com freq u encia pouco precisas. Para evitar abusos por parte dos usu arios (que podem indicar estimativas mais baixas que os tempos esperados), podem ser adotadas pol ticas de premia c ao em fun c ao do acerto das estimativas, mas isto n ao resolve uma s erie de problemas, entre os quais o incorreto posicionamento de um job pelo sistema devido a uma estimativa incorreta, prejudicando outros jobs. Uma outra quest ao e a possibilidade deste algoritmos provocar a estagna c ao (starvation ) de processos grandes os quais podem permanecer in-
77
denidamente na la de espera caso processos de menor dura c ao cheguem continuamente ao sistema. Uma solu c ao para este problema seria impor um tempo m aximo de espera xo ou proporcional ao tempo de servi co, a partir do qual tais processos seriam executados, para evitar a estagna c ao. Avaliemos o mesmo exemplo utilizado para o escalonamento FIFO, onde quatro processos A, B, C e D com tempos de processamento distintos, respectivamente 3, 35, 12 e 4 segundos, s ao escalonados em conforme suas dura c oes e tempo de chegada pelo sistema operacional, como mostra a Tabela 3.3. Tabela 3.3: Exemplo de la de processos sob escalonamento SJF Processo tchegada tservico tespera tperm tpn A 0 3 0 3 1.00 D 3 4 0 4 1.00 C 2 12 5 17 1.42 B 1 35 18 51 1.46 M edias 5.75 18.75 1.22 Podemos perceber que neste caso, em fun c ao do escalonamento ordenar os processos segundo sua dura c ao, os menores processos obtiveram o melhor servi co sem que isso resultasse numa degrada c ao signicativa para os processos maiores. Tanto o tempo m edio de espera como os tempos m edios de perman encia e de perman encia normalizado apresentam valores bastante inferiores aos obtidos com o escalonamento FIFO (Tabela 3.1) ou mesmo o HPF (Tabela 3.2), evidenciando as qualidades do escalonamento SJF. Da mesma forma que os demais esquemas de escalonamento vistos, o escalonamento SJF n ao e utilizado como esquema principal de escalonamento, mas como forma auxiliar de escalonamento para processamento de las batch.
3.5.4
Escalonamento HRN (Highest Response-Ratio Next )
Para corrigir algumas das deci encias do escalonamento SJF, Hansen (1971) prop os um balanceamento entre a dura c ao do job e seu tempo de espera, de forma a compensar a espera excessiva de tarefas de maior dura c ao. Para tanto idealizou uma forma din amica de organiza c ao da la de processos atrav es do c alculo de suas taxas de resposta (response ratio ) ou prioridades como dado a seguir: tespera + tservico (3.3) tservico A fun c ao de sele c ao escolhe o job de maior a prioridade para fazer uso do processador, ou seja, max(prioridade). Observe atentamente a rela c ao que determina a prioridade, podemos notar que, na verdade, este valor corresponde ao tempo de perman encia normalizado, tal como mostra prioridade =
78
a Equa c ao 3.2. Temos assim que, num primeiro momento, os jobs de curta dura c ao s ao favorecidos, pois o tempo de perman encia gura no numerador da fra c ao enquanto apenas o tempo de servi co aparece no denominador. A medida que a espera vai se tornando maior, at e mesmo os jobs de maior dura c ao v ao tendo suas prioridades aumentadas at e que estas superem as prioridades de processos curtos rec em-chegados, proporcionando um equil brio bastante positivo a medida que os processos v ao sendo selecionados e executados. Na Figura 3.7 temos uma ilustra c ao deste esquema de escalonamento.
Figura 3.7: Escalonamento HRN (Highest Response-Ratio Next ) Uma vez encaminhados a CPU, os jobs s ao processados at e sua naliza c ao, sendo assim, este um algoritmo n ao preemptivo de escalonamento apesar da forma din amica com que a la de processos em espera e administrada. Da mesma forma que no escalonamento SJF e SRT, o escalonamento HRN pressup oe a disponibilidade dos tempos de execu c ao de cada job, o que pode inviabilizar seu uso pr atico, tal como o de outros algoritmos de escalonamento baseados em estimativas do tempo de execu c ao. Novamente tomemos o exemplo utilizado para o escalonamento FIFO e SJF, onde quatro processos A, B, C e D com tempos de processamento distintos, respectivamente 3, 35, 12 e 4 segundos, s ao escalonados em conforme suas prioridades pelo sistema operacional. Note que as prioridades s ao reavaliadas ao nal do t ermino de cada job, determinando a pr oxima tarefa a ser processada, como mostra a Tabela 3.4. Tabela 3.4: Exemplo de la de processos sob escalonamento HRN Processo tchegada tservico tespera tperm tpn A 0 3 0 3 1.00 C 2 12 1 13 1.08 D 3 4 12 16 4.00 B 1 35 18 53 1.51 M edias 7.75 21.25 1.90 Podemos observar que os resultados apresentados pelo HRN foram bas-
79
tante superiores ao FIFO (Tabela 3.1), mas um pouco inferiores ao algoritmo SJF (Tabela 3.3). Por outro lado, o HRN n ao apresenta o risco do adiaamento innito, sendo mais equilibrado para o processamento de jobs de tamanhos diversos.
3.5.5
Escalonamento SRT (Shortest Remaining Time )
O algoritmo de escalonamento SRT (Shortest Remaining Time ) ou SRF (Shortest Remaining First ) e a variante preemptiva do escalonamento SJF. A la de processos a serem executados pelo SRT e organizada conforme o tempo estimado de execu c ao, ou seja, de forma semelhante ao SJF, sendo processados primeiro os menores jobs. Na entrada de um novo processo, o algoritmo de escalonamento avalia seu tempo de execu c ao incluindo o job em execu c ao, caso a estimativa de seu tempo de execu c ao seja menor que o do processo correntemente em execu c ao, ocorre a substitui c ao do processo em execu c ao pelo rec em chegado, de dura c ao mais curta, ou seja, ocorre a preemp c ao do processo em execu c ao. Assim, a fun c ao de sele c ao do SRT corresponde ` a min(tservicorestante ). Cada processo suspenso pelo SRT dever a ser recolocado na la em uma posi c ao correspondente apenas ao seu tempo restante de execu c ao e n ao mais o tempo de execu c ao total, tornando-se necess ario registrar os tempos decorridos de execu c ao de cada processo suspenso. A Figura 3.8 esquematiza o funcionamento de algoritmo.
Figura 3.8: Escalonamento SRT (Shortest Remaining Time ) A sobrecarga imposta pelo registro dos tempos decorridos de execu c ao e pela troca de contexto e justicada pelo fato de pequenos processos serem executados praticamente de imediato, permitindo oferecer tempos m edios de espera baixos, tornando este algoritmo u til para sistemas em tempo repartido. Por outro lado, este algoritmo tamb em se baseia nas estimativas de tempo de execu c ao dos processos, ou seja, possui as mesmas deci encias dos escalonamentos SJF e HRN quanto ` a precis ao das estimativas e abusos por parte dos usu arios. Sendo assim, devem tamb em ser consideradas as seguintes quest oes:
80
CAP ITULO 3. ESCALONAMENTO DE PROCESSOS 1. Jobs de maior dura c ao tem seus tempos de espera vari aveis em fun c ao de jobs menores que venham a ser executados primeiramente. 2. Existe um risco potencial de processos grandes acabarem sendo adiados por um tempo indeterminado (starvation ) devido ao excessivo favorecimento de jobs de curta dura c ao. 3. Dado que a preemp c ao poderia, teoricamente, ocorrer quando um processo esta prestes a ser nalizado, algum mecanismo extra deve ser adicionado para evitar que esta preemp c ao inoportuna acabe impondo um servi co pior.
Teoricamente, o escalonamento SRT deveria oferecer um melhor situa c ao de performance do que o escalonamento SJF, embora a sobrecarga existente possa equiparar os resultados obtidos em situa c oes particulares. Podemos aplicar o exemplo utilizado anteriormente para os algoritmos de escalonamento estudados ao SRT, como mostra a Tabela 3.5. Tabela 3.5: Exemplo de la de processos sob escalonamento SRT Processo tchegada tservico tespera tperm tpn A 0 3 0 3 1.00 D 3 4 0 4 1.00 C 2 12 5 17 1.42 B 1 35 18 51 1.46 M edias 5.75 18.75 1.22 Dada a ordem de chegada particular deste caso, podemos perceber que os resultados obtidos pelo SRT s ao exatamente os mesmos do algoritmos SJF Tabela 3.3), como teoricamente previsto. Mas devemos observar que para outros conjuntos de processos, os resultados deveriam ser ligeiramente melhores que o SJF.
3.5.6
Escalonamento RR (Round-Robin )
No escalonamento RR (Round Robin ) ou circular os processos tamb em s ao organizados numa la segundo sua ordem de chegada, sendo ent ao despachados para execu c ao. No entanto, ao inv es de serem executados at e o m (completion ), a cada processo e concedido apenas um pequeno intervalo de tempo (time slice ou quantum ). Caso o processo n ao seja nalizado neste intervalo de tempo, ocorre sua substitui c ao pelo pr oximo processo na la de processos ativos, sendo o processo em execu c ao interrompido e novamente colocado na la de processos prontos, mas em seu m. Isto signica que ao nal de seu intervalo de tempo, isto e, de seu quantum, ocorre a preemp c ao do processador, ou seja, o processador e designado para outro processo, sendo
81
salvo o contexto do processo interrompido para permitir a continuidade da sua execu c ao quando sua vez chegar novamente. Tal situa c ao e ilustrada na Figura 3.9.
Figura 3.9: Escalonamento RR (Round Robin ) O escalonamento RR se baseia na utiliza c ao de temporizadores, constituindo um algoritmo preemptivo bastante adequado para ambiente interativos, ou seja, em sistemas em tempo repartido onde coexistem m ultiplos usu arios simult aneos sendo, portanto, necess ario garantir-se tempos de resposta razo aveis. A sobrecarga (overhead ) imposta pela troca de contexto representa um investimento para atingir-se um bom n vel de eci encia, pois com diversos processos em execu c ao simult anea (pseudoparalelismo) e poss vel manter ocupados todos os recursos do sistema. A determina c ao do tamanho do intervalo de tempo (quantum ) e extremamente importante, pois relaciona-se com a sobrecarga imposta ao sistema pelas trocas de contexto dos processos ativos. Na Figura 2.5, onde ilustramos o escalonamento de processos, podemos observar o quantum de processamento concedido para cada processo e os tempos de preserva c ao de recupera c ao de contexto a cada preemp c ao. Para cada processo despachado para execu c ao ocorre: 1. a recupera c ao do contexto do processo, que toma um tempo que denominaremos (trc ), 2. a execu c ao do processo pela dura c ao do quantum e 3. a preserva c ao do processo ap os o t ermino de seu quantum, a qual tamb em toma um intervalo de tempo denotado por (tpc ). Como o tempo tomado para a troca de contexto (ttc ) n ao eu til do ponto de vista de processamento de processos dos usu arios, temos que para cada janela de tempo concedida aos processos a troca de contexto representa uma sobrecarga, pois somente o quantum de processamento e efetivamente u til. Dado que a troca de contexto toma um tempo aproximadamente constante temos que a sobrecarga pode ser calculada atrav es da rela c ao a seguir: ttc = trc + tpc (3.4)
82
sobrecarga =
ttc ttc + quantum
(3.5)
Por exemplo, se o tempo para troca de contexto (ttc ) toma 2 ms e o quantum e de 8 ms, temos que apenas 80% do tempo de processamento e u til, ou seja, a sobrecarga imposta pela troca de contexto representa 20% do processamento. Podemos tamb em medir o rendimento proporcionado pelo escalonamento RR considerando quanto do tempo alocado para cada processo e efetivamente usado para o processamento, ou seja, a rela c ao entre o quantum (usado para o processamento) e a soma deste com o tempo para troca de contexto (tomada para cada processo), como na rela c ao que segue: quantum ttc = 1 sobrecarga = 1 (3.6) quantum + ttc ttc + quantum
rendimento =
Ao aumentarmos o quantum diminu mos a sobrecarga percentual da troca de contexto, mas um n umero menor de usu arios (nu) ser a necess ario para que os tempos de resposta (tr ) se tornem maiores e percept veis. Diminuindo o quantum temos uma situa c ao inversa de maior sobrecarga e tamb em de um maior n umero poss vel de usu arios sem degrada c ao sens vel dos tempos de resposta. tr = nu (quantum + ttc ) ou tr (3.8) quantum + ttc Usualmente o tamanho do quantum utilizado e tipicamente algo em torno de 20ms. Com ou aumento da velocidade dos processadores, a troca de contexto se d a mais rapidamente, diminuindo a sobrecarga e aumentando ligeiramente a quantidade de usu arios poss veis para um mesmo limite de tempo de resposta. Na Tabela 3.6 temos um exemplo hipot etico do comportamento poss vel do rendimento e do n umero de usu arios em fun c ao da varia c ao do quantum usado pelo sistema. Nestes c alculos consideramos um tempo de resposta xo de tr = 1s e tamb em um tempo troca de contexto constante ttc = 2ms. Na Figura 3.10 podemos ver o comportamento do rendimento e n umero de usu arios do sistema em fun c ao do quantum para um tempo de resposta xo, conforme a Tabela 3.6 Como antes, podemos vericar o comportamento do algoritmo de escalonamento RR para uma seq u encia de quatro processos A, B, C e D, com os mesmos tempos de chegada e servi co. Tomaremos como quantum um valor de 100 ms. Assim teremos os resultados apontados pela Tabela 3.7. nu = (3.7)
83
Tabela 3.6: Rendimento e n umero de usu arios em fun c ao do quantum quantum n umero de rend. (ms) usu arios (%) 1 333 33.3 2 250 50.0 5 143 71.4 10 83 83.3 20 45 90.9 50 19 96.2 100 10 98.0 200 5 99,0 500 2 99.6 1000 1 99.8 Tabela 3.7: Exemplo de la de processos sob Processo tchegada tservico tespera A 0 3 4.6 B 1 35 18.0 C 2 12 17.5 D 3 4 9.3 M edias 12.35 escalonamento RR tperm tpn 7.6 2.53 53.0 1.51 29.5 2.46 13.3 3.32 25.85 2.46
N ao surpreendentemente, o algoritmo RR apresenta resultados bastante melhores que o escalonamento FIFO e pouco inferiores aos algoritmos SJF, HRN e SRT. Por outro lado, apresenta um grau de interatividade muito superior a todos os algoritmos citados, compensando largamente seu emprego.
3.5.7
Escalonamento MQ (Multilevel Queues )
Quando e poss vel dividir os processos em diferentes categorias, conforme seu tipo, prioridade e consumo de recursos, pode-se empregar o escalonamento em m ultiplas las [TAN92, p. 64] [SGG01, p. 105]. Deste modo, a la de processos prontos seria separada em v arias las, uma para cada tipo de processo, tais como processos do sistema, processos interativos, processos de edi c ao interativa, processos batch e processos secund arios, como ilustrado na Figura 3.11, onde a la de processos do sistema teria a maior prioridade enquanto a la de processos secund arios teria a menor prioridade. Cada la pode possuir seu pr oprio algoritmo de escalonamento, ou seja, algumas las pode ser preemptivas enquanto outras n ao, sendo que os crit erios de sele c ao dos processos para execu c ao e da preemp c ao, quando poss vel, um arranjo comum que a podem ser distintos de uma la para outra. E la de processos do sistema e batch usem um algoritmo tal como o FIFO
84
Figura 3.10: Comportamento do rendimento e n umero de usu arios em fun c ao do quantum enquanto que as demais utilizem algoritmos semelhantes ao round robin. Entre as diferentes las a divis ao do processamento tamb em pode ocor poss rer de diversas maneiras. E vel realizar tal divis ao considerando um algoritmo de prioridade simples, onde a la de maior prioridade tem seus processos executados at e que esteja vazia. Isto pode comprometer o n vel de resposta dos processos nas demais las, possibilitando at e mesmo a estagna c ao de processos nas las de prioridades inferiores. Outra solu c ao seria o emprego de um algoritmo round robim assim etrico, onde, por exemplo, a la de processos de sistema poderia receber uma janela de processamento de 50% enquanto as demais receberiam janelas progressivamente menores, tais como 25%, 15%, 10% e 5%. Uma alternativa simplicada de emprego deste algoritmos e o uso de apenas duas las, uma para processos em primeiro plano (foreground ) e outra para processos em segundo plano (background ), de modo que as duas las utilizam um algoritmo round robin convencional e a divis ao do processamento entre as las utilizasse um round robin assim etrico que dedicasse 80% do processamento para a la de primeiro plano e os 20% restantes para la de segundo plano.
3.5.8
Escalonamento MFQ (Multilevel Feedback Queues )
O escalonamento MFQ (Multilevel Feedback Queues ) ou las multin vel realimentadas e um interessante esquema de divis ao de trabalho do processador que e baseado em v arias las encadeadas, como mostra a Figura 3.12. Diferentemente do algoritmo MQ, que disp oe de las distintas para processos de tipos diferentes, todos os novos processos s ao colocados inicial-
85
Figura 3.11: Escalonamento MQ (Multiple queues ) mente na la de n vel 1, que tem um comportamento FIFO, ou seja, o processo aguarda sua vez para execu c ao conforme sua ordem de chegada. Ao utilizar o processador podem ocorrer tr es situa c oes: 1. o processo e nalizado e ent ao retirado das las; 2. o processo solicita o uso de dispositivos de E/S, sendo bloqueado at e que o pedido de E/S seja atendido, voltando para a mesma la at e que seu quantum de tempo se esgote; e 3. tendo esgotado seu quantum inicial de tempo, o processo e colocado no nal da la de n vel 2. Nas las seguintes o mecanismo e o mesmo, embora os processos s o utilizem o processador na sua vez e na aus encia de processos nas las de n vel superior. Quando novos processos aparecem em las superiores ocorre a preemp c ao dos processos nas las n vel inferior, de forma a atender-se os processos existentes nas las superiores. Au ltima la apresenta um comportamento um pouco diferente: ela n ao e uma FIFO e sim uma la circular, ou seja, de escalonamento round robin, onde os processos permanecem at e que seja nalizados. Neste esquema de escalonamento temos que: processos curtos s ao favorecidos pois recebem tratamento priorit ario enquanto permanecem nas las de n vel superior;
86
Figura 3.12: Escalonamento MFQ (Multiple feedback queues ) processos com utiliza c ao intensa de E/S s ao favorecidos pois o uso de E/S n ao os desloca para las inferiores; e processos de processamento maior tamb em s ao favorecidos pois os quanta de tempo s ao progressivamente maiores nas las de n vel inferior. O esquema de m ultiplas las encadeadas tem comportamento semelhante ` um esquema de prioridades, onde as las de n a vel superior eq uivalem aos n veis de prioridade mais altos do sistema e a u ltima la, de escalonamento round robin corresponde ao n vel de prioridade mais baixo. Considerando que um algoritmo de escalonamento deveria avalar a natureza dos processos em execu c ao promovendo um escalonamento adequado de modo que, minimamente, fossem favorecidos: processos de curta dura c ao de forma a minimizar os tempos m edios de resposta; e processos que demandem dispositivos de E/S para obter adequada utiliza c ao dos perif ericos do sistema. Notamos que o MFQ constitui uma alternativa bastante atraente, pois pode ser considerado um algoritmo adaptativo, ou seja, e capaz de perceber
DOS ALGORITMOS DE ESCALONAMENTO 87 3.6. COMPARAC AO o comportamento de um processo, favorecendo-o atrav es da recoloca c ao em uma la de n vel adequado. O crit erio de recoloca c ao de processos nas mesmas las ap os uso de dispositivos de E/S inuencia grandemente no quanto este esquema de escalonamento e adaptativo, isto e, no quanto ele e capaz de atender aos diferentes padr oes de comportamento dos processos. Embora a sobrecarga para administra c ao deste esquema de escalonamento seja maior, o sistema torna-se mais sens vel ao comportamento dos processos, separando-os em categorias (os v arios n veis das las), possibilitando ganho de eci encia.
3.6
Compara c ao dos algoritmos de escalonamento
Nas Tabelas 3.8 e 3.9 agrupamos as principais carater sticas dos algoritmos de escalonamento estudados nas se c oes anteriores, permitindo a avalia c ao comparativa em termos de sua fun c ao de sele c ao, preemptividade, throughput (produtividade), tempo de resposta e sobrecarga apresentados. Tabela 3.8: Algoritmos de escalonamento n ao preemptivos
Caracter stica Fun c ao de Sele c ao Preemptividade Throughput Tresposta Sobrecarga Adiamento Indenido FIFO min(tchegada ) n ao
m edia alto baixa
HPF max(prio) n ao
m edia baixo:m edio baixa:alta
SJF min(tservico ) n ao
alta baixo:m edio baixa:alta
HRN max(tpn ) n ao
alta baixo:m edio baixa:alta
n ao
sim
sim
n ao
Dentre os algoritmos n ao preemptivos (Tabela 3.8) temos que apresentam o seguinte comportamento geral: O algoritmo FIFO e o mais simples e tamb em o mais ineciente, pois acaba penalizando processos pequenos que ocorram entre processos maiores e tamb em n ao trata o uso de dispositivos de E/S da maneira adequada, penalizando o sistema como um todo. O algoritmo HPF e relativamente simples e permite implantar uma pol tica diferencida de escalonamento atrav es da deni c ao de prioridades. No entanto os resultados do escalonamento tendem a se aproximar do FIFO quando ocorrem v arios processos com o mesmo n vel de prioridade. O escalonamento SJF penaliza os processos longos, sendo poss vel o adiamento indenido destes. Por outro lado, proporciona uma alta
88
CAP ITULO 3. ESCALONAMENTO DE PROCESSOS produtividade as custas de uma maior sobrecarga e tempos de resposta m edios. O HRN e um dos melhores algoritmos de escalonamento n ao preemptivos, pois apresenta alta produtividade, tempos de resposta adequados e bom equil brio entre atendimento de processos grandes e pequenos. Al em disso n ao possibilita a ocorr encia de adiamento indenido.
Tabela 3.9: Algoritmos de escalonamento preemptivos Caracter stica RR SRT MQ MFQ Fun c ao de constante min(tservrest ) complexa complexa Sele c ao Preemptividade sim sim sim sim
(quantum ) (chegada) alta baixo:m edio m edia:alta (quantum ) m edia baixo:m edio m edia:alta (quantum ) m edia baixo:m edio m edia:alta
Throughput Tresposta Sobrecarga Adiamento Indenido
m edia baixo:m edio baixa
n ao
sim
sim
sim
Analisando agora os algoritmos preemptivos (Tabela 3.9), todos possuem implementa c ao mais sosticada que os algoritmos n ao preemptivos A solu c ao round robin e uma alternativa geral simples, que proporciona tratamento justo e e ainda razoavelmente produtivo, pois sua eci encia se acha bastante associada ao tamanho do quantum. O escalonamento SRT apresenta produtividade alta e tempos de resposta adequado, mas desfavorece processos longos al em de possibilitar o adiamento indenido. A sobrecarga e um de seus aspectos negativos. O algoritmo MQ e uma solu c ao que pode ser ligeiramente mais complexa que o round robin ou t ao complexa como o MFQ. Permite obter bons resultados quando a categoriza c ao dos processos e poss vel. O algoritmo MFQ e razoavelmente mais complexo, implicando em maior sobrecarga, oferecendo o mesmo n vel de produtividade do round robin. Por outro lado se mostra mais eciente em situa c oes que os processos exibem comportamento I/O bounded, t pico de aplica c oes comerciais com processamento simples de grandes quantidades de dados.
Cap tulo 4
Gerenciamento de Mem oria

Neste cap tulo vamos tratar do gerenciamento de mem oria e de suas implica c oes para com as funcionalidades oferecidas pelos sistemas operacionais. Para isto veremos como as diferentes formas de endere camento inuenciam as capacidades de um sistema e as diferentes estrat egias de organiza c ao e controle da mem oria.
4.1
Primeiras considera c oes
Antes de denirmos o que e o gerenciamento de mem oria, devemos primeiro considerar a estrutura dos computadores, tal como proposta no nal da d ecada de 1930 por John Von Neumann, matem atico h ungaro erradicado nos EUA, que trabalhava na Universidade de Princeton: Um computador e composto de tr es partes fundamentais: o processador, os dispositivos de entrada/sa da e a mem oria. Atrav es desta estrutura, ilustrada na Figura 4.1, Von Neumann mudou radicalmente o conceito do computador, armando que o programa deveria ser armazenado na mem oria junto com os dados, transformando as sosticadas m aquinas de calcular existentes em uma nova esp ecie de m aquina, completamente diferente, mais gen erica e capaz de lembrar seq u encias de comandos previamente fornecidas, executando-as elmente. Este novo conceito permitiu construir-se computadores capazes de executar diferentes seq u encias de instru c oes sem a altera c ao de seu hardware, o que n ao acontecia com as antigas m aquinas de calcular gigantes. Mas duas vertentes surgiram praticamente na mesma epoca, direcionando diferentemente a arquitetura de sistemas computacionais baseados em mem oria. Conforme forma organizados, receberam o nome de arquitetura de Von Neumann ou arquitetura Princeton. Os pesquisadores da Universidade de Harvard propuseram uma arquitetura ligeiramente diferente da proposta inicial de Von Neumann, onde 89
90
CAP ITULO 4. GERENCIAMENTO DE MEMORIA
Figura 4.1: Arquitetura Princeton existiam dispositivos de mem oria distintos para o armazenamento de dados e programas (veja a Figura 4.2). O grande diferencial e que a arquitetura de Princeton possui um u nico barramento para transfer encia de dados e instru c oes entre mem oria e processador enquanto que a arquitetura de Harvard possui dois barramentos, cada um ligando o processador aos dispositivos de mem oria de dados e programas respectivamente. Apesar da arquitetura de Harvard ser potencialmente mais eciente, a simplicidade da arquitetura Princeton predominou com o passar dos anos.
Figura 4.2: Arquitetura Harvard Apesar destas duas arquiteturas serem conceitos revolucion arios para a epoca, existia um grave problema: n ao se dispunha de tecnologia suciente para constru c ao de dispositivos eletro-eletr onicos que funcionassem como mem orias. Quando Von Neumann prop os o computador como uma m aquina capaz de memorizar e executar seq u encias de comandos, j a existia tecnologia para implementar-se os primeiros circuitos processadores e tamb em os dispositivos b asicos de entrada e sa da, mas n ao se sabia como construir circuitos de mem oria. Se passaram v arios anos at e que uma primeira implementa c ao satisfat oria de um circuito de mem oria permitisse construir um computador conforme sugerido por Von Neumann. Isto explica a origem de um defasagem tecnol ogica, at e hoje n ao superada por completo, entre mem orias e
4.1. PRIMEIRAS CONSIDERAC OES
91
processadores. O pr oprio termo core memory, utilizado para designar a mem oria prim aria ou principal, tem sua origem nos primeiros dispositivos de mem oria constru dos com pequenos n ucleos magnetiz aveis de ferrite interligados matricialmente por uma delicada a c ao de cobre, onde cada n ucleo armazenava um u nico bit. Tipicamente tem-se que os processadores s ao capazes de ler e principalmente escrever mais r apido do que os circuitos de mem oria do mesmo n vel tecnol ogico. Isto usualmente for ca uma determinada espera por parte dos processadores quando ocorre a troca de informa c oes com a mem oria. Estes tempos de espera s ao conhecidos como wait states. Este problema n ao seria t ao grave se a intera c ao entre processador e mem oria n ao constitu sse a pr opria ess encia do funcionamento dos computadores baseados na arquitetura de Von Neumann. Na arquitetura de Von Neumman o processador exibe o seguinte comportamento (como ilustrado na Figura 1.3) enquanto estiver ativo s ao repetidas as a c oes seguintes: busca de uma instru c ao (ciclo de fetch ou opcode fetch ); decodica c ao da instru c ao (ciclo de instruction decode ); e execu c ao da instru c ao (ciclo de instruction execution ). Notamos que o ciclo de fetch e basicamente uma opera c ao de leitura da mem oria, sendo o ciclo de decodica c ao interno ao processador, enquanto o ciclo de execu c ao pode realizar tanto opera c oes internas ao processador como tamb em opera c oes de leitura ou escrita na mem oria. Apesar das diculdades encontradas, a arquitetura computacional baseada nos tr es elementos b asicos (processador, mem oria e dispositivos de entrada/sa da) ainda se mostra a melhor que existe, principalmente quando se inclui nela todos os avan cos tecnol ogicos destes u ltimos 1950 anos. Hoje temos que, em conseq u encia da mencionada defasagem tecnol ogica e dos problemas inerentes a constru c ao de dispositivos de mem oria, o custo relativo entre mem oria e principalmente o processador faz com que a mem oria represente uma parcela bastante signicativa de um sistema computacional, parcela esta que se torna ainda mais signicativa quanto mais sosticado e tal sistema (usualmente s ao sistemas de alto desempenho). muito importante ressaltarmos que, quando se fala em mem E oria, estamos nos referindo aos circuitos que trocam dados diretamente com o processador durante o ciclo de execu c ao de seus comandos mais b asicos, ou seja, a mem oria prim aria ou armazenamento prim ario. Os dispositivos de armazenamento secund ario, isto e, os dispositivos de mem oria de massa tal como tas, cartuchos e disco magn eticos (xos ou remov veis) n ao devem ser confundidos com a mem oria b asica do computador.
92
A mem oria dita prim aria possui intera c ao direta com o processador, isto e, ca diretamente conectada aos seus barramentos. J a os dispositivos chamados de mem oria secund aria necessitam de alguma circuitaria ou memos mec anica extra para que os dados presentes no barramento do processador sejam gravados em suas m dias e vice-versa. Como veremos mais tarde, a mem oria secund aria ter a papel fundamental dentro do gerenciamento da mem oria prim aria, mas isto deve ser tratado com cautela, pois apesar de seu custo ser bastante inferior ao da mem oria prim aria b asica, sua velocidade e milhares de vezes menor, como indicado na Tabela 4.1. Tabela 4.1: Valores M edios de Tempo de Acesso e Pre co por MByte para Dispositivos de Microcomputadores PC Compat veis em 1998 Dispositivo Tempo de Acesso Pre co/MByte (ms) (US$) Cartuchos 200 0.05 Disco R gido 13 0.22 SIMM 45 12.00 DIM 25 16.00 Sendo assim, somente uma cuidadosa an alise de custo versus benef cio, que leve em conta outros fatores inerentes ao gerenciamento de mem oria, poder a diagnosticar com precis ao como e quando utilizar-se da mem oria secund aria ao inv es da mem oria prim aria. Resumidamente, justicamos a necessidade do gerenciamento de mem oria pelos tr es fatores relacionados a seguir: A mem oria prim aria e um dos elementos b asicos da arquitetura computacional atual. Dado que a velocidade de suas opera c oes de leitura e escrita serem mais baixas que a correspondentes velocidades dos processadores e ainda seu custo ser mais elevado, exige-se seu uso cuidadoso. Como todo processo utiliza mem oria prim aria, ao gerenciarmos mem oria estamos indiretamente gerenciando os processos.
4.2
Multiprograma c ao
Como j a vimos, a multiprograma c ao e uma importante t ecnica utilizada para o projeto e constru c ao de sistemas operacionais. Segundo Guimar aes: A maioria do computadores modernos opera em regime de multiprograma c ao, isto e, mais de um programa em execu c ao simult anea na mem oria. A exist encia nesses sistemas de pe-
4.2. MULTIPROGRAMAC AO rif ericos ass ncronos e com velocidades de opera c ao as mais diversas tornou economicamente necess ario introduzir a multiprograma c ao a m de utilizar de maneira mais eciente os recursos do sistema. [GUI86, p. 71] [grifos do autor]
93
Da mesma forma, isto tamb em permite que uma tarefa seja dividida em partes, as quais podem ser executadas paralelamente, reduzindo o tempo total de processamento. Em suma, a multiprograma c ao visa alcan car melhores ndices de produtividade num sistema computacional. Em computadores de pequeno porte ou destinados ao uso pessoal e toler avel uma situa c ao de baixa eci encia ou baixa produtividade, onde tanto o processador como os dispositivos perif ericos permanecem ociosos por boa parte do tempo de funcionamento do equipamento. Tomemos como exemplo um programa (ou rotina) conversor de imagens de formato BMP para GIF que, num sistema monoprogramado, e executado utilizando 8 segundos da atividade do processador (a convers ao da imagem propriamente dita) e 24 segundos de atividade de dispositivos de E/S (gastos para carregamento do arquivo de entrada e armazenamento do arquivo de sa da produzido pela rotina. A execu c ao deste programa imp oe a situa c ao relacionada na Tabela 4.2. Tabela 4.2: An alise de ociosidade Tempo Total 32 s Tempo de Proc 8s Tempo de I/O 24 s Ociosidade do Proc. 75 % Ociosidade do Disco 25 % Ociosidade de Outros Disp. 100 % A ociosidade do processador exibida neste exemplo representa um desperd cio de sua capacidade equivalente a execu c ao de outros tr es programas id enticos. Constata c ao an aloga pode ser feita para os dispositivos de E/S deste sistema. Tal situa c ao n ao e admiss vel em sistemas de maior porte e, portanto, de maior custo de aquisi c ao e propriedade. As possibilidades oferecidas por sistemas monoprogramados impedem que melhores ndices de produtividade e eci encia sejam atingidos, neste sentido, a multiprograma c ao e a alternativa que permite, as custas de um sistema de maior complexidade, obter ndices adequados de produtividade e eci encia. Basicamente, o objetivo da multiprograma c ao e maximizar a produtividade (throughput ) e minimizar os tempos de resposta. Para isto e necess ario a presen ca de v arios programas ativos, simultaneamente na mem oria principal do sistema de maneira a obter-se a melhor utiliza c ao poss vel dos recursos do sistema. O maior problema da multiprograma c ao e, portanto,
94
tornar compat veis os tempos de execu c ao dos programas e o atendimento dos usu arios junto das diferentes velocidades de opera c ao dos perif ericos do sistema. Se partirmos de um modelo bastante simplicado de sistema onde possamos supor verdadeiras as seguintes condi c oes: a sobrecarga imposta pelos mecanismos de administra c ao do sistema operacional e desprez vel; os processos sejam totalmente independentes; e existe capacidade de efetuar-se processamento verdadeiramente paralelo. Nestes casos a taxa de ociosidade e utiliza c ao do processador podem ser dadas respectivamente pelas seguintes rela c oes: ociosidade = tp io utilizacao = 1 ociosidade = 1 tp io (4.1)
(4.2)
Nestas equa c oes p e o n umero de processos ativos existentes no sistema e tio representa a taxa m edia de utiliza c ao de dispositivos de E/S por parte destes processos. Atrav es desta rela c ao, podemos obter as seguintes curvas ilustrando o comportamento da utiliza c ao do processador para um n umero vari avel de processos, considerando-se diferentes taxas m edias de utiliza c ao de E/S.
Figura 4.3: Comportamento da taxa de utiliza c ao do processador
DA MEMORIA 4.3. ORGANIZAC AO
95
Notamos que conforme aumenta a taxa m edia de utiliza c ao de dispositivos de E/S (tio ) por parte dos processos, maior e o n umero p de processos necess ario para que a utiliza c ao do processador se mantenha em n veis adequados, ou seja, utilizacao > 85%. Isto pode ser entendido de outra forma: quanto maior a taxa m edia de utiliza c ao de dispositivos de E/S, maior eo n umero de usu ario suportado pelo sistema. Apesar de ser uma simplica c ao, tais valores tem valor indicativo, ou seja, o comportamento esperado em sistemas reais e o mesmo a despeito dos valores absolutos obtidos. Com isto justica-se a necessidade de ambientes multiprogramados como u nica forma de obter-se sistemas de alta produtividade e eci encia.
4.3
Organiza c ao da mem oria
Num sistema computacional o armazenamento de dados ocorre hierarquicamente, ou seja, em diversos n veis dado que e realizado em diferentes tipos de dispositivos devido ` a quatro fatores b asicos: tempo de acesso velocidade de opera c ao custo por unidade de armazenamento capacidade de armazenamento Com isto em mente, o projetista de um sistema operacional determina quanto de cada tipo de mem oria ser a necess ario para que o sistema seja ao mesmo tempo eciente e economicamente vi avel. Em virtude das diculdades tecnol ogicas associadas a constru c ao de dispositivos ecientes de mem oria e seu custo, o armazenamento de dados assumiu historicamente a seguinte organiza c ao: Armazenamento interno S ao posi c oes de mem oria dispon veis internamente ao processador para permitir ou agilizar sua opera c ao. Constitui-se dos registradores do processador e de seu cache interno. Armazenamento prim ario S ao as posi c oes de mem oria externa, diretamente acess veis pelo processador. Tipicamente s ao circuitos eletr onicos integrados do tipo RAM, EEPROM, EPROM, PROM ou ROM. Armazenamento secund ario S ao as posi c oes de mem oria externa que n ao podem ser acessadas
96
Figura 4.4: Organiza c ao da mem oria em n veis diretamente pelo processador, devendo ser movidas para o armazenamento prim ario antes de sua utiliza c ao. Tipicamente dispositivos de armazenamento de massa tais como unidades de disco e ta. Note que o armazenamento interno e aquele que possui as maiores velocidades de acesso, ou seja, os menores tempos de acesso representando os melhores dispositivos em termos de performance, embora sendo os mais caros. Disto decorre sua implementa c ao em quantidades menores. Em contrapartida, os dispositivos de armazenamento secund ario s ao os de maior capacidade e de melhor rela c ao custo por byte, mas signicativamente mais lentos. A mem oria prim aria representa um caso intermedi ario, onde a velocidade e tempo de acesso s ao adequadas ` a opera c ao direta com o processador, mas cujo custo ainda assim e elevado. Com a evolu c ao do computadores, a atual organiza c ao conta com outros elementos adicionados para otimizar a performance do sistema e ainda assim reduzir seu custo, conforme a gura a seguir:
Figura 4.5: Organiza c ao t pica de armazenamento
DE GERENCIAMENTO DE MEMORIA 4.4. DEFINIC AO
97
Os registradores, implementados em n umero limitado devido ao seu custo, s ao geralmente utilizados para manter dentro do processador dados freq uentemente utilizados. Os cache interno e externo, devido sua maior velocidade, s ao usados para manter uma por c ao do programa (que pode assim ser executada mais rapidamente do que na mem oria principal), ou uma por c ao de dados (evitando-se uso da mem oria principal) e com isto aumentando o desempenho do sistema [DEI92, p. 30]. A mem oria prim aria armazena os programas e dados em execu c ao no sistema. Os dispositivos de armazenamento secund ario s ao usados para preserva c ao dos dados de forma perene, embora tamb em possam ser usados para expandir as capacidades da mem oria prim aria. O cache de disco e utilizado para acelerar a opera c ao das unidades de disco, podendo esta t ecnica ser utilizada para outros tipos de perif ericos.
4.4
Deni c ao de gerenciamento de mem oria
A necessidade de manter m ultiplos programas ativos na mem oria do sistema imp oe outra, a necessidade de controlarmos como esta mem oria e utilizada por estes v arios programas. O gerenciamento de mem oria e, portanto, o resultado da aplica c ao de duas pr aticas distintas dentro de um sistema computacional: 1. Como a mem oria principal e vista, isto e, como pode ser utilizada pelos processos existentes neste sistema. 2. Como os processos s ao tratados pelo sistema operacional quanto ` as suas necessidades de uso de mem oria. Como a mem oria e um recurso caro, cuja administra c ao inuencia profundamente na eci encia e performance de um sistema computacional, e necess ario considerar-se tr es estrat egias para sua utiliza c ao: 1. Estrat egias de busca As estrat egias de busca (fetch strategies ) preocupam-se em determinar qual o pr oximo bloco de programa ou dados que deve ser transferido da mem oria secund aria para a mem oria prim aria. Usualmente se utilizam estrat egias de demanda, ou seja, s ao transferidos os blocos determinados como necess arios para a continua c ao do processamento. 2. Estrat egias de posicionamento S ao as estrat egias relacionadas com a determina c ao das regi oes da mem oria prim aria (f sica) que ser ao efetivamente utilizados pelos programas e dados, ou seja, pela determina c ao do espa co de endere camento utilizado (placement strategies ).
98
CAP ITULO 4. GERENCIAMENTO DE MEMORIA 3. Estrat egias de reposi c ao ou substitui c ao S ao as estrat egias preocupadas em determinar qual bloco ser a enviado a mem oria secund aria para disponibiliza c ao de espa co na mem oria principal para execu c ao de outros programas, ou seja, determinam quais blocos de mem oria ser ao substitu dos por outros (replacement strategies ).
Minimamente, todo sistema computacional possui alguma estrat egia de busca e alguma estrat egia b asica de posicionamento. O aumento da sostica c ao dos sistemas computacionais exige a utiliza c ao de estrat egias de busca posicionamento mais sosticadas. Para maximizar-se as capacidades dos sistemas computacionais s ao necess arias as estrat egias de reposi c ao. Historicamente, o desenvolvimento da organiza c ao e gerenciamento de mem oria foi grandemente afetado pelo pr oprio desenvolvimento dos computadores e evolu c ao dos sistemas operacionais. Os modos b asicos de organiza c ao da mem oria dos sistemas s ao: monoprogramado multiprogramados com armazenamento real, particionamento xo e endere camento absoluto multiprogramados com armazenamento real, particionamento xo e endere camento reloc avel multiprogramados com armazenamento real, de particionamento vari avel multiprogramados com armazenamento virtual paginado multiprogramados com armazenamento virtual segmentado multiprogramados com armazenamento virtual combinado Na Figura 4.6 temos um quadro onde se ilustra o relacionamento dos modelos b asicos de organiza c ao da mem oria e, de certa forma, sua evolu c ao. Com rela c ao ao primeiro aspecto b asico da ger encia de mem oria, para entendermos como os processos enxergam a mem oria, e necess ario conhecer em detalhe como os programas se comportam durante sua execu c ao. O comportamento exibido pelos programas durante sua execu c ao cria determinadas limita c oes que devem ser observadas cuidadosamente pelo sistema operacional atrav es de seu gerenciamento de mem oria. Por outro lado, os programas tamb em devem se comportar dentro de regras estabelecidas pelo pr oprio sistema operacional, as quais comp oem o modelo de administra c ao de mem oria empregado pelo sistema. Para sabermos como se comporta um programa durante sua execu c ao e quais s ao suas limita c oes quanto a utiliza c ao da mem oria, devemos analisar todo o processo de cria c ao dos programas.
DE PROGRAMAS 4.5. CRIAC AO
99
Figura 4.6: Evolu c ao da organiza c ao da mem oria
4.5
Cria c ao de programas
Os programas s ao criados a partir de arquivos-texto, que cont em um roteiro estruturado de passos e a c oes a serem executadas pelo programa que se deseja., ou seja, estes arquivos-texto s ao uma representa c ao dos algoritmos que se desejam programar. Estes passos e a c oes est ao descritos dentro do arquivo-texto atrav es de uma linguagem de programa c ao e por isso s ao usualmente chamados de arquivo-fonte do programa (resumidamente arquivo-fonte ou fonte). As linguagens de programa c ao utilizadas podem ser de alto, m edio ou baixo n vel, mas qualquer que seja a linguagem, seu tipo e a forma de estrutura c ao do programa, o arquivo-fonte continua a ser simplesmente um texto, an alogo ` a uma reda c ao, sujeito ` a regras de sintaxe e de contexto. Da mesma forma que os computadores n ao entendem a nossa linguagem, ou seja a linguagem que naturalmente utilizamos para nossa comunica c ao, estas m aquina t ao pouco entendem as linguagens de programa c ao diretamente. Existem entidades especiais respons aveis pela transforma c ao do arquivo-fonte do programa em uma forma pass vel de execu c ao pelo computador. Estas entidades est ao ilustradas na Figura 4.7. O compilador (compiler ) e um programa especial que traduz o arquivo fonte em um arquivo bin ario que cont em instru c oes, dados e endere cos (representados binariamente) que permitem executar as a c oes necess arias atrav es das instru c oes em linguagem de m aquina do processador existente
100
Figura 4.7: Esquema de cria c ao de programas no computador em quest ao. Os arquivos bin arios produzidos pelo compilador s ao os arquivos-objeto ou resumidamente objeto. Note que cada compilador e apropriado para uma u nica linguagem de programa c ao. O ligador (linker ), quando necess ario, apenas encadeia dois ou mais arquivos objeto sob a forma de um u nico arquivo de programa execut avel ou arquivo-execut avel. O arquivo-execut avel e aquele que pode ser transferido para a mem oria do computador possibilitando a execu c ao do programa. Assim como os compiladores, o ligador tamb em e uma entidade deste processo de gera c ao de programas e tamb em est a sujeito a operar com arquivos objeto produzidos apenas por determinados compiladores. Devemos ressaltar que at e agora os arquivos fonte, objeto e execut avel constituem arquivos, ou seja, est ao armazenados nas estruturas de mem oria secund aria (unidades de disco r gido, discos ex veis, tas, cartuchos ou discos opticos). Existe uma outra entidade especial, chamada carregador (loader ), que e parte integrante do sistema operacional, respons avel por transportar os arquivos de programa execut avel da mem oria secund aria para a mem oria principal, onde se dar a a execu c ao do programa carregado. Os carregadores constituem uma parte do sistema operacional porque a coloca c ao de programas na mem oria e a execu c ao dos mesmos s ao fun c oes deste, respons avel por controlar ecientemente as estruturas de mem oria prim aria, de armazenamento secund ario e o processamento do sistema com-
101
putacional. Ap os o transporte do arquivo execut avel para a mem oria principal e poss vel iniciar sua execu c ao, onde ele mesmo se transforma numa imagem execut avel, que representa a expans ao do c odigo de programa contido no arquivo execut avel em c odigo execut avel, areas de mem oria reservadas para vari aveis do programa, pilha retorno e area extra para aloca c ao din amica por parte do programa. A bem da verdade, o sistema operacional, antes da carga do m odulo de c odigo, deve conhecer de antem ao seu tamanho total e a quantidade m nima de mem oria extra necess aria. Tais informa c oes residem geralmente num cabe calho (header ) localizado no in cio do arquivo de programa execut avel, que n ao e copiado para mem oria, mas apenas lido pelo sistema operacional.
4.5.1
Espa cos l ogicos e f sicos
Retomemos os conceitos envolvidos com os arquivos de programa fonte. Qual e o objetivo b asico de um programa? A resposta e: ensinar o computador a executar um seq u encia de passos, manuseando dados de forma interativa ou n ao, com o objetivo nal de realizar c alculos ou transforma c oes com os dados fornecidos durante a execu c ao do programa. Para isto, ap os o entendimento do problema, idealiza-se conceitualmente uma forma de representa c ao do dados a serem manipulados e depois disso um conjunto de opera c oes especiais que manipular ao as estruturas criadas possibilitando a obten c ao dos resultados esperados do programa. Notem que ao projetar-se um programa, por mais simples ou complexo que ele seja, dene-se um espa co l ogico que re une todas as abstra c oes feitas para criar-se o programa, sejam elas de natureza estrutural ou procedural/funcional. Tais abstra c oes s ao os objetos l ogicos do programa. O espa co l ogico cont em todas as deni c oes necess arias para o programa, mas sem qualquer v nculo com as linguagens de programa c ao ou com os processadores e computadores que executar ao os programas criados a partir desta concep c ao. O espa co l ogico e a representa c ao abstrata da solu c ao do problema, tamb em abstrata. Durante a implementa c ao dos programas utilizam-se, como meios de express ao, as linguagens de programa c ao que possibilitam expressar de maneira concreta (apesar das limita c oes impostas por qualquer linguagem de programa c ao) as formula c oes contidas no espa co l ogico. Pode-se dizer assim que os programas fonte representam, numa dada linguagem de programa c ao, o espa co l ogico do programa. Num outro extremo, dentro do computador a execu c ao do programa tem que ocorrer dentro da mem oria principal, como conseq u encia e limita c ao da arquitetura de Von Neumann. Seja qual for o computador e a particulariza c ao da arquitetura de seu hardware, a mem oria principal pode sempre ser expressa como um vetor, unidimensional, de posi c oes de mem oria que se iniciam num determinado
102
ponto, usualmente o zero, e terminam em outro, 536.870.912 para um computador com 512 Mbytes de mem oria, por exemplo. Cada posi c ao desta estrutura de mem oria e id entica, podendo armazenar o que se chama de palavra de dados do computador, na pr atica um conjunto de bits. Se a palavra de dados tem 4 bits , a mem oria est a organizada em nibbles. Palavras de dados de 8, 16 e 32 bits representam, respectivamente, organiza c oes de mem oria em bytes, words e double words. Tipicamente se organizam as mem orias dos microcomputadores em bytes, assim cada posi c ao de mem oria poderia armazenar um byte de informa c ao, sendo que nos referenciamos as posi c oes de mem oria pelos seus n umeros de posi c ao, os quais s ao chamados de endere cos. Como a mem oria de um computador e um componente eletr onico, sicamente palp avel, dizemos que os endere cos de mem oria representam sicamente a organiza c ao de mem oria de um computador. Sabemos que um programa quando em execu c ao na mem oria principal de um computador se chama imagem execut avel e que esta imagem ocupa um regi ao de mem oria nita e bem determinada. Ao conjunto de posi c oes de mem oria utilizado por uma imagem se d a o nome de espa co f sico desta imagem. De um lado a concep c ao do programa, representada e contida pelo seu espa co l ogico. Do outro lado, durante a execu c ao da imagem temos que as posi c oes de mem oria usadas constituem o espa co f sico deste mesmo programa. De alguma forma, em algum instante o espa co l ogico do programa foi transformado e ligado a organiza c ao de mem oria do sistema computacional em uso, constituindo o espa co f sico deste mesmo programa. A liga c ao entre o espa co l ogico e f sico representa, na verdade, a um processo de mapeamento, onde cada elemento do espa co l ogico e unido de forma u nica a uma posi c ao de mem oria do computador, acabando por denir um espa co f sico. A este processo de liga c ao se d a o nome de mapeamento ou binding (amarra c ao), como representado na Figura 4.8. No nosso contexto binding signica o mapeamento do espa co l ogico de um programa no espa co f sico que possibilita sua execu c ao dentro do sistema computacional em uso.
Figura 4.8: Representa c ao do binding Veremos a seguir que o binding tem que ser realizado por uma das entidades envolvidas no processo de cria c ao de programas, ou seja, em alguns ins-
103
poss tante da compila c ao, liga c ao, carregamento ou mesmo execu c ao. E vel tamb em que o binding seja realizado por mais de uma destas entidades, onde cada uma realiza uma parcela deste processo de mapeamento.
4.5.2
Compiladores (compilers )
Como j a foi denido, um compilador e um programa especial capaz de traduzir um arquivo escrito em uma linguagem de programa c ao espec ca em um outro arquivo contendo as instru c oes, dados e endere cos que possibilitam a execu c ao do programa por um processador particular. O compilador e, portanto, capaz de entender um algoritmo expresso em termos de uma linguagem de programa c ao, convertendo-o nas instru c oes necess arias para sua execu c ao por um processador particular (vide Figura 4.9).
Figura 4.9: Compilador e cross -compilador Todas as deni c oes internas s ao transformadas em c odigo. Fun c oes, estruturas de dados e vari aveis externas, tem apenas o local de chamada marcado em tabelas de s mbolos externos para liga c ao posterior com bibliotecas ou outros m odulos de c odigo. Al em de considerar o processador que executar a tais instru c oes, alguns aspectos da arquitetura e do sistema operacional devem ser observados pelos compiladores como forma de produzir c odigo verdadeiramente u til para uma dada arquitetura computacional. No Exemplo 4.1 temos um trecho de c odigo escrito em linguagem de alto n vel e um poss vel resultado de compila c ao. Os compiladores podem gerar c odigo de duas maneiras b asicas, isto e, empregando dois modos de endere camento: o absoluto e o reloc avel. Quando no modo de endere camento absoluto, o compilador imagina que o programa ser a sempre executado numa u nica e bem determinada regi ao de mem oria. Sendo assim, durante a compila c ao, o compilador associa diretamente posi c oes de mem oria a estruturas de dados, vari aveis, endere cos de rotinas e fun c oes do programa. Em outras palavras, o compilador xa
104
CAP ITULO 4. GERENCIAMENTO DE MEMORIA trecho de c odigo compilado 0200: . . . LOAD 500 . . . CALL printf . . . JNZ 0200
// trecho de c odigo fonte; while (...) { . . . a = a + 1; . . . printf("%d\n", a); . . . } Exemplo 4.1 Resultado da compila c ao
os endere cos de execu c ao do programa, realizando por completo o binding, tornando-se assim compiladores absolutos.
Figura 4.10: Arquivo objeto gerado atrav es de compila c ao absoluta Na Figura 4.10, onde se apresenta a estrutura interna de arquivos gerados atrav es de compila c ao absoluta, temos os elementos seguintes: Cabe calho Regi ao onde s ao colocadas informa c oes gerais sobre o arquivo objeto e suas partes. Tamb em conhecido como header. C odigo Segmento onde reside o c odigo do programa, propriamente dito. E gerado da mesma forma que na compila c ao absoluta. TSE A tabela de s mbolos externos e o local onde s ao listadas as posi c oes de chamada de s mbolos externos (vari aveis, estruturas ou fun c oes). Os arquivos objeto produzidos tem seus endere cos calculados a partir de um endere co de origem padronizado ou informado antes da compila c ao. Este endere co de origem, a partir do qual os demais s ao denidos, e chamado de endere co base de compila c ao ou apenas de endere co base. Desta maneira a compila c ao se torna mais simples, mas como conseq u encia direta disto temos que:
105
um arquivo de programa execut avel s o pode ser executado numa regi ao xa de mem oria; n ao podem existir duas ou mais inst ancias do mesmo programa execut avel na mem oria, a n ao ser que se realizem compila c oes adicionais for cando a gera c ao do c odigo para uso em diferentes regi oes de mem oria; dois ou mais diferentes programas execut aveis n ao podem ser carregados na mem oria a n ao ser que tenham sido compilados prevendo exatamente a ordem de carregamento e as areas adicionais de mem oria que venham a utilizar; duas ou mais imagens execut aveis n ao podem se sobrepor na mem oria (ocupar os mesmos endere cos de mem oria) total ou parcialmente; uma imagem execut avel deve sempre ocupar uma regi ao cont nua de mem oria; a soma das imagens poss veis de serem carregadas em mem oria para execu c ao paralela tem que ser menor ou igual a quantidade total de mem oria dispon vel. As raz oes para estas limita c oes s ao simples e todas baseadas no fato de que dentro do arquivo objeto s o existem n umeros bin arios. Tais n umeros representam tanto os c odigos das instru c oes do processador como os dados constantes do programa e tamb em os endere cos determinados pelo compilador. Como existem apenas n umeros bin arios em todo o arquivo objeto, n ao e trivial a distin c ao entre instru c oes, dados e endere cos, tornando praticamente imposs vel: reverter a compila c ao, pois o binding se tornou irrevers vel, n ao sendo poss vel reconstituir-se o espa co l ogico que originou o programa; modicar o endere camento do programa pois n ao se pode distinguir que s ao os endere cos dentro dos arquivos objeto gerados pelos compiladores absolutos. Quando no modo de endere camento reloc avel, o compilador continua realizando todas as suas tarefas, como no caso da compila c ao absoluta, xando os endere cos de execu c ao durante a compila c ao, mas al em de gerar o c odigo o compilador reloc avel monta o arquivo objeto da seguinte forma: O u nico elemento novo no arquivo objeto e a TER (tabela de endere cos reloc aveis) onde s ao relacionadas as posi c oes de todos os endere cos existentes dentro do bloco de c odigo cujo valor depende da posi c ao inicial do c odigo, ou seja, lista todos os endere cos relativos existentes.
106
Figura 4.11: Arquivo objeto gerado atrav es de compila c ao reloc avel Desta forma, a TER relaciona onde est ao os endere cos que deveriam ser modicados para permitir a transposi c ao da imagem execut avel de uma regi ao de mem oria para outra, constituindo o segredo dos compiladores reloc aveis, pois e atrav es desta tabela que o binding torna-se revers vel, ou melhor, alter avel, o que corresponde dizer que o binding n ao se realizou por completo. Portanto temos as seguintes implica c oes: ainda n ao e poss vel reverter-se a compila c ao em si pois apesar do binding ser alter avel, ainda e imposs vel reconstituir-se o espa co l ogico original do programa; e poss vel que outra entidade venha a modicar o atual endere camento do programa, pois os endere cos est ao evidenciados na TER, sendo que tal modica c ao possibilita determinar o espa co f sico do programa em fun c ao da disponibilidade de mem oria do sistema. De qualquer forma o uso de compiladores reloc aveis proporcionar a as seguintes situa c oes: um arquivo de programa execut avel poder a ser executado em diversas regi oes de mem oria, a serem determinadas pelo sistema operacional; poder ao existir duas ou mais inst ancias do mesmo programa execut avel na mem oria, sem a necessidade da realiza c ao de compila c oes adicionais para for car a gera c ao do c odigo para uso em diferentes regi oes de mem oria; dois ou mais diferentes programas execut aveis poder ao ser carregados na mem oria sem que seja necess aria a previs ao da ordem exata de carregamento e as areas adicionais de mem oria que venham a ser utilizadas; duas ou mais imagens execut aveis n ao podem se sobrepor na mem oria (ocupar os mesmos endere cos de mem oria) total ou parcialmente;
107
uma imagem execut avel deve sempre ocupar uma regi ao cont nua de mem oria; a soma das imagens poss veis de serem carregadas em mem oria para execu c ao paralela tem que ser menor ou igual a quantidade total de mem oria dispon vel. Vemos que uma parte das limita c oes provocadas pelo uso de compiladores absolutos podem ser contornadas com o uso do modelo de compila c ao reloc avel. Como os ligadores n ao exercem participa c ao no binding no tocante a modica c ao ou naliza c ao do binding, temos que os carregadores s ao os candidatos naturais a naliza c ao do binding no caso da compila c ao reloc avel.
4.5.3
Ligadores (linkers )
Programas capazes de unir parcelas de c odigo, compiladas separadamente, em um u nico arquivo de programa execut avel. Atrav es de s mbolos e posi c oes relacionados em tabelas de s mbolos geradas pelos compiladores, os ligadores s ao capazes de unir trechos de c odigo existentes em diferentes arquivos objeto em um u nico arquivo execut avel. Os s mbolos destas tabelas representam fun c oes ou estruturas de dados que podem, dentro de certas regras, ser denidas e criadas em certos arquivos. Segundo estas mesmas regras, outros arquivos de programa fonte podem utilizar-se destas fun c oes e estruturas sem a necessidade de redeni-las, bastando a indica c ao adequada de sua exist encia no exterior destes arquivos fontes. Assim sendo temos: M odulos exportadores Aqueles onde s ao indicadas fun c oes, estruturas de dados e vari aveis que ser ao utilizadas por m odulos externos. Utilizam varia c oes de cl ausulas extern ou export. // Exporta c~ ao de estruturas e vari aveis em linguagem C // estrutura de dados typedef struct { char FuncName[ID LEN]; int Loc; } FuncType; // vetor de estruturas exportado extern FuncType FuncTable[]; // vari avel inteira exportada extern int CallStack[NUM FUNC]; Exemplo 4.2 Declara c oes de exporta c ao
108
CAP ITULO 4. GERENCIAMENTO DE MEMORIA M odulos importadores Aqueles onde s ao indicadas quais fun c oes, estruturas de dados e vari aveis encontram-se declaradas e implementadas em m odulos externos. Utilizam varia c oes de cl ausulas import ou include.
// Importa c~ ao de m odulos em linguagem C #include <vcl\Forms.hpp> #include <vcl\Classes.hpp> #include <vcl\ Windows.hpp> #include <dos.h> Exemplo 4.3 Declara c oes de importa c ao Cabe ao ligador a tarefa de unir os arquivos que cont em estas deni c oes aos arquivos que as utilizam, gerando disto um u nico arquivo de programa, como ilustrado na Figura 4.12. A liga c ao nunca afeta a maneira com que o binding foi ou ser a realizado, constituindo um elemento neutro dentro da cria c ao dos programas quando analisada sob o aspecto de modelo de endere camento. Os ligadores participam do binding efetuando a uni ao dos espa cos f sicos dos m odulos a serem ligados como o programa execut avel, que determina o espa co f sico denitivo. Os ligadores n ao exercem papel de modica c ao ou naliza c ao do binding, tarefa que ca a cargo das entidades anteriores (os compiladores) ou posteriores (os carregadores e relocadores).
Figura 4.12: Esquema de compila c ao em separado e uso de ligador A compila c ao em separado, com a conseq uente uni ao posterior dos m odulos produzidos atrav es de um ligador, tem os seguintes objetivos: 1. Reduzir o tempo de desenvolvimento diminuindo os tempos consumidos durante a compila c ao atrav es da parti c ao do programa fonte em
109
peda cos (logicamente divididos e encadeados). Pode-se a partir desta divis ao concentrar-se o trabalho em uma das partes de cada vez, que por ser menor toma um menor tempo de compila c ao. Quando se considera o resultado nal, as diversas compila c oes intermedi arias durante o desenvolvimento totalizam um menor tempo quando feita por partes do que quando o programa era manuseado por inteiro. 2. Permitir a divis ao do trabalho dado que o programa pode ser dividido em partes. Seguindo o mesmo princ pio que o da redu c ao do tempo de desenvolvimento, as diversas partes podem ser implementadas paralelamente por equipes de 2 ou mais programadores. Assim os totais gastos s ao os mesmos quando se consideram a soma dos tempos gastos por cada elemento da equipe ou o custo de tal trabalho, mas tem-se a indiscut vel vantagem de que o desenvolvimento pode ser realizado num prazo bastante inferior dado que as partes podem ser desenvolvidas em paralelo. Tal divis ao requer cuidadoso projeto e especica c ao detalhada e consistente das partes do programa. 3. Permitir a padroniza c ao de c odigo e a constru c ao de bibliotecas de fun c oes e estruturas de dados. Dado que e poss vel a compila c ao de uma parte de um programa contendo apenas fun c oes (de uso geral ou espec co) e estruturas de dados associadas, pode-se com isto distribuir-se esta fun c oes e estruturas sob a forma compilada, ou seja um m odulo objeto. Outros programadores poder ao utilizar este m odulo em seus programas, mas n ao poder ao alter a-lo, da obt em-se a padroniza c ao segura de fun c oes e estruturas de dados. Para que isto seja poss vel basta seguir as regras de compila c ao por partes e acompanhar o m odulo objeto de uma descri c ao das suas fun c oes (par ametros de entrada, resultados retornados) criando-se assim bibliotecas. 4. Permitir o uso de diferentes linguagens de programa c ao dentro de um mesmo programa. Considerando a capacidade limitada dos Ligadores em interpretar as tabelas de s mbolos geradas pelos compiladores, se v arios compiladores, mesmo que de diferentes linguagens de programa c ao, s ao capazes de gerar um formato compat vel de informa c ao simb olica, ent ao um ligador apropriado ser a capaz de unir estes diferentes m odulos num u nico arquivo de programa execut avel, mesmo que os m odulos tenham sido escrito em diferentes linguagens. Na verdade, durante a implementa c ao destes m odulos, devem ser observadas as conven c oes de chamada para rotinas externas escritas em outras linguagens espec cas para cada linguagem. Com isto podem ser aproveitadas bibliotecas escritas numa certa linguagem (as bibliotecas matem aticas do FORTRAN, por exemplo) em programas escritos em outras linguagens (C ou PASCAL). Atrav es destas t ecnicas, podem ser melhor exploradas certas carater sticas das linguagens em programas
110
CAP ITULO 4. GERENCIAMENTO DE MEMORIA envolvendo v arias linguagens (C e Clipper, C e DBase, C e SQL, C e PASCAL , VisualBasic e C, etc).
4.5.4
Carregadores (loaders )
Os carregadores s ao os programas respons aveis pelo transporte dos arquivos de programa execut aveis das estruturas de armazenamento secund ario (unidades de disco ou ta) para a mem oria principal. Os carregadores tem suas a c oes dirigidas pelo sistema operacional, que determina qual m odulo execut avel deve ser carregado e em que regi ao de mem oria isto deve ocorrer (endere co base de execu c ao). Ap os o t ermino do processo de carregamento, o carregador sinaliza ao sistema operacional que o programa foi carregado, neste ponto o sistema operacional determinar a quando se iniciar a a execu c ao do programa, que se transforma em uma imagem execut avel ao iniciar sua execu c ao efetivamente. Quando o arquivo objeto foi gerado em modo absoluto, os carregadores apropriados para esta situa c ao apenas realizam uma c opia do arquivo de programa execut avel, transferindo dados do dispositivo de armazenamento secund ario (unidades de disco ou ta) para a mem oria principal. Nesta situa c ao, tais carregadores s ao chamados de carregadores absolutos e recebem do sistema operacional apenas as informa c oes do nome do arquivo execut avel a ser carregado e o endere co de carga (endere co a partir de onde se iniciar a a c opia do c odigo na mem oria principal). Se o endere co de carga for o mesmo que o endere co base da compila c ao, a imagem resultante ser a executada sem problemas, de acordo com o que foi programado no fonte. Caso contr ario as conseq u encias s ao imprevis veis, resultando geralmente na interrup c ao abrupta do programa pelo sistema operacional, na invas ao da area de dados/c odigo de outros programas, no c alculo impr oprio dos resultados ou na perda de controle do sistema. Quando temos que o arquivo objeto foi gerado em modo reloc avel, devem ser utilizados carregadores reloc aveis, ou seja, carregadores capazes de interpretar o conte udo da TER (tabela de endere cos reloc aveis) de forma a transpor a imagem execut avel da area original (iniciada/denida pelo endere co base de compila c ao) para uma outra area de mem oria. A transposi c ao da area de mem oria se baseia no fato de que durante a transfer encia do programa execut avel para a mem oria principal o carregador reloc avel, atrav es da TER identica quem s ao os endere cos componente do c odigo. Cada vez que o carregador reloc avel l e um endere co dentro do c odigo, ele soma ao endere co lido (endere co original da compila c ao) o valor do endere co de carga fornecido pelo sistema operacional e com isto se realiza o modica c ao do binding (iniciado pelo compilador reloc avel) nalizandose o mapeamento com a transposi c ao da imagem para uma nova regi ao de mem oria, determinada pelo sistema operacional e n ao pelo compilador.
111
Endnovo = Endoriginal + (Endbasecompilacao Endbasecarregamento )
(4.3)
A TSE (tabela de s mbolos externos) e lida pelo sistema operacional para que os m odulos externos necess arios ao programa sejam carregados previamente. Caso tais m odulos sejam usados globalmente, isto e, compartilhados por v arios programas (como as DLLs dos sistemas MS-Windows 95/98), o sistema operacional s o realiza o carregamento quando tais m odulos n ao est ao presentes na mem oria. Finalmente devemos observar que tanto o cabe calho existente no arquivo de programa execut avel como a TSE n ao s ao transferidas para mem oria principal. No entanto a area ocupada pelo programa n ao corresponde apenas ao segmento de c odigo contido no arquivo execut avel, sendo substancialmente maior, como ilustrado na Figura 4.13
Figura 4.13: Estrutura t pica de imagem execut avel Tal expans ao do c odigo ocorre devido as necessidades dos programas de possuirem uma area adicional de mem oria para armazenamento da pilha dos endere cos de retorno (stack ) e outra area extra para armazenamento de conte udo din amico do programa (heap ), tais como vari aveis locais e blocos de mem oria alocados din amicamente. Por essa raz ao, ap os a transfer encia do c odigo do armazenamento secund ario para mem oria, chamamos tal conte udo de mem oria de imagem execut avel ou simplesmente imagem.
4.5.5
Relocadores (swappers )
Os relocadores s ao rotinas especiais do sistema operacional respons aveis pela movimenta c ao do conte udo de certas areas de mem oria prim aria para mem oria secund aria (especicamente dispositivos de armazenamento como unidades de disco) e vice-versa, como ilustrado na Figura 4.14. A exist encia de relocadores num sistema depende do tipo de gerenciamento de mem oria oferecido pelo sistema operacional. Antes de vericarmos quais modelos
112
de gerenciamento de mem oria podem fazer uso dos relocadores, devemos compreender melhor a natureza de seu trabalho.
Figura 4.14: Conceito de reloca c ao Considerando que num sistema multiprogramado existem v arios processos ativos (em estado ready ), bloqueados (em estado blocked ) e suspensos (em estado suspended ), sabemos que apenas um processo est a efetivamente em execu c ao, isto e, utilizando o processador (estado running ), ent ao, a medida de suas necessidades, este processo em execu c ao poder a solicitar areas adicionais de mem oria. Estes pedidos de aloca c ao de mem oria podem ser atendidos de duas formas: areas efetivamente livres s ao cedidas ao processo ou aciona-se o relocador para libera c ao de areas de mem oria pertencentes aos demais processos ativos e inativos atrav es da remo c ao de seu conte udo para os arquivos de troca, no que se denomina opera c ao de troca ou swapping. Seguindo instru c oes do sistema operacional, que det em o gerenciamento da mem oria e dos processos, um relocador pode ser comandado para retirar o conte udo de uma area de mem oria armazenado-a em disco. O espa co em mem oria disponibilizado atrav es desta opera c ao e pode ser usado para atender pedidos de aloca c ao de mem oria do processo correntemente em execu c ao. Com isto, partes de alguns processos ser ao transferidas para o disco. Quando estes processos, cuja algumas de suas partes est ao armazenadas no disco, necessitarem de tais conte udos, uma nova opera c ao de reloca c ao pode ser efetuada para, novamente disponibilizar espa co, de modo que este seja agora usado para que o conte udo das partes anteriormente copiadas em disco, seja recolocada na mem oria. Todas estas opera c oes ocorrem sob orienta c ao do sistema operacional. O que geralmente ocorre e que o relocador realiza uma c opia das area de mem oria movimentadas para o disco em um arquivo especial denominado arquivo de troca ou swap le. Ao copiar tais areas de mem oria para o disco, estas s ao assinaladas como livres, tornando-se dispon veis para outros processos. Tamb em se efetua um registro do que foi copiado para mem oria possibilitando recuperar este conte udo quando necess ario. Nesta situa c ao, se avaliarmos a soma total de mem oria utilizada por todos os processos ativos, isto e, processos nos estados de running e tamb em
4.6. MEMORIA VIRTUAL
113
em ready, temos que a quantidade de mem oria utilizada por eles pode ser signicativamente maior do que a mem oria f sica instalada no sistema, pois alguns destes processos tiveram suas area de mem oria transferidas para a unidade de disco quando n ao estavam em execu c ao. Este e o princ pio b asico que possibilita a implementa c ao de mem oria virtual como ser a tratado a seguir (se c ao 4.6).
4.6
Mem oria virtual
O conceito de reloca c ao de mem oria possibilitou o desenvolvimento de um mecanismo mais sosticado de utiliza c ao de mem oria que se denominou mem oria virtual ou virtual memory. Segundo Deitel: O termo mem oria virtual e normalmente associado com a habilidade de um sistema endere car muito mais mem oria do que a sicamente dispon vel [DEI92, p. 215]. Este conceito e antigo: surgiu em 1960 no computador Atlas, constru do pela Universidade de Manchester (Inglaterra), embora sua utiliza c ao mais ampla s o tenha acontecido muitos anos depois. Tanenbaum simplica a deni c ao do termo: A id eia b asica da mem oria virtual e que o tamanho combinado do programa, dados e pilha podem exceder a quantidade de mem oria f sica dispon vel para o mesmo [TAN92, p. 89]. Outra deni c ao poss vel de mem oria virtual e a quantidade de mem oria excedente a mem oria f sica instalada em um sistema computacional que esta aparentemente em uso quando se consideram a soma das quantidades totais de mem oria utilizadas por todos os processos existentes num dado momento dentro deste sistema. Na Figura 4.15 temos uma representa c ao da mem oria real e virtual.
Figura 4.15: Representa c ao da mem oria real e virtual Por sua vez, Silberschatz e Galvin prop oem as seguintes deni c oes:
114
CAP ITULO 4. GERENCIAMENTO DE MEMORIA Mem oria Virtual e uma t ecnica que permite a execu c ao de processos que podem n ao estar completamente na mem oria [SG94, p. 301]. Mem oria Virtual e a separa c ao da mem oria l ogica vista pelo usu ario da mem oria f sica [SG94, p. 302].
De qualquer forma, o termo mem oria virtual indica que o sistema computacional possui a capacidade de oferecer mais mem oria do que a sicamente instalada, ou seja, e capaz de disponibilizar uma quantidade aparente de mem oria maior do que a mem oria de fato (real) existente do sistema. Os maiores benef cios obtidos atrav es da utiliza c ao de sistemas que empregam mecanismos de mem oria virtual s ao: Percep c ao por parte de programadores e usu arios de que a quantidade de mem oria potencialmente dispon vel e maior do que a realmente existente no sistema. Abstra c ao de que a mem oria e um vetor unidimensional, cont nuo, dotado de endere camento linear iniciado na posi c ao zero. Maior eci encia do sistema devido ` a presen ca de um n umero maior de processos, permitindo uso equilibrado e sustentado dos recursos dispon veis. A mem oria f sica tem seu tamanho usualmente limitado pela arquitetura do processador ou do sistema, ou seja, possui um tamanho m aximo que e xo e conhecido. J a a mem oria virtual tem seu tamanho limitado, freq uentemente, pela quantidade de espa co livre existente nas unidade de disco do sistema possuindo, portanto, um valor vari avel e mais ex vel (pois e mais f acil acrescentar novas unidades de disco a um sistema ou substituir as unidades do sistema por outras de maior capacidade). Do ponto de vista de velocidade, a velocidade de acesso da mem oria f sica e substancialmente maior do que da mem oria virtual, mas a velocidade da mem oria total do sistema tende a ser uma m edia ponderada das velocidades de acesso da mem oria f sica e virtual cujos pesos s ao as quantidades envolvidas. De qualquer modo, a velocidade m edia de acesso a mem oria do sistema torna-se uma valor intermedi ario entre as velocidades de acesso da mem oria f sica e virtual sendo que quanto maior a quantidade de mem oria virtual utilizada menor ser a a velocidade m edia de acesso a mem oria. V elM emF isica > V elM emT otal > V elM emV irtual A mem oria virtual pode ser implementada basicamente atrav es de mecanismos de: Pagina c ao T ecnica em que o espa co de endere camento virtual e dividido em blocos, denominados unidades de aloca c ao, de tamanho e posi c ao xas,
115
geralmente de pequeno tamanho, os quais se associa um n umero. O sistema operacional efetua um mapeamento das unidades de aloca c ao em endere cos de mem oria, determinando tamb em quais est ao presentes na mem oria f sica e quais est ao nos arquivos de troca. Segmenta c ao T ecnica em que o espa co de endere camento virtual e dividido em blocos de tamanho xo ou vari avel, denidos por um in cio e um tamanho, cuja posi c ao tamb em pode ser xa ou vari avel, mas identicados univocamente. O sistema operacional mapeia estes blocos em endere cos de mem oria, efetuando um controle de quais blocos est ao presentes na mem oria f sica e quais est ao nos arquivos de troca. Atualmente, os mecanismos mais populares de implementa c ao de mem oria virtual s ao atrav es da pagina c ao. A segmenta c ao e um alternativa menos utilizada, embora mais adequada do ponto de vista de programa c ao, de forma que em alguns poucos sistemas se usam ambas as t ecnicas.
Figura 4.16: MMU e Reloca c ao din amica Estas duas t ecnicas s o podem ser implementadas se for poss vel a desassocia c ao dos endere cos referenciados pelos processos em execu c ao dos efetivamente utilizados na mem oria f sica do sistema. Isto eq uivale a dizer que o binding deve se completar no momento da execu c ao de cada instru c ao, permitindo adiar at eou ltimo momento o mapeamento do espa co l ogico de um programa em seu espa co f sico denitivo de execu c ao, isto e o que chamamos de reloca c ao din amica. Para isto o processador deve dispor de mecanismos de deslocamento dos endere cos referenciados pelo programa para as regi oes de mem oria que efetivamente ser ao usadas. E obvio que tal tarefa s o pode ser completada com um sosticado mecanismo de endere camento de mem oria, mantido pelo sistema operacional. Tais mecanismos s ao geralmente imple-
116
mentados como uma unidade de gerenciamento de mem oria ou memory management unit (MMU) esquematizada na Figura 53. Al em dos mecanismos de pagina c ao ou segmenta c ao, a mem oria virtual exige a disponibiliza c ao de espa co nos dispositivos de armazenamento secund ario para a cria c ao de um (ou mais) arquivos de troca, os swap les. Em fun c ao da velocidade dos dispositivos de E/S, as unidades de disco s ao quase sempre utilizadas, minimizando o impacto das transfer encias entre mem oria prim aria (mem oria f sica do sistema) e mem oria secund aria (unidades de disco). A mem oria total de um sistema e, portanto, a soma de sua mem oria f sica (de tamanho xo) com a mem oria virtual do sistema. O tamanho da mem oria virtual do sistema e denida por, basicamente, o menor valor dentre os seguintes: capacidade de endere camento do processador, capacidade de administra c ao de endere cos do sistema operacional e capacidade de armazenamento dos dispositivos de armazenamento secund ario (unidades de disco). Nos sistemas Win32 (Windows 95/98 e Windows NT) s ao oferecidas fun c oes espec cas para o gerenciamento de mem oria virtual. Suas API (Application Program Interface ) oferecem, dentre outras, as importantes fun c oes relacionadas na Tabela 4.3 [CAL96, p. 252-262]. Tabela 4.3: Fun c oes de gerenciamento de mem oria virtual da API Win32 Fun c ao Utiliza c ao VirtualAlloc Permite reservar ou alocar mem oria para um programa. VirtualFree Libera mem oria alocada ou reservada atrav es de VirtualAlloc. GetProcessHeap Obt em um handler para o heap atual. CreateHeap Cria um novo heap. HeapAlloc Efetua uma aloca c ao parcial no heap. HeapReAlloc Modica o tamanho de uma aloca c ao parcial do heap. HeapSize Retorna o tamanho corrente do heap. HeapFree Libera uma aloca c ao parcial do heap. HeapDestroy Destroy a area de heap. GlobalMemoryStatus Retorna informa c oes sobre utiliza c ao da mem oria do sistema. Atrav es destas fun c oes o usu ario pode administrar o uso da mem oria virtual do sistema, determinando a utiliza c ao da mem oria f sica, tamanho
117
e utiliza c ao do arquivo de troca, tamanho do heap etc. Al em disso pode efetuar a aloca c ao de novas areas de mem oria para sua aplica c ao, o que permite a cria c ao de um mecanismo particular de utiliza c ao e controle do espa co de endere camento virtual que opera de forma transparente com rela c ao aos mecanismos de mem oria virtual implementados pelo sistema operacional. Nos Exemplos 4.4 e 4.5 temos exemplos de utiliza c ao de algumas destas fun c oes. O Exemplo 4.4 utiliza a fun c ao da API GlobalMemoryStatus para determinar o tamanho da mem oria f sica instalada, a quantidade de mem oria f sica dispon vel, o tamanho do arquivo de troca e sua utiliza c ao. { Para Borland Delphi 2.0 ou superior. procedure TForm1.UpdateMemStatus; var Status: TMemoryStatus; function ToKb(Value: DWORD): DWORD; begin result := Value div 1024; end; }
begin { Obt^ em status da mem oria } Status.dwLength := sizeof(TMemoryStatus); GlobalMemoryStatus(Status); with Status do { Atualiza labels e gauges } begin Label1.Caption:=IntToStr(ToKb(dwTotalPhys))+ Kb; Label2.Caption:=IntToStr(ToKb(dwTotalPhys dwAvailPhys))+ Kb; Label3.Caption:=IntToStr(ToKb(dwTotalPageFile))+ Kb; Label4.Caption:=IntToStr(ToKb(dwTotalPageFile dwAvailPageFile))+ Kb; Gauge1.MaxValue:=dwTotalPhys; Gauge1.Progress:=dwTotalPhys - dwAvailPhys; Gauge2.MaxValue:=dwTotalPageFile; Gauge2.Progress:=dwTotalPageFile - dwAvailPageFile; end; end; Exemplo 4.4 Uso de GlobalMemoryStatus J a no Exemplos 4.5 que aloca um bloco de mem oria de tamanho Size, permitindo seu uso atrav es de um ponteiro para a area alocada, efetuando sua libera c ao ap os o uso. A rotina possui um tratamento m nimo de erros.
118
{ Para Borland Delphi 2.0 ou superior. } P := VirtualAlloc(nil, Size, memCommit or mem Reserve, Page ReadWrite); if P = nil then ShowMessage("Aloca c~ ao n~ ao foi poss vel") else begin { Uso da area alocada atrav es do ponteiro P. } . . . { Libera c~ ao da a rea alocada ap os uso. } if not VirtualFree(P, 0, mem Release) then ShowMessage("Erro liberando mem oria."); end; Exemplo 4.5 Aloca c ao de bloco de mem oria com VirtualAlloc
4.7
Modelos de gerenciamento de mem oria
Como ilustrado na Figura 44, existem v arios diferentes modelos para a organiza c ao e o gerenciamento de mem oria os quais trataremos brevemente: Monoprogramado com armazenamento real Multiprogramado com parti c oes xas sem armazenamento virtual Multiprogramado com parti c oes vari aveis sem armazenamento virtual Multiprogramado com armazenamento virtual atrav es de pagina c ao Multiprogramado com armazenamento virtual atrav es de segmenta c ao Multiprogramado com armazenamento virtual atrav es de pagina c ao e segmenta c ao combinadas
4.7.1
Monoprogramado com armazenamento real
Neste modelo de gerenciamento a mem oria e dividida em duas parti c oes distintas, de tamanhos diferentes, onde uma e utilizada pelo sistema operacional e a outra e utilizada pelo processo do usu ario conforme ilustrado na Figura 4.17. Este modelo, tamb em chamado de modelo de aloca c ao cont nua, armazenamento direto ou monoprogramado com armazenamento real, era a forma mais comum de gerenciamento de mem oria at e meados da d ecada de 1960. Tamb em era a t ecnica mais comum usada pelos sistemas operacionais das primeiras gera c oes de microcomputadores.
4.7. MODELOS DE GERENCIAMENTO DE MEMORIA
119
Figura 4.17: Organiza c ao da mem oria em modo monoprogramado real Esta forma de gerenciamento de mem oria e bastante simples e permite que apenas um processo seja executado de cada vez, o que limita a programa c ao a constru c ao de programas estritamente seq uenciais. Na pr atica este esquema de gerenciamento s o est a preparado para a execu c ao de um programa de cada vez, sendo que raramente a mem oria ser a inteiramente utilizada, sendo freq uente a exist encia de uma area livre ao nal da area de programa destinada ao usu ario. Dado que o espa co de endere camento corresponde a quantidade de mem oria prim aria sicamente instalada no sistema, que n ao s ao utilizados mecanismos de mem oria virtual e que usualmente apenas um processo (programa) era executado de cada vez, este modelo de organiza c ao tamb em e conhecido como organiza c ao monoprogramada real. Como exemplo o PC-DOS/MS-DOS (Disk Operating System ), sistema operacionais dos microcomputadores IBM e seus compat veis, utiliza um esquema semelhante, onde o sistema operacional cava residente na primeira parte da mem oria e a area de programa destinada aos usu arios utilizava o espa co restante dos 640 Kbytes de espa co de endere camento dispon veis. O CP/M (Control Program/Monitor ), dos microcomputadores Apple e compat veis utilizava esquema semelhante. No caso do DOS, v arios outros esquemas adicionais forma criados para estender as capacidades b asicas (e bastante limitadas) de endere camento do sistema operacional, entre elas os mecanismos de extens ao de mem oria e os overlays. Os overlays (do termo recobrimento), s ao o resultado da estrutura c ao dos procedimentos de um programa em forma de arvore, onde no topo est ao os procedimentos mais usados e nos extremos os menos utilizados. Esta estrutura c ao deve ser feita pelo usu ario, satisfazendo as restri c oes do programa a ser desenvolvido e da mem oria dispon vel no sistema. Uma biblioteca de controle dos overlays, que funcionava como um sistema de gerenciamento de mem oria virtual, deve ser adicionada ao programa e mantida na mem oria todo o tempo, procura manter apenas os procedimentos de uma se c ao vertical da arvore, minimizando a quantidade necess aria de mem oria f sica e
120
assim superando as limita c oes do DOS [GUI86, p. 184].
4.7.2
Particionamento xo
Dada as vantagens dos sistemas multiprogramados sobre os monoprogramados, e necess ario que a mem oria seja dividida de forma tal a possibilitar a presen ca de v arios processos simultaneamente. A maneira mais simples de realizar-se esta tarefa e efetuar a divis ao da mem oria prim aria do sistema em grandes blocos os quais s ao denominados parti c oes. As parti c oes, embora de tamanho xo, n ao s ao necessariamente iguais, possibilitando diferentes congura c oes para sua utiliza c ao, como ilustrado na Figura 4.18.
Figura 4.18: Organiza c ao da mem oria em modo multiprogramado com parti c oes xas Enquanto o sistema operacional utiliza permanentemente uma destas parti c oes, usualmente a primeira ou a u ltima, os processos dos usu arios podem ocupar as demais parti c oes, cujo n umero depender a do tamanho total da mem oria do sistema e dos tamanhos das parti c oes realizadas. Geralmente as parti c oes eram determinadas atrav es da congura c ao do sistema operacional, o que poderia ser feito de tempos em tempos ou at e mesmo diariamente pelo operador do sistema. At e uma nova deni c ao dos tamanhos das parti c oes, os tamanhos e posi c oes anteriormente denidos eram xos. Os processos poder ao ent ao ocupar as parti c oes de mem oria a partir de uma la u nica de processos que encaminhar a o processo para a parti c ao dispon vel. Tanto o modelo de endere camento absoluto como reloc avel podem ser utilizados pois: Nos sistemas batch os programas eram compilados no instante da execu c ao possibilitando o uso de compiladores absolutos, dado que
121
a posi c ao que o programa utilizaria na mem oria (parti c ao) era conhecida; Se utilizado compiladores reloc aveis, um carregador reloc avel poderia transpor o c odigo corretamente para a parti c ao escolhida. Quando do uso de parti c oes iguais, uma u nica la de processos poderia atender a contento a tarefa de denir qual processo ocuparia uma certa parti c ao, embora ocorresse perda signicativa de mem oria pela n ao utiliza c ao integral das parti c oes. O uso de parti c oes xas de diferentes tamanhos permitia fazer melhor uso da mem oria, pois nesta situa c ao poderiam ser utilizadas las diferentes de processos para cada parti c ao, baseadas no tamanho do processo/parti c ao. Ainda assim poder amos ter uma situa c ao de parti c oes livres e uma, em especial, com uma la de processos. A melhor solu c ao encontrada foi adotar uma u nica la de processos e crit erios de elegibilidade para designa c ao de parti c oes para processos visando bom uso da mem oria e um throughput adequado. Torna-se evidente que a determina c ao da parti c ao para a execu c ao de um dado processo inuencia no desempenho do sistema. Para esta tarefa podemos utilizar um dos seguintes crit erios, que correspondem a estrat egias de posicionamento (placement strategies ): First t : Aloca-se o processo para a primeira parti c ao encontrada que comporte o processo, minimizando o trabalho de procura. Best t : O processo e alocado para a menor parti c ao que o comporte, produzindo o menor desperd cio de areas de mem oria, exige pesquisa em todas as parti c oes livres. Worst t : O processo e alocado para a maior parti c ao que o comporte, produzindo o maior desperd cio de areas de mem oria, exige pesquisa em todas as parti c oes livres. Langsam et al. [LAT96, p. 625] sugerem alguns algoritmos em linguagem C para a aloca c ao de blocos de mem oria utilizando o rst t e best t, bem como para sele c ao da melhor parti c ao a ser liberada. De qualquer forma, o espa co de endere camento corresponde ao tamanho da mem oria prim aria do sistema, ou seja, a somat oria dos tamanhos das parti c oes e, portanto, do tamanho m aximo dos processos em execu c ao, e igual a mem oria f sica instalada no sistema. Assim, o particionamento xo e um esquema de organiza c ao de mem oria que n ao utiliza mem oria virtual. V arios sistemas comerciais de grande porte utilizavam este esquema de gerenciamento de mem oria, onde o operador ou o administrador do sistema denia o n umero e o tamanho das parti c oes da mem oria principal.
122
4.7.3
Particionamento vari avel
O particionamento vari avel e bastante semelhante ` a organiza c ao de mem oria em parti c oes xas, exceto pelo fato de que agora e o sistema operacional efetua o particionamento da mem oria. A cada novo processo, a mem oria e dividida, de forma que parti c oes de diferentes tamanhos sejam posicionadas na mem oria do sistema. A medida que os processos sejam nalizados, suas parti c oes tornam-se livres, podendo ser ocupadas no todo ou em parte por novos processos como esquematizado na Figura 4.19. Este esquema de organiza c ao de mem oria tamb em e denominado de particionamento por demanda.
Figura 4.19: Organiza c ao da mem oria em modo multiprogramado com parti c oes vari aveis Neste tipo de sistema, a estrat egia de posicionamento worst t e bastante u til pois permite maximizar o tamanho das area livres (buracos) obtidas a cada aloca c ao, aumentando as possibilidade de sucesso de transforma c ao da area desocupada em uma nova parti c ao livre para um novo processo. Mesmo utilizando-se o algoritmo worst t ainda e poss vel que existam regi oes livres de mem oria entre as parti c oes efetivamente alocadas. Este fen omeno, que tende a aumentar conforme a utiliza c ao do sistema e n umero de processos presentes na mem oria, e denominado fragmenta c ao interna. Desta forma, uma certa por c ao da mem oria total do sistema pode continuar permanecendo sem uso, anulando alguns dos benef cios do particionamento vari avel e do algoritmo worst t. Um estrat egia poss vel para eliminar a fragmenta c ao interna e a da compacta c ao de mem oria, onde todas as parti c oes ocupadas s ao deslocadas em dire c ao ao in cio da mem oria, de forma que todas as pequenas areas livres componham uma u nica area livre maior no nal da mem oria, como indicado na Figura 4.20. A compacta c ao de mem oria e uma t ecnica raramente utilizada devido ao alto consumo de processador para o deslocamento de todas as parti c oes e
123
manuten c ao das estruturas de controle da mem oria. O trabalho despendido no reposicionamento de uma parti c ao pode ser suciente para nalizar o processo que a ocupa ou outro presente na mem oria, tornando a movimenta c ao de parti c oes um onus para os processos em execu c ao.
Figura 4.20: Compacta c ao de mem oria Da mesma forma que na organiza c ao da mem oria atrav es de parti c oes xas, no particionamento vari avel o espa co de endere camento e igual ao tamanho da mem oria prim aria existente no sistema e, portanto, um esquema de organiza c ao de mem oria que tamb em n ao utiliza mem oria virtual.
4.7.4
Pagina c ao
A pagina c ao e um esquema de organiza c ao de mem oria que faz uso da mem oria virtual, ou seja, o espa co de endere camento e maior que o tamanho da mem oria sicamente presente no sistema, como representado na Figura 4.21. O espa co de endere camento total do sistema, denominado de espa co de endere camento virtual e dividido em pequenos blocos de igual tamanho chamados p aginas virtuais (virtual pages ) ou apenas p aginas (pages ). Cada p agina e identicada por um n umero pr oprio. Da mesma forma a mem oria f sica e dividida em blocos iguais, do mesmo tamanho das p aginas, denominados molduras de p aginas (page frames ). Cada moldura de p agina tamb em e identicada por um n umero, sendo que para cada uma destas molduras de p agina corresponde uma certa regi ao da mem oria f sica do sistema, como mostra a Figura 4.22. Para que este esquema de divis ao seja u til, o sistema operacional deve realizar um mapeamento de forma a identicar quais p aginas est ao presentes na mem oria f sica, isto e, deve determinar quais os page frames que est ao ocupados e quais p aginas virtuais (virtual pages ) est ao nele armazenados. O sistema operacional tamb em deve controlar quais p aginas virtuais est ao localizadas nos arquivos de troca (swap les ), que em conjunto com a mem oria f sica do sistema representam a mem oria virtual do sistema (vide
124
Figura 4.21: Espa cos de endere camento virtual e real na pagina c ao
Figura 4.15). A medida que os programas v ao sendo executados, o sistema operacional vai relacionando quais p aginas virtuais est ao sendo alocadas para cada um destes programas, sem se preocupar com o posicionamento cont guo de partes de um mesmo programa. No instante efetivo da execu c ao a MMU (memory management unit ) converte os endere cos virtuais em endere cos f sicos utilizando as tabelas de p aginas, como esquematizado na Figura 61. Neste mesmo momento a MMU detecta se uma dada p agina est a ou n ao presente na mem oria f sica, realizando uma opera c ao de page fault (falta de p agina) caso n ao esteja presente. Quando ocorre um page fault e acionada uma rotina do sistema operacional que busca na mem oria virtual (nos arquivos de troca) a p agina necess aria, trazendo-a para a mem oria f sica. Esta opera c ao e particularmente complexa quando j a n ao existe espa co livre na mem oria f sica, sendo necess aria a utiliza c ao de um algoritmo de troca de p aginas para proceder-se a substitui c ao de p aginas. Os page faults s ao um decorr encia da exist encia de um mecanismo de mem oria virtual e embora sejam opera c oes relativamente lentas quando com coparadas ao processamento, propiciam grande exibilidade ao sistema. E mum a implementa c ao de mecanismos de contabiliza c ao dos page faults em sistemas de maior porte, onde pode existir at e mesmo um limite, congurado pelo administrador do sistema, para a ocorr encia de troca de p aginas. A convers ao de endere cos por parte da MMU e necess aria porque cada programa imagina possuir um espa co de endere camento linear originado no zero quando na verdade compartilha blocos isolados da mem oria f sica com
125
Figura 4.22: Endere camento Virtual e Real na Pagina c ao
outros programas que tamb em est ao em execu c ao. Outra implica c ao deste mecanismo e que os blocos sicamente ocupados na mem oria principal n ao necessitam estar continuamente nem ordenadamente posicionados. Isto permite tanto a execu c ao de um processo com apenas uma de suas p aginas presente na mem oria f sica, como a execu c ao de um processo cujo tamanho total e maior que o armazenamento prim ario do sistema. Sendo assim, a pagina c ao e um esquema extremamente ex vel. O mapeamento das p aginas virtuais nos efetivos endere cos de mem oria e realizado pela MMU com o aux lio de tabelas de p aginas, que determinam a rela c ao entre as p aginas do espa co de endere camento virtual e as molduras de p aginas do espa co de endere camento f sico, ou seja, oferendo suporte para as opera c oes de convers ao de endere cos necess arias ao uso deste esquema de organiza c ao de mem oria. Num sistema de pagina c ao pura, os endere cos virtuais (veja a Figura 4.23 s ao denominados v, tomando a forma de pares ordenados (p, d), onde p representa o n umero da p agina virtual e d a posi c ao desejada, ou seja, o deslocamento (displacement ou oset ) a partir da origem desta p agina.
Figura 4.23: Formato do endere co virtual para sistema de pagina c ao pura
126
J a as posi c oes das molduras de p aginas (page frames ), isto e, seus endere cos iniciais s ao determinados da seguinte forma: como as molduras de p aginas possuem o mesmo tamanho das p aginas virtuais, os endere cos iniciais dos page frames s ao m ultiplos integrais do tamanho das p aginas, n ao podendo ser designadas de outra forma. A Tabela 4.4 exibe a rela c ao entre as molduras de p aginas e seu endere camento na mem oria f sica. Tabela 4.4: Endere camento das N umero do Tamanho do Page Frame Page Frame 0 p 1 p 2 p 3 p 4 p . . . . . . n1 p Molduras de P aginas Endere camento Real das P aginas 0 : p 11 p : 2p 1 2p : 3p 1 3p : 4p 1 4p : 5p 1 . . . (n 1)p : np 1
O funcionamento da MMU, conforme esquematizado na Figura 4.24, pode ser descrito resumidamente nos passos relacionados abaixo: 1. MMU recebe o endere co virtual contido nas instru c oes do programa. 2. O n umero de p agina virtual e usado como ndice na tabela de p aginas. 3. Obt em-se o endere co f sico da moldura de p agina que cont em o endere co virtual solicitado ou ocorre um page fault. 4. MMU comp oe o endere co nal usando o endere co da moldura de p agina e uma parte do endere co virtual (displacement ). Para o funcionamento apropriado da MMU e necess aria a exist encia de tabelas de p aginas, mantidas total ou parcialmente na mem oria prim aria pelo sistema operacional. Cada entrada da tabela de p aginas cont em, geralmente: um bit indicando presen ca ou aus encia da p agina na mem oria principal; o n umero da moldura de p agina (page frame number ); e dependendo da implementa c ao, o endere co da p agina no armazenamento secund ario (swap les ) quando ausente da mem oria principal.
127
Figura 4.24: Convers ao de endere cos pela MMU O mecanismo de convers ao de endere cos depende da organiza c ao das tabelas de p aginas (um, dois ou m ultiplos n veis) e da forma do mapeamento (mapeamento direto, mapeamento associativo e mapeamento combinado associativo/direto). Em fun c ao do tamanho do espa co de endere camento virtual, do tamanho da p agina e do tamanho da mem oria real, os arranjos das tabelas de p aginas podem se tornar grandes e complexos. Diversos estudos e estrat egias j a foram realizados para sugerir organiza c oes mais ecientes para o mapeamento e a convers ao de endere cos. Temos assim que a pagina c ao permite a execu c ao de programas individualmente maiores que a mem oria f sica do sistema ou, no caso mais comum, a execu c ao de diversos programas cuja soma dos seus tamanhos exceda o tamanho da mem oria f sica. Gra cas a MMU, implementada no hardware do processador, as aplica c oes podem ser desenvolvidas imaginando um espa co de endere camento linear, cont nuo e de grande tamanho, simplicando bastante o trabalho de programa c ao. A pagina c ao e o sistema de organiza c ao de mem oria mais utilizado atualmente. Exemplos de sistemas computacionais que utilizam a pagina c ao pura s ao: DEC PDP-11, minicomputador de 16 bits popular da d ecada de 1970, contando com um espa co de endere camento virtual de 16 bits, p aginas de 8 KBytes e at e 4 MBytes de mem oria f sica, utilizando tabelas de p aginas de um u nico n vel [TAN92, p. 97].
128
CAP ITULO 4. GERENCIAMENTO DE MEMORIA DEC VAX (Virtual Addresses eXtensions), sucessor do DEC PDP-11, minicomputador de 32 bits, possuindo um espa co de endere camento virtual de 32 bits e pequenas p aginas de 512 bytes. Os modelos de sua fam lia contavam com no m nimo 2 MBytes de mem oria f sica at e 512 MBytes. As tabelas de p aginas possu am dois n veis [TAN92, p. 98]. IBM OS/2 2.0 (Operating System/2), operando em plataforma Intel 80386 ou 80486, oferecia at e 512 MBytes de espa co l ogico linear por processo num esquema de endere camento de 32 bits, tamanho de p agina de 4 KBytes com pagina c ao por demanda [IBM92b, p. 11]. IBM AS/400, minicomputador de 64 bits que utiliza um esquema de tabela de p aginas invertidas (inverted page table ) [STA96, p. 248]. Microsoft Windows 95, dirigido para processadores 80386 ou superior, oferece espa co de endere camento linear virtual de 2 GBytes (endere cos de 32 bits ), p aginas de 4 KBytes [PET96, p. 293].
4.7.5
Segmenta c ao
Enquanto que a organiza c ao da mem oria atrav es da pagina c ao e um modelo puramente unidimensional, isto e, o espa co de endere camento virtual oferecido a cada um dos diversos processos eu nico e linear, a segmenta c ao prop oe um modelo bidimensional, onde cada processo pode utilizar-se de diversos espa cos de endere camento virtuais independentes. Este conceito foi introduzido nos sistemas Burroughs e Multics [GUI86, p. 137]. Num esquema de mem oria segmentada, o espa co de endere camento virtual e dividido em blocos de tamanho vari avel, onde cada bloco pode assumir tamb em um posicionamento vari avel, isto e, para um dado processo, enquanto cada segmento deve ocupar um espa co de endere camento cont nuo na mem oria f sica, n ao existe necessidade dos diversos segmentos deste processo estarem alocados de forma cont gua ou sequer ordenada. Estes blocos s ao denominados segmentos de mem oria ou simplesmente segmentos, como ilustrado na Figura 4.25. comum que os segmentos possuam um tamanho m E aximo, limitado ao tamanho da mem oria f sica do sistema e um n umero m aximo de segmentos distintos. Cada segmento representa um espa co de endere camento linear independente dos demais segmentos, isto permite que cada segmento possa crescer ou diminuir conforme suas necessidades e livremente de outros segmentos. Uma situa c ao poss vel e comum e a de um processo que possui um segmento de c odigo (o programa em si), um ou mais segmentos de dados e um segmento para sua pilha (stack ), todos com diferentes tamanhos. Dado que um segmento e uma unidade l ogica, o programador deve explicitamente determinar sua utiliza c ao. Embora seja poss vel ter-se c odigo,
129
Figura 4.25: Armazenamento prim ario na segmenta c ao
dados e pilha num u nico segmento, isto representa uma m a utiliza c ao desta estrutura de organiza c ao da mem oria, invalidando seus benef cios. A organiza c ao da mem oria em segmentos favorece e simplica a organiza c ao de estruturas de dados, principalmente as de tamanho vari avel em tempo de execu c ao. Al em disto oferece importantes facilidades do ponto de vista de compartilhamento e prote c ao. Por exemplo, uma biblioteca de fun c oes pode ser colocada num segmento e compartilhada pelas diversas aplica c oes que as necessitem. A cada segmento podem ser associados tipos de acesso que especiquem as opera c oes que podem ser executadas no segmento, tais como leitura (read ), escrita (write ), execu c ao (execute ) e anexa c ao (append ). Tais opera c oes podem ainda ser associadas a modos de acesso espec cos, criando um amplo conjunto de possibilidades u teis para implanta c ao de esquemas de seguran ca [DEI92, p. 233]. Num sistema de segmenta c ao pura, os endere cos virtuais, cuja estrutura se indica na Figura 4.26, s ao denominados v e tomam a forma de pares ordenados (s, d), onde s representa o n umero do segmento e d a posi c ao desejada, ou seja, o deslocamento (displacement ou oset ) a partir da origem deste segmento. Notamos que a forma c ao dos endere cos na segmenta c ao e semelhante a existente na pagina c ao.
Figura 4.26: Formato do endere co virtual para sistema de segmenta c ao
130
Um processo somente pode ser executado se ao menos um de seus segmentos contendo c odigo estiver presente na mem oria f sica. Para isto segmentos devem ser transferidos da mem oria secund aria para a mem oria prim aria da mesma forma que as p aginas no esquema de pagina c ao, ou seja, cada segmento deve ser transferido inteiramente e posicionado numa regi ao cont nua de mem oria. Isto indica que os segment faults s ao opera c oes mais lentas, dado que os segmentos s ao usualmente maiores do que as p aginas, e tamb em menos freq uentes, pois o n umero de segmentos de um processo e tipicamente menor que o n umero de p aginas equivalente. Outro ponto e que deve ser determinada qual regi ao de mem oria permite a coloca c ao do novo segmento, opera c ao que pode ser realizada atrav es de algoritmos que apliquem as estrat egias de posicionamento (placement strategies ). O segmento que deve ser substitu do, em caso de um segment fault, deve ser obtido atrav es de algoritmos que implementem as estrat egias de substitui c ao (replacement strategies ). O mapeamento dos endere cos virtuais em endere cos reais pertencentes aos segmentos corretos se faz de maneira id entica ` a pagina c ao, ou seja, utiliza um esquema de mapeamento e tabelas de mapeamento de segmentos (segment map tables ): 1. MMU recebe o endere co virtual contido nas instru c oes do programa. 2. O n umero de segmento virtual e usado como ndice na tabela de segmentos. 3. Obt em-se o endere co f sico de in cio do segmento ou ocorre um segment fault. 4. MMU comp oe o endere co nal usando o endere co de in cio do segmento e uma parte do endere co virtual (displacement ). O mecanismo de convers ao de endere cos depende da organiza c ao das tabelas de segmentos e da forma do mapeamento (mapeamento direto ou mapeamento associativo). Exemplos de sistemas computacionais que utilizaram a segmenta c ao pura s ao: Burroughs B6700, computador do in cio da d ecada de 60, com arquitetura tipo pilha [GUI86, p.157]. HP 3000, minicomputador tipo pilha cujo espa co l ogico consistia de at e 255 segmentos de c odigo execut avel de 16 KBytes cada e um u nico segmento de dados de 64 KBytes manipulado por hardware [GUI86, p.172].
131
Intel 8086/8088, microprocessador de 8 bits, oferecia um espa co de endere camento l ogico de 1 MByte, podendo efetuar o endere camento f sico de no m aximo 64 KBytes, tamanho m aximo dos segmentos que administrava [BOR92, p. 342]. IBM OS/2 1.x (Operating System/2), voltado para o microprocessador Intel 80286, utilizava segmenta c ao pura, onde o tamanho m aximo dos segmentos era 64 Kbytes, espa co de endere camento virtual de 512 MBytes por aplica c ao e mem oria f sica m axima de 16 MBytes [IBM92b, p. 11][LET89, p. 142]. Microsoft Windows 3.x, tamb em dirigido para o microprocessador Intel 80286, usava segmenta c ao pura, segmentos de no m aximo 64 KBytes, 48MBytes de espa co de endere camento virtual e mem oria f sica m axima de 16 MBytes [IBM92b, p. 14]. Apesar de ser um esquema de organiza c ao de mem oria que oferece uma s erie de vantagens, a segmenta c ao apresenta uma grande desvantagem: conforme os segmentos se tornam grandes, as opera c oes de posicionamento e substitui c ao tendem a se tornar lentas conduzindo o sistema a uma situa c ao de ineci encia. Existe ainda o problema maior de um segmento individual se tornar maior que a mem oria f sica dispon vel no sistema. A solu c ao desta desvantagem se d a na utiliza c ao conjunta dos esquemas de segmenta c ao e pagina c ao, como veremos mais a frente.
4.7.6
Pagina c ao versus Segmenta c ao
Como visto, os esquemas de organiza c ao de mem oria atrav es de pagina c ao e segmenta c ao possuem vantagens e desvantagens. Na Tabela 4.5 temos um quadro comparativo, tal como proposto por Deitel [DEI92, p. 131], onde se avaliam estas formas de organiza c ao do armazenamento prim ario. Podemos notar que a pagina c ao e um esquema de organiza c ao de mem oria mais simples, principalmente para o programador, enquanto que a segmenta c ao, a custo de uma maior complexidade, oferece mecanismos mais sosticados para organiza c ao e compartilhamento de dados ou procedimentos. A raz ao para isto se encontra no porque destes esquemas terem sido inventados. Enquanto a pagina c ao foi desenvolvida para ser um esquema de organiza c ao invis vel ao programador, proporcionando um grande espa co de endere camento linear, maior que a mem oria f sica e de uso simples, o prop osito da segmenta c ao foi permitir que programas e dados pudessem ser logicamente divididos em espa cos de endere camento independentes facilitando o compartilhamento e prote c ao [STA96, p. 249]. Enquanto o grande inconveniente da pagina c ao pura e sua excessiva simplicidade como modelo de programa c ao, a segmenta c ao pura imp oe dicul-
132
Tabela 4.5: Quadro comparativo pagina c ao versus Considera c ao Programador precisa saber que esta t ecnica e utilizada? Quantos espa cos de endere camento linear existem? O espa co de endere camento virtual pode exceder o tamanho da mem oria f sica? Dados e procedimentos podem ser distinguidos? Tabelas cujo tamanho e vari avel podem ser acomodadas facilmente? O compartilhamento de procedimentos ou dados entre usu arios e facilitado?
segmenta c ao Pag. Seg. N ao Sim 1 Sim N ao N ao N ao Muitos Sim Sim Sim Sim
dades no gerenciamento da mem oria virtual, pois a troca de segmentos entre o armazenamento prim ario e secund ario se torna lento para segmentos de grande tamanho, penalizando o desempenho do sistema.
4.7.7
Pagina c ao e segmenta c ao combinadas
De forma que possam ser obtidas as maiores vantagens dos esquemas de pagina c ao e segmenta c ao, desenvolveu-se o uso combinado destas duas t ecnicas em sistemas com esquemas h bridos de gerenciamento de mem oria, mais conhecidos como sistemas multiprogramados com pagina c ao e segmenta c ao combinadas. A pagina c ao proporciona grande espa co de endere camento linear e facilidade para o desenvolvimento embora n ao ofere ca mecanismos mais sosticados de organiza c ao de c odigo e dados bem como de compartilhamento, seguran ca e prote c ao. Por sua vez, a segmenta c ao oferece tais mecanismos de organiza c ao, compartilhamento e prote c ao, mas deixa de ser conveniente quando os segmentos tornam-se grandes al em de impor um modelo de desenvolvimento de software um pouco mais complexo. Combinando-se pagina c ao e segmenta c ao de forma que os segmentos tornem-se paginados, associam-se as vantagens de cada um destes esquemas eliminando suas maiores deci encias as custas de uma organiza c ao um pouco mais complexa mas transparente para o desenvolvedor. Num sistema com pagina c ao/segmenta c ao combinadas, os segmentos devem necessariamente ter tamanho m ultiplo do tamanho das p aginas, n ao mais necessitando ser armazenado inteiramente na mem oria e t ao pouco de forma cont gua e ordenada. Todos os benef cios da segmenta c ao s ao mantidos, ou seja, os programas podem ser divididos em m ultiplos espa cos de endere camento virtuais que, ao serem paginados, n ao necessitam de armazenamento cont nuo na mem oria real. Se desejado, todo programa e dados podem ser concentrados num u nico segmento, fazendo que o resultado sejam
133
semelhante a um sistema paginado puro. Desta forma, num sistema de pagina c ao/segmenta c ao combinadas, os endere cos virtuais, como indicado na Figura 4.27, denominados v, tomam a forma de triplas ordenadas (s, p, d), onde s representa o n umero do segmento, p representa o n umero da p agina virtual e d a posi c ao desejada, ou seja, o deslocamento (displacement ou oset ) a partir da origem da p agina indicada dentro deste segmento.
Figura 4.27: Formato do endere co virtual para sistema de pagina c ao e segmenta c ao combinadas Notamos que o espa co de endere camento virtual oferecido e tridimensional, tornando-se necess ario a exist encia de uma estrutura de controle mais sosticada nestes sistemas. Geralmente o sistema operacional mant em uma tabela de mapa de segmentos por processo, cuja indica c ao gura no PCB (Process Control Block abordado na se c ao 2.4.1), e uma tabela de p aginas para cada segmento individual. Para se resolver um endere co virtual determinando-se o endere co real torna-se necess aria a utiliza c ao de informa c oes em tr es tabelas diferentes. O funcionamento da MMU nestes sistemas, se encontra esquematizado na Figura 4.28 e pode ser descrito, resumidamente, como segue: 1. MMU recebe o endere co virtual contido nas instru c oes do programa. 2. A partir da tabela de controle dos processos (tabela de PCB), e selecionada a tabela de mapa de segmentos pertencente ao processo. 3. O n umero de segmento virtual e usado como ndice na tabela de segmentos obtendo-se o n umero de p agina virtual. utilizada a tabela de p 4. E aginas relativa ao segmento em uso. 5. O n umero de p agina virtual e usado como ndice na tabela de p aginas. 6. Obt em-se o endere co f sico da moldura de p agina que cont em o endere co virtual solicitado ou ocorre um page fault. 7. MMU comp oe o endere co nal usando o endere co da moldura de p agina e uma parte do endere co virtual (displacement ).
134
A manuten c ao desta estrutura complexa requer cuidadoso projeto para que n ao consuma recursos excessivos e processamento signicativo nos sistemas que as utilizam. Exemplos de sistemas computacionais que utilizam a pagina c ao e segmenta c ao combinadas s ao: Honeywell 6000, computadores das d ecadas de 1960 e 1970, operando com sistema operacional MULTICS suportando processos com at e 218 (262.144) segmentos cada um com at e 64 KBytes de tamanho [TAN92, p. 132]. IBM System/360, computador do nal da d ecada de 1960, com espa co l ogico de 16 MBytes divididos em 16 segmentos de 1 MByte [GUI86, p.154]. IBM MVS (Multiple Virtual Storage System ), operando na arquitetura ESA/370, prov e cada processo com at e 2 GBytes de, nos quais poderiam existir 2048 segmentos de 256 p aginas de 4096 bytes [DEI92, p. 677]. Fam lia Intel P6, suportando at e 64 TBytes de endere camento virtual e um m aximo de 4 GBytes de mem oria f sica, oferecendo at e 8192 segmentos de at e 4 GBytes cada um, compostos de p aginas de 4096 bytes [STA96, p. 252].
4.7.8
Tabelas de p aginas
Como visto, tanto a organiza c ao de mem oria atrav es de pagina c ao como de segmenta c ao e os sistemas h bridos que utilizam a pagina c ao combinada com segmenta c ao, s ao implementadas tabelas para realizar a convers ao de endere cos virtuais em endere cos f sicos. Estas tabelas, suportadas diretamente pelo hardware do sistema e mantidas pelo sistema operacional s ao, juntamente com os mecanismos de convers ao de endere cos, o ponto central destes esquemas de organiza c ao de mem oria. A id eia b asica e que o endere co virtual e composto de duas partes, um n umero da p agina virtual e um deslocamento dentro da p agina. O n umero da p agina virtual e usado como ndice numa tabela de p aginas, ou seja, e somado ao endere co de base da tabela de p aginas, mantido num registrador qualquer do processador, obtendo-se uma refer encia para uma entrada da tabela que cont em o endere co real da moldura de p agina desejada. Somandose o deslocamento contido no endere co virtual ao endere co da moldura de p agina obtido da tabela de p aginas obt em-se o endere co real completo. Na Figura 4.29 temos uma ilustra c ao que esquematiza as opera c oes realizadas na convers ao de um endere co virtual para um outro real. Este esquema de convers ao de endere cos e denominado convers ao ou tradu c ao
135
Figura 4.28: Estrutura de tabelas para sistemas com pagina c ao e segmenta c ao combinadas
136
de endere cos por mapeamento direto, ou ainda, pagina c ao com um n vel de tabelas.
Figura 4.29: Convers ao de endere cos por mapeamento direto Embora de relativa simplicidade e eci encia, o mapeamento indireto pode apresentar dois problemas importantes a medida que o espa co de endere camento virtual se torna relativamente muito maior que a mem oria f sica dispon vel ou poss vel de ser implementada no sistema [TAN92, p. 93]. Os problemas identicados s ao: 1. A tabela de p aginas pode se tornar extremamente grande. Grandes espa cos virtuais de endere camento requerem tabelas com muitas entradas. Se as tabelas s ao grandes, uma por c ao preciosa da mem oria pode ser consumida para este m, reduzindo a mem oria dispon vel para os processos que podem ser executados pelo sistema. 2. Tabelas de p aginas em mem oria versus troca de tabela de p aginas. Como cada processo possui suas tabelas de p aginas, ao esgotar-se o seu quantum, a sua execu c ao e interrompida sendo substitu da por outro processo. Se for realizada a troca das tabelas durante o chaveamento de processos, economiza-se mem oria prim aria embora tornando a opera c ao de troca de contexto lenta. Se forem mantidas todas as tabelas de p aginas em mem oria prim aria, a troca de contexto torna-se r apida, mas isto pode exaurir a mem oria prim aria do sistema. 3. O mapeamento pode se tornar lento para tabelas grandes ou complexos. Como cada refer encia a mem oria deve necessariamente ter
137
seu endere co convertido, quanto maiores ou mais complexas as tabelas, mais numerosas e complicadas ser ao as opera c oes de convers ao e, assim, ser a maior o overhead imposto pela convers ao dos endere cos, fazendo que o maepamento se torne inconvenientemente lento, afetando de forma signicativa a performance do sistema. Para ilustrar esta situa c ao, analisemos a seguinte situa c ao: na arquitetura DEC VAX, cada processo pode possuir at e 2 GBytes (231 bytes) de espa co de endere camento. Como as p aginas deste sistema possuem apenas 512 bytes (29 bytes), ent ao e necess ario uma tabela de p aginas contendo 222 entradas para cada processo existente no sistema, ou seja, 4.194.304 entradas. Se uma tabela desta magnitude j a e indesej avel, que tal um sistema Pentium, que no modo segmentado/paginado oferece 64 TBytes (246 bytes) de mem oria virtual? Com p aginas de 4096 bytes (212 bytes) e sabendo que metade do endere camento virtual e oferecido individualmente para cada 34 processo, uma tabela simples por processo deveria conter 22 entradas, ou seja, 8.589.934.592 de entradas! Uma primeira solu c ao seria submeter a tabela de p aginas ` a pagina c ao, como qualquer outra area de mem oria, armazenando-a na mem oria virtual, fazendo que apenas uma parte dela esteja necessariamente presente na mem oria prim aria. Outra solu c ao para evitar a presen ca de enormes tabelas na mem oria, conforme indicado por Tanembaum [TAN92, p. 94], e divis ao destas numa estrutura de m ultiplos n veis, como indicado na Figura 68. Um espa co virtual de 32 bits poderia ter seu endere co divido em tr es partes: (1) um n umero de tabela de p aginas T P1 de 10 bits, (2) um n umero de p agina virtual T P2 de 10 bits e (3) um deslocamento (oset ) de 12 bits. O valor T P1 atua como ndice para a tabela de p aginas de primeiro n vel, selecionando uma das tabelas do segundo n vel. Na tabela de segundo n vel selecionada, o valor T P2 atua como outro ndice, obtendo-se assim o endere co real da moldura de p agina (page frame ). A MMU comp oe o endere co real nal a partir do endere co da moldura de p agina ,obtido na tabela de segundo n vel, e do deslocamento (oset ), retirado do endere co virtual. Com a divis ao de uma u nica tabela (de primeiro n vel) em uma tabela de entrada (de primeiro n vel) e tabelas de p aginas auxiliares (de segundo n vel) passa a ser poss vel administrar-se a pagina c ao das tabelas de p aginas de maneira mais ex vel. Como regra geral, cada tabela de p aginas nunca e maior que o tamanho de uma p agina [STA96, p. 248]. De forma an aloga, um sistema de tabela de p aginas de dois n veis pode ser expandido para tr es, quatro ou mais n vel, embora a exibilidade adicionada torna-se menos valiosa do que a complexidade inerente ao maior n umero de n veis. Cada hardware espec co possui uma estrutura de tabelas particular, que leva em conta as peculiaridades da implementa c ao tais
138
Figura 4.30: Estrutura multin vel para tabelas de p aginas como o tamanho do espa co de endere camento virtual, a m axima quantidade f sica de mem oria endere c avel e o tamanho da p agina. Independentemente do n umero de n veis e do layout das tabelas, as entradas t picas das tabelas de p aginas possuem v arios campos utilizados para o controle adequado da mem oria: o n umero da moldura de p agina (page frame number ) que indica o endere co real da p agina, o bit presente/ausente (present/absent ) que sinaliza se a p agina est a ou n ao na mem oria prim aria, os bits de prote c ao (protection ) que especicam as opera c oes que podem ser realizadas na p agina, um bit de habilita c ao do cache (caching disabled ) usado para evitar que a p agina seja colocada no cache e os bits de refer encia (referenced ) e modica c ao (modied ) utilizados para controlar o uso e altera c ao do conte udo da p agina.
Figura 4.31: Entrada T pica de uma Tabela de P aginas Exemplos de sistemas que se utilizam de diferentes formas para a implementa c ao e administra c ao de suas tabelas de p aginas s ao:
4.7. MODELOS DE GERENCIAMENTO DE MEMORIA Pagina c ao em um n vel: DEC PDP-11. Pagina c ao em dois n veis: DEC VAX. Pagina c ao em tr es n veis: Sun Spark. Pagina c ao em quatro n veis: Motorola 68030. Pagina c ao via mem oria associativa (n vel zero): MIPS R2000.
139
Pagina c ao via tabelas invertidas: IBM RS6000 (sistemas RISC), IBM PowerPC, IBM AS/400.
4.7.9
Algoritmos de troca de p aginas
Os mecanismos de mem oria virtual se baseiam no fato de que por c oes dos processos s ao armazenadas em arquivos especiais denominados arquivos de troca. Quando um processo necessita acessar uma por c ao de seu c odigo contida fora do espa co de endere camento real, ocorre um page fault, ou seja, e detectada a falta de uma p agina que dever a ser trazida novamente para a mem oria principal. As opera c oes de substitui c ao de p aginas s ao lentas pois envolvem o acesso a mem ` oria secund ario, ou seja, necessitam acessar dispositivos de entrada e sa da, muito mais lentos do que a mem oria prim aria. E obvio que se a p agina substitu da for necess aria em breve ou for preciso um n umero muito grande de substitui c oes para execu c ao dos programas ativos, ocorrer a a hiperpagina c ao (hiperpaging ou thrashing ) ou seja, uma degrada c ao signicativa da performance do sistema devido ao excesso de opera c oes de troca de p aginas. Sendo assim estes algoritmos devem procurar substituir p aginas pouco utilizadas ou n ao utilizadas por aquelas que s ao freq uentemente utilizadas pelos processos ativos, minimizando as opera c oes de substitui c ao de p aginas. O grande problema consiste ent ao em determinar qual p agina ser a substitu da ou copiada para os arquivos de troca como forma de liberar espa co para aquele p agina que se tornou necess aria. Um algoritmo otimo de troca de p aginas deveria ser capaz de identicar qual p agina n ao mais ser a utilizada ou estabelecer aquela que demorar a mais a ser novamente utilizada, minimizando a ocorr encia de page faults e com isto as opera c oes de troca de p aginas. Como n ao e poss vel realizar tal previs ao, outras formas de se denir qual p agina ser a substitu da s ao empregadas [DEI92, p. 254]. Note que se uma p agina n ao tiver sido modicada ent ao n ao necessita ser copiada para a mem oria virtual (armazenamento secund ario), podendo ser simplesmente sobrescrita pela p agina que tomar a seu lugar na mem oria prim aria, ou seja, uma opera c ao de substitui c ao simples. Se a p agina foi modicada ent ao dever a ser copiada para o armazenamento secund ario antes da substitui c ao pela nova p agina, numa opera c ao mais lenta do que uma substitui c ao simples.
140
Os algoritmos que tratam deste problema s ao aqueles que implementam as estrat egias de substitui c ao (replacement strategies ) e s ao denominados algoritmos de troca ou algoritmos de substitui c ao de p aginas. Os algoritmos de substitui c ao de p aginas mais comuns s ao: Random First In First Out (FIFO) Second Chance Clock Last Recently Used (LRU) Last Frequently Used (LFU) Not Recently Used (NRU) Troca de p aginas aleat oria Algoritmo de baixa sobrecarga que seleciona aleatoriamente qual p agina dever a ser substitu da. Quanto maior o n umero de p aginas existentes, maior s ao as chances de sucesso imediato deste algoritmo. Embora seja r apido e de implementa c ao simples, e raramente utilizado dado que a p agina substitu da pode ser a pr oxima a ser necess aria. Tamb em e chamado de random page replacement. Troca de p aginas FIFO A id eia central deste algoritmo e que as p aginas que est ao a mais tempo na mem oria podem ser substitu das, ou seja, as primeiras que entram s ao as primeiras que saem (FIFO ou First In First Out ). Para isto associa-se um marca de tempo (timestamp ) para cada p agina, criando-se uma lista de p aginas por idade, permitindo a identica c ao das mais antigas. Este mecanismo de substitui c ao, embora prov avel e l ogico, n ao necessariamente se traduz em verdade, pois processos de longa dura c ao pode continuar necessitando de suas p aginas mais do que processos de curta dura c ao que entram e saem rapidamente enquanto os outro permanecem. Dada esta raz ao n ao e utilizado na forma pura, mas sim varia c oes deste algoritmo. Troca de p aginas segunda chance O algoritmo de troca de p aginas segunda chance (second chance ) e uma varia c ao da estrat egia FIFO. Como visto, a deci encia do algoritmo de troca de p aginas FIFO e que uma p agina de uso intenso, presente a muito tempo na mem oria, pode ser indevidamente substitu da.
141
No algoritmo de troca de p aginas Segunda Chance a sele c ao prim aria da p agina a ser substitu da e semelhante ao FIFO, ou seja, escolhe-se a p agina mais antiga. Antes de proceder-se a substitui c ao propriamente dita, vericase o bit de refer encia da p agina. Se o bit estiver em 1, signica que a p agina foi usada, da o algoritmo troca sua marca de tempo por uma nova e ajusta o bit de refer encia para zero, simulando uma nova p agina na mem oria, ou seja, uma segunda chance de perman encia na mem oria prim aria. Nesta situa c ao outra p agina deve ser escolhida para substitui c ao. Se o bit de refer encia estivesse em 0 a p agina seria substitu da. Com este comportamento, se uma p agina antiga e utilizada, seu bit de refer encia sempre ser a 1, fazendo com que permane ca na mem oria prim aria a despeito de sua idade real. Troca de p aginas rel ogio O algoritmo de troca de p aginas rel ogio (clock ) e uma outra varia c ao da estrat egia FIFO. Para superar a deci encia do algoritmo de troca de p aginas FIFO, que e a substitui c ao de uma p agina de uso intenso em fun c ao de sua idade na mem oria, o algoritmo segunda chance verica o bit de refer encia mantendo na mem oria p aginas em uso atrav es da renova c ao de sua marca de tempo. Tal comportamento eq uivale a dizer que as p aginas no in cio da lista (mais velhas) s ao reposicionadas no m da lista (mais novas). A estrat egia do rel ogio e manter uma lista circular, onde se o bit de refer encia e 1, seu valor e trocado por 0 e a refer encia da lista movida conforme os ponteiros de um rel ogio. Caso contr ario a p agina e substitu da. Troca de p aginas LRU A atua c ao do algoritmo de troca de p aginas LRU (least recently used ou menos usada recentemente) se baseia em identicar a p agina que n ao foi utilizada pelo maior per odo de tempo, assumindo que o passado e um bom indicativo do futuro. Para isto e necess ario que cada p agina possua uma marca de tempo (timestamp ) atualizada a cada refer encia feita ` a p agina, o que signica uma sobrecarga substancial. A implementa c ao pode ser feita atrav es de listas contendo uma entrada para cada page frame, sendo o elemento da lista correspondente a uma p agina utilizada sendo posicionado no nal da lista. Este algoritmo n ao costuma ser usado sem otimiza c oes devido ` a sobrecarga que imp oe. Al em disso, em la cos longos ou chamadas com muitos n veis de profundidade, a pr oxima p agina a ser usada pode ser exatamente uma das menos usadas recentemente, colocando o sistema numa situa c ao de opera c oes desnecess arias devido a page faults. O sistema operacional MS Windows 95 utiliza esta estrat egia de substitui c ao de p aginas [PET96, p. 725].
142
Troca de p aginas LFU Uma variante do algoritmo LRU e a estrat egia conhecida como LFU (least frequently used ou menos freq uentemente usada) ou ainda NFU (not frequently used ou n ao usada freq uentemente). Neste algoritmo pretende-se calcular a freq u encia de uso das p aginas, de forma a se identicar qual p agina foi menos intensivamente utilizada. Apesar de melhorar o desempenho do algoritmo LRU, ainda e poss vel que p aginas pesadamente utilizadas durante uma certa etapa do processamento permane cam desnecessariamente na mem oria prim aria em rela c ao a outras etapas mais curtas cujas p aginas n ao ter ao uso t ao intenso, levando a substitui c oes in uteis. Troca de p aginas NRU As entradas de cada p agina na tabela de p aginas possuem geralmente bits de refer encia e modica c ao (bits referenced e modied, conforme Figura 69) cujos valores combinados denem quatro situa c oes ou grupos de p aginas, como relacionado na Tabela 4.6. Tabela 4.6: Grupos de p aginas Bit Situa c ao Modied 0 N ao referenciado e n ao modicado 1 N ao referenciado e modicado 0 Referenciado e n ao modicado 1 Referenciado e modicado
Bit Referenced 0 0 1 1
A atua c ao do algoritmo de troca de p aginas NRU (not recently used ou n ao recentemente usada) ou NUR (not used recently ou n ao usada recentemente) se baseia em remover uma p agina, aleatoriamente escolhida, do grupo de menor utiliza c ao que contiver p aginas nesta situa c ao. Neste algoritmo se d a prefer encia a remo c ao de uma p agina modicada sem uso no u ltimo ciclo do que uma sem modica c ao que tenha sido utilizada. Este algoritmo e utilizado em v arios sistemas devido aos seus pontos fortes: simplicidade, f acil implementa c ao e performance adequada.
Cap tulo 5
Gerenciamento de I/O
O acr onimo I/O (Input/Output ) ou E/S (Entrada/Sa da) representa toda a sorte de dispositivos eletr onicos, eletromec anicos e opticos que s ao integrados a um sistema computacional com o prop osito de realizar a comunica c ao do processador e mem oria com o meio externo. De certa forma, o computador seria uma m aquina in util caso n ao existissem meios de realizar-se as opera c oes de entrada e sa da. Os dispositivos de I/O, dispositivos perif ericos ou apenas perif ericos podem ser classicados de forma ampla em tr es categorias [STA96, p. 179]: Human-Readable Dispositivos apropriados para serem utilizados por usuarios do computador tais como o teclado, o mouse ou o monitor de v deo. Machine-Readable S ao aqueles projetados para interliga c ao do computador com outros equipamentos, tais como unidades de disco, CD-ROM ou ta magn etica. Communication Destinados a realizar a comunica c ao do computador com outros dispositivos remotos, tais como placas de rede ou modems.
5.1
M odulos de I/O
A arquitetura de Von Neumann (Figura 1.2) dene o computador como o conjunto de processador, mem oria e dispositivos de entrada e sa da interconectados atrav es v arios barramentos (buses ) especializados: o barramento de dados (data bus ), o barramento de endere cos (address bus ) e o barramento de controle (control bus ). Mas diferentemente do que poder amos pensar, os dispositivos perif ericos em si n ao s ao conectados diretamente ` a tais barramentos, mas, ao inv es disso, os perif ericos s ao conectados a m odulos de I/O que por sua vez s ao ligados aos barramentos do sistema. As raz oes para isto s ao v arias: 143
144
CAP ITULO 5. GERENCIAMENTO DE I/O Existem in umeros tipos de perif ericos, com diferentes formas de opera c ao, sendo impratic avel implantar no computador uma l ogica que permitisse a opera c ao com todos ou mesmo uma grande parte destes dispositivos. Como visto, a velocidade de opera c ao dos dispositivos perif ericos e muito menor que a da mem oria ou do processador.
Desta forma e muito mais conveniente implementar-se m odulos de I/O que atuem como conex oes mais gen ericas para os diferentes perif ericos, possibilitando o uso de estruturas padronizadas para liga c ao com a mem oria e processador. Por essa raz ao, os m odulos de IO s ao freq uentemente chamados de interfaces. Um m odulo de I/O geralmente possui algumas linhas de controle internas que servem para determinar as a c oes que devem ser executadas pelo m odulo, linhas de status que servem para indicar o estado de funcionamento do m odulo ou resultado de alguma opera c ao, linhas de dados para conex ao do m odulo de I/O com o barramento de dados do sistema e um conjunto particular de linhas para conex ao com o perif erico que efetivamente ser a controlado pelo m odulo de I/O. Na Figura 5.1 temos um representa c ao gen erica do que pode ser um m odulo de I/O.
Figura 5.1: Estrutura gen erica de m odulo de I/O A conex ao com o barramento do processador geralmente tende a ser uma interface de alto n vel, isto e, uma conex ao orientada ` a comandos, mais adaptada ` a opera c ao com um processador e, portanto, dirigida ao trabalho de programa c ao de alto n vel. J a a conex ao com o perif erico propriamente dito e usualmente uma interface de baixo n vel, contendo in umeros sinais el etricos e um protocolo dedicado pr oprio, que exige tratamento mais especializado. Desta forma, as particularidades de cada tipo de perif erico cam isoladas do sistema principal, facilitando o desenvolvimento dos programas que utilizar ao estes dispositivos.
DE MODULOS 5.2. OPERAC AO DE I/O
145
Esta estrutura permite que um u nico m odulo de I/O controle mais de um perif erico, geralmente do mesmo tipo, tal como nos controladores de unidades de disco IDE 1 que podem administrar de uma at e quatro unidades de disco deste padr ao. Os m odulos de I/O geralmente executam algumas das seguintes fun c oes: controle e temporiza c ao, comunica c ao com o processador, comunica c ao com perif erico, armazenamento tempor ario de dados e detec c ao de erros. Uma outra estrutura poss vel para os m odulos de I/O s ao os canais de I/O (I/O channels ). Os canais de I/O s ao sistemas computacionais de prop osito especial destinados ao tratamento de entrada e sa da de forma independente do processador do sistema computacional [DEI92, p. 27]. Esta alternativa estrutural, usada tipicamente em computadores de grande porte (mainframes ), opera com m ultiplos barramentos de alta velocidade, podendo acessar o armazenamento prim ario de forma independente, proporcionando grande desempenho, pois as opera c oes de I/O s ao realizadas paralelamente ao processamento. Micro e minicomputadores utilizam geralmente um modelo de barramento interno simples para comunica c ao entre processador, mem oria e os demais dispositivos do sistema. Compartilhando este barramento encontramse dispositivos especializados nas em fun c oes mais importantes (unidades de disco e monitor de v deo) chamados controladores, proporcionando consider avel ganho de performance e ainda assim utilizando uma arquitetura mais simples que os canais de I/O [TAN92, p. 207].
5.2
Opera c ao de M odulos de I/O
Os m odulos de I/O podem ser operados de tr es maneiras b asicas: I/O Programado, I/O com Interrup c oes e I/O com Acesso Direto ` a Mem oria (DMA) De forma geral, o que distingue estas tr es formas de opera c ao e a participa c ao do processador e a utiliza c ao do mecanismo de interrup c oes, conduzindo a resultados bastante distintos.
5.2.1
I/O Programado
Com o I/O programado (programmed I/O ) os dados s ao trocados diretamente entre o processador e o m odulo de I/O, ou seja, o processador deve
1 O acr onimo IDE signica integrated device eletronics ou dispositivo eletr onico integrado.
146
CAP ITULO 5. GERENCIAMENTO DE I/O
executar um programa que verique o estado do m odulo de I/O, preparandoo para a opera c ao se necess ario, enviando o comando que deve ser executado e aguardando o resultado do comando para ent ao efetuar a transfer encia entre o m odulo de I/O e algum registrador do processador. Portanto e responsabilidade do processador vericar o estado do m odulo de I/O em todas as situa c oes, inclusive quando aguarda dados. Isto signica que o processador n ao pode executar outras tarefas enquanto aguarda a opera c ao do m odulo de I/O. Veja na Figura 5.2 um esquema indicando o funcionamento das opera c oes de I/O programadas.
Figura 5.2: Funcionamento do I/O programado Como os comandos enviados ao m odulo de I/O podem signicar uma opera c ao com um dispositivo perif erico lento, digamos uma unidade de disco, ent ao o processador dever a permanecer em espera durante toda a opera c ao executada no perif erico, por mais lento que possa ser, signicando um s erio comprometimento da performance geral do sistema, dado que o processador ca ocupado com a monitora c ao da opera c ao em andamento (veja Figura 5.3). O m odulo de I/O se relaciona com o processador atrav es de comandos, ou seja, c odigos de controle transformados em sinais enviados ao m odulo que indica qual opera c ao dever a ser realizada, tais como controle (control ), teste (test ), escrita (write ) ou leitura (read ). Geralmente os comandos do m odulo de I/O tem equival encia direta com as instru c oes do processador, facilitando sua opera c ao integrada. Dado que e poss vel para um m odulo de I/O controlar mais de um dispositivo perif erico, ent ao e necess ario que sejam associados endere cos a cada um destes perif ericos, de forma a permitir sua opera c ao individualizada. Existem duas formas para a interpreta c ao destes endere cos por parte dos m odulos de I/O quando existe o compartilhamento de barramentos do sistema:
147
Figura 5.3: Temporiza c ao do I/O programado Mapeada em Mem oria (memory-mapped ) Onde o m odulo de I/O opera dentro do espa co de endere camento da mem oria, usando um conjunto de endere cos reservados. Desta forma o processador trata os registradores de status e dados do m odulo de I/O como posi c oes ordin arias de mem oria utilizando opera c oes comuns de leitura e escrita. Para o funcionamento neste modo o processador deve dispor de uma linha individual de leitura e outra para escrita. Mapeada em I/O (I/O mapped ) Tamb em chamada de I/O isolado (isolated I/O ), onde existe um espa co de endere camento independente para os dispositivos de I/O. Para tanto o processador deve dispor de uma linha de leitura/escrita e outra de entrada/sa da. As portas de I/O passam a ser acess veis apenas por opera c oes especiais de I/O. Utilizando a forma de I/O mapeado em mem oria temos uma maior simplicidade e a disponibilidade de um maior conjunto de instru c oes embora reduzido espa co em mem oria devido a reserva de endere cos para portas de I/O. Os computadores baseados nos processadores Motorola 680x0 utilizam este m etodo. Com o I/O isolado temos maior seguran ca nas opera c oes envolvendo mem oria ou I/O e um maior espa co de endere camento as custas de uma organiza c ao ligeiramente mais complexa e um reduzido n umero de instru c oes dedicadas. Os microcomputadores IBM PC compat veis s ao um exemplo desta utiliza c ao. No caso, para enviar-se dados ao monitor de v deo padr ao do sistema devem ser utilizados os endere cos de I/O na faixa de 03D0h a 03DFh, enquanto que o acesso ` as placas de som tipo SoundBlaster devem
148 usar o endere co 0220h.
5.2.2
I/O com interrup c oes
Para superar o problema da espera do processador por opera c oes nos dispositivos perif ericos, pode ser utilizado o mecanismo das interrup c oes, ou seja o I/O atrav es de interrup c oes (interrupt driven I/O ). Tecnicamente falando, uma interrup c ao permite que uma unidade ganhe a aten c ao imediata de outra, de forma que a primeira unidade possa nalizar sua tarefa [DEI92, p. 25]. Assim sendo, quando o processador envia um comando para o m odulo de I/O, o mesmo pode passar executar uma outra tarefa, sem a necessidade de monitorar o m odulo acionado. Quando a opera c ao for conclu da, o m odulo de I/O interrompe o processador, isto e, aciona uma interrup c ao para requisitar o processamento dos dados (a troca de dados com o processador). O processador executa a troca de dados, liberando o m odulo de I/O e retomando o processamento anterior. Conforme podemos observar na Figura 5.4, a opera c ao de I/O com interrup c oes e a seguinte: 1. O processador envia um comando ao m odulo de I/O (por exemplo, uma opera c ao read ), que a realiza de modo independente (i.e., em paralelo a atividade do processador). 2. O processador passa a executar outra tarefa, ou seja, um outro processo. 3. Ao nalizar a opera c ao requisitada, o m odulo de I/O sinaliza uma interrup c ao para o processador. 4. Ao t ermino da instru c ao corrente, o processador verica a ocorr encia de uma interrup c ao, determinando qual dispositivo a originou e ent ao sinalizando conhecimento (acknowledgment signal ). 5. O processador salva o contexto da tarefa atual na pilha (stack ), preservando assim o conte udo do contador de programa e demais registradores. 6. O processador carrega o endere co da rotina de servi co no contador de programa para poder iniciar a execu c ao da rotina de tratamento da interrup c ao detectada. Tais endere cos s ao armazenados numa regi ao pr e-determinada da mem oria, denominada vetor de interrup c oes. 7. A rotina de tratamento da interrup c ao e executada, ou seja, os dados solicitados s ao lidos do m odulo de I/O para um registrador do processador e depois transferidos para uma area de mem oria apropriada.
149
8. Finalizada a rotina de tratamento da interrup c ao, o processador restaura o contexto da tarefa interrompida, lendo o conte udo do contador de programa e demais registradores da pilha. 9. O processador retorna ao processamento da tarefa no ponto em que foi interrompida. 10. Mais um momento mais a frente, em seu quantum, o processo que solicitou a opera c ao de I/O ser a executado com os dados obtidos a sua disposi c ao.
Figura 5.4: Funcionamento do I/O com interrup c oes A opera c ao de dispositivos de I/O utilizando interrup c oes permite que o processador permane ca trabalhando enquanto o m odulo de I/O realiza a opera c ao solicitada, melhorando o desempenho do sistema pois duas atividades s ao paralelizadas, embora os dados da opera c ao continuem a ser manipulados pelo processador, como mostra tamb em a Figura 5.5. O maior problema relacionado com o uso das interrup c oes e que, usualmente, o processador disp oe de poucas linhas de interrup c ao. Desta forma surgem as seguintes quest oes: como o processador identicar a o m odulo que sinalizou uma interrup c ao e como ser ao tratadas m ultiplas interrup c oes simult aneas? Para resolver-se esta quest oes, podem ser empregadas v arias diferentes t ecnicas [STA96, p. 194]: m ultiplas linhas de interrup c ao, software poll, hardware poll vetorizado e bus arbitration vetorizada. Usualmente s ao assinalados n umeros para as interrup c oes, onde as de menor n umero tem prioridade sobre as n umero maior. Isto signica que uma interrup c ao de n umero 4 ser a processada primeiro do que uma interrup c ao de n umero maior (>= 5), sem ser interrompida por estas, mas podendo ser interrompida por uma interrup c ao de n umero menor (< 4).
150
Figura 5.5: Temporiza c ao do I/O com interrup c oes Como exemplo, apresentamos a Tabela 5.1 que cont em o mapeamento das interrup c oes num sistema IBM-PC compat vel. Alguns dos valores s ao padronizados enquanto outros s ao particulares do sistema utilizado como exemplo. Tabela 5.1: Mapa de interrup c oes de um IBM-PC compat vel
Int 0 1 2 3 4 5 6 7 Dispositivo Cron ometro do sistema Teclado Controlador de interrup c ao Placa de rede (*) Porta de comunica c ao COM1 Placa de som (*) Controlador de disco ex vel Porta de Impressora LPT1 Int 8 9 10 11 12 13 14 15 Dispositivo CMOS/Rel ogio do sistema Porta de comunica c ao COM3 Porta de comunica c ao COM2 Ponte PCI (*) Mouse porta PS/2 (*) Coprocessador num erico Controlador IDE/ESDI Controlador IDE/ESDI
(*) Op c oes n ao padronizadas
5.2.3
I/O com Acesso Direto ` a Mem oria (DMA)
As t ecnicas de I/O programado e I/O com interrup c oes possuem um grande inconveniente que e a limita c ao da velocidade de transfer encia de dados a capacidade do processador em movimentar tais dados a partir do m odulo de I/O para o armazenamento prim ario, pois isso envolve a execu c ao repetida de v arias instru c oes. Al em disso o processador ca comprometido n ao
151
apenas com a transfer encia dos dados, mas com a monitora c ao do m odulo de I/O, no caso de I/O programado, ou com a sobrecarga imposta pelas opera c oes de interrup c ao, no caso de I/O via interrup c ao. Se um m odulo de I/O for utilizado para a movimenta c ao de uma grande quantidade de dados, ambas as formas comprometer ao a performance do sistema. Para solucionar-se este problema pode ser utilizada uma outra t ecnica denominada I/O atrav es de acesso direto ` a mem oria ou DMA (direct memory access ). A t ecnica de DMA prop oe utilizar uma u nica interrup c ao para efetuar a transfer encia de um bloco de dados diretamente entre o perif erico e a mem oria prim aria, sem o envolvimento do processador e com isso reduzindo o n umero de opera c oes necess arias e assim acelerando o processo. Para tanto, torna-se necess aria a exist encia de um m odulo adicional, chamado de controlador de DMA, cuja opera c ao, ilustrada na Figura 5.6, e descrita a seguir [STA96, p. 199]: 1. O processador envia comando (leitura ou escrita) para controlador de DMA. 2. O processador continua seu trabalho enquanto DMA efetua a transfer encia com o dispositivo de I/O. 3. Para acessar a mem oria o controlador de DMA rouba ciclos do processador para acessar a mem oria principal, atrasando-o ligeiramente. 4. Ao nal da opera c ao o controlador de DMA aciona uma interrup c ao para sinalizar o t ermino da opera c ao. 5. O processador pode executar a rotina de tratamento da interrup c ao processando os dados lidos ou produzindo novos dados para serem escritos. Este m etodo e signicativamente mais r apido do que o I/O programado ou I/O via interrup c oes pois utiliza apenas uma u nica interrup c ao, o processador ca liberada para executar outras tarefas e a transfer encia dos dados ocorre em bloco (e n ao byte a byte ) diretamente entre o perif erico e a mem oria. O controlador de DMA e um dispositivo especializado nesta opera c ao, suportando tipicamente o trabalho com v arios perif ericos diferentes, cada um utilizando um canal de DMA (DMA channel ). Outra grande vantagem da t ecnica de DMA e que ela pode ser implementada no hardware de diversas formas diferentes, conforme a quantidade de dispositivos de I/O e performance pretendida, como ilustrado na Figura 5.7.
152
Figura 5.6: Funcionamento do I/O com DMA
5.3
Tipos de dispositivos de E/S
Os dispositivos de I/O e suas interfaces podem ser classicados de forma ampla quanto ao tipo de conex ao e tipo de transfer encia de dados.
5.3.1
Conex ao de Dados dos I/O
Conforme natureza do perif erico que ser a conectado ao sistema e tamb em as condi c oes desta liga c ao, as conex oes dos dispositivos de I/O, do ponto de vista dos dados, s ao projetadas para opera c ao serial ou paralela. Numa conex ao serial, uma u nica linha de sinal e utilizada para o estabelecimento de toda a conex ao, protocolo e transfer encia de dados entre o m odulo de I/O e o perif erico, ou seja, todos os bits, sejam de dados ou controle, s ao transferidos um a um entre m odulo de I/O e perif erico. Numa conex ao paralela, v arias linhas de sinal s ao utilizadas de modo que v arios bits de dados (bytes ou words tipicamente) sejam transferidos em paralelo, ou seja, ao mesmo tempo, acelerando as transfer encias, pois se comportam como v arias linhas seriais atuando ao mesmo tempo. Tamb em e comum que existam linhas independentes para o tr afego de sinais de controle. As conex oes seriais s ao baratas, relativamente con aveis, embora nominalmente mais lentas que as conex oes paralelas, sendo usualmente utilizadas para dispositivos baratos e lentos tais como impressoras e terminais. As conex oes paralelas, devido a interface mais complexa, s ao mais caras, bastante con aveis e de melhor desempenho, sendo utilizadas para conex ao com dispositivos mais velozes, tais como unidades de disco, unidades de ta ou mesmo impressoras r apidas. Em ambas os tipos de conex ao, o m odulo de I/O e o perif erico trocam sinais de controle garantindo a permiss ao para o envio ou recebimento de dados (protocolo de conex ao ou handshaking ). A transfer encia dos dados
5.3. TIPOS DE DISPOSITIVOS DE E/S
153
Figura 5.7: Congura c oes de DMA e feita, exigindo o envio de sinais de conrma c ao a cada byte ou bloco dependendo do dispositivo, tipo de conex ao e do protocolo de transfer encia adotado.
5.3.2
Tipos de Transfer encia de I/O
Os dispositivos de I/O atuam usualmente como dispositivos orientados ` a caractere (character devices ) e dispositivos orientados ` a blocos (block devices ). Nos primeiros, orientados ` a caractere, a transfer encia de dados e feita byte a byte, sem a necessidade de alguma forma de estrutura c ao dos dados por parte do m odulo de I/O e do perif erico, ou seja, o formato dos dados recebidos e transmitidos e responsabilidade da aplica c ao que utiliza o dispositivo. Nos dispositivos de transfer encia orientados ` a blocos, a troca de dados e realizada em blocos de tamanho xo, cujo tamanho depende do dispositivo, usualmente entre 128 e 1024 bytes. Os blocos tamb em possuem um formato particular, exigindo que a aplica c ao conhe ca tal formato tanto para a constru c ao de tais blocos destinados ` a transmiss ao como para sua adequada recep c ao.
154
Temos portanto que a opera c ao de dispositivos orientados ` a caractere e ` a blocos e bastante diferente. Unidades de disco e ta s ao dispositivos orientados ` a blocos enquanto que impressoras, terminais, teclados e portas seriais s ao orientados ` a caractere [PIT98, p. 68]. Nem todos os dispositivos se ajustam a esta classica c ao, tais como os temporizadores (timers ) do sistema ou monitores de v deo de mem oria [TAN92, p. 206]. Nos sistemas Unix esta distin c ao e bastante aparente, principalmente durante os procedimento de instala c ao e congura c ao do sistema operacional.
5.3.3
Conex oes ponto a ponto e multiponto com I/Os
A conex ao mais simples entre um dispositivo perif erico e seu m odulo de I/O e do tipo , ou seja, as linhas de sinais existentes para a comunica c ao entre estas unidades s ao dedicadas a este m. Desta forma, um m odulo de I/O deveria dispor de um conjunto de linhas para dispositivo de I/O com o qual pretende se comunicar. Por outro lado, e poss vel que um m odulo de I/O compartilhe um conjunto de linhas de sinais entre diversos dispositivos perif ericos, desde que dentre estas linhas existam algumas para realizar o endere camento ou sele c ao do dispositivo com o qual deseja-se realizar a opera c ao. A conex ao multiponto e como um conjunto de barramentos dedicado a comunica c ao entre um m odulo de I/O e v arios dispositivos semelhantes. Uma representa c ao das conex oes ponto a ponto e multiponto se encontra na Figura 5.8.
Figura 5.8: Conex oes ponto-a-ponto e multiponto A conex ao ponto-a-ponto oferece melhor conabilidade, permite a opera c ao simult anea de diversos perif ericos simultaneamente (dependendo apenas das capacidades do m odulo de I/O) embora exigindo um maior n umero de geralmente utilizada para a conex conex oes e, portanto linhas de sinal. E ao de dispositivos mais simples, tais como modems, teclado e impressoras. Exemplos de conex oes ponto-a-ponto padronizadas s ao os protocolos RTS/CTS (Request to Send e Clear to Send ) e Xon/Xo (Transmission
5.4. DISPOSITIVOS PERIFERICOS T IPICOS
155
On e Transmisson O ). O RTS/CTS e Xon/XO s ao considerados protocolos de baixo n vel simples, bastante utilizados em comunica c ao de curta dist ancia entre computadores e perif ericos de baixa velocidade, usualmente utilizando a interface padr ao RS-232C (equivalente ` a standard CCITT V.24) [BLA87, p. 53]. Veja uma representa c ao do funcionamento destes protocolos entre dois equipamentos DTE (data terminal equipment ) na Figura 5.9.
Figura 5.9: Protocolos RTS/CTS e Xon/Xo Dado que s ao protocolos simples, sua implementa c ao e f acil, constituindo uma alternativa ex vel e de baixo custo para interliga c ao de equipamentos tais como multiplexadores, demultiplexadores, modems, impressoras, terminais de v deo, plotters, mesas digitalizadoras etc. A conex ao multiponto e bastante mais ex vel do que a conex ao pontoa-ponto pois permite maior escalabilidade, utilizando reduzido n umero total de linhas, mas por outro lado n ao permite a opera c ao simult anea dos perif ericos conectados. Tal conex ao e tipicamente utilizada para dispositivos de armazenamento, tais como unidades de disco, ta, cartucho, CD-ROM, etc. Existem v arios padr oes para estas conex oes, onde s ao exemplos: IDE (integrated device eletronics ), EIDE (extended IDE ), SCSI (small computer system interface ), USB (universal serial bus )
5.4
Dispositivos perif ericos t picos
Os dispositivos perif ericos tem papel fundamental dentro de um sistema computacional, pois como colocado anteriormente, o computador seria in util
156
se fosse apenas composto de processador e mem oria. Existem muitos tipos de dispositivos perif ericos, dentre os mais comuns podemos citar: Unidades de Disco R gido Unidades de Disco Flex vel Unidades de Fitas Magn etica Unidades de CD-R/RW Unidades de DVD-R/RW Mouse Trackball Mousepad Teclados Scanners Mesas digitalizadoras Impressoras Modems Portas de comunica c ao serial Portas de comunica c ao paralela Portas de comunica c ao USB Placas de Rede Monitores de v deo Portas de jogos Placas de som Placas de captura de v deo etc. Al em destes, a maioria voltados para uso em microcomputadores, existem dispositivos apropriados para sistemas computacionais de grande porte, tais como controladoras de terminais, terminais de v deo, subsistemas de armazenamento secund ario, subsistemas de comunica c ao etc. Dentre todos estes dispositivos daremos destaque as unidades de disco e ta por representarem os perif ericos mais importantes do ponto de vista de armazenamento secund ario. Al em destes, faremos alguns coment arios sobre os terminais de v deo, essenciais em sistemas multiusu ario.
5.4.1
Unidades de disco
Atualmente, praticamente todos os tipos de computadores disp oe de unidades de disco magn etico. Estas unidades s ao compostas de um ou mais discos met alicos de a co ou alum nio recobertos de uma na pel cula magnetiz avel. Estes disco, montados verticalmente num mesmo eixo, giram em velocidade constante (2400 ou 3600 rpm, por exemplo). As unidades podem possuir cabe cas de leitura e grava c ao xas (uma para cada trilha de cada disco) ou cabe cas m oveis (uma para cada disco). Neste caso bra cos mec anicos, dotados de dispositivos de acionamento, s ao respons aveis pela movimenta c ao r apida e precisa de cabe cas por praticamente toda a superf cies dos discos. Estas cabe cas s ao capazes de gravar ou ler dados magneticamente armazenados na pel cula que recobre os discos, dados estes que permanecem gravados mesmo que as unidades de disco permane cam desligadas por um razo avel per odo de tempo. As tecnologias envolvidas no desenvolvimento e fabrica c ao das unidades de disco vem sido aperfei coadas desde as primeiras gera c oes de computadores e com isto, as unidades de disco magn etico comuns, isto e, instaladas em computadores destinados ao segmento SOHO2 , exibem as seguintes caracter sticas:
2 SOHO signica small oce or home oce, ou seja, micro e pequenas empresas al em de escrit orios dom esticos caracterizando um grande segmento de mercado que utiliza mi-
157
Grandes capacidades de armazenamento, tipicamente maiores que 1 GBytes (230 ), Dimens oes reduzidas (discos de 3.5 ou menores), Baixo consumo (apropriados para equipamentos port ateis), Tempos de acesso inferiores a 15 ms e Baixo custo por MByte. As unidades de disco s ao constru das de forma modular por quest oes de economia e modularidade, permitindo que v arias unidades possam ser controladas por um mesmo m odulo de I/O, mais conhecido como controladora de disco, em arranjos ponto a ponto ou multiponto, como mostra a Figura 5.8. A congura c ao multiponto e mais comum pois simplica o projeto das controladoras de disco dada a redu c ao do n umero de conex oes necess arias. Isto permite grande exibilidade aos sistemas computacionais pois a capacidade do armazenamento secund ario pode ser aumentada pela simples adi c ao de novas unidades de disco. Outros sistemas tem duplicadas suas unidades de disco, utilizando t ecnicas de espelhamento (mirroring ), onde os dados s ao gravados de forma id entica nas unidade espelhadas, permitindo a r apida recupera c ao do sistema em caso de falhas. Uma outra estrat egia de alta conabilidade e disponibilidade e a utiliza c ao de m ultiplas unidades de disco num arranjo conhecido como RAID (redundant array of inexpensive disks ), onde os dados s ao gravados de forma distribu da num grupo de unidades permitindo at e mesmo a substitui c ao de uma unidade de disco com o equipamento em funcionamento. Stallings traz maiores detalhes sobre as t ecnicas de RAID [STA96, p. 161]. As unidade de disco, que s ao dispositivos de acesso direto, isto e, qualquer setor contendo informa c ao pode ser acessado atrav es de uma simples opera c ao de pesquisa (seek ) sem necessidade da leitura de setores adicionais. Dispositivos desta natureza tamb em s ao chamados de dispositivos de acesso aleat orio. A IBM tradicionalmente denomina suas unidades de disco de DASD (direct access storage devices ) numa clara alus ao a forma com que os dados pode serem lidos e gravados. Com tais caracter sticas, podemos perceber sua import ancia para os computadores. Segundo Deitel [DEI92, p. 26], as unidades de disco magn etico s ao talvez o mais importante perif erico dentro de um sistema computacional. Organiza c ao dos discos Do ponto de vista de organiza c ao, uma unidade de disco pode possui um ou v arios discos (disks ), ` as vezes chamados de pratos (platters ). Todo o
crocomputadores e equipamentos de pequeno porte.
158
conjunto de discos e dividido em circunfer encias conc entricas denominadas cilindros (cylinders ). Para cada superf cie de disco equipada com cabe ca de leitura (head ) se dene uma trilha (track ), que tamb em e dividida radialmente em setores (sectors ), tal como fatias de uma pizza. Entre as trilhas existe um espa co livre (inter-track gap ) tal como entre os setores (inter-sector gap ). Todo o espa co livre existente entre trilhas e setores n ao e utilizado por estes dispositivos. Na Figura 5.10 temos a estrutura de uma unidade de disco magn etico.
Figura 5.10: Estrutura esquem atica de uma unidade de disco magn etico Como forma de simplica c ao, todas as trilhas armazenam a mesma quantidade de dados, portanto a densidade de grava c ao e maior nas trilhas interiores dos discos. O hardware da unidade de disco disp oe de meios para identicar o setor inicial sendo que os demais setores s ao identicados conforme o disco e trilha ao quais pertencem, recebendo uma numera c ao de refer encia. O processo de divis ao das superf cies em trilhas e setores e o que se denomina formata c ao f sica da unidade enquanto que sua adequa c ao ao sistema de arquivos do sistema operacional e chamada de formata c ao l ogica. Os dados s ao gravados nos setores de cada trilha podendo ser recuperados posteriormente se for conhecido o n umero do setor desejado. Uma outra caracter stica fundamental das unidades de disco e a possibilidade de serem divididas em parti c oes. Uma parti c ao e um conjunto de cilindros consecutivos, cujo tamanho e determinado pelo usu ario [NOR89, p. 103], permitindo que: uma unidade de disco f sica seja vista e tratada como v arias unida-
159
des de disco l ogicas distintas, facilitando a organiza c ao dos dados e instala c ao de programas; e v arios sistemas operacionais diferentes sejam instalados nas diversas parti c oes, ampliando signicativamente as possibilidades de uso da m aquina. No sistema operacional multiusu ario IBM VM/SP (Virtual Machine/System Product ), usado em computadores IBM de grande porte, um procedimento comum para aloca c ao de espa co em disco para os usu arios era a cria c ao de mini-discos, na verdade, pequenas parti c oes de uma das unidades de disco do sistema. Atrav es de uma solicita c ao aos operadores do sistema, o usu ario recebia direitos de acesso ` a um novo mini-disco, criado para seu uso particular. Para o usu ario, cada mini-disco aparentava ser uma unidade de disco de uso privativa e isolada das demais, onde os arquivos e programas eram criados e modicados, podendo o usu ario dar direitos de acesso de seu mini-disco para outros usu arios do sistema. Quando necess ario, o usu ario podia pedir uma amplia c ao de seu mini-disco ou requerer um novo mini-disco, de forma a possuir v arias mini-parti c oes diferentes do sistema. Resumidamente, caracter sticas importantes que descrevem uma unidade de disco s ao: n umero de discos, n umero de superf cies, n umero de cilindros, n umero de setores, movimenta c ao das cabe cas (xas ou m oveis), tipo de cabe cas (de contato, de espa camento xo ou aerodin amicas), tempo m edio de acesso, capacidade de transfer encia da controladora e MTBF (Medium Time Between Failures ). A maioria dos detalhes de opera c ao das unidades de disco magn etica s ao tratadas pelas controladoras de disco, cujas interfaces padronizadas s ao de f acil integra c ao com a maioria dos sistemas computacionais. Estas interfaces padronizadas (por exemplo IDE, EIDE e SCSI) trabalham com comandos de alto n vel, facilitando o trabalho de programa c ao. As controladoras geralmente possuem capacidade para tratar v arios discos simultaneamente, embora a opera c ao paralela se resuma ao acionamento das unidade de discos em busca de setores (overlapped seeks ), pois a transfer encia de dados de uma u nica unidade geralmente consome toda capacidade de processamento destas controladoras. Ainda assim, a habilidade de realizar acessos (seeks ) aos discos melhora consideravelmente a performance destas unidades. Tempo de acesso Quando e solicitada uma opera c ao de leitura ou escrita numa unidade de disco, e necess ario mover-se a cabe ca de leitura e escrita at e o setor desejado para o in cio da opera c ao. Tal tempo e determinado por tr es fatores [TAN92, p. 217] [STA96, p. 160]:
160
1. o tempo necess ario para mover-se at e o cilindro correto, ou seja , o tempo de acesso ` a trilha ou tempo de pesquisa da trilha (seek time ); 2. o tempo necess ario para a cabe ca ser posicionada no in cio do setor desejado, chamado de atraso rotacional (rotational delay ) e 3. o tempo de transfer encia dos dados, isto e, a leitura ou escrita dos dados (transfer time ou transmission time ). A soma destes tr es componentes de tempo e o que se denomina tempo de acesso (access time), ou seja, o tempo necess ario para a leitura ou escrita de um determinado setor, como indicado na Equa c ao 5.1. Estes componentes do tempo de acesso tamb em est ao representados na Figura 5.11. taccess = tseek + trotationaldelay + ttransf er (5.1)
Dado que, para a maioria das unidades de disco, o tempo de movimenta c ao entre trilhas (seek time ) e o maior dentro desta composi c ao, sua redu c ao colabora substancialmente com a performance destes dispositivos (esta e raz ao pela qual existem unidades de disco com cabe cas xas, pois nelas o seek time e zero).
Figura 5.11: Componentes do tempo de acesso de uma unidade de disco
5.4.2
Escalonamento de disco
Uma das maiores quest oes relacionadas ao desempenho das unidades de disco se relaciona a forma com que as cabe cas de leitura s ao posicionadas em fun c ao dos pedidos de leitura e escrita realizados. O controle deste atendimento e feito por algoritmos de escalonamento de disco (disk scheduling algorithms ou disk arm scheduling algorithms ). Considerando um sistema multiprogramado onde existam in umeros processos efetuando pedidos de leitura e escrita, em fun c ao da maior velocidade
161
de processamento em rela c ao a capacidade de realizar a leitura e escrita dos dados por parte da unidade de disco, e razo avel considerar que os pedidos dever ao esperar para poderem ser atendidos, portanto os processos car ao bloqueados at e suas respectivas solicita c oes serem completas. Quanto mais r apido a unidade de disco puder completar as solicita c oes, menor o tempo de espera dos processos, beneciando o sistema. Como as opera c oes solicitadas provavelmente utilizar ao setores distintos, a unidade dever a efetuar uma s erie de movimenta c oes da cabe ca de leitura para realizar o trabalho necess ario, assim sendo, quanto menor o tempo despendido na movimenta c ao da cabe ca de leitura melhor o desempenho da unidade. Esta e a justicativa da preocupa c ao com o escalonamento das tarefas de movimenta c ao das cabe cas de leitura [DEI92, p. 363]. Um algoritmo para escalonamento do disco deve ent ao proporcionar boa produtividade (throughput ), oferecer baixo tempo de resposta e apresentar razo avel previsibilidade (comportamento previs vel nas diversas situa c oes de carga). Existem v arios algoritmos para escalonamento do disco, onde alguns preocupam-se em otimizar a movimenta c ao entre trilhas e outros em aproveitar o percurso rotacional das cabe cas de leitura: FCFS (rst come rst served ) Neste algoritmo, a la de pedidos e executada na ordem em que aparecem, sem qualquer reordena c ao ou otimiza c ao de movimenta c ao. Esta forma de escalonamento pode resultar em longos tempos de espera em situa c oes de alta carga de trabalho, embora razo avel para situa c oes de baixo carregamento [DEI92, p. 366] [TAN92, p. 217]. SSTF (shortest seek time rst ) A la de pedidos e executada de forma que sejam atendidos primeiro os pedidos que exigem a menor movimenta c ao poss vel entre trilhas, qualquer que seja o sentido da movimenta c ao (setores internos para centro ou setores externos para bordas). Pedidos destinados aos setores extremos geralmente recebem baixa qualidade de servi co, podendo ocorrer um adiamento indenido (starvation ), al em disso proporciona grande vari ancia em termos de desempenho conforme a seq u encia de pedidos. E um algoritmos orientado ` a cilindros [DEI92, p. 366] [TAN92, p. 218]. SCAN uma varia E c ao do SSTF, desenvolvida por Denning em 1967, que pretendia corrigir sua vari ancia e a possibilidade de adiamento indenido. O SCAN, tal como o SSTF, tamb em trabalha escolhendo os pedidos que exigem menor movimenta c ao, mas apenas numa dire c ao preferencial, ou seja, ele primeiro realiza os pedidos numa dire c ao (p.e., do cilindro mais externo para o mais interno) para depois realizar uma mudan ca de dire c ao (do cilindro mais interno para o mais externo)
162
CAP ITULO 5. GERENCIAMENTO DE I/O completando as tarefas. Novos pedidos que v ao surgindo durante a varredura s ao atendidos se poss vel durante a varredura em andamento. Por isso tamb em e conhecido como algoritmo do elevador (elevator algorithm ). Embora os setores externos continuem a ser menos visitados que os setores intermedi arios, n ao existe a possibilidade de um adiamento indenido e a qualidade do servi co e mais regular. Para baixa carga de trabalho este e melhor algoritmo de escalonamento para disco conhecido. Tamb em e um algoritmos orientado ` a cilindros [DEI92, p. 366]. C-SCAN O algoritmo C-SCAN (circular SCAN) e uma varia c ao do algoritmo SCAN que elimina a quest ao de atendimento diferenciado para os cilindros extremos. O C-SCAN atende os pedidos, na ordem em que exigem menor movimenta c ao, seguindo uma dire c ao pr e-denida: do cilindro mais externo para o mais interno. Ao nalizar os pedidos nesta dire c ao, o bra co e deslocado para o pedido que necessita o setor mais externo sendo reiniciada a varredura. Para uma carga de trabalho m edia este algoritmo proporciona os melhores resultados. Se tamb em otimizado para minimizar o atraso rotacional, torna-se o melhor algoritmo, inclusive para alta carga de trabalho [DEI92, p. 369]. N-SCAN O algoritmo N-SCAN (n step SCAN) e uma outra varia c ao do SCAN. Sua movimenta c ao e semelhante ao SCAN, exceto pelo fato que apenas os pedidos pendentes s ao atendidos ` a cada varredura. Os pedidos que chegam durante uma varredura s ao agrupados e ordenados para serem atendidos no retorno da varredura. Proporciona boa performance e bom tempo de resposta m edio com pequena vari ancia, n ao existindo a possibilidade de adiamento innito para quaisquer pedidos [DEI92, p. 368]. Eschenbach A movimenta c ao e semelhante ao C-SCAN, mas cada cilindro tem sua trilha percorrida por completo, sendo os pedidos reordenados durante este percurso. Para pedidos em setores sobrepostos apenas um e uma estrat atendido na varredura corrente. E egia para otimiza c ao do atraso rotacional, embora o C-SCAN se prove melhor [DEI92, p. 365].
Em situa c oes de grande carga de trabalho, deve ser considerada a otimiza c ao rotacional, ou seja, dado que aumentam as possibilidades de dois ou mais pedidos se referenciarem a mesma trilha. Uma estrat egia semelhante ao SSTF para a otimiza c ao rotacional e o algoritmo SLTF (shortest latency time rst ) que procura atender os pedidos com menor atraso rotacional dentro da trilha corrente [DEI92, p. 370].
163
Veja na Figura 5.12 uma compara c ao destes algoritmos de escalonamento de disco supondo um disco de 40 cilindros, com a cabe ca inicialmente sobre o cilindro n umero 11, cujos pedidos indicam cilindros: 2, 36, 16, 34, 9 e 12. Os gr acos representam a movimenta c ao da cabe ca de leitura segundo um algoritmo espec co para atender a s erie dada de pedidos. Se considerarmos que entre duas trilhas distintas existe um percurso que pode ser calculado por: P ercurso = |trilhaf inal trilhainicial | (5.2)
Ent ao o percurso total realizado para atendimento de n pedidos e a somat oria dos percursos individuais, ou seja: P ercursototal = P ercursoi (5.3)
As unidades de discos ex veis (oppies comuns e ZIP disks) tamb em funcionam segundo os mesmos princ pios e possuem a mesma organiza c ao, exceto pelo fato de possu rem cabe cas de leitura/escrita de contato e que utilizam o algoritmo de escalonamento de disco FCFS. Na Tabela 5.2 temos a organiza c ao de um disco ex vel de 3.5 com qu adrupla densidade [NOR89, p. 100]. Tabela 5.2: Organiza c ao de um oppy de 1.44 Mbytes N umero de Superf cies 2 N umero de Cilindros 80 N umero de Trilhas por Cilindro 2 N umero de Setores por Trilha 9 Tamanho do Setor (bytes ) 512 Capacidade Total (bytes ) 1.474.560 Na trilha 0 do lado 0 de um disquete de qu adrupla densidade temos 9 setores ocupados respectivamente por: um setor de boot, quatro setores destinados ` a tabela de aloca c ao de arquivos (FAT propriamente dita, como veremos na se c ao ???) e quatro setores para a organiza c ao do diret orio do disquete. Na trilha 0 do lado 1 temos os tr es u ltimos setores destinados ` a organiza c ao do diret orio e seis setores destinados aos dados. Nas demais trilhas do disquete teremos nove setores de dados cada. O registro de boot sempre est a localizado na trilha 0 e setor 0 de disquetes. Nele pode ser colocado um pequeno programa destinado a iniciar o processo de carregamento do sistema operacional, possibilitando que este disquete possa dar a partida do sistema. Cada sistema operacional possui um formato diferente para o conte udo do registro de boot, mas a id eia central e sempre a mesma.
164
Figura 5.12: Compara c ao dos algoritmos de escalonamento de disco
165
5.4.3
Unidades de ta
As unidades de ta magn etica s ao outro importante dispositivo de I/O tendo sido os primeiros perif ericos utilizados para o armazenamento secund ario nos sistemas computacionais. Utiliza os mesmos princ pios f sicos para o armazenamento perene de dados: uma na ta pl astica (de Mylar ou material semelhante) e recoberta com algum oxido met alico cujas propriedades magn eticas possibilitam que atrav es de uma cabe ca leitura se realize a grava c ao ou leitura de dados na ta. As tas, acondicionadas em rolos ou cartuchos de v arios tipos e tamanhos, s ao movimentadas tal como gravadores de audio de ta em rolo ou cassete, embora tipicamente com maior velocidade. A cabe ca leitura, que trabalha em contato direto com a ta pl astica, grava simultaneamente v arios bits de informa c ao na ta, paralelamente ao sentido do comprimento da ta, de forma que nesta sejam identicadas trilhas de grava c ao (tracks ). O n umero de trilhas existente e vari avel, dependendo do tipo de unidade de ta e da ta magn etica que utiliza, mas valores usuais s ao 9, 18 ou 36 trilhas, para a grava c ao paralela de um byte, word ou double word por vez respectivamente, juntamente com alguns bits extras utilizados para o controle de paridade [STA96, p. 174]. Cada bloco de informa c ao gravada, 128, 256 ou 512 bytes, e identicado como um registro f sico (physical record ), separado do registro anterior e posterior por espa cos denominados espa cos inter-registro (inter-record gaps ). Veja na Figura 5.13 a representa c ao esquem atica da organiza c ao de uma ta magn etica contendo 9 trilhas.
Figura 5.13: Formato esquem atico de ta magn etica Diferentemente das unidade de disco, que s ao dispositivos de acesso direto, as unidades de ta magn etica s ao conhecidas como dispositivos de acesso seq uencial, pois para efetuar-se a leitura de um determinado registro f sico, todos os registros existentes entre a posi c ao inicial da cabe ca de leitura e o registro desejado devem ser lidos. Se o registro desejado estiver localizado numa posi c ao anterior a posi c ao corrente, ent ao a ta ou cartucho dever ao ser rebobinados at e o seu in cio ou posi c ao anterior adequada para que a pesquisa pelo registro desejado possa ser iniciada. Claramente temos que as unidades de ta s ao dispositivos mais lentos que as unidades de disco.
166
O tempo de acesso (access time ) para uma unidade de ta magn etica tamb em e dado pela soma de tr es componentes de tempo, representados na Figura 5.14: 1. o tempo necess ario para a cabe ca de leitura come car a ser movimentada, chamado de tempo de atraso de movimenta c ao (move delay ); 2. o tempo necess ario para mover-se at e o registro f sico, ou seja , o tempo de acesso ao registro (seek time ) e 3. o tempo de transfer encia dos dados, isto e, o tempo decorrido nas opera c oes de leitura ou escrita dos dados no registro (transfer time ou transmission time ). Sendo assim, o tempo de acesso pode ser determinado como indicado na Equa c ao 5.4. taccess = tmovedelay + tseek + ttransf er (5.4)
Devido ao fato das unidades de ta magn etica terem cabe cas de leitura de contato, isto e, que para lerem os dados s ao mantidas em contato com a ta, a movimenta c ao da ta s o ocorre durante as opera c oes de leitura ou escrita minimizando tanto o desgaste da ta magn etica como da cabe ca de leitura. Da a exist encia do atraso de movimenta c ao que corresponde ao tempo necess ario para o acionamento do mecanismo de movimenta c ao da ta. Veja na Figura 5.14 uma representa c ao esquem atica dos componentes do tempo de acesso de uma unidade de ta.
Figura 5.14: Componentes do tempo de acesso de uma unidade de ta Nos discos ex veis ocorre o mesmo que nas unidades de ta: a movimenta c ao s o ocorre durante as opera c oes de leitura e escrita, pois a cabe ca de leitura tamb em e do tipo de contato, sendo que depois da opera c ao a
167
movimenta c ao e interrompida. Nos discos r gidos, o mecanismo de movimenta c ao dos discos permanece ativo durante todo o tempo, exceto nos casos de economia de energia, onde o mecanismo de acionamento e desativado para redu c ao do consumo, t pico em computadores port ateis ou pessoais. Em sistemas computacionais de grande porte, podem existir procedimentos especiais para que unidades de ta magn etica, geralmente pr oximas ao computador central, possam ser utilizadas pelos usu arios do sistema. Apesar da velocidade bastante mais baixa, as unidades de ta magn etica ainda s ao largamente utilizadas, pois a m dia utilizada e remov vel e barata. Atualmente os formatos de ta em rolo est ao caindo em desuso, sendo preferidos os formatos tipo cartucho, cujas capacidades de grava c ao podem ser superiores a 1 GByte por cartucho, congurando um dispositivo de armazenamento secund ario compacto e de baix ssimo custo por MByte. Devido ` a velocidade e custo, as aplica c oes mais comuns das tas magn eticas s ao a realiza c ao de c opias de seguran ca (backups ) e o transporte manual de grandes quantidades de dados (por exemplo, RAIS, IR, folha de pagamento, rela c ao de recebimento para concession arias de servi cos p ublicos etc).
5.4.4
Terminais
Todos os sistemas computacionais, de qualquer porte, que oferecem servi cos interativos para v arios usu arios simult aneos, utilizam terminais para realizar a comunica c ao entre os usu arios e os computadores. Os terminais tamb em s ao denominados TTY (teletype ), devido a uma empresa de mesmo nome que tornou-se conhecida pelo seus equipamentos. Existem v arios tipos diferentes de terminais os quais empregam diferentes tecnologias e estrat egias para seu funcionamento. Na Figura 5.15 temos uma classica c ao dos terminais, semelhante a sugerida por Tanenbaum [TAN92, p. 227].
Figura 5.15: Tipos de terminais Os terminais baseados na interface RS-232 utilizam um protocolo de comunica c ao serial para a transmiss ao de dados entre o computador e o terminal, onde um u nico caractere e transmitido por vez, a taxa de 1200 a 9600 bps (bits por segundo), como ilustrado na Figura 5.16. Esta forma
168
de comunica c ao se tornou t ao comum que v arios fabricantes desenvolveram circuitos integrados (chips) especializados nesta tarefa, chamados de UARTs (Universal Asynchronous Receiver Transmitter), entre os quais citamos o popular Intel 8255. Apenas a transmiss ao de um u nico caractere a 9600 bps toma aproximadamente 1 ms, portanto uma tela de 25 linhas por 80 colunas (2000 caracteres), tomaria 2 segundos para ser preenchida completamente.
Figura 5.16: Protocolo de comunica c ao serial Os terminais que utilizam este protocolo s ao compostos por um teclado, um monitor de v deo e alguns circuitos eletr onicos que implementam a l ogica de controle necess aria ao seu funcionamento, sendo portanto equipamentos de custo relativamente baixo. A UART interna do terminal e conectada a interface RS-232 do computador via um cabo de tr ` es os (terra, transmiss ao e recep c ao). A interface RS-232 do computador deve possuir tantas conex oes e UARTs quantos terminais a serem conectados, como ilustrado na Figura 5.17. Tal forma de conex ao, com o passar do anos, come cou a se tornar um inconveniente dado o n umero crescente de terminais de um sistema computacional. O funcionamento desta conex ao pode ser descrito da seguinte maneira: 1. Quando o terminal deseja enviar um caractere ao computador (para estabelecer uma conex ao com o sistema ou para enviar dados e comandos do usu ario), ele o envia para sua UART. 2. Quando a UART efetua a transmiss ao do caractere, gera uma interrup c ao indicando que pode transmitir outro caractere. 3. A UART do computador recebe o caractere, processando-o, enviando uma resposta quando devido. 4. A UART recebe o caractere, gerando uma interrup c ao para o processamento do caractere no terminal. Os terminais de c opia impressa (hardcopy ), percursores dos terminais de v deo, imprimem em papel todas as mensagens recebidas do computador. Atrav es de seu teclado as mensagens s ao enviadas do terminal para o computador. Os terminais CRT (catodic ray tube ) s ao os terminais que utilizam monitores de v deo para exibi c ao das mensagens, operando da mesma forma que os terminais hardcopy.
169
Figura 5.17: Conex ao computador e terminais RS-232
Os terminais inteligentes s ao pequenos computadores especializados na transmiss ao e recep c ao de mensagens, possuindo in umeras fun c oes de congura c ao, possibilitando sua congura c ao para o trabalho com diferentes computadores em situa c oes diversas. Dada sua capacidade interna de processamento, podem armazenar seq u encias de dados ou realizar tarefas mais complexas. Outra categoria dos terminais s ao aqueles que possuem mem oria mapeada, isto e, cuja interface com o computador principal se d a atrav es de sua mem oria de v deo (v deo RAM) e um controlador especial denominado controlador de v deo (v deo controller). Nesta situa c ao, o terminal deve possuir capacidade interna de processamento, podendo se comunicar com o computador central atrav es de outras formas mais ecientes tais como os protocolos BSC (binary synchronous control ) introduzido pela IBM em 1961, o padr ao ISO HDLC (high-level data link control ) ou o SDLC (synchronous data link control ), vers ao IBM do protocolo HDLC. Black [BLA87] traz detalhes destes protocolos, comparando-os e mostrando suas aplica c oes. A fam lia IBM 3270 e um conjunto de terminais, impressoras e controladoras de terminais tipicamente utilizados em sistemas de grande porte IBM, sendo bastante conhecidas em diversos segmentos corporativos. Os terminais de v deo IBM 3178 e 3278 s ao seus integrantes os mais conhecidos, com alguns milh oes de unidades vendidas [BLA87, p. 83]. Estes terminais, conectados atrav es de cabos coaxiais, utilizam um protocolo propriet ario da IBM para comunica c ao com controladoras de terminais (IBM 3172 e 3174), que concentravam tal comunica c ao para um computador central, possibilitando in umeras congura c oes, como ilustrado na Figura 5.18. O processador do terminal, tendo recebido as informa c oes do computador central atrav es de sua conex ao dedicada, coloca as informa c oes que devem ser exibidas na mem oria de v deo enquanto o controlador de v deo gera o sinal correspondente ao conte udo da mem oria de v deo, produzindo a imagem
170
Figura 5.18: Fam lia IBM 3270
adequada, liberando o processador de tal tarefa. O princ pio e o mesmo para os terminais orientados ` a caractere, onde a mem oria de v deo e preenchida com os caracteres e atributos para sua exibi c ao; ou orientados ` a bit, onde a mem oria de v deo e preenchida com os pontos (pixels ) que devem ser renderizados. Nos terminais orientados ` a caractere apenas telas constitu das de caracteres e uma limitada quantidade de s mbolos gr acos podem ser compostas e exibidas, restringindo as suas possibilidades de utiliza c ao. J a os terminais orientados ` a mphbit permitem a exibi c ao de gr acos e imagens, caracteres usando m ultiplos fontes, sistemas de janelas, cones, cuja resolu c ao (quantidade total de pixels que podem ser apresentados numa u nica imagem) dependente da quantidade de mem oria de v deo, das capacidades do monitor de v deo e do meio de transmiss ao. As telas s ao reproduzidas em ciclos de 20 ms (terminais monocrom aticos) e 17 ms (terminais coloridos) permitindo a r apida exibi c ao de caracteres. O teclado, nesta congura c ao tamb em tornase completamente independente, interrompendo o processador do terminal para enviar seq u encias de caracteres. Os microcomputadores IBM PC e compat veis utilizam esta estrat egia para exibi c ao de seus v deos, podendo possuir controladores de v deo bastante sosticados, destinados a reprodu c ao de imagens em alta velocidade (v deo) ou renderiza c ao em 2D e 3D.
5.5. SISTEMAS DE ARQUIVOS
171
5.5
Sistemas de arquivos
Como vimos na se c ao 4.3, os dispositivos de armazenamento secund ario s ao utilizados para armazenar dados de forma perene, isto e, o armazenamento e feito de forma con avel e ntegra, mesmo quando o sistema computacional permanece desligado por longos per odos de tempo. O armazenamento perene de informa c oes e desejado pelas seguintes raz oes [TAN92, p. 145]: Existem in umeros problemas pr aticos que requerem o armazenamento de grandes quantidades de informa c oes, as quais n ao ser ao utilizadas totalmente por um certo processo, por exemplo, consultas a uma lista telef onica, movimenta c ao de uma conta corrente, recupera c ao de um hist orico escolar, altera c ao de um cadastro m edico, atualiza c ao de uma inadmiss cha de estoque etc. E vel que tais informa c oes sejam reintroduzidas no computador a cada uso. Existem uma outra innidade de problemas pr aticos que produzem dados durante sua execu c ao, raz ao de sua exist encia, que n ao podem ser descartados pois ser ao utilizados por outros processos, tal como o cruzamento de dados informados em declara c oes de imposto de renda, o resultado de simula c oes f sicas/qu micas/matem aticas, a solu c ao de problemas diversos etc. Certos conjuntos de dados n ao podem pertencer a um u nico processo, isto e, serem dispostas no espa co de endere camento de um simples programa, devendo ser compartilhada por muitos outros processos, tal como os dados de lota c ao de avi oes de uma companhia a erea, as informa c oes de tarifa c ao de uma companhia telef onica etc. Os sistemas computacionais est ao sujeitos ` a falhas ou situa c oes de conting encia, onde e importante que seus dados estejam preservados (duplicados) de forma segura, permitindo sua recupera c ao e uso em um outro sistema computacional. Todas estas raz oes justicam a necessidade do armazenamento de informa c oes em meios distintos da mem oria prim aria, que tem capacidade limitada, e de forma independente dos processos, dada as quest oes de persist encia e compartilhamento, sem considerarmos as quest oes relacionadas a integridade e seguran ca dos dados. Para que o armazenamento possa ser realizado de maneira tal a atender as raz oes enunciadas, e necess aria uma adequada organiza c ao destes dados nos dispositivos destinados ao armazenamento secund ario, tal como unidades de disco, unidades de ta magn etica, CD-ROMs etc. Dado que podem existir muitos processos num sistema computacional, cada um utilizando e produzindo diferentes conjuntos de dados, torna-se
172
necess ario distinguir tais conjuntos de dados. Os arquivos (les ) s ao as unidades que cont em estes conjuntos distintos de dados, de forma que estes possam ser utilizados pelos processos. Como tudo mais num sistema computacional, o sistema operacional controla as opera c oes sobre os arquivos, organizando seu armazenamento no que chamamos de sistema de arquivos (le system ). Um sistema de arquivos geralmente cont em [DEI92, p. 389]: M etodos de acesso: forma com que os dados s ao armazenados nos arquivos; Gerenciamento de arquivos: conjunto de mecanismos de armazenamento, refer encia, compartilhamento e seguran ca; Mecanismos de integridade: que asseguram que os dados de um arquivo permanecem ntegros. Ainda segundo Deitel [DEI92, p. 391], um sistema de arquivos deve permitir, funcionalmente falando, que: os usu arios possam criar, modicar e eliminar arquivos, bem com realizar sua duplica c ao ou a transfer encia de dados entre arquivos; seja poss vel o compartilhamento de arquivos atrav es de mecanismos controlados e bem denidos; as opera c oes de backup e sua restaura c ao sejam suportadas; seja poss vel a ado c ao ou implementa c ao de procedimentos de prote c ao e seguran ca; e que a interface seja amig avel e consistente, admitindo a realiza c ao de opera c oes apenas atrav es dos nomes simb olicos dos arquivos, garantindo independ encia do dispositivo utilizado. Com isto percebemos que os sistemas de arquivos preocupam-se com a organiza c ao e controle do armazenamento secund ario de um sistema computacional. Tamb em e necess ario destacar que um sistema operacional pode suportar diversos sistemas de arquivos, isto e, podem operar utilizando diferentes formas de administra c ao dos dispositivos de armazenamento secund ario. A seguir, na Tabela 5.3, alguns exemplos de sistemas operacionais e dos sistemas de arquivos suportados.
173
Tabela 5.3: Sistemas de arquivos de alguns sistemas operacionais

Sistema operacional MS-DOS MS-Windows 95/98 MS-Windows NT MS-Windows 2000 MS-Windows XP IBM OS/2 Linux Sistemas de arquivos suportados FAT (le allocation table ) 12 e 16 bits FAT (le allocation table ) 12 e 16 bits VFAT (virtual le allocation table ) 32 bits FAT (le allocation table ) 12 e 16 bits VFAT (virtual le allocation table ) 32 bits NTFS (new technology le system ) FAT (le allocation table ) 12 e 16 bits HPFS (high performance le system ) FAT (le allocation table ) 12 e 16 bits VFAT (virtual le allocation table ) 32 bits Minix (Mini Unix) Extended File System Ext2 (second extended le system - Nativo) Sun Solaris UFS
5.5.1
Arquivos
Existem v arias deni c oes poss veis para o conceito de arquivos. Tanembaum arma que, de forma simplicada, os arquivos podem ser entendidos como seq u encias de bytes n ao interpretadas pelo sistema, dependendo-se de aplica c oes apropriadas para sua correta utiliza c ao [TAN95, p. 246]. Deitel coloca que arquivos s ao uma cole c ao identicada de dados [DEI92, p. 389], enquanto Guimar aes explica: Um arquivo e um conjunto de informa c oes relacionadas entre si e residentes no sistema de mem oria secund aria: discos, tas, cart oes, etc [GUI86, p. 211]. Outras deni c oes poderiam ser citadas, mas o que e mais importante e o conceito inerente ` a utiliza c ao dos arquivos. Arquivos s ao um poderoso mecanismo de abstra c ao que permite ao usu ario (e seus programas) utilizar dados armazenados dentro do sistema computacional, ou seja, atrav es da manipula c ao dos arquivos s ao realizadas as opera c oes de escrita e leitura de dados, de forma transparente, evitando que sejam conhecidos detalhes do funcionamento com que estas opera c oes tratam e armazenam a informa c ao [TAN92, p. 146]. Os arquivos, dependendo do sistema operacional e do sistema de arquivos em uso, podem possuir uma identica c ao (le naming ), atributos (attributes ), capacidades (capacities ), lista de controle de acesso (control access list ) e uma organiza c ao ou tipo. Para que os dados possam ser corretamente identicados e utilizados, o sistema de arquivos deve prover um mecanismo de identica c ao dos arquivos, isto e, uma forma de distin c ao simples dos arquivos, que permita
174
sua adequada opera c ao. Isto e feito atrav es da associa c ao de um nome ao arquivo propriamente dito. Desta forma muitas das opera c oes que podem ser realizadas sobre os arquivos s ao especicadas em termos de seus nomes, simplicando muito tais tarefas. Diferentes sistemas operacionais usam formas de denomina c ao distintas para a identica c ao de seus arquivos, como exemplicado na Tabela 5.4. Tabela 5.4: Denomina c ao de arquivos em v arios sistemas
Sistema operacional MS-DOS (FAT12 e FAT16) MS-Windows 95, 98, 2000, XP (VFAT) MS-Windows NT (NTFS) IBM OS/2 (HPFS) UNIX (gen erico) Composi c ao do nome 1-8 char 1-255 char Composi c ao da extens ao 1-3 char 1-255 char Outras caracter sticas Extens ao opcional Insens vel ao caixa Admite m ultiplas exts Comprimento total < 256 Insens vel ao caixa Admite m ultiplas exts Comprimento total < 256 Insens vel ao caixa Extens ao opcional Comprimento total < 256 Insens vel ao caixa N ao usa extens oes Comprimento total < 256 Sens vel ao caixa
1-255 char
1-255 char
1-255 char
1-255 char
1-255 char
1-255 char
Note que o UNIX, dado possuir um sistema de arquivos com denomina c ao sens vel ao caixa, trataria como sendo diferentes arquivos com os nomes ab, AB, Ab e aB. Tal caracter stica, embora u til, pode se tornar um pesadelo em certas situa c oes quando n ao se percebe a sutileza de um u nico caractere com o caixa errado. Nos sistemas que n ao utilizam extens oes ou admitem m ultiplas extens oes, podem surgir denomina c oes tais como names.dat.old ou source.c.gzip, indicando que diferentes a c oes foram tomadas com os arquivos. Al em dos nomes os arquivos podem possuir atributos, isto e, informa c oes que n ao fazem parte dos arquivos, embora associadas aos mesmos, que podem ser utilizadas para indicar: criador (creator ), propriet ario (owner ), tamanho (size ), data de cria c ao (creation date ), data do u ltimo acesso (last access date ), data da u ltima altera c ao (last modication date ), ags diversas (de sistema, oculta c ao, de arquivo, de leitura etc) permiss oes de acesso, tamanho do registro, tamanho m aximo, tipo etc. As permiss oes de acesso s ao usadas em conjunto com as capacidades ou listas de controle de acesso. As capacidades s ao informa c oes que autorizam certos usu arios ou processos a realizarem certas opera c oes sobre os arquivos, tal como leitura e escrita. As listas de controle de acesso s ao rela c oes de usu ario que podem realizar opera c oes espec cas sobre um dado arquivo, tal como execu c ao ou
175
escrita. Enquanto as capacidades s ao associadas aos usu arios ou processos as listas de acesso s ao associadas diretamente aos arquivos. Os sistemas UNIX utilizam-se de uma lista de acesso simplicada baseada no conceito de grupos. Permiss oes s ao associadas a todos os arquivos e podem ser diferenciadas em tr es n veis: o do propriet ario, o do grupo ao qual pertence seu propriet ario e dos demais usu arios. Para cada n vel podem ser especicadas separadamente permiss oes para leitura, escrita e execu c ao, que quando combinadas resultam em diferentes modos de acesso. J a o MS-DOS associa apenas um mphbit de permiss ao de escrita (Read-Only ), ao qual se associam os atributos Oculto (Hidden ), Sistema (System ) e Arquivo (Archive ), que na pr atica representam um prec ario esquema de prote c ao contra elimina c ao indevida. Existem diversas estruturas poss veis para os arquivos tais como seq uencial, por registros e em arvore [TAN92, p. 148], tal como ilustrado na Figura 5.19.
Figura 5.19: Estruturas poss veis de arquivos Na estrutura seq uencial, um arquivo e uma seq u encia de bytes, garantindo a m axima exibilidade ao usu ario do sistema operacional que oferece opera c oes bastante simples. Na estrutura de registro, um arquivo e uma seq u encia de registros, os quais podem ter diversos formatos. Esta estrutura e um pouco menos ex vel e depende de opera c oes um pouco mais sosticadas do SO. Existem diversos arranjos para arquivos organizados como seq u encias de registros: registro de tamanho xo desbloqueados, registro de tamanho xo bloqueado, registro de tamanho vari avel desbloqueados e registro de tamanho vari avel bloqueado [DEI92, p. 393]. Sistemas operacionais como DOS, MS-Windows 95, 98 e NT e Unix estruturam seus arquivos como seq u encias de bytes. Computadores de grande porte, tipicamente os sistemas IBM utilizam, como organiza c ao mais comum, as seq u encias de registro. A organiza c ao em arvore e raramente implementada.
176
Dependendo do conte udo do arquivo este pode ser entendido como de um certo tipo. Muitos sistemas operacionais utilizam a extens ao do nome do arquivo como uma refer encia para o tipo de seu conte udo. Particularmente nos sistemas operacionais MS-Windows 95, 98, NT, 2000 ou XP podem ser associadas aplica c oes a determinadas extens oes, auxiliando o usu ario. Genericamente arquivos comuns, isto e, aqueles utilizados pelos usu ario para o armazenamento de informa c oes, podem ser considerados como do tipo texto, quando seu conte udo pode ser visualizado diretamente (via comandos DOS type [IBM92a] ou Unix more [CON99, p. 132]); ou sendo bin ario, quando seu conte udo precisa ser interpretado por uma aplica c ao para poder ser visualizado. Os arquivos execut aveis tamb em s ao arquivos bin arios, cuja execu c ao e realizada diretamente pelo sistema operacional. Vale ressaltar que um arquivo bin ario n ao e simplesmente uma seq u encia de instru c oes que podem ser executadas pelo processador, al em do c odigo execut avel propriamente dito o sistema operacional necessita conhecer informa c oes adicionais sobre o tamanho do programa, sua area de dados, o tamanho necess ario para sua pilha de retorno, etc.
Figura 5.20: Formato de arquivos execut aveis no Win-32 Geralmente estas informa c oes s ao posicionadas num cabe calho (header ) do arquivo sendo que cada sistema operacional possui um formato pr oprio de arquivo identicado como execut avel. Na Figura 5.20 encontramos os formatos de arquivos execut aveis do sistemas operacionais DOS, Windows 3.x e Windows 95 enquanto que Figura 5.22 mostra a estrutura de um arquivo execut avel no sistema Unix com detalhes de seu cabe calho. Especicamente no sistema operacional Windows 95/98 e Windows NT e poss vel visualizarse detalhes internos de arquivos execut aveis e bibliotecas de v nculo din amico (DLLs ou dynamic link libraries ) tais como cabe calho da imagem, cabe calho opcional, tabela de importa c ao, tabela de se c oes e informa c oes do cabe calho. Isto e poss vel atrav es da op c ao de visualiza c ao r apida oferecida pelo gerenciador de arquivos nativo, como ilustrado na Figura 5.21.
177
Figura 5.21: Visualiza c ao r apida de execut aveis no MS-Windows 98 Al em dos arquivos comuns, os sistemas de arquivos geralmente mant em arquivos especiais denominados diret orios (directories ) que cont em partes da estrutura do sistema de arquivos. Em sistemas Unix ainda existem arquivos especiais utilizados para modelar certos dispositivos perif ericos, podendo ser arquivos especiais de caracteres (character special les ) ou arquivos especiais de blocos (block special les ) que permitem o acesso terminais, impressoras e rede no primeiro caso, discos, tas e outros dispositivos de armazenamento secund ario no segundo. Finalmente, do ponto de vista de armazenamento e acesso, os arquivos podem ser organizados das seguintes maneiras [DEI92, p. 392]: Seq uencial Quando os registros ou bytes s ao posicionados em sua ordem f sica. Numa ta isto representa armazenamento cont guo, embora em discos magn eticos isto n ao seja necessariamente verdade. Direto Quando os registro ou bytes s ao diretamente acessados no meio em que s ao armazenados, usualmente um DASD. A aplica c ao deve conhecer a localiza c ao dos dados no dispositivo, sendo familiar com sua um m organiza c ao. E etodo extremamente r apido, embora complexo. Seq uencial Indexado Os registros bytes s ao organizados numa seq u encia l ogica conforme uma chave e o sistema mant em um ndice para acelerar
178
Figura 5.22: Formato de arquivos execut aveis (binaries ) no Unix o acesso a determinadas partes de um arquivo. Esta e uma forma de organiza c ao comum em tabelas de bancos de dados. Particionado Quando o arquivo e composto de subarquivos denominados membros. Para acessar seus membros (members ), o arquivo particionado possui um diret orio, que funciona como seu ndice. S ao utilizados para armazenar bibliotecas ou bancos de dados.
5.5.2
Diret orios
Um diret orio (directory ) nada mais e que um arquivo mantido pelo sistema de arquivos que cont em uma lista de arquivos e possivelmente outros diret orios. Desta forma e poss vel criar-se estruturas hier arquicas de arquivos, onde os diret orios existentes dentro de outros s ao denominados subdiret orios, tal como nos sistemas Unix, OS/2, DOS, Windows e outros. O que motivou a cria c ao dos diret orios e o fato de que torna-se dif cil a organiza c ao de um n umero grande de arquivos armazenados num determinado dispositivo sem qualquer forma de divis ao. Os primeiros dispositivos de armazenamento secund ario tinham pequena capacidade o que resultava no armazenamento de um pequeno n umero de arquivos, catalogados num diret orio u nico associado ao pr oprio dispositivo. A medida que a capacidade de armazenamento destes dispositivos cresceu, as unidades de disco passaram a armazenar v arios milhares de arquivos, assim a apresenta c ao de uma simples listagem dos arquivos existentes signicaria para o usu ario visualizar muitas telas repletas de nomes. O sistema operacional DOS, em sua vers ao 1.0 lan cada em 1981, suportava apenas um diret orio u nico por dispositivo, usualmente discos ex veis de limitada capacidade. Com a introdu c ao de suporte para discos r gidos de maior capacidade na vers ao 2.0 liberada em 1983, foram adicionadas capacidades para cria c ao e manuten c ao de diret orios e subdiret orios [JAM87, p. 25].
179
A cria c ao de diret orios permite que os arquivos sejam divididos e organizados conforme seu tipo, propriet ario, utiliza c ao ou qualquer outro crit erio, possibilitando seu acesso de forma mais simples. Como mostra a Figura 5.23, existem v arias organiza c oes poss veis de diret orios, tais como em um n vel, em dois n veis ou em m ultiplos n veis (ou em arvores).
Figura 5.23: Organiza c oes Poss veis de Diret orios Tamb em e poss vel organizar-se os diret orios como grafos ac clicos (acyclic graph directories ) que permite que um arquivo ou mesmo um diret orio seja apontado por m ultiplas entradas presentes em diferentes diret orios, ou seja, que tal arquivo ou diret orio simultaneamente presentes como conte udo de v arios diret orios ao mesmo tempo, permitindo seu compartilhamento [SG00, p. 356]. Isto e comum em sistemas UNIX, onde podem ser criados links apontando os arquivos ou diret orios compartilhados. Internamente os diret orios s ao organizados como um conjunto de entradas, uma para cada arquivos ou subdiret orio que cont em. A cada uma destas entradas s ao associados atributos que descrevem as permiss oes associadas aos arquivos, os endere cos onde o arquivo est a sicamente armazenado no dispositivo e outras informa c oes tais como tamanho do arquivo, data de cria c ao, etc. como visto na se c ao 5.5.1. No sistema de arquivos FAT (le allocation table ) do MS-DOS e outros sistema operacionais, uma entrada t pica de diret orio possui a estrutura ilustrada na Tabela 5.5 [JAM87, p. 266] [NOR89, p. 106] [TAN92, p. 167]. Nos sistemas Unix as entradas de diret orios s ao bem mais simples, como mostra a Tabela 5.6. Quando s ao solicitadas opera c oes sobre arquivos, tais como abertura ou cria c ao de um arquivo, o sistema operacional consulta o diret orio corrente
180
Tabela 5.5: Entrada de diret orio do sistema de arquivos FAT Campo Tamanho (bytes) Nome do arquivo 8 Extens ao 3 Atributos 1 Reservado para DOS 10 Hora 2 Data 2 N umero do Setor Inicial 2 Tamanho do Arquivo 4 Total 32 Tabela 5.6: Entrada de diret orio de sistemas Unix Campo Tamanho (bytes) N umero do I-Node 2 Nome do Arquivo 14 Total 16 (current directory ), isto e, o diret orio que est a sendo consultado no momento, vericando a exist encia do arquivo desejado para abertura ou a possibilidade de cria c ao de um novo arquivo segundo as regras de identica c ao do sistema. A exist encia de uma estrutura de diret orios traz como implica c ao direta a necessidade de uma forma de denomina c ao u nica dos arquivo considerandose o sistema como um todo. Da mesma forma que n ao e poss vel a exist encia de dois arquivos de mesmo nome em um mesmo diret orio, dois arquivos ou diret orios quaisquer n ao podem ter a mesma denomina c ao do ponto de vista do sistema. Esta denomina c ao sist emica dos arquivos e chamada de especica c ao completa do caminho do arquivo ou apenas caminho do arquivo (pathname ) e deve permitir a identica c ao u nica de qualquer arquivo ou diret orio do sistema. A especica c ao de caminho de arquivo pode ser absoluta (absolute pathname ) ou relativa (relative pathname ) quando se refere a diret orio corrente. Muitas vezes o diret orio corrente e tratado como diret orio de trabalho (working directory ). Os caminhos de arquivos para arquivos ou diret orios s ao formados pelo nome dos diret orios nos quais est ao contidos, sendo que utiliza-se um caractere especial, que n ao pode ser utilizado na denomina c ao de arquivos e diret orios, como O sistemas operacionais DOS e Windows utilizam-se de uma estrutura de diret orios hierarquicamente organizada, tal como nos sistemas Unix,
181
diferenciando-se pelo caractere de separa c ao de nomes e principalmente pela forma de denomina c ao de dispositivos. Enquanto que no Unix os dispositivos s ao tratados como arquivos especiais e mapeados diretamente no sistema de arquivos a partir de diret orios arbitr arios, isto e, especicados pelo usu ario durante a congura c ao ou opera c ao do sistema atrav es do comando mount [CON99, p. 224], tanto o DOS como o Windows d ao uma denomina c ao espec ca para cada dispositivo f sico, chamando-os de unidades. Sendo assim, qualquer que seja o dispositivo de armazenamento, ou seja, para oppies, discos, CD-R/RWs etc., sempre temos um diret orio raiz para cada unidade. Da a necessidade de adicionar-se a especica c ao da unidade ao caminho absoluto e tamb em a impossibilidade de especicar-se caminhos relativos envolvendo unidades distintas.
Figura 5.24: Estrutura de diret orio de um sistema Unix Na maioria dos casos, os sistemas operacionais utilizam-se de diret orios particulares para armazenamento de arquivos espec cos, como mostra a Tabela 5.7.
5.5.3
Servi cos do sistema operacional
O sistema operacional, atrav es de seu sistema de arquivo, deve prover um conjunto de opera c oes para manipula c ao dos arquivos e de seu conte udo e tamb em dos diret orios. Do ponto de vista dos arquivos, visto como unidades, devem ser oferecidas as seguintes opera c oes [DEI92, p. 389] [TAN92, p. 153]: Abertura (open ) prepara arquivo para uso.
182
Tabela 5.7: Diret orios espec cos

Sistema operacional DOS Windows 95/98 Diret orio DOS TMP ou TEMP Windows Windows\System Windows\Temp Windows\Command Arquivos de Programa Meus Documentos usr home bin etc OS2 OS2\System OS2\MDOS Prop osito Arquivos do sistema Arquivos tempor arios Utilit arios do sistema Arquivos do sistema Arquivos tempor arios Arquivos do DOS Produtos instalados Arquivos do usu ario Programas de usu arios Diret orios de usu arios Arquivos bin arios do sistema Arquivos diversos de cong. Utilit arios do sistema Arquivos do sistema Arquivos do DOS
Unix
OS/2
Fechamento (close ) encerra o uso do arquivo evitando sua altera c ao. Cria c ao (create ) cria um novo arquivo. Elimina c ao (erase, delete ou destroy ) remove um arquivo. Renomea c ao (rename ) troca o nome de um arquivo. C opia (copy ) copia o conte udo de um arquivo para outro. Exibi c ao (type ou list ) exibe o conte udo de um arquivo. Cataloga c ao (cat ou dir ) lista os arquivos existentes num determinado diret orio ou unidade. Modica c ao de atributos (get ou set ) obt em ou modica os atributos de um arquivo. Do ponto de vista do conte udo dos arquivos, isto e, considerando a manipula c ao dos dados armazenados nos arquivos, devem tamb em existir opera c oes para: Leitura (read ) possibilita a leitura de dados contidos nos arquivos. Escrita (write ) efetua a grava c ao de dados em um arquivo. Pesquisa (seek ou nd ) para determinar uma posi c ao para escrita ou leitura em um arquivo.
183
Anexa c ao (append ) para adi c ao de novos dados num arquivo existente. Inser c ao (insert ) para inclus ao de um dado em um arquivo. Atualiza c ao (update ) para modica c ao de um dado existente em um arquivo. Elimina c ao (delete ) para remo c ao de um dado existente em um arquivo. As opera c oes de inser c ao, atualiza c ao e elimina c ao de dados em arquivos n ao s ao comuns, existindo em sistemas de grande porte onde os arquivos s ao usualmente organizados em blocos ou registros formatados. Como muitos sistemas de arquivos suportam diret orios, opera c oes espec cas deve ser supridas para sua utiliza c ao [TAN92][p. 161] [SG00, p. 350] Cria c ao (create ) efetua a cria c ao e preparo de um novo diret orio. Remo c ao (delete ou remove ) elimina um diret orio e opcionalmente seu conte udo. Abertura (open ) opera c ao que permite a leitura de um diret orio. Fechamento (close ) opera c ao que encerra o uso de um dado diret orio. Leitura (read ) permite a leitura do conte udo de um diret orio, ou seja, sua cataloga c ao ou listagem. Pesquisa (search ) para possibilitar a localiza c ao de determinados arquivos em um diret orio. Renomea c ao (rename ) troca o nome de um diret orio. Navega c ao (traverse ) permite a navega c ao entre diret orios do sistema. Ainda podem ser poss veis outras opera c oes sobre arquivos e diret orios, tais como sua reorganiza c ao sob algum crit erio (ordena c ao), inclus ao ou remo c ao de liga c oes (links no sistema Unix, atalhos nos sistemas Windows ou shadows nos sistemas OS/2), obten c ao de informa c oes sobre arquivos ou diret orios, associa c ao com aplicativos etc. Todas as opera c oes suportadas pelo sistema operacional para manipulac ao de arquivos e diret orios est ao dispon veis para utiliza c ao em programas atrav es das chamadas do sistema (system calls ), como no exemplo dado no Exemplo 5.1 de algumas chamadas para um programa simples destinado ao sistema Unix.
184
// vari avel para controle do arquivo int arquivo; // cria c~ ao de arquivo arquivo = create("nome do arquivo", modo); // abertura de arquivo apenas para leitura arquivo = open("nome do arquivo", O RDONLY); // leitura de arquivo read(arquivo, buffer, tamanho do buffer); // escrita em arquivo write(arquivo, buffer, tamanho do buffer); // fecha arquivo close(arquivo); Exemplo 5.1 Fragmentos de programa para sistema Unix
5.5.4
Implementa c ao L ogica
Como implementa c ao l ogica de um sistema de arquivos entende-se a met afora que e apresentada ao usu ario do sistema para que o sistema de arquivos se torne compreens vel da maneira mais simples poss vel, isto e, de modo que os detalhes da implementa c ao e funcionamento reais do sistema de arquivos sejam completamente ocultos do usu ario do sistema. Nos sistemas DOS, Windows e Unix, o usu ario entende o sistema de arquivos como uma estrutura hier arquica de diret orios que admite opera c oes sobre arquivos e diret orios. Utilizando uma interface de modo texto que oferece uma linha de comando, isto e, uma interface tipo linha de comando ou prompt do sistema, o usu ario pode digitar comandos para realizar as opera c oes desejadas imaginando a organiza c ao hier arquica de diret orios e arquivos que n ao e diretamente vis vel atrav es destas interfaces simples. Na Tabela 5.8 a seguir temos alguns exemplos de comandos DOS, Windows e Unix para manipula c ao de arquivos e diret orios. As interfaces em modo texto exigem maior abstra c ao do usu ario, que deve memorizar a sintaxe dos comandos que utiliza mais freq uentemente, o que evidentemente signica que tais usu arios devem ter maior proci encia t ecnica para utiliza c ao destes sistemas. Esta diculdade motivou o desenvolvimento de interfaces gr acas que, entre outros benef cios, possibilitassem: uma abstra c ao mais simples do sistema de arquivos,
185
Tabela 5.8: Comandos DOS, Windows e Unix para manipula c ao de arquivos Prop osito DOS Windows Unix Copiar arquivo copy copy cp Renomear arquivo ren ren mv Apagar arquivo del del rm Mover arquivo N/D move mv Exibir arquivo type type more Listar arquivos dir dir ls Criar diret orio md md mkdir Remover diret orio rd rd rmdir Troca de diret orio cd cd cd uma melhor visualiza c ao da distribui c ao de arquivos atrav es da estrutura de diret orios e unidades de armazenamento, maior produtividade do usu ario e cria c ao de um modelo de interface mais consistente que pudesse ser disponibilizada para outras aplica c oes. Para os sistemas Unix foi criado o padr ao gr aco de janelas Xwindows, que pode ser utilizado para desenvolvimento de aplica c oes gr acas, e tamb em o CDE (Common Desktop Environment ), conduzido por um cons orcio dos maiores fabricantes de sistemas Unix num esfor co de padroniza c ao da interface gr aca de seus sistemas. Outros fabricantes, tais como IBM, Microsoft e Apple oferecem seus sistemas operacionais com interfaces gr acas propriet arias, todas baseadas em janelas. O tratamento gr aco que especicamente os sistemas MS-Windows d ao a estrutura de diret orios, isto e, uma organiza c ao hier arquica de pastas nas quais podem existir arquivos e outras pastas e a id eia central da met afora apresentada. Mesmo sem o conhecimento de comandos de navega c ao na estrutura de diret orios ou de opera c oes sobre arquivos, o usu ario dos sistemas MS-Windows pode se movimentar pela estrutura de diret orios, pode copiar, renomear, eliminar e criar arquivos ou diret orios apenas atrav es da utiliza c ao do sistema de menus oferecidos ou das opera c oes que podem ser realizadas atrav es do teclado ou mouse. Tamb em e poss vel executar-se aplica c oes e criar-se atalhos (links ). As opera c oes realizadas atrav es dos menus, teclado e mouse s ao transformadas pelo sistema operacional em chamadas do sistema que realizam as tarefas especicadas, evitando tanto o conhecimento da forma com que tais opera c oes s ao verdadeiramente realizadas como a memoriza c ao dos comandos de manipula c ao de arquivos e diret orios. Nas Figuras 5.25 e 5.26 temos exemplos dos utilit arios de gerenciamento
186
de arquivos que acompanham os sistemas MS-Windows 95/98/NT e XP respectivamente.
Figura 5.25: Gerenciador de arquivos do MS-Windows 95/98/NT Estas interfaces gr acas facilitam muito a opera c ao do sistema principalmente para usu arios menos experientes, al em disso proporcionam melhor visualiza c ao da estrutura de diret orios e da distribui c ao de arquivos pelos diret orios e unidades de armazenamento do sistema.
5.5.5
Implementa c ao F sica
A implementa c ao f sica de um sistema de arquivos representa a forma com que efetivamente os dados s ao tratados nos dispositivos de armazenamento, isto e, corresponde a organiza c ao f sica dos dados nestes dispositivos e como se d ao as opera c oes de armazenamento e recupera c ao destes dados. Conforme Tanenbaum: Usu arios est ao preocupados em como os arquivos s ao denominados, quais opera c oes s ao permitidas, a apar encia da estrutura de diret orios e quest oes relacionadas a interface. Os implementadores est ao interessados em como arquivos e diret orios s ao armazenados, como o espa co em disco e gerenciado e como fazer que tudo funcione de forma eciente e con avel [TAN92, p. 162]. Como indicado por Deitel [DEI92, p. 394] e Tanenbaum [DEI92, p. 162], os arquivos podem ser armazenados basicamente de duas formas, ou seja, atrav es da:
187
Figura 5.26: Gerenciador de arquivos do MS-Windows XP Aloca c ao cont gua e Aloca c ao n ao cont gua. O projeto de um sistema de arquivos exige o conhecimento de v arias informa c oes, entre elas: o tipo e n umero de usu arios; caracter sticas das aplica c oes que ser ao utilizadas; quantidade, tamanho e opera c oes sobre arquivos. A considera c ao destes fatores permite determinar qual a melhor forma de organiza c ao de seus arquivos e diret orios. Aloca c ao cont gua Uma forma de organizar-se os arquivos sicamente e atrav es da armazenagem dos dados em areas adjacentes dos dispositivos f sicos, isto e, em setores consecutivos das unidades de disco [SG00, p. 373]. Sistemas de arquivos implementados desta forma s ao denominados de aloca c ao cont gua ou cont nua e neles o armazenamento f sico corresponde ` a organiza c ao l ogica do arquivo, ou seja, o primeiro bloco de dados ocupa o primeiro setor alocado e assim sucessivamente (vide Figura 5.27). Este e o esquema mais simples de organiza c ao f sica de arquivos que exibe algumas vantagens e desvantagens [DEI92, p. 395] [DEI92, p. 163]. As vantagens s ao: o controle de armazenamento do arquivo, isto e, a manuten c ao de diret orios, se reduz ao tamanho do arquivo e ao setor inicial utilizado e
188
Figura 5.27: Organiza c ao f sica na aloca c ao cont gua as opera c oes de leitura e escrita s ao as mais ecientes poss veis para qualquer tipo de dispositivo. Enquanto que as desvantagens s ao: exige que o tamanho do arquivo seja conhecido no instante de sua cria c ao e a ocorr encia de fragmenta c ao (veja discuss ao na se c ao5.5.6) reduz a capacidade efetiva de armazenamento, pois novos arquivos s o podem ser criados em areas cont guas. Sistemas que exigem maior performance nas opera c oes de leitura e escrita e que n ao necessitem de modica c oes freq uentes no tamanho de seus arquivos podem utilizar ecientemente este esquema de aloca c ao, tal como o sistema operacional IBM Vm/CMS. Aloca c ao n ao cont gua A outra forma poss vel de organizar-se sicamente o armazenamento de arquivos e atrav es da aloca c ao n ao cont gua. Neste esquema cada bloco do arquivo pode estar armazenado num setor distinto da unidade de disco, de forma que o armazenamento f sico n ao corresponde ` a organiza c ao l ogica do arquivo, como mostra a Figura 5.28. O principal objetivo da aloca c ao n ao-cont gua e proporcionar um mecanismo mais apropriado para o armazenamento de arquivos que tendem a ter seus tamanhos aumentados ou diminu dos conforme s ao utilizados. A aloca c ao n ao-cont gua pode ser implementada de v arias formas e dentre estas as estrat egias de aloca c ao orientadas ` a setores: Lista ligada de setores Lista ligada de setores indexada
189
Figura 5.28: Organiza c ao f sica na aloca c ao n ao cont gua Indexa c ao de n os (i-nodes ) Na lista ligada de setores (linked list allocation ) cada setor do disco cont em um ponteiro que pode ser utilizado para indicar um outro setor [SG00, p. 376]. Desta forma uma arquivo pode ser armazenado atrav es de uma entrada simples no diret orio que indica o primeiro de uma seq u encia de setores, onde cada um destes setores aponta para o pr oximo. Um ponteiro com valor nulo indica que o arquivo terminou (vide Figura 5.29). N ao existe necessidade dos setores alocados estarem em posi c oes adjacentes tal como na aloca c ao cont gua. O sistema pode manter uma lista de setores livres, que podem ser retirados para a cria c ao e aumento de arquivos ou recuperados quando diminuem ou s ao eliminados. Isto permite um mecanismo de armazenamento que acomoda facilmente as varia c oes de tamanho dos arquivos, usando integralmente a capacidade do disco, eliminando a necessidade de mecanismos de compacta c ao embora promova a fragmenta c ao da unidade de disco.
Figura 5.29: Aloca c ao n ao cont gua com lista ligada Conforme Tanenbaum [TAN92, p. 163] os maiores problemas encontrados no uso do mecanismo de uma lista ligada de setores s ao: 1. As opera c oes de leitura e escrita tendem a ser inecientes devido a fragmenta c ao inerente deste m etodo.
190
2. O acesso rand omico deixa de existir pois torna-se necess ario ler cada setor alocado para se determinar o pr oximo at e a posi c ao desejada. 3. O posicionamento do ponteiro dentro de cada setor faz com que o bloco de dados deixe de ser uma pot encia de 2, criando alguns inconvenientes do ponto de vista de programa c ao. A lista ligada de setores indexada utiliza o mesmo princ pio de armazenamento de setores interligados eliminando o inconveniente associado criada uma tabela contendo a rela ao ponteiro existente em cada setor. E c ao de todos os setores do dispositivos sendo que para cada entrada se associa um ponteiro (retirado dos setores de dados). A entrada do diret orio correspondente ao arquivo aponta para um setor desta tabela (o primeiro setor do arquivo) que tem associado um ponteiro para a pr oxima entrada e assim sucessivamente. Um ponteiro nulo indica o m do arquivo na tabela. Isto permite o acesso rand omico do arquivo e mant em o bloco de dados do setor num tamanho que e pot encia de 2, embora a ineci encia devido a fragmenta c ao permane ca. Temos uma representa c ao deste esquema de organiza c ao na Figura 5.30.
Figura 5.30: Aloca c ao n ao cont gua com lista ligada indexada A principal desvantagem deste m etodo e o tamanho que da tabela de aloca c ao pode ter em unidades de grande capacidade, por exemplo, uma
191
unidade de 1.2 Gbytes dividida em setores de 1 Kbytes possui uma tabela de aloca c ao com mais de um milh ao de entradas, que pode consumir espa co precioso para ser mantida integralmente em mem oria, pois cada entrada da tabela tipicamente utiliza 3 ou 4 bytes dependendo de como se d a a otimiza c ao do sistema [TAN92, p. 164]. O DOS e Windows utilizam esta estrat egia para a organiza c ao f sica de oppies e unidades de disco. A tabela de setores e chamada de Tabela de Aloca c ao de Arquivos (le allocation table ) que d a origem ao nome do sistema de arquivos FAT. Na FAT o registro inicial armazena informa c oes sobre a pr opria unidade, existindo valores especiais para designa c ao de m de arquivo e setores defeituosos [NOR89, p. 112]. A numera c ao associada ao nome FAT, como FAT12, FAT16 e FAT32, indica o n umero de bits utilizado para numera c ao dos setores, representando assim a quantidade m axima de setores que pode ser controlada, ou seja, 12 bits permitem endere car 4.096 setores, 16 bits endere cam 64K setores e 32 bits possibilitam 4G setores distintos. Isto exibe outra fraqueza desta estrat egia, uma unidade de 1.2 GBytes de capacidade possuir a setores de 512K (307,2K) e 32K (19,2K) com FAT de 12 e 16 bits respectivamente, o que e um inconveniente devido a granularidade excessivamente grossa (um arquivo de 1 byte ocupa sempre um setor). Outra forma comum de organiza c ao de arquivos e atrav es da indexa c ao de n os (index nodes ou i-nodes ). Um n o indexado e uma pequena estrutura de dados que cont em um conjunto de atributos e umas poucas centenas de entradas onde cada entrada e um endere co de um bloco de dados na unidade de disco. Desta forma, um pequeno arquivo pode ser mapeado com um u nico i-node, otimizando todas as opera c oes realizadas sobre ele. Se o arquivo n ao puder ser armazenado num u nico i-node, alguns dos endere cos de blocos de dados s ao substitu dos por endere cos de outros i-nodes denominados de bloco indireto simples (single indirect block ). Para arquivos ainda maiores podem ser usados blocos indiretos duplos ou triplos (double ou triple indirect block ). Este e esquema tipicamente utilizado pelos sistemas Unix, como tamb em esquematizado na Figura 5.31. Uma varia c ao destas estrat egias e alocar grupos de setores, denominados blocos (blocks ou extents ) ao inv es de setores individuais, no que se denomina estrat egias de aloca c ao orientadas ` a blocos. Estas estrat egias visam combinar algumas das vantagens da aloca c ao cont gua e da aloca c ao n ao cont gua atrav es da aloca c ao de blocos ao inv es de setores individuais, o que elimina parcialmente o problema da fragmenta c ao al em de permitir a otimiza c ao da leitura ou escrita atrav es de opera c oes com blocos inteiros (read ahead ou lazy write ). Como indica Deitel [DEI92, p. 397], existem v arias maneiras de se implementar sistemas de aloca c ao orientados ` a blocos, semelhantes as existentes para setores: Lista ligada de blocos (block chaining )
192
Figura 5.31: Aloca c ao n ao cont gua com I-Nodes Lista ligada de blocos indexada (index block chaining ) Mapeamento orientado ` a blocos (block oriented le mapping ) Na lista ligada de blocos um n umero xo de setores e alocado de cada vez, isto e, os blocos possuem o mesmo tamanho, de modo que cada bloco contenha um ponteiro para o pr oximo bloco tal como na lista ligada de setores, apresentando vantagens e desvantagens id enticas. Na lista ligada de blocos indexada, cujo princ pio tamb em e o mesmo da lista ligada de setores indexada, e poss vel termos blocos de tamanho xo ou vari avel, num mecanismo mais ex vel para o armazenamento de dados. No mapeamento orientado ` a blocos, os ponteiros s ao substitu dos por um esquema de numera c ao que pode ser facilmente convertido para a numera c ao de setores de uma unidade de disco. As opera c oes de modica c ao de tamanho de arquivos se tornam bastante ageis neste esquema [DEI92, p. 400].
5.5.6
Fragmenta c ao
Sob certos aspectos, os problemas de que devem ser resolvidos para organiza c ao do armazenamento secund ario s ao semelhantes aos encontrados no gerenciamento de mem oria. A forma de armazenamento mais simples e a disposi c ao dos dados em setores adjacentes das unidades de disco, mas os arquivos s ao freq uentemente modicados e eliminados e com isto seus tama-
193
nhos s ao vari aveis. Este fato provoca o que se chama de fragmenta c ao, isto e, come cam a surgir setores livres entre setores ocupados. Se o armazenamento de arquivos e feito atrav es da aloca c ao cont gua temos que uma altera c ao em seu tamanho imp oe algum grau de fragmenta c ao, pois se seu tamanho aumenta e a regi ao de armazenamento atual n ao pode ser expandida, a area anteriormente utilizada provavelmente car a livre enquanto o arquivo ser a rearranjado numa outra area. Na situa c ao em que o arquivo tem seu tamanho reduzido, sobrar ao alguns setores livres no nal de sua area original que s o poder ao ser ocupados por pequenos arquivos. Na Figura 5.32 temos uma esquematiza c ao da ocorr encia da fragmentac ao em sistemas de arquivos com aloca c ao cont gua e tamb em com aloca c ao n ao cont gua.
Figura 5.32: Ocorr encia de fragmenta c ao com aloca c ao cont gua Na aloca c ao cont gua temos que os arquivos s ao armazenados sempre em setores consecutivos, assim o desempenho de opera c oes de leitura e escrita n ao e comprometido pela fragmenta c ao, por outro lado a utiliza c ao do disco ser a comprometida pois setores fragmentados do disco poder ao permanecer livres n ao possibilitando o armazenamento de arquivos maiores. Caso o armazenamento de arquivos seja feito atrav es de aloca c ao n ao cont gua, setores livres passam a ser ocupados de forma descontinua pelos arquivos a medida que seus tamanhos aumentam ou diminuem. Embora o aproveitamento do espa co em disco seja integral, as opera c oes de leitura e escrita ter ao seu desempenho comprometido tanto mais fragmentado esteja o arquivo sob uso. Notamos que em ambos os casos ocorre a fragmenta c ao. Satyanarayanan (1981) efetuou um estudo sobre o tamanho dos arquivos e as opera c oes realizadas sobre eles concluindo que:
194
CAP ITULO 5. GERENCIAMENTO DE I/O a maioria dos arquivos e de pequeno tamanho, as opera c oes de leitura s ao mais freq uentes que as opera c oes de escrita, a maioria das opera c oes de leitura e escrita s ao seq uenciais e que grande parte dos arquivos tem vida curta.
Isto signica que a fragmenta c ao ir a ocorrer qualquer que seja a forma de aloca c ao. Como isto pode n ao ser admiss vel em certos sistemas, podem ser implementados mecanismos de compacta c ao ou desfragmenta c ao que reorganizam o armazenamento nos dispositivos de armazenamento de forma a possibilitar a utiliza c ao integral do espa co dispon vel no caso da aloca c ao cont gua ou de otimizar as opera c oes de leitura e escrita quando a aloca c ao e n ao-cont gua. Outros sistemas oferecem utilit arios que podem realizar esta opera c ao, permitindo ao usu ario ou administrador maior controle sobre o armazenamento, como ilustrado na Figura 5.33.
Figura 5.33: Utilit ario de desfragmenta c ao de disco do MS-Windows 98
Refer encias Bibliogr acas

[BLA87] Uyless BLACK. Computer Networks: Protocols, Standards and Interfaces. Prentice Hall, Englewood Clis, NJ, 1987. [BOR92] BORLAND. Borland C++ 3.1 Programmers Guide. Borland International, Scotts Valey, CA, 1992. [CAL96] Charles CALVERT. Delphi 2 Unleashed, 2nd Edition. Sams Publishing, Indianapolis, IN, 1996. [CON99] CONECTIVA. Manual do Usu ario do Conectiva Linux Guarani. Conectiva, Curitiba, PR, 1999. [CRA04] CRAY. Cray X1 Product Overview. Cray Research Inc., Internet: http://www.cray.com/, recuperado em 01/2004, 2004. [DAV91] William S. DAVIS. Sistemas Operacionais: uma vis ao sistem atica. C ampus, Rio de Janeiro, RJ, 1991. [DEI92] [GUI86] Harvey M. DEITEL. An Introduction to Operating Systems, 2nd Edition. Addison-Wesley, Reading, MA, 1992. C elio Cardoso GUIMARAES. Princ pios de Sistemas Operacioa nais, 5 Edi c ao. C ampus, Rio de Janeiro, RJ, 1986.
[IBM92a] IBM. IBM DOS 5.02 Technical Reference. IBM, BocaRaton, FL, 1992. [IBM92b] IBM. A Technical Guide to OS/2 2.0. IBM, BocaRaton, FL, 1992. [JAM87] Kris JAMSA. DOS: The Complete Reference. Osborne McGrawHill, Berkeley, CA, 1987. [LAT96] Y. LANGSAM, M. J. AUGENSTAIN, and A. M. TENENBAUM. Data Structures Using C and C++, 2nd Edition. Prentice Hall, Upper Saddle River, NJ, 1996. Gordon LETWIN. Explorando o OS/2. C ampus, Rio de Janeiro, RJ, 1989. 195
[LET89]
196
REFERENCIAS BIBLIOGRAFICAS
[NCA04] NCAR. NCAR/SCD Supercomputer Gallery. National Center for Atmospheric Research - Scientic Computer Division, Internet: http://www.scd.ucar.edu/computers/gallery/, recuperado em 01/2004, 2004. [NOR89] Peter NORTON. Guia do Programador para IBM PC. C ampus, Rio de Janeiro, RJ, 1989. [PET96] Charles PETZOLD. Programming Windows 95. Microsoft Press, Redmond, WA, 1996. [PIT98] [SG94] David PITTS. Red Hat Linux Unleashed. Sams Publishing, Indianapolis, IN, 1998. Abraham SILBERSCHATZ and Peter Baer GALVIN. Operating System Concepts, 4th Edition. Addison-Wesley, Reading, MA, 1994. Abraham SILBERSCHATZ and Peter Baer GALVIN. Sistemas Operacionais: Conceitos, 5a Edi c ao. Prentice Hall, S ao Paulo, SP, 2000.
[SG00]
[SGG01] Abraham SILBERSCHATZ, Peter Baer GALVIN, and Greg GAGNE. Sistemas Operacionais: Conceitos e Aplica c oes. C ampus, Rio de Janeiro, RJ, 2001. [SHA96] William A. SHAY. Sistemas Operacionais. Makron Books, S ao Paulo, SP, 1996. [STA92] [STA96] William STALLINGS. Operating Systems. Macmillan, New York, NY, 1992. William STALLINGS. Computer Organization and Architecture: Designing for Performance, 4th Edition. Prentice Hall, Upper Saddle River, NJ, 1996.
[TAN92] Andrew S. TANENBAUM. Modern Operating Systems. Prentice Hall, Upper Saddle River, NJ, 1992. [TAN95] Andrew S. TANENBAUM. Distributed Operating Systems. Prentice Hall, Upper Saddle River, NJ, 1995.

Livro de Sistemas Operacionais Excelente

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro de Sistemas Operacionais Excelente

Enviado por

Direitos autorais:

Formatos disponíveis

Notas sobre

Peter Jandl Jr.

SUMARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 40 40 43 45 46 49 50 51 51 53 53 54 57 58 60 62 64 64 67 68 69 69 71 72 73 74 76 77 79 80 83 84 87 89 89 92 95 97 99 101 103

2.9 2.10 2.11

Denindo os sistemas operacionais

CAP ITULO 1. INTRODUC AO

1.1. DEFININDO OS SISTEMAS OPERACIONAIS

CAP ITULO 1. INTRODUC AO

Objetivos de um sistema operacional

1.3. BREVE HISTORICO

Breve hist orico

CAP ITULO 1. INTRODUC AO

1.3. BREVE HISTORICO

CAP ITULO 1. INTRODUC AO

1.3. BREVE HISTORICO

CAP ITULO 1. INTRODUC AO

1.3. BREVE HISTORICO

D ecada de 1970 e 1980

CAP ITULO 1. INTRODUC AO

1.4. TIPOS DE SISTEMAS OPERACIONAIS

Tipos de sistemas operacionais

CAP ITULO 1. INTRODUC AO

1.5. RECURSOS E AMBIENTE OPERACIONAL

Recursos e ambiente operacional

CAP ITULO 1. INTRODUC AO

1.5. RECURSOS E AMBIENTE OPERACIONAL

CAP ITULO 1. INTRODUC AO

O que e um processo computacional

CAP ITULO 2. PROCESSOS

Subdivis ao dos processos

2.2. OCORRENCIA DE PROCESSOS

Figura 2.1: Subdivis ao de um processo

Ocorr encia de processos

CAP ITULO 2. PROCESSOS

Processos seq uenciais

2.3. ESTADO DOS PROCESSOS

Estado dos processos

CAP ITULO 2. PROCESSOS

2.3. ESTADO DOS PROCESSOS

CAP ITULO 2. PROCESSOS

PCB e tabelas de processos

2.4. PCB E TABELAS DE PROCESSOS

CAP ITULO 2. PROCESSOS

Figura 2.6: Organiza c ao de uma tabela de processos

Opera c oes sobre processos

Fun c oes do n ucleo de sistema operacional

CAP ITULO 2. PROCESSOS suporte ` a fun c oes de administra c ao do sistema

Competi c ao por recursos

Regi oes cr ticas

Figura 2.7: Representa c ao de uma regi ao cr tica Segundo Guimar aes:

CAP ITULO 2. PROCESSOS

Figura 2.8: Representa c ao de c odigo reentrante

2.8. PROTOCOLOS DE ACESSO

36 La co: LDA X BZ La co CLR X . . .

; Sai da RC MVI A,1 ; Coloca um no acumulador EXA X ; Troca acumulador com X

Exemplo 2.2 Protocolo de acesso funcional com instru c ao EXA

Solu c ao com instru c oes TST ou TSL

; armazena zero na flag ; retorna, i.e., saiu da RC

Situa c oes de corrida

CAP ITULO 2. PROCESSOS

2.8. PROTOCOLOS DE ACESSO

CAP ITULO 2. PROCESSOS

Requisitos de um protocolo de acesso

DE DEKKER 2.9. A SOLUC AO