Apostila PUC

SISTEMAS OPERACIONAIS
Ricardo Lus de Freitas
SISTEMAS OPERACIONAIS
INTRODUO ......................................................................................................................................... 1 1.1. Definio............................................................................................................................................ 1 1.1.1. S.O. como Mquina Virtual ........................................................................................................ 2 1.1.2. S.O. como Gerenciador de Recursos............................................................................................ 3 1.2. Histrico............................................................................................................................................. 3 1.2.1. Vlvulas e Painis de Conexo (1945-1955)................................................................................ 3 1.2.2. Transstores e Sistemas de Lote (batch) (1955-1965)................................................................... 4 1.2.3. Circuitos Integrados e Multiprogramao (1965-1980)................................................................ 5 1.2.4. Computadores Pessoais e Redes (1980 - 1990) ............................................................................ 7 2. PROCESSOS ............................................................................................................................................. 8 2.1. Introduo .......................................................................................................................................... 8 2.1.1. Hierarquia de Processos ............................................................................................................ 10 2.1.2. Estados dos Processos ............................................................................................................... 10 2.1.3. Implementao de Processos ..................................................................................................... 11 3. COMUNICAO ENTRE PROCESSOS ................................................................................................ 12 3.1. Condies de Disputa ....................................................................................................................... 12 3.2. Sees Crticas ................................................................................................................................. 13 3.3. Excluso Mtua com Espera Ocupada .............................................................................................. 14 3.3.1. Desabilitando interrupes ........................................................................................................ 14 3.3.2. Variveis de Comporta.............................................................................................................. 14 3.3.3. Alternncia Estrita.................................................................................................................... 14 3.4. SLEEP e WAKEUP.......................................................................................................................... 15 3.5. Semforos......................................................................................................................................... 18 3.6. Monitores ......................................................................................................................................... 19 3.7. Passagem de Mensagens................................................................................................................... 22 4. ESCALONAMENTO DE PROCESSOS .................................................................................................. 25 4.1. Escalonamento "Round-Robin"......................................................................................................... 26 4.2. Escalonamento com Prioridade......................................................................................................... 27 4.3. Filas Mltiplas ................................................................................................................................. 28 4.4. Menor Servio (job) Primeiro ........................................................................................................... 29 4.5. Escalonamento Dirigido a Poltica.................................................................................................... 30 4.6. Escalonamento em Dois Nveis......................................................................................................... 30 5. GERENCIAMENTO DE MEMRIA ...................................................................................................... 32 5.1. Gerenciamento de Memria sem Troca ou Paginao ....................................................................... 32 5.2. Monoprogramao sem Troca ou Paginao ..................................................................................... 32 5.3. Multiprogramao ............................................................................................................................ 32 5.3.1. Multiprogramao com Parties Fixas..................................................................................... 33 5.3.2. Relocao e Proteo................................................................................................................. 34 5.3.3. Troca (swapping) ...................................................................................................................... 36 5.3.4. Multiprogramao com Parties Variveis............................................................................... 36 5.4. Gerenciamento de Espao................................................................................................................. 37 5.4.1. Gerencimento com Mapa de Bits............................................................................................... 37 5.4.2. Gerenciamento com Listas Encadeadas ..................................................................................... 38 5.5. Alocao de Espao de Troca (swap) ................................................................................................ 39 5.6. Memria Virtual............................................................................................................................... 40 5.6.1. Paginao ................................................................................................................................. 40 5.6.2. Segmentao............................................................................................................................. 43 6. ALGORITMOS DE MUDANA DE PGINA........................................................................................ 45 6.1. Mudana tima de Pgina................................................................................................................ 45 6.2. Mudana da Pgina no Recentemente Usada................................................................................... 46 6.3. Mudana de Pgina "Primeira a Entrar, Primeira a Sair"(FIFO) ....................................................... 47 6.4. Mudana da Pgina Menos Recentemente Utilizada ......................................................................... 47 6.5. Simulando LRU em Software ........................................................................................................... 48 1.
6.6. Consideraes de Projeto para Sistemas de Paginao....................................................................... 49 6.6.1. Modelo do Conjunto Ativo (Working Set) ................................................................................. 50 6.6.2. Rotinas de Alocao Local X Global ......................................................................................... 51 6.6.3. Tamanho da Pgina .................................................................................................................. 53 6.6.4. Consideraes de Implementao.............................................................................................. 54 7. ENTRADAS E SADAS .......................................................................................................................... 56 7.1. Princpios de Hardware de E/S ......................................................................................................... 56 7.1.1. Dispositivos de E/S ................................................................................................................... 56 7.1.2. Controladores de Dispositivos ................................................................................................... 57 7.1.3. Acesso Direto Memria.......................................................................................................... 57 7.2. Princpios de Software de E/S........................................................................................................... 58 7.2.1. Objetivos do Software de E/S .................................................................................................... 58 7.2.2. Tratadores de Interrupo ......................................................................................................... 59 7.2.3. Condutores de Dispositivos (device drivers) .............................................................................. 60 7.2.4. Software Independente de Dispositivo ....................................................................................... 60 7.2.5. Software de E/S no Espao de Usurio ...................................................................................... 62 8. DEADLOCK ........................................................................................................................................... 63 8.1. Recursos........................................................................................................................................... 63 8.2. Modelamento de Deadlock................................................................................................................ 64 8.3. O "Algoritmo da Avestruz"............................................................................................................... 67 8.4. Deteco e Recuperao.................................................................................................................... 67 8.5. Preveno de Deadlock..................................................................................................................... 68 8.6. Evitao Dinmica de Deadlock ....................................................................................................... 69 8.6.1. Algoritmo do Banqueiro para um nico Recurso ....................................................................... 69 8.6.2. O Algoritmo do Banqueiro para Vrios Recursos ...................................................................... 71 9. SISTEMA DE ARQUIVOS...................................................................................................................... 73 9.1. Viso do Usurio .............................................................................................................................. 73 9.2. Pontos Bsicos com Relao a Arquivos ........................................................................................... 73 9.3. Diretrios ......................................................................................................................................... 74 9.3.1. Conceito ................................................................................................................................... 74 9.3.2. Estrutura do Diretrio ............................................................................................................... 75 9.4. Projeto de Sistema de Arquivos......................................................................................................... 77 9.4.1. Gerenciamento do Espao em Disco.......................................................................................... 77 9.4.2. Armazenamento de Arquivos .................................................................................................... 78 9.4.3. Arquivos Compartilhados ......................................................................................................... 81
Notas de Aula - Sistemas Operacionais -
1. INTRODUO
1.1. Definio
Qualquer pessoa que teve algum contato com um sistema de computao sabe que o mesmo consiste em dois componentes principais: o hardware (que engloba toda a parte fisicamente montada, em geral em circuitos eletrnicos) e o software (que compreende toda a programao para levar o hardware a executar o que foi determinado pelo usurio). bvio que a falta de qualquer um dos componentes acima acarreta a inutilidade do outro, bem como a ineficincia de um tem implicaes srias na utilizao do outro. O que talvez no seja de conhecimento difundido o fato de que, nos sistemas atuais, tanto o hardware como o software apresentam uma organizao aproximada em camadas, de forma a facilitar a sua utilizao. possvel apresentar um esquema para essa organizao como na Figura1:
Figura1: Organizao do hardware e software em camadas
Na parte de hardware, a linguagem de mquina
o que o usurio "enxerga" do
processador, isto , o seu nico modo de operar com o processador atravs da linguagem de mquina. Ao chegar no processador uma instruo de mquina, a microprogramao a responsvel pela interpretao e controle da sua execuo, atravs da ativao dos dispositivos fsicos. Em alguns processadores pequenos a interpretao e controle de execuo tambm realizada por meio de dispositivos, deixando portanto de existir a
camada de microprogramao.
Na parte de Software, o objetivo final so os programas
aplicativos. Para possibilitar o desenvolvimento de programas aplicativos existem programas como compiladores, editores de texto, depuradores, entre outros. Estes programas no deixam de ser aplicativos, apenas so voltados ao programador e no ao usurio final. Para permitir a utilizao eficiente dos recursos de hardware, bem como fornecer facilidades extras ao usurio existe o sistema operacional. Pode-se dividir as funes do S.O. em duas categorias: a definio de uma mquina virtual e o gerenciamento de recursos.
1.1.1. S.O. como Mquina Virtual Como formador de uma mquina virtual, a funo do S.O. apresentar ao usurio uma mquina com as seguintes caractersticas: i) Facilidade de operao: isto , o S.O. deve fornecer uma interface entre o usurio e o hardware que apresenta maior facilidade de programao de a presente originalmente no hardware. Um exemplo tpico disto a escrita em disco flexvel. Para esta operao, um controlador precisa das seguintes instrues: recalibrao: corresponde a um ajuste da cabea de leitura na primeira trilha, pois cada movimento posterior da cabea sempre relativo, de forma que se a mesma se apresenta inicialmente mal posicionada, todos os futuros posicionamentos sero errados; movimento da cabea: isto , o deslocamento da mesma para a trilha requerida; espera do setor: que representa uma espera at que a cabea de leitura se posiciona sobre o setor; escrita dos dados - verificao: para garantir que os dados foram verdadeiramente escritos e sem nenhum erro. Alm destes passos podem existir outros, dependendo do controlador utilizado, do tipo de acesso (leitura, escrita, formatao, etc) e de se ocorrem erros ou no. Atualmente existem diversos controladores de disco que cuidam eles mesmo de tarefas como posicionamento da cabea, leitura ou escrita, verificao de erros. No entanto mesmo nestes casos o processo de controle restante ao processador central complicado, pois exige tarefas como: controle das trilhas e setores fsicos onde se encontra ou deve ser colocada a informao
tentar novamente no caso de ocorrncia de erros, visto que os mesmos so bastante frequentes nos meios magnticos atuais devido a condies transitrias Como vemos, o programador mdio no deve ser envolvido com os detalhes deste processo todo. Para isto, os sistemas operacionais fornecem mtodos muito mais simples e estruturados de uma forma mais voltada aos problemas do usurio do que a estrutura interna do computador ii) Extenso das capacidades da mquina: o S.O. pode fornecer tambm algumas capacidades no presentes no computador original, como, por exemplo, mltiplos usurios e sistemas de proteo de acesso.
1.1.2. S.O. como Gerenciador de Recursos Como um gerenciador de recursos, a funo do S.O. controlar (ou gerenciar) a utilizao de todos os recursos fornecidos pelo hardware e a sua distribuio entre os diversos programas que competem por ele de forma a garantir: i) a execuo correta dos diversos programas ii) alta eficincia na utilizao dos recursos Dentro deste ponto de vista ento, ao S.O. compete cuidar de quem est usando que recurso, aceitar (ordenadamente) requisies de um dado recurso, realizar a contagem de utilizao de recursos e mediar conflitos nos pedidos de recursos por vrios programas.
1.2.
Histrico
Para uma melhor idia do curso de desenvolvimento dos sistemas operacionais atuais, apresentamos a esquematizao da evoluo histrica dos mesmos, enfatizando a relao entre a evoluo dos S.O. e os avanos em hardware.
1.2.1. Vlvulas e Painis de Conexo (1945-1955) Os primeiros computadores foram implementados atravs de vlvulas a vcuo, consistindo em salas inteiras de circuito, consumindo energia eltrica suficiente para cidades inteiras. A programao era realizada atravs de painis onde as conexes realizadas representavam os 0 e 1 dos cdigos binrios da linguagem de mquina. No existia o
conceito de sistema operacional, sendo que cada usurio introduzia o seu programa por painis e aguardava os resultados. A probabilidade de falha do sistema durante a execuo de algum programa era altssima, devido baixa confiabilidade das vlvulas a vcuo.
1.2.2. Transstores e Sistemas de Lote (batch) (1955-1965) A introduo dos transstores, com a consequente reduo de tamanho e consumo e o aumento da confiabilidade permitiu o desenvolvimento dos primeiros sistemas realmente utilizveis fora dos crculos acadmicos e governamentais, o que garantiu a comercialidade dos mesmos. Comea a surgir nesta poca a distino entre projetistas, construtores, operadores, programadores e pessoal da manuteno. Entretanto, os computadores ainda eram extremamente grandes e caros, devendo ser acondicionados em grandes salas com ar condicionado e operados por pessoal profissional. Seu uso era portanto restrito entidades governamentais, grandes corporaes e universidades. O processo de execuo de uma tarefa (job) era, resumidamente: i) perfurao de um conjunto de cartes com o programa a ser executado; ii) o operador pega os cartes e os coloca na leitura. Se o compilador FORTRAN for necessrio, ele colocado (tambm como um conjunto de cartes) na leitora; iii) o resultado sai na impressora e levado pelo operador para um local onde o usurio o recolhe. Este processo, alm de lento, desperdia muito tempo de programao devido ao deslocamento do operador pela sala, buscando conjuntos de cartes a serem utilizados e pela lentido dos dispositivos de entrada e sada (leitora de cartes e impressora). Para maximizar a eficincia na utilizao dos processadores, e devido ao surgimento das unidades de fita magntica, foi utilizada um novo procedimento: i) perfurao dos cartes e envio ao operador; ii) o operador junta os conjuntos de cartes e, com a utilizao de um computador mais barato, grava-os em uma fita magntica; iii) a fita magntica levada ao processador principal e lida; iv) os programas da fita so executados e o resultado gravado em outra fita magntica;
v) esta fita de sada levada ao computador secundrio (mais barato), lida e seu contedo impresso em uma impressora comum; vi) a sada da impressora entregue aos usurios. Este processo, denominado OFF-LINE, garantiu uma maior eficincia na utilizao do processador principal. Porm aumentou o tempo de resposta do sistema para cada usurio. Este aumento do tempo de resposta do sistema se d em funo de se juntar uma quantidade razovel de conjuntos de cartes para se gravar uma fita. Desta forma, cada usurio, para obter a resposta a seu programa, deve aguardar a execuo de diversos outros programas armazenados na mesma fita. Isto fica ainda mais crtico quando um dos programas de uma fita apresenta um tempo de execuo muito elevado.
1.2.3. Circuitos Integrados e Multiprogramao (1965-1980) Com a introduo de circuitos integrados, houve uma grande reduo no tamanho e custo dos sistemas, bem com um aumento em sua complexidade e generalidade. Isto permitiu o desenvolvimento de dispositivos de entrada e sada inteligentes, de forma que os prprios se responsabilizam pelo controle da transferncia de dados entre eles e a memria principal. Outro desenvolvimento importante foi a introduo dos discos, que permitem um acesso aleatrio informao contida nos mesmos, diferentemente das fitas magnticas, que somente permitem um acesso aos dados na ordem em que os mesmos esto gravados (note que isto pode ficar transparente atravs de uma programao cuidadosa, entretanto com alto custo em tempo de execuo). Estes foram fatores fundamentais para o sucesso do conceito de multiprogramao, apresentado a seguir. Simultaneamente com a utilizao de circuitos integrados, surgiu o conceito de multiprogramao. A idia provm dos seguintes fatos: i) durante a execuo de programas que realizam alta utilizao de clculos (ex: programas cientficos) todos os dispositivos de entrada e sada permanecem inativos; ii) durante a execuo de programas com alta utilizao de entrada e sada (ex: programas comerciais com consultas base de dados e impresso de relatrios) o processador permanece durante grande porcentagem do tempo aguardando os dispositivos de entrada/sada.
Desta forma, surgiu a idia de se colocar diversas tarefas (jobs) dentro de alguma "partio" da memria principal e executando simultaneamente de forma que, se alguma tarefa precisa aguardar a transferncia de dados para um dispositivo, outra tarefa pode utilizar o processador central neste perodo. Outro conceito introduzido foi o de "SPOOL (de "Simultaneous Peripherical Operation On Line") que corresponde leitura imediata dos jobs para o disco no momento da sua chegada, sendo que ao terminar um dos jobs ativos, um novo job imediatamente carregado do disco para a partio de memria vazia e executado (partio um trecho de memria alocado a um job). Este processo tem a vantagem de que, com a leitura simultnea dos dados para um meio de armazenamento mais rpido e com a transferncia de dados entre os meios realizada simultaneamente com a operao da unidade de processamento principal, desapareceu praticamente o tempo manual de montagem e desmontagem de fitas. Alm disso, dispondo de diversos jobs a serem executados no disco, o sistema operacional podia escolher entre eles por prioridade, e no necessariamente por ordem de chegada. Entretanto, at este ponto, o sistema continuava sendo um sistema de lotes, sendo o tempo entre a apresentao de um conjunto de cartes e a retirada do resultado extremamente alto, principalmente quando se est realizando a depurao de programas. Para diminuir o tempo de resposta do sistema a um dado job foi introduzido o conceito de compartilhamento de tempo ("time-sharing"), no qual cada usurio possui um terminal ligado em linha com o computador, podendo ainda o computador rodar, no fundo, alguns lotes com a utilizao do tempo disponvel devido lentido de entrada de dados dos usurios. Nesta poca tambm surgiram os minicomputadores, com uma menor capacidade de processamento numrico mas tambm com um custo muito menor.
Obs.: Multiprogramao e multiprocessamento: Estes conceitos devem ser claramente distinguidos. Multiprogramao: corresponde a diversos programas distintos executando em um mesmo processador. Multiprocessamento: corresponde a diversos processadores, dentro de um mesmo sistema de computao, executando programas diversos ou cooperando na execuo de um mesmo programa.
Note que foi a existncia de multiprocessamento entre os dispositivos de entrada/sada e o processador central que tornou atrativa a introduo da multiprogramao, mas a relao para por a.
1.2.4. Computadores Pessoais e Redes (1980 - 1990) Com a integrao em larga escala e o surgimento dos microcomputadores, surge tambm o conceito de "user-friendly" para S.O., que corresponde ao desenvolvimento de sistemas operacionais para serem utilizados por pessoas sem nenhum conhecimento de computao e que, provavelmente, no tm nenhum interesse em vir a conhecer algo. Um outro desenvolvimento interessante que foi bastante impulsionado pelos microcomputadores (apesar de no depender dos mesmos) o de sistemas operacionais para redes de computadores, que consistem em computadores distintos interligados por elementos de comunicao. Os sistemas operacionais para redes so divididos em duas categorias: 1. sistemas operacionais de rede: no qual cada usurio tem conhecimento de seu prprio computador e pode acessar dados em outros computadores; 2. sistemas operacionais distribudos: em que o sistema operacional faz com que todos os computadores da rede formem uma unidade, de forma que nenhum usurio tenha conhecimento de quantos computadores h na rede ou de em qual (ou quais) computador o seu especfico programa est executando.
2. PROCESSOS
2.1.
Introduo
No mtodo tradicional de S.O., considera-se todo o software como organizado em um nmero de processos sequenciais ou, mais simplesmente, processos. Define-se um processo como um programa em execuo, sendo que para sua especificao completa, deve-se incluir tanto o programa propriamente dito como os valores de variveis, registradores, contador de programa (Program Counter, PC), e outros dados necessrios definio completa de seu estado. Cada processo trabalha como se possusse para si uma UCP (unidade central de
processamento, o processador principal do computador) prpria, chamada UCP virtual. Na realidade, na grande maioria dos casos uma nica UCP compartilhada entre todos os processos. Isto , existe apenas uma UCP real, mas tantas UCP virtuais quantos forem os processos. Alguns sistemas de multiprocessamento apresentam diversas UCP reais, entretanto mesmo nestes casos ocorre a necessidade de compartilhamento de vrias ou todas UCP pelos diversos processos. Os processos, em uma mesma UCP real executam um por vez, mas essa execuo realizada de forma a criar a iluso de que os mesmos esto executando em paralelo, conforme a Figura 2 apresentada abaixo, onde mostrada a execuo na UCP real, a aparncia criada ao usurio, e a distribuio de tempo da UCP real entre os diversos processos.
Figura 2: Distribuio de tempo da UCP real entre os diversos processos. Um fator derivado do mtodo como a implementao das UCP virtuais realizada, e que apresenta fundamental importncia no desenvolvimento de sistemas operacionais, o fato de que a taxa de execuo de cada processo no uniforme nem reproduzvel. Com isto,
quer-se dizer que no possvel assumir nada com relao taxa com que cada processo ser executado, nem em relao a outros processos, nem em relao a diversas execues de um mesmo processo. Uma das implicaes disto que os programas no podem ser feitos levando em considerao as temporizaes de execuo das instrues (p.ex.: no se pode fazer um programa que execute certo nmero de repeties de um "loop" e com isso espere conseguir uma demora fixa de tempo, como um segundo). Isto ocorre porque no se sabe o momento em que a UCP ser chaveada para outro processo, fazendo com que o atual tenha sua continuao retardada. Para fixar melhor a diferena entre um programa e um processo, observe a seguinte comparao extravagante: Suponha um padeiro no muito experiente. Para fazer um po ele se utiliza de alguns ingredientes (farinha, sal, gua, bromato, etc.) e segue a receita de um livro de receitas. Neste caso poder-se-ia estabelecer a seguinte comparao: O padeiro a UCP, os
ingredientes so as entradas e a receita o programa (desde que o padeiro entenda tudo o que est escrito na receita, isto , que a mesma esteja em uma linguagem apropriada). O processo neste caso corresponde ao ato de o padeiro estar executando o po da receita com as entradas disponveis. Suponha agora que, enquanto o padeiro est amassando o po (um dos passos
indicados pela receita) ele picado por uma abelha. Como no muito forte, ele comea a chorar e julga extremamente importante cuidar da picada de abelha antes de acabar o po. Para isto ele dispe de novas entradas (os medicamentos) e de um novo programa (o livro de primeiros socorros). Terminado o curativo da picada o padeiro volta a amassar o po no mesmo ponto em que parou. Aqui tem-se uma interrupo (a picada de abelha) fazendo a UCP (padeiro) chavear do processo de preparao do po para o processo de curativo da picada. Outro fato importante aqui que o processo de preparao do po deve ser guardado com todo o seu estado corrente (isto , em que ponto da receita ele est e qual a disposio de todos os componentes da massa e seu estado atual) para que possa ser reassumido no mesmo ponto em que foi interrompido.
Notas de Aula - Sistemas Operacionais - 10
2.1.1. Hierarquia de Processos Em todos os S.O. de multiprogramao deve haver alguma forma de criar e terminar processos conforme o necessrio execuo dos pedidos de usurios. Por isso, um processo tem a possibilidade de gerar outros processos, que por sua vez podem gerar outros, e assim sucessivamente, gerando uma hierarquia de processos. Na gerao de um novo processo, o processo gerado recebe o nome de filho, e o que pediu a gerao recebe o nome de pai. Um pai pode apresentar diversos filhos, mas cada filho s pode ter um pai. 2.1.2. Estados dos Processos Durante a sua existncia, os processos podem se apresentar, do ponto de vista do sistema, em diferentes estados. Sero apresentados os trs mais importantes e os fatos que levam os processos a mudar de um estado outro. O primeiro estado a considerar consiste naquele em que um processo est efetivamente executando, isto , est rodando. Durante a sua existncia, um processo pode necessitar interagir com outros processos. Por exemplo, um processo pode gerar uma sada que ser utilizada por outro. Este o caso dos processo cat e grep no exemplo abaixo:
cat cap1 cap2 cap3 | grep arquivo
o processo cat utilizado para concatenar arquivos e apresentar a sada concatenada na sada padro do sistema, stdout (normalmente o terminal do usurio); no caso do exemplo, ele concatena os arquivos de nomes cap1, cap2 e cap3. O programa grep utilizado para selecionar as linhas em que aparece uma dada cadeia de caracteres, utilizando como entrada a entrada padro, stdin (normalmente o terminal do usurio); no nosso exemplo, procura as linhas em que aparece a palavra arquivo. Como a sada do processo cat est ligada entrada do processo grep por meio de um pipe, a linha acima faz com que a sada seja todas as linhas que contm a palavra "arquivo" nos trs arquivos citados (cap1, cap2 e cap3). No entanto, durante a execuo desses dois processos, como no se sabe a que taxa cada um ser executado, pode ocorrer de que o processo grep queira ler um dado de entrada que ainda no foi gerado pelo cat. Quando isto ocorre, o processo grep deve ser bloqueado at haver entradas.
Outro estado a considerar quando o processo tem todas as condies de executar, mas no pode pois a UCP foi alocada para a execuo de um outro processo. Neste caso o processo est pronto. Os trs estados e suas interrelaes podem ser apresentados como na Figura 3:
EXECUO
1
BLOQUEADO
PRONTO
Figura 3: Estados de um Processo Onde: as transies entre os processo esto numeradas de acordo com a anotao: 1. bloqueamento por falta de entrada 2. escalonador selecionou um outro processo 3. escalonador selecionou este processo 4. entrada ficou disponvel Em alguns sistemas, o processo deve requisitar o bloqueamento, quando notar que no dispe de entradas. Em outros sistemas, o bloqueamento realizado automaticamente pelo prprio sistema, sem que o usurio precise se ocupar disso durante a programao. O escalonador (scheduler) citado acima uma parte do S.O. responsvel pelo
chaveamento da UCP entre os diversos processos, tendo como principal objetivo a conciliao da necessidade de eficincia do sistema como um todo e de justia para com os processos individuais. 2.1.3. Implementao de Processos Para a implementao de processos, alm dos programas serem executados, devem ser guardadas algumas informaes, necessrias ao escalonador, para permitir que um processo seja reassumido exatamente no ponto em que foi interrompido. Esses dados so armazenados na chamada tabela de processos, que consiste em um vetor de estruturas com uma entrada por processo. Esta estrutura contm dados como: contador de programa (PC), ponteiro de pilha (SP), estado dos arquivos abertos, registradores, alm de diversas outras informaes.
3. COMUNICAO ENTRE PROCESSOS

3.1. Condies de Disputa
Quando existe compartilhamento entre processos de uma memria, na qual cada um pode escrever ou ler, podem ocorrer as chamadas condies de disputa. Exemplifica-se isto
atravs de um spooler de impressora (que corresponde a um programa que permite diversos usurios utilizarem uma mesma impressora, simplesmente fazendo com que cada um envie o nome de um arquivo a ser impresso, e imprimindo os arquivos na ordem em que foram solicitados pelos diversos usurios). Considera-se que o programa funciona lendo os nomes dos arquivos a imprimir de um diretrio de spool. Cada programa que deseja a impresso de um arquivo envia o nome do mesmo para o diretrio de spool. Considera-se o diretrio de spool como organizado em diversas unidades numeradas, sendo que cada unidade pode conter o nome de um arquivo, veja na Figura 4
Figura 4 Tem-se tambm duas variveis, entra e sai que so utilizadas respectivamente para indicar qual a prxima unidade de diretrio vazia (e que portanto pode ser ocupada por um novo nome de arquivo) e qual a prxima unidade a ser impressa. Supondo que, no caso indicado na Figura 4, onde entra=7, um processo A resolve requisitar a impresso de um arquivo chamado a.prg. Para isto, ele precisa ler o valor da varivel entra, colocar o nome do arquivo na unidade correspondente e incrementar o valor de entra de um. Supondo ento que o processo A leu entra=7, aps o que foi interrompido pelo escalonador, que determinou o incio da execuo do processo B. Este processo (B), resolve ento imprimir o arquivo b.prg. Para isto l o valor de entra, onde encontra 7, coloca b.prg na unidade 7 do diretrio de spool, e incrementa entra para 8. Aps isto o escalonador determina a volta da execuo do processo A, que retorna exatamente no ponto onde estava. Ento, para o processo A, o valor de entra continua sendo 7 e, portanto, ele colocar a.prg na
unidade 7 do diretrio de spool (exatamente onde tinha sido colocado b.prg) e incrementa o valor de entra que leu (isto , 7) gerando como resultado 8, que ser armazenado em entra. O resultado de tudo isto que o pedido de impresso de b.prg desapareceu, e portanto o processo que o requisitou no ser servido. Isto o que se chama de uma condio de disputa.
3.2.
Sees Crticas
Claramente as condies de disputa, como a apresentada acima, devem ser evitadas, e os S.O. devem ser construdos de forma a evitar disputas entre os diversos processos. Note
que o problema de disputa ocorreu, no programa de spool da impressora, devido ao fato de existirem dois processos acessando "simultaneamente" os dados compartilhados entre os mesmos. Isto nos indica que as condies de disputa podem ser evitadas, proibindo que mais de um processo leia e escreva simultaneamente em uma rea de dados compartilhada. Isto o que se chama de excluso mtua. Durante a maior parte do tempo um processo executa computaes internas, que no requerem acesso a dados de outros processos. Os trechos de programa em que os processos esto executando computaes sobre dados compartilhados com outros processos so chamados de sees crticas. Para evitar disputas basta ento garantir que no havero dois processos simultaneamente em suas sees crticas. Alm disto, para haver uma cooperao eficiente e correta entre os processos, deve-se satisfazer as seguintes condies: 1. no podem haver dois processos simultaneamente em suas sees crticas; 2. no so feitas suposies sobre a velocidade relativa dos processos e sobre o nmero de UCPs; 3. nenhum processo parado fora de sua regio crtica pode bloquear outros processos 4. nenhum processo deve esperar um tempo arbitrariamente longo para entrar em sua regio crtica.
3.3.
Excluso Mtua com Espera Ocupada
3.3.1. Desabilitando interrupes A forma mais simples de garantir a excluso mtua fazer com que cada processo desabilite interrupes ao entrar na regio crtica, e as reabilite imediatamente antes de sair. Isto impede que a UCP seja chaveada para outro processo, pois o chaveamento realizado atravs de uma interrupo peridica vinda de um relgio que ativa o escalonador. Esta soluo apresenta os seguintes problemas: a. os usurios devem ter o direito de desabilitar interrupes, o que significa que se algum se esquecer de reabilit-las, o S.O. no poder mais executar; b. se o computador possuir vrias UCP o mtodo no funciona, pois somente sero desabilitadas as interrupes da UCP que estiver rodando o programa
Da conclui-se que a desabilitao de interrupes, necessria a algumas tarefas do kernel, deve ser restrita ao mesmo.
3.3.2. Variveis de Comporta Pode-se pensar numa soluo em que se estabelea uma varivel auxiliar, denominada varivel de comporta (lock variable), que quando em 0 indica que a regio crtica est livre, e quando em 1 indica que a mesma est ocupada. Desta forma, possvel fazer com que cada processo, antes de entrar, teste o valor da comporta: se for 0 (aberta), coloca em 1 e prossegue o processamento, colocando em 0 quando terminar, e se for 1 (fechada) aguarda at se tornar 0. O grande problema com esta soluo que a disputa apenas se transferiu da regio crtica para a varivel de comporta (pense no que ocorre se um processo for interrompido imediatamente depois de ler o valor da varivel e antes de alter-lo...).
3.3.3. Alternncia Estrita Esta uma soluo que obriga que a regio crtica seja dada a um dos processos por vez, em uma estrita alternncia. O algoritmo apresentado abaixo representa um exemplo disto, com a utilizao de uma varivel vez, que indica de qual processo a vez de entrar na regio crtica:
procedure proc_0; begin while (TRUE) do begin while (vez 0) (*espera*) secao_critica; vez := 1; secao_normal; end end; procedure proc_1; begin while (TRUE) do begin while (vez 1) (*espera*) secao_critica; vez := 0; secao_normal; end end;
do;
do;
O teste contnuo de uma varivel na espera de um certo valor chamado de espera ocupada, e representa, como evidente, um enorme desperdcio de UCP. O problema com a soluo de alternncia estrita que requer que os dois processos se alternem precisamente, o que significa que o nmero de acessos de cada processo deve ser exatamente igual ao do outro. Alm disto, existe uma violao da regra 3 apresentada acima, pois se um dos processos pra fora de sua seo crtica, o outro no poder prosseguir normalmente, pois aps entregar a seo crtica para o outro processo no pode mais pedi-la novamente.
3.4.
SLEEP e WAKEUP
As solues com espera ocupada tm o grave inconveniente de desperdiar tempo de UCP nos loops de espera para a entrada na regio crtica. Alm disto apresenta um outro problema quando se trata de processos com prioridades diferente. Suponha dois processos: um, chamado H, de alta prioridade e outro, chamado L de baixa prioridade. Se o processo L estiver executando em sua regio crtica quando o processo H selecionado para execuo, ento, se o processo H tenta entrar em sua regio crtica no pode, pois o processo L est
dentro da mesma e, portanto fica em um loop de espera. Mas, como H tem alta prioridade, o processo L no poder executar at que H termine, pois apresenta prioridade mais baixa. Tem-se neste caso uma situao chamada de deadlock, onde nenhum dos processos pode prosseguir pois est aguardando alguma condio que somente pode ser atingida pela execuo do outro. Para isto, define-se duas rotinas SLEEP e WAKEUP, que realizam a espera atravs do bloqueamento do processo, ao invs do desperdcio do tempo de UCP. SLEEP: faz com que o processo que est executando seja transferido do estado de rodando para o de bloqueado. WAKEUP: pega um processo em estado bloqueado e o transfere para o estado pronto, colocando-o disponvel para execuo quando o escalonador julgar adequado. Para exemplificar a utilizao de SLEEP e WAKEUP, observe o problema do produtor e do consumidor. Neste problema clssico existem dois processos: um chamado produtor que coloca dados em um buffer, e outro chamado consumidor que retira dados do buffer. O buffer apresenta uma capacidade finita de reter dados, de forma que surgem problemas em duas situaes: i) quando o produtor deseja colocar mais dados em um buffer cheio ii) quando o consumidor deseja retirar dados de um buffer vazio. Em ambos os casos, faz-se com que o processo que no pode acessar o buffer no momento execute um SLEEP e seja bloqueado, somente sendo acordado quando o outro processo alterar a situao do buffer e executar WAKEUP. No programa abaixo tem-se uma tentativa de resolver o problema do produtorconsumidor com a utilizao de SLEEP e WAKEUP. A varivel cont compartilhada entre os dois processos: cont:=0; (* inicialmente buffer vazio *) procedure produtor; begin while (TRUE) do begin produz_item(item); (* produz um item *) if (cont=N) then SLEEP; (* se buffer cheio, dorme *) entra_item(item); (* coloca item no buffer *) cont:= cont+1; (* incremente n. de itens *) if (cont=1) then WAKEUP(consumidor); (*se buffer estava vazio, end acorda consumidor *) end;
procedure consumidor; begin while (TRUE) do begin if (cont=0) then SLEEP; (* se buffer vazio, dorme *) remove_item(item); (* l item do buffer *) cont:= cont-1; (* decrementa n. de itens *) if (cont=N-1) then WAKEUP(produtor); (* se buffer estava cheio, acorda produtor *) consome_item(item); (* utiliza o item lido *) end end; Infelizmente este programa apresenta um problema na utilizao da varivel cont. Veja nos seguintes passos: 1. consumidor l cont=0 2. escalonador interrompe consumidor e roda produtor 3. produtor coloca item e incrementa cont para 1 4. como descobre que cont=1, chama WAKEUP para o consumidor 5. consumidor volta a executar, mas como j estava rodando o 6. para ele cont=0 (foi o valor lido) e portanto, dorme 7. em algum momento o produtor lota o buffer e tambm dorme WAKEUP perdido
Tem-se portanto uma condio em que tanto o produtor como o consumidor esto dormindo, no podendo ser acordados pelos outros, o que caracteriza novamente um deadlock. Para este caso simples, o problema pode ser resolvido com a incluso de um bit de espera de WAKEUP. Assim, quando um WAKEUP for enviado para um processo j acordado, o bit ser marcado, sendo que a prxima vez que o processo realizar SLEEP, se o bit estiver marcado ento o processamento prossegue como se o WAKEUP tivesse sido automtico. Entretanto, esta soluo no resolve o problema geral. Pode-se, por exemplo, construir casos com trs processos onde um bit de espera no suficiente. O aumento para trs ou mais bits poderia resolver esses casos, porm o problema geral ainda permaneceria.
3.5.
Semforos
Para resolver este problema, Dijkstra props a utilizao de uma varivel inteira que conta o nmero de WAKEUP realizados. A essa varivel se deu o nome de semforo. Para trabalhar com os semforos Dijkstra props duas primitivas: DOWN(v) : generalizao de SLEEP, que pode ser definida como: if (v>0) then v:= v-1 else SLEEP; UP(v) : generalizao de WAKEUP, que pode ser definida como: if (v=0) then WAKEUP else v:= v+1; Veja que, nas representaes acima, so consideradas todas as aes de DOWN(v) e UP(v) como indivisveis, isto , o processamento realizado sem interrupes. A soluo do produtor-consumidor com semforos utilizamos trs variveis semforo: mutex : semforo binrio que garante a excluso mtua dentro da regio crtica vazio : que indica o nmero de posies vazias no buffer cheio : que indica o nmero de posies cheias no buffer amutex:= 1; (* primeiro o produtor *) vazio:= N; (* N locais vazios *) cheio:= 0; (* 0 locais cheios *) procedure produtor; begin while (TRUE) do begin produz_item(item); DOWN(vazio); (* um vazio a menos *) DOWN(mutex); (* testa exclusao mutua *) entra_item(item); (* poe item no buffer *) UP(mutex); (* sai da exclusao mutua *) UP(cheio); (* um a mais cheio *) end end; apresentada abaixo, onde
procedure consumidor; begin while (TRUE) do begin DOWN(cheio); (* um cheio a menos *) DOWN(mutex); (* testa exclusao mutua *) remove_item(item); (* le item do buffer * UP(mutex); (* sai da exclusao mutua *) UP(vazio); (* um vazio a mais *) consome_item(item); end end; A melhor forma de ocultar uma interrupo atravs da utilizao de semforos. Por exemplo, associamos um semforo chamado disco interrupo de disco, com o valor inicialmente de 0. Assim, quando um processo necessita de dados do disco executa um DOWN(disco), ficando bloqueado. Ao surgir a interrupo de disco esta executa UP(disco), desbloqueando o processo requisitante.
3.6.
Monitores
Os semforos resolvem o problema de acesso s regies crticas, entretanto apresentam grande dificuldade de utilizao. Por exemplo, no cdigo para o produtor-consumidor, se revertermos acidentalmente o DOWN(vazio) com o DOWN(mutex) no produtor, ocorrer deadlock quando o buffer estiver cheio, pois o produtor j ter pedido a excluso mtua (com a execuo de DOWN(mutex)) quando percebe que o buffer est cheio (com
DOWN(vazio)) e ento para. Mas ento o consumidor no pode mais retirar tens do buffer pois no pode mais entrar na regio crtica. Isto mostra que a programao com semforos deve ser muito cuidadosa. Para evitar essas dificuldades, Hoare e Brinch Hansen propuseram uma primitiva de sincronizao de alto nvel conhecida como monitor. Em um monitor se agrupam conjuntamente rotinas, variveis e estruturas de dados. Os monitores apresentam as seguintes caractersticas: os processos chamam rotinas no monitor quando desejam, mas no tm acesso a suas variveis e estruturas de dados internas; apenas um processo pode estar ativo no monitor em cada instante;
o monitor reconhecido pelo compilador e, portanto, tratado de uma forma especial; as primeiras instrues de cada rotina do monitor realizam um teste para verificar se existe outro processo ativo no monitor no mesmo instante. Se houver, o processo chamante suspenso, e se no houver o processamento prossegue; o compilador o responsvel pela implementao da excluso mtua entre as rotinas do monitor (em geral atravs de um semforo binrio); quem escreve as rotinas do monitor no precisa saber como a excluso mtua ser implementada, bastando colocar todas as sees crticas em rotinas de monitor
Para possibilitar o bloqueamento de processos, quando estes no podem prosseguir, introduziram-se as variveis de condio, alm das operaes WAIT e SIGNAL. Quando uma rotina de monitor no pode continuar executa um WAIT em alguma varivel de condio (por exemplo: cheio, quando o produtor encontra o buffer cheio).
Um outro processo ento pode acord-lo executando um signal na mesma varivel de condio). Para evitar que dois processos estejam ativos no monitor simultaneamente, devemos ter uma regra que diga o que deve ocorrer aps signal. Hoare props que o processo recm acordado fosse executado. Brinch Hansen props que o processo que executa um signal deve deixar imediatamente o monitor (isto , o signal deve ser a ltima operao realizada por uma rotina de monitor. Esta ltima mais simples de implementar e conceitualmente mais fcil: se um signal executado em uma varivel de condio em que diversos processos esto esperando, apenas um deles (determinado pelo escalonador) revivido. O problema do produtor-consumidor com a utilizao de monitor apresentado pelo pseudocdigo abaixo, onde utilizamos um dialeto de PASCAL que supomos reconhecer os comandos de monitor.
monitor ProdutorConsumidor; var cheio,vazio: boolean; cont: integer procedure coloca; begin if cont = N then wait(cheio); entra_item; cont := cont+1; if count = 1 then signal(vazio); end;
procedure retira; begin if cont=0 then wait(vazio); remove_item; cont:=cont-1; if cont=N-1 then signal(cheio); end; cont:=0 end monitor; procedure produtor; begin while true do begin produz_item; ProdutorConsumidor.Coloca; end end; procedure consumidor; begin while true do begin ProdutorConsumidor.retira; consome_item; end end;
As operaes wait e signal so muito parecidas com as de sleep e wakeup, que tinham problemas graves de disputa. No caso atual a disputa no ocorre, pois no monitor no podem haver duas rotinas simultaneamente. Os monitores possibilitam uma grande facilidade para a programao paralela. Entretanto, possui alguns inconvenientes:
a. so uma construo de alto nvel, que deve ser reconhecida pelo compilador, isto , a linguagem que os implementa deve reconhecer os comandos de monitor empregados (muito poucas linguagens de fato os implementam);
b. eles se baseiam (tanto quanto os semforos) na considerao da existncia de uma memria comum compartilhada por todos os processadores. Portanto, so inaplicveis para sistemas distribudos, onde cada processador conta com sua prpria e independente memria.
3.7.
Passagem de Mensagens
Para possibilitar o trabalho com sistemas distribudos e tambm aplicvel sistemas de memria compartilhada temos o conceito de passagem de mensagens. Este mtodo usa as seguintes primitivas: SEND : envia uma mensagem para um destino dado: SEND(destino,&mensagem);
RECEIVE : recebe uma mensagem de uma origem especificada: RECEIVE(origem,&mensagem);
Se nenhuma mensagem estiver disponvel no momento de executar RECEIVE, o receptor pode bloquear at que uma chegue. Se pensamos na conexo de processadores por uma rede, pode ocorrer de uma mensagem ser perdida. Para se resguardar disto o processo que envia e o que recebe podem concordar em que, to logo uma mensagem seja captada pelo receptor, este envie uma outra mensagem acusando a recepo. Assim, se o processo que envia no receber a recepo dentro de certo tempo, pode concluir que a mensagem foi perdida e tenta a transmisso
novamente. Estas mensagens de volta so mensagens especiais chamadas de mensagens de reconhecimento. Suponha agora que a mensagem original recebida corretamente, mas o reconhecimento perdido. Neste caso, o enviador ir retransmitir a mensagem, e o receptor ir receb-la duas vezes. Portanto, deve ser possvel a distino entre uma mensagem antiga retransmitida e uma nova mensagem, o que normalmente realizado pela colocao de nmeros
consecutivos em cada mensagem original. Sistemas de mensagens tambm precisam saber exatamente quais os nomes dos diversos processos, de forma a identificar corretamente a origem e o destino de uma mensagem. Normalmente isto conseguido com uma nomeao do tipo processo@mquina. Se o nmero de mquinas for muito grande e no houver uma autoridade central, ento pode ocorrer que duas mquinas se dem o mesmo nome. Os problemas de conflito podem ser grandemente diminudos pelo agrupamento de mquinas em domnios, sendo o endereo formado por processo@mquina.domnio. Outro fator importante a considerar o de autenticao, de forma a garantir que os dados esto sendo realmente recebidos do servidor requisitado, e no de um impostor, e tambm para um servidor saber com certeza qual o cliente que requisitou. Em geral a encriptao das mensagens com alguma chave til. Utilizando a passagem de mensagens e sem memria compartilhada, podemos resolver o problema do produtor-consumidor como apresentado no programa abaixo:
procedure produtor; begin while (TRUE) do begin produz_item(item); RECEIVE(consumidor,m); (* aguarda mensagem vazia *) faz_mensagem(m,item); (* constroi mensagem*) SEND(consumidor,m); (* envia item ao consumidor *) end end; procedure consumidor; begin for i:=0 to N-1 do SEND(produtor,m); (* envia N vazios *) while (TRUE) do begin RECEIVE(produtor,m); (* pega mensagem *) extrai_item(m,item); (* pega item da mensagem *)
consome_item(item); SEND(produtor,m); end end;
(* envia resposta vazia *)
Nesta soluo assumimos que todas as mensagens tm o mesmo tamanho e que mensagens enviadas, mas ainda no recebidas, so automaticamente armazenadas pelo sistema operacional. No incio so enviados N vazios para permitir ao produtor encher todo o buffer antes de bloquear. Caso o buffer esteja cheio, o produtor bloqueia no RECEIVE e aguarda a chegada de uma nova mensagem vazia. A passagem de mensagens pode ser feita de diversas formas, das quais citaremos trs: 1. assinalando-se um endereo nico para cada processo e fazendo as mensagens serem endereadas aos processos;
2. com a utilizao de mailbox, uma nova estrutura de dados que representa um local onde diversas mensagens podem ser bufferizadas. Neste caso, os endereos em SEND e RECEIVE so as mailbox e no os processos. Se um processo tenta enviar para uma mailbox cheia ou receber de uma mailbox vazia ele automaticamente suspenso at que a mailbox apresente as condies para a operao;
3. eliminando toda a bufferizao, fazendo com que, se o processo que envia executa SEND antes do de recepo, ento, ele bloqueado at que este ltimo esteja pronto (e viceversa). Este mecanismo conhecido como rendezvous;
4. ESCALONAMENTO DE PROCESSOS
Chamamos de escalonamento (scheduling) de processos o ato de realizar o chaveamento dos processos ativos, de acordo com regras bem estabelecidas, de forma a que todos os processos tenham a sua chance de utilizar a UCP. O escalonador (scheduler) , portanto, a parte do S.O. encarregada de decidir, entre todos os processos prontos para executar, qual o que ser rodado em cada instante. Chamamos de algoritmo de escalonamento o mtodo utilizado pelo escalonador para decidir, a cada instante, qual o prximo processo a ser executado. Podemos estabelecer os seguintes critrios para um algoritmo de escalonamento: a. justia: cada processo deve conseguir sua parte justa do tempo de UCP; b. eficincia: garantir uma ocupao de 100% do tempo da UCP; c. tempo de resposta: minimizar o tempo de resposta a comandos de usurios interativos; d. minimizao do tempo que os usurios de lotes (batch) devem aguardar at conseguir a sada desses pedidos; e. maximizar o nmero de servios (jobs) processados por hora.
Como pode ser facilmente notado, vrios critrios acima entram em contradio entre si, de forma que devemos prejudicar alguns para conseguir melhoras em outros. O escalonador deve, portanto, realizar algum compromisso entre os diversos critrios. Para dificultar que os objetivos sejam alcanados, ainda temos o fato de que cada processo nico e imprevisvel. Com o objetivo de prevenir que um processo rode durante um tempo excessivo, a maioria dos computadores dispe de um relgio, que um dispositivo de temporizao que
interrompe a UCP a cada intervalo dado de tempo. A cada interrupo, o S.O. interrompe a execuo do processo atual e roda o escalonador para decidir qual o prximo processo a ser executado. Esta estratgia de interromper um processo em execuo chamada de
escalonamento preemptivo (preemptive scheduling), e contrasta com a estratgia de execuo at o trmino. Vejamos agora algumas formas de implementar o escalonamento.
4.1.
Escalonamento "Round-Robin"
Neste mtodo, a cada processo se d um intervalo de tempo, chamado de quantum,
no qual se permite que ele execute. Se o processo ainda est rodando ao fim de seu quantum, a UCP tomada deste processo e o escalonador seleciona um novo para rodar. A UCP tambm pode ser entregue a outro processo caso o processo bloqueie ou termine antes do fim do quantum. Neste caso, a UCP entregue outro processo no momento do trmino ou do bloqueio. Para a implementao deste mtodo, o escalonador mantm uma lista de processos executveis (isto , processos prontos). Quando um quantum termina sem o processo acabar, o mesmo colocado no fim dessa lista. O escalonador seleciona, ento, o primeiro processo dessa lista para execuo. Veja a Figura 5 para melhor esclarecimento.
Figura 5 O valor do quantum deve ser cuidadosamente escolhido.Isso ocorre porque existe o tempo de chaveamento (tempo para que o processo em execuo seja interrompido; tenha seu estado atual salvo; o escalonador decida qual o prximo processo e o estado deste novo processo seja restaurado). Assim, se o valor do quantum for muito pequeno, teremos uma grande proporo do tempo de execuo da UCP gasta com o processo de chaveamento, que no de interesse para os usurios. Por exemplo, se todo o chaveamento de processos leva 5ms, e o quantum for de 20ms, teremos uma utilizao de 20% do tempo total para o chaveamento. Por outro lado, se o valor do quantum for muito grande, isto pode acarretar um tempo de resposta muito grande para usurios interativos. Veja por exemplo se, para um chaveamento de 5ms escolhemos um quantum de 500ms. Neste caso o tempo gasto com o chaveamento menos que 1% do tempo total. Entretanto, se temos 10 processos executando, o tempo de resposta para um processo pode ser de at 5s. Devemos pois escolher um valor de
compromisso, nem muito grande nem muito pequeno, de acordo com o tempo de chaveamento.
4.2.
Escalonamento com Prioridade
O esquema de round-robin trata igualmente todos os processos dos sistemas, sejam eles altamente urgentes e importantes, sejam eles de pouca importncia ou sem urgncia. Para poder oferecer um tratamento distinto processos diversos, devemos introduzir o conceito de prioridade. No instante da criao de um processo, associamos ao mesmo uma prioridade. Quando o escalonador tiver que escolher, entre os processos prontos, qual o que ser executado em seguida, ele escolhe o de mais alta prioridade. Como esse esquema pode fazer com que um processo seja executado indefinidamente, no deixando espao a outros processos, o escalonador pode, a cada vez que o processo escalado para execuo, decrementar sua prioridade. No momento em que sua prioridade fica abaixo de um outro processo pronto ele interrompido e o outro processo (agora com prioridade mais alta) executado. As prioridades podem ser associadas a processos de forma esttica ou dinmica. Dizemos que uma prioridade esttica quando ela associada no momento da criao do processo (mesmo que depois ela seja decrementada para impedir o processo de monopolizar a UCP). Uma prioridade dinmica quando o escalonador que decide seu valor, baseado em estatsticas sobre a execuo deste processo em quanta anteriores. Como exemplo de prioridades estticas, podemos imaginar que em um sistema implantado em um quartel, os processos iniciados por um general devem ter prioridade sobre os processos iniciados por um coronel, e assim por diante, por toda a hierarquia. Como exemplo de prioridade dinmica, podemos citar um sistema que, quando percebe que um dado processo efetua muitas operaes de entrada/sada, aumenta a sua prioridade. Isto feito pois as operaes de entrada/sada so realizadas independentemente da UCP, de forma que, se um processo executa muitas dessas operaes, conveniente deixar que ele requisite uma nova operao o mais rpido possvel. Lembre-se que, ao requisitar uma operao de entrada/sada o processo faz uma chamada para o S.O. e fica bloqueado, aguardando o fim da operao. Assim, processos com grande utilizao de E/S no significam muita carga para a UCP, pois enquanto suas transferncias esto se executando a UCP pode estar alocada a outro processo que executa clculos. Para implementar essa forma de prioridade, o escalonador calcula a frao de tempo que o processo utilizou do seu quantum na ltima chamada. Se o processo utilizou apenas uma pequena frao (e no terminou) provavelmente porque est esperando dados de um dispositivo de E/S. Desta
forma, podemos utilizar para prioridade, um valor proporcional ao inverso da frao de quantum ocupado. Muitas vezes til agrupar os processos em classes de prioridades, fazem um
escalonamento em dois nveis: i. escalonamento de prioridade entre as diversas classes, executando todos os processos das classes de prioridades mais altas antes das classes mais baixas; ii. escalonamento round-robin dentro de cada classe, fazendo com que todos os processos de uma mesma classe revezem-se como explicado para o escalonamento round-robin.
4.3.
Filas Mltiplas
que o computador forava um chaveamento de processos
O fato importante aqui
extremamente lento, pois apenas um processo podia estar presente na memria em cada instante, fazem com que os processos devessem ser lidos do disco e escritos no disco a cada chaveamento. A utilizao prtica demonstrou que era necessrio que os processos com muita
utilizao de UCP (tambm chamados de processos limitados pela UCP, "CPU-bound") ganhassem um quantum grande de uma s vez, de forma a reduzir o nmero de
chaveamentos executados nesse processo. Por outro lado, como j vimos, no podemos atribuir quanta grandes para todos os processos, pois isso implicaria em um tempo de resposta muito grande. A soluo encontrada foi o estabelecimento de classes de prioridade. Os processos de classes mais altas so escolhidos para execuo mais frequentemente que os de classes mais baixas. Por outro lado, os processos de classes mais baixas recebem um nmero maior de quanta para processamento. Assim, os processos da classe mais alta existente recebem 1 quantum, os processos da classe imediatamente abaixo recebem 2 quanta, os processos da classe seguinte, 4 quanta, e assim sucessivamente, nas potncias de 2. Adicionalmente a isso, cada vez que um processo utiliza todos os quanta que recebeu ele abaixado de uma classe (fazendo com que seja escolhido menos frequentemente, mas execute durante mais tempo). Como exemplo, num processo que necessita de 100 quanta para executar, teremos execues de 1, 2, 4, 8, 16, 32, 37. Isto , ele selecionado para execuo 7 vezes (7
chaveamentos para este processo), sendo que no mtodo de round-robin tradicional ele seria selecionado 100 vezes at acabar (100 chaveamentos). Por outro lado, este mtodo, como definido at aqui, tem o grave inconveniente de que, se um processo comea com uma grande quantidade de clculos, mas em seguida se torna interativo (isto , exige comunicao com o usurio), teramos um tempo de resposta muito ruim. Para eliminar este problema, foi implementado o seguinte mtodo: cada vez que um <RET> teclado no terminal de um processo, este processo transferido para a classe de prioridade mais alta, na esperana de que o mesmo ir se tornar interativo. Esta soluo funcionou bem at que um usurio descobriu que, durante a execuo de um processo grande, bastava sentar no terminal e teclar aleatoriamente <RET> para ter o tempo de execuo melhorado. Em seguida ele contou sua "descoberta" a todos. V-se ento que a implementao prtica de uma estratgia eficiente muito mais difcil na prtica do que em princpio.
4.4.
Menor Servio (job) Primeiro
As estratgias apresentadas anteriormente so teis para sistemas de time-sharing. A estratgia de menor servio primeiro (shortest job first) til fundamentalmente para
sistemas de lotes (batch). Nestes sistemas, muitas vezes os usurios j tm uma boa estimativa dos tempos de execuo do programa (em geral porque o programa rodado constantemente). A estratgia consiste em escolher para execuo, entre todos os jobs disponveis, aquele de menor tempo de execuo. Para ver como esta estratgia consegue melhorar o tempo mdio de resposta do sistema, consideremos o seguinte caso: existem quatro jobs disponveis (A, B, C e D), sendo um de 8 minutos (o A) e trs de 4 minutos (B, C e D). Se o job de 8 minutos for escolhido antes, teremos a seguinte configurao: tempo de resposta de A: 8 minutos tempo de resposta de B: 8 + 4 = 12 minutos tempo de resposta de C: 8 + 4 + 4 = 16 minutos tempo de resposta de D: 8 + 4 + 4 + 4 = 20 minutos tempo de resposta mdio: 14 minutos. Se escolhemos os trs jobs de 4 minutos antes do de 8, teremos:
tempo de resposta de B: 4 minutos tempo de resposta de C: 4 + 4 = 8 minutos tempo de resposta de D: 4 + 4 + 4 = 12 minutos tempo de resposta de A: 4 + 4 + 4 + 8 = 20 minutos tempo de resposta mdio: 11 minutos.
Esta estratgia garante o mnimo tempo de resposta mdio possvel, desde que se conheam todos os servios simultaneamente. Se os servios no so todos conhecidos simultaneamente o tempo de resposta mdio pode no ser o mnimo, mas ainda uma boa aproximao.
4.5.
Escalonamento Dirigido a Poltica
Outra forma de cuidar do escalonamento fazer uma promessa ao usurio e procurar cumpri-la. Um exemplo de uma promessa simples e fcil de cumprir a de que, se existem n usurios ativos, ento, cada um receber aproximadamente 1/n do tempo de UCP. Para cumprir essa promessa podemos usar o seguinte mtodo: i. para cada usurio, mantido um valor do tempo de UCP que ele j utilizou desde que entrou, que ser chamado tempo utilizado; ii. compute quanto tempo j se passou desde que o usurio iniciou sua seo e divide-se pelo nmero de usurios, gerando o que ser chamado de tempo destinado ao processo; iii. compute, para cada usurio, a razo entre o tempo utilizado e o tempo destinado; iv. escolhe para execuo aquele usurio que apresenta a menor razo.
4.6.
Escalonamento em Dois Nveis
At aqui, consideramos que todos os processo executveis esto na memria. Este geralmente no o caso, pois dificilmente a memria principal comportar todos os dados necessrios. Precisaremos, pois, manter parte dos processos em disco.
O problema que surge que o tempo para ativar um processo que est em disco muito maior que o tempo necessrio para ativar um processo que est na memria (uma a duas ordens de grandeza maior). A melhor soluo para isto a utilizao de um escalonador em dois nveis. O
funcionamento ser ento da seguinte forma: i. um subconjunto dos processos executveis mantido na memria; ii. um outro subconjunto mantido no disco; iii. um escalonador (chamado de baixo nvel) utilizado para realizar o chaveamento (por qualquer dos mtodos j descritos, ou outros semelhantes) apenas entre os processos que esto na memria; iv. um outro escalonador (chamado de alto nvel) utilizado para trocar periodicamente o conjunto de processo que esto na memria (substituindo-os por alguns que estavam no disco).
Para realizar a escolha de qual conjunto de processos deve ser colocado na memria principal o escalonador de alto nvel deve responder perguntas tais como: Quanto tempo se passou desde que o processo foi posto ou retirado ? Quanto tempo de UCP o processo teve recentemente ? Qual o tamanho do processo ? Qual a prioridade do processo ?
5. GERENCIAMENTO DE MEMRIA
Trataremos agora da parte do S.O. conhecida como gerenciador de memria, que o responsvel por cuidar de quais partes da memria esto em uso, quais esto livres, alocar memria a processos quando eles precisam, desalocar quando eles no mais necessitarem e gerenciar a troca (swapping) dos processos entre memria principal e disco, quando a memria principal no suficientemente grande para manter todos os processos.
5.1.
Gerenciamento de Memria sem Troca ou Paginao
Troca e paginao so mtodos utilizados de movimentao da memria para o disco e vice-versa durante a execuo dos processos. Entretanto, antes de estudar esses mtodos, estudaremos o caso mais simples em que no realizada nem troca nem paginao.
5.2.
Monoprogramao sem Troca ou Paginao
Neste caso, temos um nico processo executando por vez, de forma que o mesmo pode utilizar toda a memria disponvel, com exceo da parte reservada ao sistema operacional, que permanece constantemente em local pr-determinado da memria. O S.O. carrega um programa do disco para a memria, executa-o e, em seguida, aguarda comandos do usurio para carregar um novo programa, que se sobrepor ao anterior.
5.3.
Multiprogramao
Apesar de largamente utilizada em microcomputadores, a monoprogramao praticamente no mais utilizada em sistemas grandes. Algumas razes para isso so as seguintes: - Muitas aplicaes so mais facilmente programveis quando as dividimos em dois ou mais processos. Os grandes computadores em geral oferecem servios interativos simultaneamente para diversos usurios. Neste caso, impossvel de se trabalhar com um nico processo na
memria por vez, pois isso representaria grande sobrecarga devido constante necessidade de chavear de um processo para outro (o que, com apenas um processo por vez na memria representaria constantemente estar lendo e escrevendo no disco). necessrio que diversos processos estejam "simultaneamente" em execuo, devido ao fato de que muitos deles esto constantemente realizando operaes de E/S, o que implica em grandes esperas, nas quais, por questo de eficincia, a UCP deve ser entregue a outro processo.
5.3.1. Multiprogramao com Parties Fixas J que percebemos a importncia da existncia de diversos processos na memria, devemos agora analisar de que forma este objetivo pode ser conseguido. A forma mais simples dividir a memria existente em n parties fixas, possivelmente diferentes. Essas parties poderiam ser criadas, por exemplo, pelo operador, ao inicializar o sistema. Uma forma de tratar com essas parties seria ento a seguinte: (i) cria-se uma fila para cada partio existente; (ii)cada vez que um processo iniciado, ele colocado na fila da menor partio capaz de o executar; (iii)os processo em cada partio so escolhidos de acordo com alguma forma de poltica (p.ex.: o primeiro a chegar atendido antes). Este mtodo pode ser simbolizado como na Figura 6 :
Figura 6: Esquema de Mltiplas Filas
Uma desvantagem bvia desse esquema a de que pode ocorrer que uma partio grande esteja sem utilizao, enquanto que diversos processos esto aguardando para utilizar uma partio menor (p.ex.: na figura acima temos trs processos aguardando pela partio 1, enquanto que a partio 3 est desocupada). Podemos resolver esse problema da seguinte forma: (i) estabelecemos apenas uma fila para todas as parties; (ii)quando uma partio fica livre, um novo processo que caiba na partio livre escolhido e colocado na mesma, conforme indicado na Figura 7:
Figura 7: Esquema de Fila nica O problema que surge aqui a forma de escolha implcita no item (ii). Se a partio livre for entregue para o primeiro processo da fila, pode ocorrer de que uma partio grande seja entregue a um processo pequeno, o que no desejvel (pois implica desperdcio de memria). Por outro lado, se percorremos a fila procurando o maior processo aguardando que caiba na partio, isto representar servir melhor os processos grandes em detrimento dos pequenos.
5.3.2. Relocao e Proteo Relocao e proteo so dois problemas introduzidos pela multiprogramao, e que precisam ser resolvidos. A necessidade da relocao pode ser vista nas figuras anteriores, onde fica claro que processos diferentes executam em posies de memria diferentes e, portanto, com endereos diferentes.
Suponha uma rotina em um programa que, ao trmino da ligao dos mdulos deste, colocada na posio 100 em relao ao incio do programa. claro que se esse programa for ser executado na partio 1, todas as chamadas dessa rotina devem ser enviadas para a posio de memria 100k+100. Se o programa for executado na partio 2, as chamadas para essa mesma rotina devem ser enviadas para a posio 200k+100. Uma possvel soluo modificar as instrues conforme o programa carregado na memria. Desta forma, quando o S.O. carrega o programa, adiciona a todas as instrues que se referenciem a endereos, o valor do ponto inicial de carga do programa (i.e., o incio da partio escolhida para o mesmo). Esta soluo exige que o ligador (linker) coloque no incio do cdigo binrio do programa uma tabela (ou uma lista) que apresente as indicaes das posies no programa que devem ser modificadas no carregamento. Esta soluo entretanto no resolve o problema da proteo, pois nada impede que um programa errado ou malicioso leia ou altere posies de memria de outros usurios (dado que as referncias so sempre as posies absolutas de memria). Uma soluo para isto adotada no IBM 360 foi a de dividir a memria em unidades de 2k bytes e associar um cdigo de proteo de 4 bits a cada uma dessas regies. Durante a execuo de um processo, o PSW contm um cdigo de 4 bits, que testado com todos os acessos memria realizados pelo processo, e gera uma interrupo se tentar acessar uma regio de cdigo diferente. Uma soluo alternativa tanto para o problema da relocao como para o da proteo a utilizao de registradores de base e limite. Sempre que um processo carregado na memria, o S.O. ajusta o valor do registrador de base de acordo com a disponibilidade de memria. Este registrador utilizado de forma que, sempre que um acesso realizado na memria pelo processo, o valor do registrador de base automaticamente somado, o que faz com que o cdigo do programa em si no precise ser modificado durante o carregamento. O registrador de limite utilizado para determinar o espao de memria que o processo pode executar. Todo acesso realizado pelo processo memria testado com o valor do
registrador limite, para verificar se esse acesso est se realizando dentro do espao reservado ao processo (caso em que ele vlido) ou fora do seu espao (acesso invlido). Uma vantagem adicional do mtodo dos registradores base e limite o de permitir que um programa seja movido na memria, mesmo aps j estar em execuo. No mtodo anterior isto no era possvel sem realizar todo o processo de alterao dos endereos novamente.
5.3.3. Troca (swapping) Num sistema em batch, desde que se mantenha a UCP ocupada o mximo de tempo possvel, no existe razo para se complicar o mtodo de gerenciamento da memria. Entretanto, num sistema de time-sharing, onde muitas vezes existe menos memria do que o necessrio para manter todos os processos de usurio, ento preciso que uma parte dos processos sejam temporariamente mantidos em disco. Para executar processos que esto no disco, eles devem ser enviados para a memria, o que significa retirar algum que l estava. Este processo denominado troca (swapping), e o que passaremos a estudar.
5.3.4. Multiprogramao com Parties Variveis A utilizao de parties fixas para um sistema com swapping ineficiente, pois implicaria em que grande parte do tempo as parties estariam sendo utilizadas por processos muito pequenos para as mesmas. A soluo para isso tratarmos com parties variveis, isto , parties que variam conforme as necessidades dos processos, tanto em tamanho, como em localizao, como em nmero de parties. Isto melhora a utilizao de memria mas tambm complica a alocao e desalocao de memria. possvel combinar todos os buracos formados na memria em um nico, o que conhecido como compactao de memria, mas isto raramente utilizado, devido grande utilizao de UCP requerida. Um ponto importante a considerar quanta memria deve ser alocada a um processo, quando o mesmo iniciado. Se os processos necessitam de uma certa quantidade pr-fixada e invariante de memria, ento basta alocar a quantidade necessria para cada processo ativo e o problema est resolvido. Entretanto, muitas vezes os processos necessitam de mais memria durante o processamento (alocao dinmica de memria). Neste caso, quando um processo necessita de mais memria, podem ocorrer dois casos: a. existe um buraco (regio no ocupada) de memria prximo ao processo: neste caso, basta alocar memria desse buraco; b. o processo est cercado por outros processos, ou o buraco que existe no suficiente: neste caso, podemos tomar alguma das seguintes aes:
mover o processo para um buraco de memria maior (grande o suficiente para as novas exigncias do processo); se no houver tal espao, alguns processos devem ser retirados da memria, para deixar espao para esse processo; se no houver espao no disco para outros processos, o processo que pediu mais espao na memria deve ser morto (kill). Quando se espera que diversos processos cresam durante a execuo, pode ser uma boa idia reservar espao extra para esses processos quando os mesmos so criados, para eliminar a sobrecarga de lidar com movimentao ou troca de processos. Trataremos agora de duas das formas principais de cuidar da utilizao de memria: mapas de bits, listas e sistemas de desabrochamento.
5.4.
Gerenciamento de Espao
5.4.1. Gerencimento com Mapa de Bits Este mtodo consiste em formar um mapa de bits. A memria subdividida em unidades de um certo tamanho. A cada uma dessas unidades associado um bit que, se for 0 indica que essa parte da memria est livre, e se for 1, indica que ela est ocupada. O tamanho da unidade que associada com um bit deve ser cuidadosamente escolhida, entretanto, mesmo com a associao de apenas 4 bytes de memria para cada bit no mapa, a parte da memria gasta com esse mapa de apenas 3%. Se escolhemos mais de 4 bytes, o espao ocupado pela tabela ser menor, mas o desperdcio de memria crescer . A Figura 8 mostra um trecho de memria e o mapa de bits associado.
Figura 8
A desvantagem desse mtodo, que, quando um novo processo que ocupa k unidades de memria deve ser carregado na memria, o gerenciador deve percorrer o mapa de bits para encontrar k bits iguais a zero consecutivos, o que no um processo simples.
5.4.2. Gerenciamento com Listas Encadeadas Neste caso, mantemos uma lista encadeada de segmentos alocados e livres, sendo que cada segmento um processo ou um buraco entre dois processos. Na Figura 8, anteriormente apresentada, temos tambm a lista associada ao trecho de memria indicado. H indica um buraco e P um processo. A lista apresenta-se em ordem de endereos, de forma que quando um processo termina ou enviado para o disco, a atualizao da lista simples: cada processo, desde que no seja nem o primeiro nem o ltimo da lista, apresenta-se cercado por dois segmentos, que podem ser buracos ou outros processos, o que nos d as quatro possibilidades mostradas na Figura 9:
Figura 9 Note que os buracos adjacentes devem ser combinados num nico. Vejamos agora alguns algoritmos que podem ser utilizados para escolher o ponto em que deve ser carregado um processo recm criado ou que veio do disco por uma troca (foi swapped in). Assumimos que o gerenciador de memria sabe quanto espao alocar ao processo:
1. First Fit (primeiro encaixe): neste caso, o algoritmo consiste em percorrer a fila at encontrar o primeiro espao em que caiba o processo. um algoritmo rpido; 2. Next Fit (prximo encaixe): o mesmo que o algoritmo anterior, s que ao invs de procurar sempre a partir do incio da lista, procura a partir do ltimo ponto em que encontrou. Simulaes mostraram que esse algoritmo apresenta um desempenho prximo ao anterior; 3. Best Fit (melhor encaixe): consiste em verificar toda a lista e procurar o buraco que tiver espao mais prximo das necessidades do processo. um algoritmo mais lento e, alm disso, simulaes demonstram que tem um desempenho pior que o First Fit, devido ao fato de tender a encher a memria com pequenos buracos sem nenhuma utilidade; 4. Worst Fit (pior ajuste): sugerido pelo fracasso do algoritmo anterior, consiste em pegar sempre o maior buraco disponvel. Simulaes mostraram que tambm seu desempenho ruim.
Os quatro algoritmos podem ter sua velocidade aumentada pela manuteno de duas listas separadas, uma para processos e outra para buracos. Ainda outro algoritmo possvel, quando temos duas listas separadas, o Quick Fit (ajuste rpido), que consiste em manter listas separadas para alguns dos tamanhos mais comuns especificados (por exemplo, uma fila para 2k, outra para 4k, outra para 8k, etc.). Neste caso, a busca de um buraco com o tamanho requerido extremamente rpido, entretanto, quando um processo termina, a liberao de seu espao complicada, devido necessidade de reagrupar os buracos e modific-los de fila.
5.5.
Alocao de Espao de Troca (swap)
Chamamos de espao de troca ao espao ocupado no disco pelos processos que a esto guardados pelo fato de que foram retirados da memria devido a uma troca (swap). Os algoritmos para gerenciar o espao alocado em disco para swap so os mesmos apresentados para o gerenciamento da memria, com a diferena de que em alguns sistemas, cada processo tem no disco um espao reservado para o mesmo, de forma que no est, como na memria, sendo constantemente mudado de lugar.
Um fator adicional de diferena o fato de que, pelos discos serem dispositivos de bloco, a quantidade de espao reservado para os processos no disco devero ser mltiplas do tamanho do bloco.
5.6.
Memria Virtual
Quando os programas comearam a ficar grandes demais para a quantidade de memria necessria, a primeira soluo adotada foi a de utilizao de overlay. Nesta tcnica, o programa era subdividido em partes menores, chamadas overlays, e que podiam ser rodadas separadamente. Quando um dos overlays terminava a execuo, um outro poderia ser carregado na mesma posio de memria utilizada pelo anterior (isto existe ainda em linguagens como o Turbo-Pascal e o Aztec C). O problema com este mtodo que todo o trabalho de diviso de programas em overlays, que alis no simples, deve ser realizado pelo programador. A tcnica de memria virtual uma outra forma de executar um programa que no cabe na memria existente, mas que no apresenta os inconvenientes dos overlays, por ser realizada de forma automtica pelo prprio computador. Neste caso, partes do programa, dos dados, e da pilha so mantidas no disco, sendo que existe uma forma de deciso cuidadosa de quais devem permanecer no disco e quais na memria. Da mesma forma, podemos alocar diversos processos na memria virtual, de forma que cada um pensa ter uma quantidade de memria que somadas ultrapassam a quantidade real de memria.
5.6.1. Paginao Paginao uma tcnica muito utilizada em sistemas com memria virtual. Antes, estabeleamos o conceito de espao virtual. Chamamos de espao virtual ao espao de memria que pode ser referenciado por um programa qualquer em dado processador. Por exemplo, um processador com endereamento de 16 bits possui um espao virtual de 64k bytes (se o endereamento for em bytes). Quando uma instruo como:
LD A,(1000h); carrega acumulador com contedo do endereo 1000 (em hexadecimal) apresentada no Z80, o 1000h corresponde a um endereo virtual, de um espao de endereamento virtual de 64k bytes.
Em um computador sem memria virtual, o endereo virtual corresponde ao endereo efetivamente colocado no duto de endereamento da memria. No exemplo acima, seria colocado no duto de endereos o valor binrio correspondente a 1000h. Quando o computador possui memria virtual, esse endereo virtual enviado para uma unidade de gerenciamento de memria, MMU (memory management unit), que corresponde a um chip ou um conjunto de chips que translada esse endereo virtual em um endereo fsico, de acordo com uma tabela.
A operao da MMU pode ser explicada conforme apresentado na Figura 10:
Figura 10 O espao de endereos virtuais dividido em unidades chamadas pginas e o espao de memria fsica dividido em unidades chamadas quadros de pgina, de mesmo tamanho das pginas. A MMU tem uma tabela que indica, para cada pgina, qual o quadro de pgina que corresponde mesma. No exemplo da Figura 10, temos um espao virtual de 64k bytes, uma memria fsica de 32k bytes, e pginas de 4k bytes. Se o processador tenta acessar o endereo 0, a MMU verifica que isto corresponde ao primeiro endereo da primeira pgina,
verifica ento que essa primeira pgina est alocada no terceiro quadro de pgina (i.e. o de nmero 2). Converte ento esse endereo para 8192 (decimal) e envia esse endereo convertido para a memria. Note que nem o processador nem a memria precisaram ficar sabendo da existncia de paginao. No entanto, como nem todas as pginas do espao virtual podem estar residentes na memria simultaneamente, ocorrer o caso de que um acesso seja realizado para uma pgina que no est na memria. Para saber isto, a MMU mantm na tabela de translao um bit para cada pgina que indica se a mesma est presente na memria ou no. Se um acesso for realizado a uma pgina ausente, gerada uma falta de pgina (page fault), o que chama uma rotina de tratamento de interrupo especfica para o S.O., que ento se encarrega do carregamento da pgina faltante e o ajuste correspondente na tabela de translao. A forma mais comum de implementao da MMU, escolher alguns dos bits mais significativos do endereo virtual como indicadores do nmero de pgina e o restante dos bits como um deslocamento dentro dessa pgina. Por exemplo, na Figura 10, apresentada acima, de 16 bits do endereo virtual, 12 sero utilizados para o deslocamento (pois so necessrios 12 bits para enderear os 4k bytes de uma pgina), sendo os 4 restantes utilizados como um ndice para qual das 16 pginas est sendo referenciada. A MMU portanto, pega os 4 bits do ndice de pgina, acessa a posio correspondente da tabela de translao, verifica se a pgina est presente na memria, se no estiver, gera uma interrupo para carregamento e, depois, verifica o valor colocado nessa entrada da tabela de translao e os junta aos 12 bits de deslocamento dentro da pgina. A Figura 11 mostra a operao da MMU.
Figura 11 5.6.2. Segmentao A paginao fornece uma forma de se conseguir grandes espaos de endereamento lineares em uma quantidade finita de memria fsica. Em algumas aplicaes, no entanto, prefervel ter um espao bidimensional. O espao bidimensional no sentido de que dividido em um certo nmero de segmentos, cada um com dado nmero de bytes. Dessa forma, um endereamento sempre expresso da forma (segmento, deslocamento). Os diferentes segmentos so associados a diversos programas ou mesmo arquivos, de forma que neste caso, os arquivos podem ser acessados como se fossem posies de memria. Veja que, diferentemente da paginao, na segmentao os programadores (ou os compiladores) levavam cuidadosamente em conta a segmentao, tentando colocar entidades diferentes em segmentos diferentes. Essa estratgia facilitou o compartilhamento de objetos entre processos diferentes. A Figura 12 mostra uma implementao comum de segmentao em microcomputadores com o processador 68000.
Figura 12 Note que o hardware suporta at 16 processos, cada um com 1024 pginas de 4k bytes cada (isto , cada processo com um endereo virtual de 4M bytes). A cada um dos 16 processos, a MMU associa uma seo com 64 descritores de segmento, sendo que cada descritor contm at 16 pginas. O descritor do segmento contm o tamanho do segmento (1 a 16 pginas), bits que indicam a proteo associada com o segmento e um ponteiro para uma tabela de pginas. Note tambm que para trocar de processo, a nica coisa que o S.O. precisa fazer alterar um registrador de 4 bits e isso automaticamente muda os acessos s tabelas. Deve-se enfatizar que este apenas um exemplo de esquema de segmentao e no o nico possvel.
6. ALGORITMOS DE MUDANA DE PGINA

No momento em que detectada a falta de uma pgina (i.e., ocorre um page fault), o S.O. deve escolher uma das pginas atualmente residentes na memria para ser removida, de forma a liberar um quadro de pgina para a colocao da pgina faltante. Deve-se tomar o cuidado, caso a pgina a ser removida tenha sido alterada, de reescrev-la no disco. O problema que surge aqui o seguinte: de que forma escolher a pgina a remover ? claro que devemos procurar remover uma pgina que no seja muito necessria aos processos em execuo, isto , devemos remover uma pgina no muito utilizada. Se, ao contrrio, removssemos uma pgina amplamente utilizada, em pouco tempo uma referncia mesma seria realizada, o que ocasionaria um page-fault e a necessidade de recarregar esta pgina, alm de escolher outra para ser removida. O que devemos considerar ento o seguinte: como determinar qual pgina no est sendo muito utilizada ? Os prximos tens discutiram alguns mtodos de se realizar essa escolha.
6.1.
Mudana tima de Pgina
O mtodo timo de mudana de pgina consiste no seguinte: determinar, para cada pgina presente na memria, quantas instrues faltam para a mesma ser referenciada (i.e., quantas instrues sero executadas antes que a pgina seja referenciada); retirar a pgina que for demorar mais tempo para ser novamente referenciada. Como fcil perceber, o mtodo delineado acima no pode ser implementado numa situao real, pois exigiria conhecimento de situaes futuras (De que forma um S.O. conseguiria determinar quantas instrues faltam para uma pgina ser referenciada?). Este mtodo utilizado apenas em simulaes, onde temos um controle completo das execues dos processos, para fins de comparao de algum algoritmo com o algoritmo timo.
6.2.
Mudana da Pgina no Recentemente Usada
Este mtodo seleciona para retirar uma pgina que no tenha sido recentemente utilizada. Para determinar se uma pgina foi ou no utilizada recentemente, conta-se com o auxlio de 2 bits associados com cada uma das pginas na memria: R: indica se a pgina j foi referenciada; M: indica se a pgina foi modificada. Estes bits, presentes em muitos hardwares de paginao, so alterados automaticamente (por hardware) quando uma referncia pgina realizada. Assim, quando uma instruo l um dado em uma certa posio de memria, o bit R da pgina correspondente automaticamente colocado em 1; quando uma instruo escreve em uma dada posio de memria, os bits R e M da pgina correspondente so colocados em 1. Esses bits so colocados inicialmente em 0 quando uma pgina carregada na memria. Uma vez que esses bits sejam colocados em 1, eles s podem voltar a 0 atravs de instrues em software. O mtodo de determinar se uma pgina foi recentemente utilizada ento o seguinte: a cada tiquetaque do relgio, o S.O. coloca todos os bits R das pginas em 0; quando ocorre um page fault, temos trs categorias de pginas: classe 0: R=0, M=0 classe 1: R=0, M=1 classe 2: R=1, M=0 classe 3: R=1, M=1
A classe 2 ocorre para uma pgina que foi referenciada pelo menos uma vez desde o ltimo tiquetaque do relgio, sem ter sido alterada. A classe 3 ocorre para uma pgina que j foi alterada e referenciada desde o ltimo tiquetaque. As classes 0 e 1 so as correspondentes s classes 2 e 3 (respectivamente), que no tiveram nenhuma referncia desde o ltimo tiquetaque do relgio. - escolhe-se para ser retirada uma das pginas que pertencer classe mais baixa no vazia, no momento da ocorrncia do page fault. Esse algoritmo apresenta as vantagens de ser implementvel de forma simples e eficiente. Quando o hardware no dispe dos bits R e M, o S.O. pode simular esses bits atravs da utilizao dos mecanismos de proteo de pginas, da seguinte forma: Inicialmente, marcam-se todas as pginas como ausentes;
quando uma pgina referenciada, gerado um page fault (pois a pgina est marcada como ausente); o S.O. ento marca essa pgina como presente, mas permite apenas leitura (i.e., Read-Only); o S.O. marca tambm, em uma tabela interna, um bit R simulado para essa pgina; quando uma escrita for tentada nessa pgina, uma interrupo de acesso invlido ser gerada, e o S.O. poder ento marcar a pgina como de leitura e escrita (Read-Write); o S.O. ento marca numa tabela interna o bit M correspondente a essa pgina.
6.3.
Mudana de Pgina "Primeira a Entrar, Primeira a Sair"(FIFO)
Neste caso, mantm-se uma fila de pginas referenciadas. Ao entrar uma nova pgina, ela entra no fim da fila, substituindo a que estava colocada no incio da fila. O problema com este algoritmo que pode retirar pginas muito valiosas (i.e., pginas que, apesar de estarem a bastante tempo na memria esto sendo amplamente utilizadas). Uma possvel soluo para esse problema consiste na utilizao dos bits R e M: verifica os bits R e M da pgina mais antiga; se essa pgina for classe 0, escolhe-a para ser retirada; se no for, continua procurando na fila; se em toda a fila no achou nenhum classe 0, prossegue para as classes seguintes (1, 2 e 3). Uma variao dessa soluo o algoritmo conhecido como segunda chance: verifica o bit R da pgina mais velha; se R for zero, utiliza essa pgina; se R for 1, pe R em 0 e coloca a pgina no fim da fila; prossegue analisando a fila, at encontrar uma pgina com R=0 (no pior caso, ser a primeira pgina, que teve seu R alterado para 0).
6.4.
Mudana da Pgina Menos Recentemente Utilizada

(Least Recently Used, LRU)
Este mtodo se baseia nas seguintes observaes:
pginas muito utilizadas nas instrues mais recentes provavelmente permanecero muito utilizadas nas prximas instrues; pginas que no so utilizadas a tempo provavelmente no sero utilizadas por bastante tempo; O algoritmo ento consiste no seguinte: quando ocorre um page fault, retira a pgina que a mais tempo no referenciada. O problema bsico com este algoritmo que a sua implementao muito dispendiosa: deve-se manter uma lista de todas as pginas na memria, com as mais recentemente utilizadas no comeo e as menos recentemente utilizadas no final; e esta lista deve ser alterada a cada referncia de memria. Note-se que a implementao por software completamente invivel em termos de tempo de execuo. Vejamos agora duas possveis solues por hardware. Na primeira, mantemos no processador um contador C, com um nmero relativamente grande de bits (p.ex.: 64 bits). Com esse contador, realizamos o seguinte procedimento: - cada instruo executada, incrementamos esse contador; cada entrada na tabela de pginas, tem tambm associado um campo com tantos bits quantos os do contador C; depois de cada referncia memria, o contador C armazenado na entrada correspondente pgina referenciada; quando ocorre um page fault, escolhemos a pgina com o menor valor no campo de armazenamento do contador (pois essa ser a pgina que foi referenciada a mais tempo). Na segunda soluo, para n quadros de pginas, temos uma matriz n X n de bits, e agimos da seguinte forma: quando a pgina i referenciada, colocamos em 1 todos os bits da linha i da tabela e, em seguida, colocamos em 0 todos os bits da coluna i da tabela; quando ocorre um page fault, retiramos a pgina que apresentar o menor nmero em sua linha (este nmero interpretado pela associao de todos os bits da linha da esquerda para a direita).
6.5.
Simulando LRU em Software
Nas solues de LRU apresentadas at agora, consideramos sempre a necessidade de hardware especial. Mas, e quando no existe hardware especial para LRU ? Com essa considerao em vista, desenvolveu-se uma aproximao para LRU, chamada NFU (no frequentemente utilizada), que pode ser realizada por software, da seguinte forma: um contador mantido, em software, para cada pgina;
a cada interrupo de relgio, o bit R correspondente a cada uma das pginas somado a esse contador (portanto, se a pgina foi referenciada dentro desse intervalo de relgio, o valor do contador ser incrementado, caso contrrio, o valor do contador ser mantido) quando ocorre um page fault, escolhe-se a pgina com valor menor nesse contador.
O grande problema com esse algoritmo que, se uma pgina intensivamente utilizada durante um certo tempo, ela tender a permanecer na memria, mesmo quando no for mais necessria (pois adquiriu um valor alto no contador). Felizmente, uma modificao simples pode ser feita no mtodo evitando esse inconveniente. A alterao consiste no seguinte: os contadores so deslocados 1 bit direita, antes de somar R R somado ao bit mais esquerda (mais significativo) do contador, ao invs de ao bit mais direita (menos significativo). Esse algoritmo conhecido como algoritmo de aging. obvio que uma pgina que no foi referenciada a 4 tique-taques ter 4 zeros esquerda e, portanto um valor baixo, colocando-a como candidata substituio. Este algoritmo tem duas diferenas fundamentais em relao ao algoritmo de LRU: 1. no consegue decidir qual a referencia mais recente com intervalos menores que um tiquetaque; 2. o nmero de bits do contador finito e, portanto, quando este chega a zero, no conseguimos mais distinguir as pginas mais antigas. Por exemplo, com 8 bits no contador, uma pgina no referenciada a 9 tique-taques no pode ser distinguida de uma pgina no referenciada a 1000 tique-taques. No entanto, em geral 8 bits suficiente para determinar que uma pgina j no mais necessria.
6.6.
Consideraes de Projeto para Sistemas de Paginao
Veremos alguns pontos que devem ser considerados, alm do algoritmo de paginao propriamente dito, para que um sistema de paginao tenha um bom desempenho.
6.6.1. Modelo do Conjunto Ativo (Working Set) Num sistema puro de paginao, que tambm pode ser chamado de paginao por demanda, o sistema comea sem nenhuma pgina na memria e elas vo sendo carregadas medida em que forem necessria, seguindo o algoritmo de substituio de pgina escolhido. Esta estratgia pura pode ser melhorada, como veremos a seguir. Um primeiro dado importante a considerar a existncia, na grande maioria dos processos, de uma localidade de referncias, o que significa que os processos mantm, em cada uma das fases de sua execuo, referncias a fraes pequenas do total do nmero de pginas necessrias a ele. Um exemplo disso um compilador, que durante um certo tempo acessa as pginas correspondentes anlise sinttica, depois essas pginas deixam de ser necessrias, passando-se ento a utilizar as de anlise semntica e assim por diante. Baseado neste fato, surge o conceito de conjunto ativo (working set), que corresponde ao conjunto de pginas correntemente em uso de um dado processo. fcil de notar que, se todo o conjunto ativo de um processo estiver na memria principal, ele executar praticamente sem gerar page faults, at que passe a uma nova fase do processamento. Por outro lado, se no houver espao para todo o conjunto ativo de um processo, este gerar muitos page faults, o que ocasionar uma grande diminuio em seu tempo de execuo, devido necessidade de constantes trocas de pginas entre memria e disco. Aqui surge o conceito de thrashing, que ocorre quando um processo gera muitos page fault em poucas instrues. Surge ento a seguinte considerao: o que fazer quando um processo novo iniciado ou, num sistema com swap, quando um processo que estava em disco deve ser colocado na memria? Se deixarmos que esse processo gere tantos page fault quanto necessrios para a carga do seu working set, teremos uma execuo muito lenta. Devemos ento, de alguma forma, determinar qual o working set do processo e carreg-lo na memria antes de permitir que o processo comece a executar. Este o chamado modelo do conjunto ativo (working set model). O ato de carregamento adiantado das pginas (antes da ocorrncia do page fault para a mesma) chamado pr-paginao. Vejamos agora algumas consideraes com relao aos tamanhos dos working set. Se a soma total dos working set de todos os processos residentes em memria maior que a quantidade de memria disponvel, ento ocorrer thrashing. (Obs: processos residentes na memria so aqueles que o escalonador de baixo nvel utiliza para a seleo do atualmente
em execuo. O escalonador em alto nvel o responsvel pela troca (swap) dos processos residentes em memria, a certos intervalos de tempo.) Portanto, devemos escolher os processos residentes em memria de forma que a soma de seus working set no seja maior que a quantidade de memria disponvel. Aps os fatos apresentados acima, surge a questo: como determinar quais as pginas de um processo que fazem parte de seu working set? Uma possvel soluo para isto utilizar o algoritmo de aging, considerando como parte do working set apenas as pginas que apresentem ao menos um bit em 1 em seus primeiros n bits (i.e., qualquer pgina que no seja referenciada por n tique-taques consecutivos retirada do working set do processo). O valor de n deve ser definido experimentalmente.
6.6.2. Rotinas de Alocao Local X Global Devemos agora determinar de que forma a memria ser alocada entre os diversos processos executveis que competem por ela. As duas estratgias bsicas so chamadas de alocao local e alocao global, que so descritas a seguir: alocao local: quando gerado um page fault em um dado processo, retiramos uma das pginas do prprio processo, para a colocao da pgina requerida; alocao global: quando um page fault gerado, escolhe para retirar uma das pginas da memria, no importa a qual processo ela esteja alocada. Para exemplificar a diferena entre as duas tcnicas, veja a Figura 13 onde, na situao da figura (a), gerado um page fault para a pgina A6 (os nmeros ao lado das pginas indicam o valor do contador do algoritmo de aging). Se seguimos uma estratgia local, a pgina retirada ser a A5 (conforme (b)), enquanto que para uma estratgia global, a pgina retirada ser a B3.
Figura 13 fcil de notar que a estratgia local mantm fixa a quantidade de memria destinada a cada processo, enquanto que a estratgia global muda dinamicamente a alocao de memria. Em geral, os algoritmos globais apresentam maior eficincia, devido aos seguintes fatos: se o working set de um processo aumenta, a estratgia local tende a gerar thrashing; se o working set de um processo diminui, a estratgia local tende a desperdiar memria. Entretanto, se nos decidimos por utilizao de uma estratgia global, devemos resolver a seguinte questo: de que forma o sistema pode decidir dinamicamente (i.e., a todo instante) quantos quadros de pgina alocar para cada processo (em outras palavras: qual o tamanho do working set do processo em cada instante) ? Uma possvel soluo realizar a monitorao pelos bits de aging, conforme indicado acima. Entretanto isto apresenta um problema, o working set de um processo pode mudar em poucos microssegundos, enquanto que as indicaes de aging s mudam a cada tique-taque do relgio (digamos, 20ms). Uma soluo melhor para esse problema a utilizao de um algoritmo de alocao por frequncia de falta de pgina (PFF: page fault frequency). Esta tcnica baseada no fato de que a taxa de falta de pginas para um dado processo decresce com o aumento do nmero de quadros de pgina alocados para esse processo.Veja a Figura 14
Figura 14
6.6.3. Tamanho da Pgina Um outro fator que deve ser cuidadosamente estudado o tamanho da pgina. Existem consideraes em favor tanto de pginas pequenas quanto de pginas grandes, como veremos: Consideraes a favor de pginas pequenas: na mdia, metade da pgina final de qualquer segmento desperdiada (pois os programas e reas de dados no terminam necessariamente em mltiplos de pgina). Isto conhecido como fragmentao interna; um programa que consista em processos pequenos pode executar utilizando menos memria quando o tamanho da pgina pequeno. Consideraes a favor de pginas grandes: quanto menor o tamanho da pgina, maior o tamanho da tabela de pginas (para uma dada quantidade de memria virtual); quando uma pgina precisa ser carregada na memria, temos um acesso ao disco, com os correspondentes tempos de busca e espera de setor, alm do de transferncia. Assim, se j transferimos uma quantidade maior de bytes a cada acesso, diminumos a influncia dos dois primeiros fatores do tempo, aumentando a eficincia; se o processador central precisa alterar registradores internos referente tabela de pginas a cada chaveamento de processo, ento pginas maiores necessitaro registradores, o que significa menor tempo de chaveamento de processos. menos
Tamanhos comumente encontrados de pgina so: 512 bytes, 1 kbytes, 2 kbytes e 4 kbytes.
6.6.4. Consideraes de Implementao Normalmente, quando queremos implementar um sistema de paginao, devemos considerar alguns fatos que complicam um pouco seu gerenciamento, apresentaremos alguns exemplos a seguir. i) Bloqueamento de Pginas na Memria Quando um processo bloqueia aguardando a transferncia de dados de um dispositivo para um buffer, um outro processo selecionado para execuo. Se este outro processo gera um page fault, existe a possibilidade de que a pgina escolhida para ser retirada seja justamente aquela onde se encontra o buffer que estava aguardando a transferncia do dispositivo. Se o dispositivo tentar ento transferir para esse buffer, ele pode estragar a nova informao carregada pelo page fault. Existem basicamente duas solues para este problema: 1. trancamento da pgina que contm o buffer, impedindo que a mesma seja retirada da memria; 2. realizar as transferncias de dispositivos sempre para buffers internos do kernel e, aps terminada a transferncia, destes para o buffer do processo.
ii) Pginas Compartilhadas
Um outro problema que surge est relacionado com o fato de que diversos processo podem estar, em um dado momento, utilizando o mesmo programa (p.ex.: diversos usurios rodando um editor, ou um compilador). Para evitar duplicao de informaes na memria, conveniente que essas informaes comuns sejam armazenadas em pginas que so compartilhadas pelos processos que as utilizam. Um problema que surge logo de incio o seguinte: algumas partes no podem ser compartilhadas como, por exemplo, os textos que esto sendo editados em um mesmo editor. A soluo para este problema simples: basta saber quais as pginas que so apenas de leitura (p.ex.: o cdigo do programa), permitindo que estas sejam compartilhadas e impedindo o compartilhamento das pginas que so de leitura e escrita (p.ex.: o texto sob edio). Um outro problema mais difcil de resolver o seguinte:
suponha que dois processos, A e B, esto compartilhando o cdigo de um editor; se A termina a edio e, portanto, sai da memria algumas de suas pginas (as que correspondem ao cdigo do editor) no podero ser retiradas devido a serem compartilhadas, pois se isto ocorresse, seriam gerados muitos page fault para o processo B, o que representaria muita sobrecarga para o sistema; se um dos processo enviado para o disco (swap) temos uma situao semelhante ao caso do trmino de um deles (como acima).
A soluo para isto manter alguma forma de estrutura de dados que indique quais das pginas residentes esto sendo compartilhadas. Este processo, entretanto, no simples.
7. ENTRADAS E SADAS
Uma das funes principais de um S.O. controlar o acesso aos dispositivos de entrada e sada (abreviadamente: E/S ou I/O) e fornecer aos usurios uma interface simples com os mesmos. Na medida do possvel, a interface oferecida para todos os dispositivos de E/S deve ser a mesma (o que garante a Independncia de Dispositivo - device independency).
7.1.
Princpios de Hardware de E/S
Os dispositivos de E/S sero enfocados sob o ponto de vista de sua programao, que no entanto est muitas vezes ligada sua operao interna.
7.1.1. Dispositivos de E/S Divide-se os dispositivos de E/S em duas categorias: dispositivos de bloco: armazenam a informao em blocos de tamanho fixo, cada um dos quais com o seu prprio endereo, podendo ser lido independentemente de todos os outros. Ex: discos. dispositivos de caracteres: entrega ou aceita uma cadeia de caracteres, sem considerar qualquer estrutura de bloco. Ex: terminal e impressora.
Alguns dispositivos no se adaptam bem a nenhuma das duas categorias acima. Por exemplo o relgio, que nem apresenta estrutura de bloco nem realiza transmisso de caracteres, realizando apenas uma interrupo a intervalos predefinidos. Com isto, vemos que a classificao acima no exaustiva, servindo apenas como orientao para uma melhor compreenso de diversos dispositivos.
7.1.2. Controladores de Dispositivos Em geral, os dispositivos esto constitudos em duas partes: parte mecnica, que a que efetivamente executa as aes requeridas; parte eletrnica, que controla o dispositivos, sendo por isso denominada controlador ou adaptador.
O S.O. trata com o controlador e no com o dispositivo em si. Os microcomputadores ---e diversos minicomputadores--- se utilizam, para comunicao com os dispositivos de E/S (isto , com os seus controladores), do esquema de duto nico. Sistemas maiores em geral se utilizam de dutos mltiplos e computadores especializados de E/S, chamados canais de E/S, que retiram grande parte da carga da UCP com relao ao processamento de E/S. A interface entre o controlador e o dispositivo geralmente de baixo nvel, cuidando de todos os detalhes do funcionamento do dispositivo, bem como da organizao da informao de forma a ser reconhecida pela UCP. Cada controlador possui alguns registradores, que so utilizados para comunicao com a UCP. Esta comunicao pode ser realizada de duas formas: registradores no espao de memria: neste caso, os registradores dos controladores ocupam posies no espao de endereamento da memria; registradores em espao de E/S: neste caso, os registradores dos controladores so includos num espao separado de endereamento, conhecido como espao de E/S.
As operaes de E/S so ento realizadas atravs da escrita, pela UCP, de comandos nos registradores dos controladores e da leitura de resultados nesses mesmos registradores.
7.1.3. Acesso Direto Memria Vrios controladores (especialmente de dispositivos de bloco) suportam uma tcnica de transferncia conhecida como acesso direto memria (DMA). Para exemplificar a operao do DMA, vejamos como opera o acesso a disco com e sem a utilizao dessa tcnica. Quando no existe DMA, o acesso a disco feito da seguinte forma: 1. o controlador de disco l, um a um, os bits de dados vindos do disco;
2. quando um bloco completo foi transferido, feito um teste para verificar se houve erros; 3. se no houve erros, o controlador causa uma interrupo na UCP 4. a UCP entra num "loop" de leitura, que l um byte por vez do controlador.
Como pode ser visto, esse ciclo gasta um tempo considervel da UCP devido necessidade desta permanecer num "loop" para a transferncia de todos os dados provindos do disco. Para eliminar o tempo gasto pela UCP nesse "loop", utilizada a tcnica de DMA, que faz com que o ciclo de transferncia do disco fique como abaixo:
1. a UCP d ao controlador dados sobre o setor a ler, endereo de memria onde ela quer que a informao seja colocada, e nmero de bytes que devem ser transferidos; 2. aps o controlador ler o bloco e verificar os erros, como indicado anteriormente, ele automaticamente copia todo o bloco na posio de memria especificada; 3. quando o S.O. quiser utilizar os dados, estes j se encontram na posio correta da memria, no sendo necessrio utilizar tempo de UCP para a transferncia.
7.2.
Princpios de Software de E/S
Deve-se procurar organizar o software de E/S em camadas, de forma que as camadas mais baixas ocultem as particularidades do hardware s camadas mais altas e estas ltimas se ocupem de apresentar ao usurio uma interface clara e agradvel. 7.2.1. Objetivos do Software de E/S Os conceitos importantes que devem ser considerados num projeto de software para E/S so os seguintes: 1. independncia de dispositivo: isto , deve ser possvel escrever programas que possam ser utilizados, sem alterao, para dispositivos diversos, como discos flexveis, discos rgidos, e mesmo terminais de vdeo e linhas seriais. O S.O. que deve cuidar dos problemas causados pelas diferenas entre os dispositivos, e no o usurio; 2. denominao uniforme: os nomes dados aos dispositivos devem ser independentes do tipo do mesmo;
3. tratamento de erros: deve-se tratar os erros nos nveis to mais prximos do hardware quanto possvel, de forma que os nveis superiores somente se ocupem com erros que no podem ser tratados pelos nveis inferiores; 4. transmisso sncrona (bloqueante) X assncrona (interrupes): na transmisso assncrona, a UCP pede uma transferncia e em seguida vai realizar outras operaes. Quando a transferncia est pronta, um interrupo gerada para informar a UCP de que a operao foi completada. Ao se escrever programas, mais simples que as transmisses sejam consideradas bloqueantes, de forma que, ao pedir uma transferncia, o programa para at que ela esteja pronta (por exemplo, num read). O S.O. deve cuidar de fazer com que uma transferncia assncrona aparea ao usurio como sncrona; 5. dispositivos compartilhados X dedicados: alguns dispositivos podem ser compartilhados entre diversos usurios sem problema (p.ex.: discos, podendo vrios usurios possurem arquivos abertos no mesmo). O mesmo j no acontece com outros (p.ex.: impressora), que devem ser utilizados por um nico usurio por vez. O S.O. deve ser capaz de cuidar tanto de dispositivos compartilhados como de dispositivos dedicados, de uma forma que evite problemas em quaisquer dos casos. Os objetivos indicados acima podem ser atingidos de um modo abrangente e eficiente estruturando-se o software de E/S em quatro camadas: 1. tratadores de interrupes 2. condutores de dispositivos (device drivers) 3. software de E/S independente de dispositivo 4. software em nvel de usurio
Vejamos as atribuies de cada uma dessas camadas.
7.2.2. Tratadores de Interrupo Devido a extrema dependncia do hardware, as interrupes devem ser tratadas nos nveis mais baixos do S.O., de forma conhecimento da existncia de interrupes. O mtodo tradicional de trabalho fazer com que os condutores de dispositivos (device drivers) sejam bloqueados quando executam um comando de E/S. Quando a interrupo correspondente ocorre, a rotina de interrupo desbloqueia esse processo (atravs de um V que a menor parte possvel do sistema tome
em semforo, ou um signal em varivel de condio ou da transmisso de uma mensagem, dependendo do tipo de sincronizao utilizado pelo S.O.).
7.2.3. Condutores de Dispositivos (device drivers) O condutor de dispositivo contm todo o cdigo dependente do dispositivo. Cada condutor de dispositivo maneja um tipo de dispositivo ou, no mximo, uma classe de dispositivos correlacionados. O condutor de dispositivo envia os comandos aos controladores (atravs dos registradores corretos) e verifica que esses comandos sejam corretamente executados, sendo a nica parte do S.O. que tem conhecimento do controlador utilizado. Em termos gerais, a tarefa do condutor de dispositivo aceitar comandos do software independente de dispositivo e fazer com que sejam executados, devendo transformar o pedido dos termos abstratos em que realizado para termos concretos. Por exemplo, no condutor de disco, verificar onde fisicamente o bloco requisitado se encontra, verificar o estado do motor (ligado ou desligado), posio da cabea de leitura, etc. Ele ento determina os comandos que devem ser enviados ao controlador do dispositivo e os envia. A partir desse ponto temos duas situaes possveis: 1. o controlador leva algum tempo at terminar a execuo do comando, caso em que o condutor de dispositivo se bloqueia; 2. o controlador executa o comando automaticamente, no sendo necessrio o bloqueamento. No primeiro caso, o condutor bloqueado ser acordado por um interrupo proveniente do controlador. Os dados obtidos com a operao so ento passados ao software independente de dispositivo.
7.2.4. Software Independente de Dispositivo A separao exata entre os condutores e o software independente de dispositivo varivel com o S.O. As funes geralmente realizadas pela parte do software independente de dispositivo so as seguintes:
interfaceamento uniforme para os condutores de dispositivo: a funo bsica, compreendendo a execuo de funes comuns a todos os dispositivos de E/S; denominao dos dispositivos: consiste no mapeamento dos nomes simblicos nos condutores corretos; proteo dos dispositivos: em microprocessadores, em geral o usurio pode fazer o que desejar com os dispositivos de E/S, no existindo nenhuma proteo implcita. J em computadores grandes, o acesso a dispositivos de E/S proibido aos usurios. No UNIX, o acesso a dispositivos de E/S protegido pelos bits rwx, como qualquer arquivo. fornecimento de um tamanho de bloco independente do dispositivo: para dispositivos de bloco, devemos fazer com que todos os presentes no sistema apresentem ao usurio o mesmo nmero de blocos. Para dispositivos de caracter, alguns apresentam um caracter por vez (p.ex.: terminais), enquanto que outros apresentam-nos em conjuntos de vrios caracteres (p.ex.: leitora de cartes). Essas diferenas devem ser ocultadas; bufferizao: deve existir bufferizao para se poder lidar com situaes como as seguintes: a) dispositivos de bloco requerem o acesso a blocos completos, enquanto que o usurio pode requerer acesso a unidades menores; b) em dispositivos de caracteres, o usurio pode tentar escrever mais rpido do que o dispositivo pode ler, ou o dispositivo pode enviar antes que o usurio esteja pronto para ler. alocao de memria em dispositivos de bloco: a descoberta de quais o blocos livres e quais os ocupados em um dispositivo de bloco no dependente do dispositivo e pode, portanto, ser realizada neste nvel do S.O. alocao e liberao de dispositivos dedicados: pode ser tratada tambm nesta parte do S.O. Normalmente isto feito com chamadas de sistema do tipo open (para pedir acesso) e close (para liberar o acesso); informe de erros: a maioria dos erros altamente dependente do hardware e deve, portanto, ser executada nos condutores de dispositivos. No entanto, aps um condutor informar um erro, o tratamento desse erro independente do dispositivo, sendo em geral o erro informado ao processo que pediu o acesso. No caso de um erro que possa comprometer completamente o funcionamento do sistema, entretanto, uma mensagem deve ser enviada e o sistema terminado.
7.2.5. Software de E/S no Espao de Usurio Uma parte do software de E/S consiste em rotinas de biblioteca ligadas com programas de usurio e mesmo programas inteiros rodando fora do modo kernel. Chamadas de sistema, incluindo-se as de E/S, so feitas geralmente por rotinas de biblioteca. Muitas dessas rotinas no fazem nada mais do que colocar os parmetros no local apropriado para a chamada de sistema e realizar a chamada. Outras entretanto fazem um trabalho real, em geral de formatao de dados (p.ex.: printf). Temos tambm os sistemas de spooling, que consistem em uma forma de tratar dispositivos de E/S dedicados em sistemas de multiprogramao. O exemplo tpico de dispositivo que utiliza spool a impressora. A impressora poderia ser tratada atravs da utilizao de open e close. No entanto, considere o que ocorreria caso um usurio realizasse open e no utilizasse a impressora por horas. Dessa forma, criado um processo especial, chamado daemon, que o nico a ter permisso de acesso impressora, e um diretrio de spool. Quando um processo quer imprimir um arquivo ele o coloca no diretrio de spool e, ento, o daemon o imprime quando possvel.
8. DEADLOCK
Um problema com a tcnica de spool que o arquivo inteiro precisa ser escrito no disco, antes que a sada possa se iniciar (pense no que ocorreria caso um daemon iniciasse a impresso antes que o arquivo seja completamente gerado e o processo que gera o arquivo para por algumas horas antes de terminar a gerao). Em alguns casos, a sada gerada (principalmente quando se trata de sada para fita magntica) pode incluir at 50 Mbytes, o que inviabiliza que todos os dados sejam escritos no disco antes de serem enviados ? unidade. A nica soluo nesses casos no utilizar spool nesse dispositivo, mas fazer com que os usurios tenham acesso exclusivo ao mesmo quando precisarem. No entanto, esta soluo pode gerar deadlock. Suponha a seguinte situao: processo A pede unida e de fita magntica e recebe processo B pede plotter e recebe processo A pede plotter sem liberar a fita magntica processo B pede fita magntica sem liberar plotter Neste caso percebemos que tanto o processo A como o processo B so postos para dormir, situao na qual permanecero indefinidamente.
8.1.
Recursos
Chamaremos de recurso qualquer objeto ao qual deva ser dado acesso exclusivo para cada processo. Recursos podem ser dispositivos de hardware ou trechos de informao. Para alguns recursos, diversas instncias idnticas podem estar disponveis (p.ex.: diversas unidades de fita), caso em que cada uma pode ser utilizada para satisfazer um pedido distinto. Para a utilizao de um recurso temos, ento, a seguinte sequncia a ser realizada pelo processo: 1. Requisitar o recurso 2. Utilizar o recurso 3. Liberar o recurso Se um recurso no estiver disponvel quando for requisitado, o processo que o requisitou forado a aguardar, sendo dois mtodos utilizados: 1. o processo bloqueado e acordado quando o recurso estiver disponvel;
2. enviado um cdigo de erro ao processo indicando que a requisio falhou sendo, ento, que o prprio processo deve decidir a ao a tomar (p.ex.: aguardar algum tempo e pedir novamente)
8.2.
Modelamento de Deadlock
Deadlock: ocorre quando cada processo de um conjunto de processos est esperando por um evento que apenas outro processo do mesmo conjunto pode causar. Em muitos casos, o evento esperado a liberao de um recurso qualquer, isto , cada membro do conjunto est esperando pela liberao de um recurso que apenas outro membro do conjunto pode liberar. O nmero de processos ou recursos envolvidos nessa situao no importante.
Quatro condies so necessrias para que ocorra deadlock: 1. Excluso mtua: cada recurso ou est associado a exatamente um processo ou est disponvel; 2. Posse e espera (hold and wait): um processo que j possui algum recurso pode requisitar outros e aguardar por sua liberao; 3. No existe preempo: recursos dados a um processo no podem ser tomados de volta. Eles precisam ser explicitamente liberados pelo processo; 4. Espera circular: Deve haver uma cadeia circular de dois ou mais processos, cada um dos quais aguardando um recurso em posse do prximo membro da cadeia.
Podemos modelar a distribuio dos recursos e das requisies dos mesmos atravs de um grafo com dois tipos de ns: circular: representa um processo retangular: representa um recurso O significado dos arcos entre os ns o seguinte: arco de um recurso para um processo: indica que esse recurso est entregue ao processo apontado; arco de um processo para um recurso: indica que o processo est bloqueado, aguardando o recurso.
Veja a Figura 15, onde A e B so processo e R e S so recursos:
R (a)
B (b)
B (c)
Figura 15 Analisemos agora um caso mais complexo. Suponhamos a existncia de trs processos A, B e C, e de trs recursos R, S, e T. Suponhamos ainda para cada processo a seguinte ordem de requisio e liberao de recursos: A: pede R pede S libera R libera S B: pede S pede T libera S libera T C: pede T pede R libera T libera R Se o S.O. executa cada um dos processo por vez, esperando que um processo termine antes de executar o outro, ento claramente no teremos deadlock, mas tambm no teremos nenhum paralelismo. Suponhamos ento que queremos realizar o escalonamento dos processos em um mtodo de round-robin. As requisies de recursos podem ento ocorrer da seguinte forma: A pede R B pede S C pede T A pede S B pede T C pede R Neste ponto, o grafo correspondente ser como indicado na Figura 16:
(a) A B C A
(b) B C A
(c) B C
(d)
(e)
(f)
Figura 16 Vemos ento que ocorreu uma cadeia circular de processos e recursos, indicando um deadlock. Entretanto, como o S.O. tem liberdade de executar os processos e, portanto, liberar os recursos na ordem que julgar mais adequada, se ele soubesse da possibilidade de ocorrncia de deadlock na situao acima, poderia deferir, por exemplo, a execuo do processo B, fazendo com que o mesmo aguardasse para iniciar quando j no houvesse perigo de deadlock. Assim a ordem de execuo poderia ser a seguinte: A pede R C pede T A pede S C pede R A libera R A libera S E vemos ento que no haver deadlock. Note que a partir deste ponto, B pode iniciar a receber os recursos. A Figura 17 indica a evoluo dos pedidos indicados acima.
A B C A B C A B C
(l)
(m)
(n)
(o)
(p)
(q)
Figura 17 Em geral so utilizadas quatro estratgias para se tratar com o deadlock: 1. ignorar o problema 2. deteco e recuperao 3. preveno, negando uma das quatro condies necessrias 4. Evitao dinmica, por uma alocao cuidadosa dos recursos
Vejamos as tcnicas e implicaes envolvidas.
8.3.
O "Algoritmo da Avestruz"
A estratgia mais simples para lidar com o deadlock a mesma da avestruz frente a um perigo: colocar a cabea em um buraco na areia e fingir que o problema no existe. Apesar de teoricamente inaceitvel, esta soluo a mais utilizada devido aos seguintes fatores: 1. baixa probabilidade de ocorrncia de deadlock, muito menor do que da ocorrncia de quebra do sistema por erros no prprio S.O., em compiladores ou no hardware. 2. o alto preo pago pelos usurios para se prevenir os deadlocks, como veremos mais detalhadamente a seguir. O UNIX utiliza este mtodo.
8.4.
Deteco e Recuperao
Nesta tcnica, o S.O. apenas monitora as requisies e liberaes de recursos, atravs da manuteno de um grafo de recursos, que constantemente atualizado e onde se verifica a ocorrncia de ciclos. Se houver algum ciclo, um dos processos do ciclo deve ser morto
(terminado fora). Se ainda permanecer o ciclo, outro processo deve ser morto e assim sucessivamente, at que o ciclo seja quebrado.
uma tcnica utilizada em computadores grandes, geralmente em batch, onde um processo pode ser morto e mais tarde reinicializado. Deve-se, entretanto, ter cuidado de que qualquer arquivo modificado pelo processo morto deve ser restaurado ao seu estado original antes de iniciar o processo novamente.
8.5.
Preveno de Deadlock
Consiste em impor restries aos processos de forma que o deadlock seja impossvel. Se garantirmos que uma das quatro condies necessrias (veja item 4.3.2.) nunca satisfeita, ento o deadlock impossvel. Analisemos quais as possibilidades de eliminar as condies: 1) Excluso mtua: como vimos, para alguns recursos necessria a excluso mtua, pois no pode haver acesso por dois processos simultaneamente e nem sempre a tcnica de spool pode ser empregada. Portanto, esta condio no pode ser eliminada; 2) Posse e espera: Uma forma de negar esta condio fazer com que cada processo requisite todos os recursos que ir necessitar antes de iniciar a execuo. Se todos os recursos estiverem disponveis ento ele executado. Caso contrrio, o processo deve aguardar. Um problema com este mtodo que muitos processos no sabem com antecedncia quais os recursos de que iro necessitar at comear a execuo. Outro problema que os recursos no sero utilizados otimamente (Voc sabe indicar por que?). Um modo diferente de quebrar esta condio fazer com que, para pedir um novo recurso, o processo deva liberar temporariamente todos aqueles que possui e somente se conseguir o novo recurso que pode pegar os anteriores de volta; 3) No preempo: fcil notar que tomar um recurso de um processo para entreg-lo a outro gerador de confuso. Portanto, esta condio no pode ser quebrada; 4) Espera circular: Vejamos alguns mtodos de evitar a espera circular (isto , evitar que se formem ciclos fechados no grafo de recursos): cada processo s pode ter um recurso por vez e, se desejar outro, deve liberar o que possui. Isto impossibilitaria coisas simples como cpia de uma fita para outra;
dada uma numerao global a todos os recursos e os processos s podem requisitar recursos em ordem numrica estritamente crescente. O problema aqui que se torna difcil encontrar uma numerao que satisfaa a maioria das possveis condies de acesso.
8.6.
Evitao Dinmica de Deadlock
Neste mtodo procura-se evitar o deadlock sem impor restries aos processos. Isto possvel desde que alguma informao sobre a utilizao de recursos pelo processo seja disponvel antecipadamente ao S.O. o que analisaremos agora.
8.6.1. Algoritmo do Banqueiro para um nico Recurso O algoritmo do banqueiro, introduzido por Dijkstra em 1965 evita deadlocks. Consiste em simular as decises de um banqueiro no emprstimo de certa quantia de dinheiro, sujeito a certas condies especiais, como veremos. Na Figura 18 vemos a representao de quatro clientes (A, B, C e D) que tm linhas de crdito com um banqueiro. Cada um especificou o nmero mximo de unidades de crdito que ir precisar, mas eles no precisam de todas elas imediatamente, de forma que o banqueiro reservou 10 unidades para atender todos os pedidos (que totalizam 32 unidades). Cliente A B C D disponvel: 10 Figura 18 Considera-se que: cada cliente pode, em cada momento, realizar um pedido desde que este no faa com que ultrapasse seu limite de crdito; o banqueiro pode escolher livremente o momento de atendimento dos pedidos realizados, apenas se comprometendo em atend-lo em um tempo finito; Usado 0 0 0 0 Mximo 6 5 4 7
aps o recebimento de todo o crdito que especificou inicialmente (isto , o seu valor de Mximo), o cliente se compromete a devolver, dentro de um tempo finito, tudo o que lhe foi emprestado. O banqueiro deve, portanto, analisar cuidadosamente cada pedido de recurso, para garantir que no entre numa situao da qual no possa sair. Vejamos um exemplo. Chamamos de estado a situao dos emprstimos, bem como dos recursos ainda disponveis em um dado momento. Na Figura 19 temos um exemplo: Cliente A B C D disponvel: 2 Figura 19 Usado 1 1 2 4 Mximo 6 5 4 7
Um estado dito seguro se existe uma sequncia de outros estados que leva a que todos os clientes recebam seus emprstimos at seus limites de crdito. O estado da Figura 18 seguro, pois o banqueiro pode emprestar as duas unidades C, pegar a devoluo do mesmo (4 unidades) e emprestar B, pegar as 5 unidades de volta e emprestar A, pegar as 6 unidades de volta e emprestar 3 delas D, pegando ento as 7 unidades de volta, garantindo que todos os clientes foram atendidos. Suponhamos entretanto que, na mesma situao da Figura 19, o cliente B fizesse um pedido de mais uma unidade e o banqueiro atendesse. Teramos ento a situao da Figura 20: Cliente A B C D disponvel: 1 Figura 20 Usado 1 2 2 4 Mximo 6 5 4 7
Como fcil verificar, este no um estado seguro, pois no h forma de o banqueiro garantir o atendimento de todos os pedidos, o que pode vir a gerar um deadlock. Importante notar que ainda no estamos em deadlock, pois os valores de mximo no precisam necessariamente ser atingidos. Por exemplo, o cliente D pode decidir que no precisa mais de novos recursos, e devolver os 4 que j pediu ao banqueiro. Desta forma estaramos novamente numa situao segura. No entanto, o banqueiro no pode contar com isso, pois no tem formas de saber quando um cliente ir necessitar ou no do mximo que especificou. Portanto, o algoritmo do banqueiro consiste em, para cada pedido que chega, verificar se conceder o mesmo leva a um estado seguro ou no. Se levar a um estado seguro o cliente satisfeito. Para verificar se o estado seguro ou no ele deve verificar se o disponvel suficiente para atender o cliente mais prximo de seu mximo. Se for, finge que esse cliente j devolveu tudo que possua, marca o mesmo como terminado e verifica se pode atender o cliente mais prximo do mximo entre os que restam. Se ele puder levar a bom termo esse processo, atendendo (em sua anlise) todos os clientes, ento o estado seguro.
8.6.2. O Algoritmo do Banqueiro para Vrios Recursos Neste caso, montamos duas matrizes, uma de recursos entregues e outra de recursos ainda necessrios, sendo que cada linha das matrizes corresponde a um processo e cada coluna corresponde a um tipo de recurso, como na Figura 21:
FALTANDO
A B C D E
1 0 3 0 2
1 1 1 0 1
0 1 0 1 1
0 2 0 0 0
ENTREGUES A B C 3 0 1 0 1 1 1 0 1 1 0 0
D E
1 0
1 0
0 0
1 0
Figura 21
Temos tambm trs vetores E, P e D que indicam: E => recursos existentes; E = (6 3 4 2) P => recursos possudos por algum processo; P = (5 3 2 2) D => recursos disponveis; D = (1 0 2 0)
Como no caso de um nico recurso, os processos precisam avisar com antecedncia das suas necessidades de recursos. Para descobrir se um estado seguro ou no procedemos, ento, da seguinte forma:
1. procuramos uma linha L cujos recursos ainda necessrios sejam todos menores que os correspondentes valores no vetor D. Se no existir uma linha assim, o sistema provavelmente entrar em deadlock e o estado no seguro. 2. Assumir que o processo da linha L requereu todos os recursos e terminou, liberando todos os recursos que estava ocupando 3. repetir os passos 1 e 2 at que todos os processos sejam marcados como terminados. Se isto for conseguido o estado seguro.
O problema com este algoritmo que os processos raramente sabem com antecedncia a quantidade mxima de recursos que necessitaro. Alm disso, o nmero de processo no sistema varia dinamicamente, o que invalida as anlises realizadas. No conhecido nenhum algoritmo para cuidar do caso geral, sendo que apenas se utilizam alguns em aplicaes de propsito especfico.
9. SISTEMA DE ARQUIVOS
9.1.
Viso do Usurio
Para o usurio de um sistema operacional, o sistema de arquivos representa a parte com que ele tem mais contato. Os pontos principais de um sistema de arquivos, sob esse ponto de vista, so os seguintes: O que um arquivo? Como se do nomes aos arquivos? Como se protegem arquivos contra acessos no autorizados? Que operaes podem ser realizadas sobre um arquivo?
Para cada sistema operacional, as respostas essas perguntas so dadas de forma diferente.
9.2.
Pontos Bsicos com Relao a Arquivos
Os S.O. permitem que usurios definam objetos chamados arquivos e apresentam operaes especiais (realizadas por chamadas de sistema), que permitem agir sobre o mesmo (criar, destruir, escrever, ler, etc.). Trs formas comuns de organizao de arquivos so apresentadas na Figura 22:
Figura 22
No primeiro caso, os arquivos so considerados como constitudos de uma sequncia de bytes ( o caso do UNIX). No segundo caso, os arquivos so considerados como consistindo de uma sequncia de blocos, cada um de um dado tamanho ( o caso do CP/M). No terceiro caso, o arquivo organizado em blocos, sendo que cada bloco consiste de certo nmero de regies de dados e tambm de ponteiros para outros blocos semelhantes, formando-se uma rvore de blocos para cada arquivo ( o padro ISAM: indexed sequential access method). Um outro ponto importante com relao a arquivos sua utilizao para obter a independncia de dispositivo, procurando os S.O. fornecer acessos aos arquivos independente dos dispositivos utilizados para o armazenamento do arquivo. Em geral, os S.O. caracterizam os arquivos em alguns tipos. Por exemplo, o UNIX caracteriza os arquivos em: regulares, diretrio, especiais (subdividido em de bloco e de caracter) e pipes. Nestes casos, algumas pequenas diferenas existem na utilizao dos diversos tipos de arquivos. Uma forma de diferenciar arquivos fornecida por alguns S.O. a extenso (p.ex.: os .EXE, .COM, .BAT, etc do MS-DOS). Com relao a isso, as atitudes dos S.O. para com as extenses variam desde alguns que no utilizam a extenso para nada, servindo a mesma apenas como mnemnico para o usurio, at sistemas em que o tipo de extenso extremamente importante para o sistema (p.ex. ele poderia se recusar a rodar o compilador PASCAL em qualquer arquivo que no tivesse extenso .PAS).
9.3.
Diretrios
9.3.1. Conceito Os diretrios so organizados como um conjunto de diversas entradas, uma para cada arquivo. Algumas possibilidades de organizao dos diversos arquivos em diretrios so as seguintes: um nico diretrio para todos os arquivos (p.ex.: CP/M); um diretrio para cada usurio; uma hierarquia de diretrios (p.ex.: MS-DOS e UNIX). No ltimo caso, surge a necessidade de se especificar a localizao de um arquivo com relao hierarquia de diretrios. O modo geralmente utilizado a especificao de um caminho (path), que pode ser indicado de duas formas:
1. caminho absoluto: indica todo o caminho at o arquivo a partir da raiz da hierarquia; 2. caminho relativo: (associado a diretrio de trabalho: working directory): indica como se faz para chegar at o arquivo partindo do diretrio de trabalho atual. 9.3.2. Estrutura do Diretrio Devemos estabelecer agora de que forma as informaes sobre os arquivos devem ser organizadas no diretrio. Para isto veremos trs exemplos de diretrios: o do CP/M (diretrio nico), do MS-DOS e do UNIX (rvores de diretrios).
i) CP/M O CP/M possui um nico diretrio, que consiste de diversas entradas como a mostrada na Figura 23:
Figura 23 O cdigo de usurio associa cada arquivo a um usurio identificado por um nmero. O campo "extent" utilizado para arquivos que ocupam mais de uma entrada no diretrio (quando so maiores que o tamanho possvel em uma nica entrada). Nesse campo temos o nmero correspondente aquela entrada do arquivo (0 para a primeira entrada, 1 para a segunda, e assim sucessivamente). 16 espaos so reservados para os nmeros dos blocos em cada entrada no diretrio. O contador de blocos (block count) indica quantos desses 16 espaos reservados esto efetivamente sendo utilizados (quando o arquivo ocupa mais de 16 blocos, uma nova entrada deve ser alocada para o mesmo no diretrio, com o valor de "extent" ajustado correspondentemente).
ii) MS-DOS
O MS-DOS apresenta uma estrutura como a apresentada na Figura 24:
Figura 24
O campo de atributos utilizado para indicar qual o tipo de arquivo (arquivo normal, diretrio, escondido, sistema, etc). Um dos campos indica o nmero do primeiro bloco alocado para o arquivo. Para encontrar o bloco seguinte, busca-se a entrada na FAT correspondente a esse primeiro bloco e encontra-se l o nmero do bloco seguinte, repetindo-se esse procedimento at encontrar o fim do arquivo. Note que a entrada no diretrio de uma arquivo apresenta tambm o tamanho do arquivo. Quando o atributo de um arquivo indica que ele do tipo diretrio, ento, o mesmo consistir de entradas como as apresentadas aqui, podendo inclusive apresentar entradas do tipo diretrio, possibilitando a formao de uma rvore de subdiretrios.
iii) UNIX
O diretrio do UNIX extremamente simples, devido ao fato de que todas as informaes sobre um arquivo esto reunidas no i-node desse arquivo, ao invs de no diretrio. Cada entrada no diretrio como na Figura 25:
Figura 25
Os diretrios so arquivos como qualquer outros, com tantos i-nodes quantos necessrios. A raiz tem seu i-node armazenado em uma posio fixa do disco. Alm dos arquivos normais, cada diretrio possui tambm as entradas "." e "..", geradas no momento
da criao do diretrio, sendo que a primeira apresenta o i-node do prprio diretrio e a segunda o i-node do diretrio pai desse diretrio. Para a raiz, "." e ".." so iguais.
9.4.
Projeto de Sistema de Arquivos
No projeto de sistemas de arquivos, devemos estabelecer o seguinte: Como ser feito o gerenciamento do espao em disco? Como sero armazenados os arquivos? Como fazer tudo funcionar com eficincia e segurana? Veremos agora, com alguns detalhes, formas de responder s duas primeiras perguntas e rapidamente a formas de responder segunda.
9.4.1. Gerenciamento do Espao em Disco A forma de gerenciamento do espao em disco a principal considerao que deve ser feita pelo projetista de sistemas de arquivos. Uma possibilidade seria, para cada arquivo, alocar espao no disco correspondente ao nmero de bytes necessrios, sequencialmente (i.e., todos os bytes do arquivo sero consecutivos no disco). Surge um problema nesta soluo quando h necessidade de um arquivo crescer e no existe espao consecutivo aps o mesmo. Neste caso, seria necessrio deslocar o arquivo para outra parte do disco, o que lento e muitas vezes impossvel (em discos cheios). Outro problema com este tipo de soluo a fragmentao do espao em disco (da mesma forma que ocorria fragmentao da memria). A soluo para este problema, ento, a alocao para cada arquivo de blocos de tamanho fixo e no necessariamente contguos no disco. Escolhida esta opo, surge a seguinte questo: Qual o tamanho do bloco? A escolha de blocos de tamanho grande implica em que mesmo arquivos pequenos iro ocupar muito espao no disco. Por outro lado, a escolha de blocos pequenos implica em um maior nmero de leituras em disco (para um dado tamanho de arquivo), o que implica em aumento das influncias do tempo de busca de trilhas e espera de setor. Os tamanhos comumente encontrados de blocos so de 512 bytes, 1k bytes, 2k bytes e 4k bytes.
Resta-nos uma considerao importante: de que forma cuidar de quais blocos do disco esto livres e quais esto ocupados? Os mtodos, como no caso de gerenciamento de memria, so basicamente dois: lista encadeada; bit map (mapa de bits). A segunda opo geralmente a melhor, principalmente quando todo o bit map pode ser mantido simultaneamente na memria. A primeira opo s prefervel quando o bit map no pode ser mantido todo na memria e o disco est bastante ocupado (isto pois, neste caso, com o mtodo de bit map, se queremos encontrar espao para um novo arquivo, devemos ficar carregando as diversas partes do bit map do disco para a memria, pois como o disco est cheio, difcil de encontrar blocos vazios, o que torna o processo lento, enquanto que na lista encadeada, basta carregar a lista de blocos vazios ao invs de ter que carregar as diversas partes do bit map uma por vez at achar o espao necessrio).
9.4.2. Armazenamento de Arquivos Vejamos agora de que forma podemos fazer para saber quais os blocos que esto alocados a um dado arquivo. A primeira forma que poderia ser pensada seria a alocao de blocos de forma contgua no disco. Ou seja, para armazenar um determinado arquivo seria percorrido o disco buscando por um espao de blocos contguos que permitissem seu armazenamento. Entretanto, muitas vezes no existem estes buracos contguos no disco. Neste caso, seria necessrio ficar sempre reorganizando os espaos alocados no disco para criar os espaos necessrios, o que inviabiliza esta soluo. Um mtodo possvel fazer uma lista encadeada utilizando os prprios blocos, de forma que, num dados bloco (p.ex., de 1 kbytes), alguns de seus bytes so utilizados para indicar qual o prximo bloco do arquivo. A grande vantagem desta estratgia evitar a fragmentao que ocorre no uso de alocao contgua. Porm, esta soluo apresenta o problema de que para se buscar o n-simo bloco de um arquivo, devemos ler todos os n-1 blocos anteriores, alm do prprio bloco, o que implica numa grande sobrecarga de leituras em disco quando pretendemos realizar acesso aleatrio s informaes do arquivo.
Um modo de utilizar a lista encadeada sem os inconvenientes apresentados acima o utilizado no MS-DOS, atravs de uma estrutura chamada FAT (file allocation table), que poderia ser chamado de lista encadeada usando tabela. Esta soluo consiste em formar a lista dos blocos de um arquivo em uma estrutura especial (tabela), que pode ser carregada completamente na memria, eliminando simultaneamente os dois inconvenientes apontados. No MS-DOS, a FAT funciona da seguinte forma: a entrada no diretrio correspondente a um arquivo indica o primeiro setor ocupado por um arquivo; a entrada na FAT correspondente a um setor indica o prximo setor alocado ao mesmo arquivo.
Para melhor visualizar observe a Figura 26:
Figura 26 Os problemas com esta soluo so os seguintes: Como a FAT ocupa locais fixos no disco, o tamanho desta limitado pelo nmero de setores alocados para a mesma; Como cada entrada na FAT corresponde a um nmero fixo de bits, o nmero de setores no disco limitado, sendo que se quisermos utilizar discos maiores, devemos alterar completamente a FAT.
Outra forma existente a tabela de ndices encontrada no sistema UNIX, que apresenta grande facilidade de expanso de tamanho dos arquivos. Podemos resumir da seguinte forma:
as listas (tabelas) de blocos de cada arquivo so mantidas em locais diferentes (i.e., no existe um local fixo onde so guardadas as informaes sobre os blocos de todos os arquivos); a cada arquivo, associa-se uma tabela, chamada i-node (n-ndice); o i-node de um arquivo possui informaes de proteo, contagem, blocos, entre outras; no i-node existem 10 nmeros de blocos diretos; se o arquivo ocupa at 10 blocos, os nmeros desses blocos so colocados nesse espao reservado no i-node; se o arquivo ocupa mais do que 10 blocos, um novo bloco alocado ao arquivo, que ser utilizado para armazenar tantos nmeros de blocos desse arquivo quantos couberem no bloco. O endereo desse bloco ser armazenado em um nmero de bloco de endereamento indireto; se ainda forem necessrios mais blocos do que couberam nas estruturas anteriores, reservado um novo bloco que ir apontar para blocos que contm endereos dos blocos dos arquivos. O nmero desse novo bloco armazenado num bloco de endereamento duplamente indireto; se ainda no for suficiente isso, alocado um bloco de endereamento triplamente indireto. Acompanhe o processo descrito acima pela Figura 27:
Figura 27 As vantagens desse mtodo so as seguintes: os blocos indiretos so utilizados apenas quando necessrio;
mesmo para os maiores arquivos, no mximo so necessrios trs acessos a disco para se conseguir o endereo de qualquer de seus blocos.
9.4.3. Arquivos Compartilhados Quando diferentes usurios se referem a arquivos compartilhados (p.ex., num projeto em grupo), conveniente que esses arquivos apaream em diretrios diferentes (os dos diversos usurios) mas mantendo uma nica cpia do mesmo em disco (de forma a garantir que quando um usurio faz alteraes a esse arquivo, outro usurio tenha automaticamente acesso a essas alteraes, sem necessitar se preocupar em recopiar o arquivo). Em sistemas cujo diretrio possui o endereo dos blocos do arquivo (como o caso do CP/M), poderamos realizar a ligao pela cpia dos nmeros de blocos dos diretrios de um usurio para o de outro. O problema aqui que quando um dos usurios faz uma alterao no arquivo que implique em reorganizao dos blocos ocupados por ele, essa alterao no aparecer ao outro usurio. Existem duas possveis solues para esse problema: no listar os nmeros dos blocos no diretrio, mas apenas um ponteiro para uma estrutura que lista esses blocos. Este o caso dos i-node do UNIX. Veja que aqui, para estabelecer a ligao, basta fazer no novo diretrio onde deve aparecer um arquivo, uma entrada com o nome do mesmo e o nmero do seu i-node; podemos criar, no novo diretrio, uma entrada de um tipo especial, digamos tipo "link", que contm, ao invs das informaes usuais sobre o arquivo, apenas um "path para este. Este mtodo denominado "ligao simblica". A primeira das solues apresenta um problema, que pode ser ilustrado da seguinte forma: suponha que o usurio C seja o dono de um arquivo e, ento, o usurio B faz um link para o mesmo. Se permitimos que C apague o arquivo, o diretrio de B ter uma entrada que no far mais sentido. Isto pode ser solucionado (como foi no UNIX), mantendo no i-node do arquivo um campo que indica quantos links foram realizados para aquele arquivo. Neste caso, quando C remover o arquivo, o S.O. pode perceber que outros usurios ainda querem utiliz-lo e no apaga o i-node do arquivo, removendo apenas a entrada correspondente no diretrio de C. Isto evita que B fique com um arquivo sem sentido, mas introduz um novo problema: se existirem quotas na utilizao de discos (i.e., limites mximos de utilizao de disco por cada usurio), teremos o fato de que C continuar pagando pela existncia de um arquivo que j no lhe interessa.
A segunda soluo (ligao simblica) no tem esses problemas, pois, quando o dono remove o arquivo o mesmo eliminado e a partir desse ponto todos os outros usurios que tentarem acessar o arquivo por ligao simblica tero a mensagem de "arquivo inexistente". No entanto ela apresenta sobrecarga no tempo de acesso, devido necessidade de percorrer "paths" extras at se chegar no arquivo e de ocupar um i-node a mais. Uma outra vantagem desta soluo a de que permite realizar links com outras mquinas, interligadas por uma rede (ao contrrio do mtodo do i-node, que s permite ligaes dentro do prprio disco). As duas solues apresentadas tm em comum uma desvantagem: o fato de que o arquivo aparece com diferentes paths no sistema, fazendo com que, para sistemas automticos de cpia (em geral em backups), ele seja copiado diversas vezes.

Apostila PUC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostila PUC

Uploaded by

Copyright:

Available Formats

SISTEMAS OPERACIONAIS

Ricardo Lus de Freitas

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Figura1: Organizao do hardware e software em camadas

Na parte de hardware, a linguagem de mquina

o que o usurio "enxerga" do

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Na parte de Software, o objetivo final so os programas

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais -

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 10

cat cap1 cap2 cap3 | grep arquivo

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 11

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 12

3. COMUNICAO ENTRE PROCESSOS

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 13

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 14

Excluso Mtua com Espera Ocupada

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 15

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 16

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 17

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 18

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 19

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 20

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 21

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 22

RECEIVE : recebe uma mensagem de uma origem especificada: RECEIVE(origem,&mensagem);

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 23

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 24

consome_item(item); SEND(produtor,m); end end;

(* envia resposta vazia *)

Ricardo Lus de Freitas

Notas de Aula - Sistemas Operacionais - 25

Ricardo Lus de Freitas