Вы находитесь на странице: 1из 128

APRESENTAO

Sistemas Operacionais (SO) uma disciplina essencial e obrigatria em praticamente todos os cursos universitrios de Computao. De fato, um Sistema Operacional uma parte essencial de qualquer Sistema de Computao. Trata-se, ento, de uma rea de pesquisa bastante interessante, que evolui a todo o momento, posto que os Sistemas de Computao esto em constante evoluo.

Um Sistema Operacional um conjunto de rotinas executado pelo processador (CPU), de forma anloga aos programas de usurios. A principal funo dessas rotinas controlar o

funcionamento do Sistema Computacional, gerenciando de forma otimizada os recursos disponveis, como processadores, memria e dispositivos de entrada e sada, alm de, na medida do possvel, fazer a interface entre o hardware e o usurio final, procurando esconder sua complexidade e mostrando um ambiente agradvel e de fcil utilizao.

Se no existisse o Sistema Operacional, o usurio, para poder manipular o computador, deveria conhecer os diversos detalhes de hardware, o que tornaria o seu trabalho mais cansativo, lento e imprprio, com uma grande perspectiva de erros.

O objetivo desta apostila proporcionar ao leitor um bom entendimento sobre o fantstico mundo dos Sistemas Operacionais. Ao longo dos captulos iremos abordar os conceitos bsicos que envolvem toda a rea, alm de detalhar cada estrutura formadora de um Sistema Operacional. Cada captulo acompanhado de embasamento terico sobre cada parte de um Sistema Operacional,

alm de exerccios para praticar o assunto. A bibliografia e a webliografia ao fim das notas so mais do que suficiente para que o leitor se aprofunde na teoria apresentada em cada unidade.

Esta apostila completamente baseada em notas de aula do autor da disciplina de Sistemas Operacionais, ministrada no curso de Bacharelado em Cincia da Computao da Universidade Federal do Piau, alm de livros clssicos de Sistemas Operacionais, como Sistemas (referncia Operacionais bsica e Modernos, principal), de Andrew Tanenbaum de Sistemas

Fundamentos

Operacionais, de Abraham Silberschatz e Operating Systems (J. Bacon). Outro livro que foi levado em considerao como base dessa apostila o de Sistemas Operacionais do professor Rmulo Oliveira da Universidade Federal de Santa Catarina, livro este bastante didtico e utilizado como referncia na maioria dos cursos de Sistemas Operacionais no pas.

Contedo desta Apostila


Na Unidade I apresentaremos o conceito de Sistemas Operacionais, o que eles fazem e como so projetados.

Abordaremos o conceito de um Sistema Operacional partindo da viso de uma mquina estendida, que procura esconder a complexidade de hardware para o usurio e da viso de um gerenciador de recursos, que procura gerenciar todos os recursos disponveis pelo Sistema Computacional. Nesta unidade,

mostraremos tambm um histrico dos Sistemas Operacionais, mostrando sua evoluo durante os anos, sempre acompanhado da evoluo dos Sistemas Computacionais. Alm disso, trataremos de classificar os Sistemas Operacionais e apresentar como um Sistema Operacional estruturado. Ao fim de cada unidade teremos exerccios a fim de que o aluno possa praticar os conhecimentos adquiridos.

Na Unidade II comearemos a descrever a primeira parte de um projeto de Sistemas Operacionais que trata do gerenciamento de processos. Nesta unidade mostraremos como projeto o modelo de processos, abordando os conceitos bsicos, comunicao interprocessos (CIP), mtodos de excluso mtua, problemas clssicos de CIP e o gerenciamento do processador, abordando os algoritmos clssicos de escalonamento de processos, que a partir de uma lista de processos escolhe qual utilizar a CPU para executar suas atividades.

Na Unidade III est destinada ao gerenciamento dos dispositivos de entrada e sada. Atravs dos dispositivos de entrada e sada feito a ligao entre o sistema e o mundo exterior. Na unidade mostraremos os princpios de hardware e de software dos dispositivos de entrada e sada. Comumente a quantidade desses dispositivos muito menor que a quantidade de processos que necessitam deles. Dessa forma, o Sistema Operacional deve gerenci-los a fim de se evitar problemas. Veremos tambm nesta unidade as situaes de impasses (deadlocks) entre os processos.

Na Unidade IV, por sua vez, trataremos do gerenciamento de um recurso altamente importante para qualquer sistema: a memria. O ideal seria que o usurio tivesse uma quantidade infinita de memria, rpida, no-voltil e com um preo acessvel. Porm, essas caractersticas so contraditrias e, assim, o sistema deve gerenciar a memria disponvel no Sistema Computacional que, comumente, limitada. Veremos tambm nesta unidade o mtodo de gerenciamento conhecido como memria virtual.

Por fim, na Unidade V mostraremos a parte do Sistema Operacional mais visvel pelo usurio: o Sistema de Arquivo. As informaes necessitam ser gravadas de forma permanente e isso acontece atravs da abstrao arquivos. Nesta unidade

mostraremos as caractersticas gerais de arquivos e diretrios e como eles podem ser implementados.

Boa Leitura!! Erico Meneses Leo

SUMRIO GERAL

UNIDADE I VISO GERAL

1. INTRODUO 1.1. Definio de Sistemas Operacionais 1.2.Objetivos de um Sistema Operacional 1.3. Histria dos Sistemas Operacionais 1.3.1. Incio 1.3.2. Primeira Gerao (1945-1955) 1.3.3. Segunda Gerao (1956-1965) 1.3.4. Terceira Gerao (1966-1980) 1.3.5. Quarta Gerao (1981-Atual) 1.4. Classificao dos Sistemas Operacionais 1.4.1. Sistemas Monoprogramveis ou Monotarefas 1.4.2. Sistemas Multiprogramveis ou Multitarefas 1.4.3. Sistemas Multiprocessadores 1.5. Estrutura do Sistema Operacional 1.5.1. Chamadas de Sistemas WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE II GERENCIAMENTO DE PROCESSOS

1. INTRODUO AO MODELO DE PROCESSOS 1.1. Conceito de Processos 1.2. Criao de Processos 1.3. Estados de um Processo 1.4. Tabelas de Processos 1.5. Threads

2. COMUNICAO INTERPROCESSO 2.1. Condies de Corrida 2.2. Sees Crticas 2.3. Excluso Mtua com Espera Ativa 2.3.1. Desativando Interrupes 2.3.2. Variveis de Bloqueio 2.3.3. Alternncia Estrita 2.3.4. A Soluo de Peterson 2.4. Problema dos Produtores e Consumidores 2.5. Semforos 3. PROBLEMAS CLSSICOS DE CIP 3.1. Problema do Jantar dos Filsofos 3.2. Problema do Barbeiro Adormecido 4. ESCALONAMENTO DE PROCESSOS 4.1. Algoritmo de Escalonamento FIFO (First in First out) 4.2. Algoritmo de Escalonamento Menor Tarefa Primeiro 4.3. Algoritmo de Escalonamento Round Robin 4.4. Algoritmo de Escalonamento por Prioridades 4.5. Algoritmo de Escalonamento Mltiplas Filas WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE III GERENCIAMENTO DE ENTRADA E SADA

1. INTRODUO 2. PRINCPIOS DE HARDWARE DE E/S 2.1. Dispositivos de Entrada e Sada 2.2. Controladoras de Dispositivos 2.2.1. Controladoras que suportam Acesso Direto Memria 3. PRINCPIOS DE SOFTWARE DE E/S 3.1. Manipuladores de Interrupes 3.2. Drivers de Dispositivos

3.3. Software de E/S Independente de Dispositivo 3.4. Software de E/S de Nvel de Usurio 4. DEADLOCKS 4.1. Condies para um Impasse 4.2. Modelagem de Impasses atravs de Grafos 4.3. Mtodos de Lidar com Deadlocks 4.3.1. Algoritmo do Avestruz 4.3.2. Deteco e Recuperao 4.3.3. Preveno de Impasses 4.3.4. Impedimento de Impasses WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE IV GERENCIAMENTO DE MEMRIA

1. INTRODUO 2. GERENCIAMENTO BSICO DE MEMRIA


3. GERENCIA DE MEMRIA PARA MULTIPROGRAMAO

3.1. Alocao com Parties Variveis 3.1.1. Gerenciamento de Memria com Mapa de Bits 3.1.2. Gerenciamento de Memria com Listas Encadeadas 4. MEMRIA VIRTUAL 4.1. Paginao 4.2. TLB Translation Lookside Buffers 5. ALGORITMOS DE SUBSTITUIO DE PGINAS 5.1. Algoritmo de Substituio de Pgina timo 5.2. Algoritmo de Substituio de Pgina No Recentemente Utilizada 5.3. Algoritmo de Substituio de Pgina FIFO
5.4. Algoritmo de Substituio de Pgina de Segunda Chance 5.5. Algoritmo de Substituio de Pgina do Relgio 5.6. Algoritmo de Substituio de Pgina menos

Recentemente Utilizada WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE V SISTEMAS DE ARQUIVOS

1. INTRODUO AOS SISTEMAS DE ARQUIVOS 1.1. Arquivos 1.1.1. Nomeao de Arquivos 1.1.2. Estruturas de Arquivos 1.1.3. Tipos de Arquivos 1.1.4. Acesso aos Arquivos 1.1.5. Atributos de Arquivos 1.1.6. Operaes com Arquivos 1.2. Implementao de Arquivos 1.2.1. Alocao Contgua 1.2.2. Alocao por Lista Encadeada 1.2.3. Alocao por Lista Encadeada Usando ndice 1.3. Diretrios 1.3.1. Organizao de Sistemas de Diretrios 1.3.2. Nomes de Caminhos 1.3.3. Operaes com Diretrios 1.4. Implementao de Diretrios WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

Para iniciarmos nosso curso de Sistemas Operacionais (SO) devemos compreender as definies bsicas que envolvem a rea. A partir desse momento, a fim de evitar muitas repeties, iremos tratar Sistemas Operacionais pelo termo SO. Nossa primeira unidade dedicada viso geral sobre SO. Nela trataremos de definir o que um Sistema Operacional, tomando por base duas vises: a viso de SO como uma mquina estendida e o SO como gerenciador dos recursos (Andrew Tanenbaum). A definio de Sistemas Operacionais do ponto de vista de uma mquina estendida procura esconder a complexidade do hardware computacional. J a definio de Sistemas Operacionais do ponto de vista gerenciador de recursos trata de organizar os recursos computacionais disponveis, evitando assim possveis problemas, como inconsistncias e disputas entre os programas. Continuando na unidade, traremos um breve histrico dos Sistemas Operacionais, que vem junto da evoluo dos Sistemas Computacionais, alm da classificao dos SOs. Ao fim da unidade, o leitor dever ter a capacidade de entender como e por qu surgiram os Sistemas Operacionais, alm de conhecer os tipos de Sistemas Operacionais. Ao fim da Unidade,

o leitor ter disponveis exerccios e bibliografia clssica, o qual ele poder futuramente se aprofundar no estudo de Sistemas

Operacionais, e quem sabe, ingressar nesta grande rea de estudo e pesquisas.

SUMRIO

SUMRIO

UNIDADE I VISO GERAL

1. INTRODUO 1.1. Definio de Sistemas Operacionais 1.2.Objetivos de um Sistema Operacional 1.3. Histria dos Sistemas Operacionais 1.3.1. Incio 1.3.2. Primeira Gerao (1945-1955) 1.3.3. Segunda Gerao (1956-1965) 1.3.4. Terceira Gerao (1966-1980) 1.3.5. Quarta Gerao (1981-Atual) 1.4. Classificao dos Sistemas Operacionais 1.4.1. Sistemas Monoprogramveis ou Monotarefas 1.4.2. Sistemas Multiprogramveis ou Multitarefas 1.4.3. Sistemas Multiprocessadores 1.5. Estrutura do Sistema Operacional 1.5.1. Chamadas de Sistemas WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE I VISO GERAL

1. INTRODUO

Antes de comearmos a detalhar os principais componentes formadores de um Sistema Operacional (SO), devemos

primeiramente entender alguns conceitos e funcionalidades bsicas. Devemos compreender que, se no existisse o Sistema Operacional, at seria possvel utilizar os Sistemas Computacionais disponveis atualmente, porm, a complexidade e dificuldade na sua

manipulao os tornariam bem pouco atraentes. Se no existisse o Sistema Operacional, o usurio, para poder manipular o computador ou qualquer Sistema Computacional, deveria conhecer os diversos detalhes de hardware (tarefa rdua), o que tornaria o seu trabalho mais cansativo, lento e imprprio, sem considerar a grande quantidade de problemas e erros nos resultados obtidos. Como explicitado por Rmulo (2008) em seu livro de Sistemas Operacionais, em torno de um computador, existem usurios com problemas a serem resolvidos, problemas esses que podem se estender de simples entretenimento, at edio de textos, figuras e atividades mais complexas, como uma anlise estatstica ou um gerenciamento de uma empresa por completo. O software, de um modo geral, utilizado para solucionar os problemas do usurio, enquanto que o hardware do computador o dispositivo fsico capaz de executar esses softwares. Esses softwares, responsveis por realizar as atividades dos usurios, comumente so chamados de programas aplicativos. Com base no que j foi dito, surge a seguinte pergunta: mas onde entra o Sistema Operacional? Assim, o Sistema Operacional

pode ser caracterizado como uma camada de software localizado entre o hardware e os programas aplicativos que executam as atividades dos usurios, como esboado na Figura 1.

Figura 1: Sistema Computacional composto pelo hardware, programas de sistemas e programa aplicativos.

Como pode ser visto na Figura 1, levando em considerao que temos uma camada intermediria, o SO entre os programas aplicativos e o hardware em si, o usurio no necessita conhecer toda a complexidade de implementao do hardware do Sistema Computacional para, assim, poder utiliz-lo. O Sistema Operacional, de fato, opera como uma interface entre o usurio e o dispositivo fsico em si, no qual o usurio, quando necessita acessa-lo, faz essa solicitao diretamente ao Sistema Operacional.

1.1. Definio de Sistemas Operacionais Segundo Tanenbaum, podemos definir um Sistema

Operacional levando em considerao dois pontos de vistas:

O Sistema Operacional como uma Mquina estendida; O Sistema Operacional como gerenciador de recursos.

De fato, unindo e entendendo os dois pontos de vista, o aluno ter total condio de definir um bom conceito de Sistemas Operacionais. Examinaremos com detalhes esses dois pontos de vista.

O Sistema Operacional como uma Mquina estendida O usurio (que pode ser um programador ou um usurio final), comumente, no est interessado em saber os detalhes funcionais dos dispositivos. Como exemplo, o usurio no quer saber o que preciso, a nvel de hardware, para que seja lido uma determinada informao de um disquete ou de um disco rgido (tarefa bem complexa, que exige o conhecimento de registradores, motores, cilindros e outros dispositivos fsicos). O usurio deseja ter uma interface mais palpvel e mais simples de lidar. No caso dos discos, por exemplo, uma abstrao tpica seria que o disco contenha um conjunto de nomes de arquivos. A partir desses nomes, possvel realizar as operaes bsicas (abrir, ler, escrever e fechar), sem se importar qual a velocidade e estado atual do motor, por exemplo. Assim, o Sistema Operacional aparece como o programa que esconde do usurio a complexidade do hardware e apresenta uma viso fcil e simples para as operaes sobre os dispositivos. Essa viso equivalente a uma mquina estendida ou mquina virtual, mais fcil de lidar.

O Sistema Operacional como gerenciador de recursos Por outro lado, o Sistema Computacional composto de uma srie de recursos, no qual podemos enumerar: processadores,

memrias, discos, mouses, teclados, impressoras, placas de rede e uma infinidade de dispositivos em geral. Dessa forma, o Sistema Operacional aparece como sendo o responsvel por organizar e alocar de forma ordenada todos esses recursos disponveis. Essa tarefa, em uma primeira vista, pode parecer simples. Porm, quando se tem vrios programas disputando os recursos, que so limitados, necessrio utilizar tcnicas de alocao dos dispositivos, a fim de se evitar inconsistncias e, at mesmo, situaes que resultem numa parada do sistema de uma forma geral.

1.2. Objetivos de um Sistema Operacional Para o desenvolvimento de um Sistema Operacional devemos ento ter como metas atingir os seguintes objetivos: Tornar a utilizao do computador eficiente e conveniente, a fim de ter um ganho de produtividade e, dessa forma, utilizar o Sistema Computacional para agilizar as

atividades do dia-a-dia; Garantir a integridade e segurana dos dados

armazenados e processados pelos programas e dos recursos fsicos disponveis.

1.3. Histria dos Sistemas Operacionais Os Sistemas Operacionais, ao longo dos anos, vm se desenvolvendo e ganhando novas caractersticas, sendo necessrio partimos ao seu histrico para que possamos compreender como se deu essa evoluo. Partindo do pressuposto que a histria dos Sistemas Operacionais sempre esteve intimamente vinculado histria das arquiteturas de computadores, iremos fazer um breve resumo dos principais eventos relacionados evoluo dos Sistemas Operacionais.

1.3.1. Incio O primeiro computador digital, de fato, foi projetado por volta da dcada de 1820 pelo matemtico Charles Babbage e intitulada como motor analtico. Esta mquina, por se tratar de um equipamento puramente mecnico e a tecnologia da poca no permitir a construo de engrenagens de alta preciso o qual Babbage necessitava, nunca funcionou adequadamente. Assim, o Mquina Analtica de Babbage. motor analtico de Babbage no possua Sistema Operacional. Um dado interessante est no fato de que Babbage sabia que era preciso de um software para o seu motor analtico e, assim, contratou uma jovem chamada Ada Lovelace como primeiro programador do mundo. O nome da linguagem de programao Ada foi criado em homenagem a esta jovem.

1.3.2. Primeira Gerao (1945-1955) Impulsionado pela Segunda Guerra Mundial, surgiram os grandes computadores digitais, formados por milhares de vlvulas e que ocupavam salas inteiras. Estes computadores, desenvolvidos por Howard Aiken e John von Neumann, eram extremamente lentos. Para trabalhar nesta mquina era necessrio o conhecimento do funcionamento do seu hardware, onde a programao era feita atravs de linguagem de mquina, frequentemente ligando painis Computador de Primeira Gerao. de conectores com fios para o controle das funes bsicas. Nessa poca, ainda no existia o conceito de Sistema Operacional. Por esse fato, esta gerao ficou conhecida como a gerao das vlvulas e painis de conectores.

1.3.3. Segunda Gerao (1956-1965) Com o desenvolvimento dos transistores, os computadores sofreram um enorme avano, tornando-se mais confiveis a fim de serem comercializados. Transistor Nesta poca, com o surgimento das primeiras linguagens de programao, os programas deixaram de ser feitos diretamente no

hardware, facilitando assim o processo de desenvolvimento de programas. As mquinas de transistores eram armazenadas em salas e operadas por equipes especiais. Para executar uma atividade, o programador escrevia o seu programa, inicialmente, em um papel (em FORTRAN ou ASSEMBLY), e transformava este em cartes perfurados. O seu conjunto de cartes era levado para a sala onde se encontrava a mquina e era entregue diretamente aos operadores. Os cartes eram carregados em fitas magnticas, que eram Computador de Segunda Gerao lidas pelo computador, que executava um programa de cada vez, gravando o resultado do processamento em uma fita de sada. Esse tipo de processamento, onde um lote de programas era submetido ao computador, deu-se o nome de processamento em lotes ou processamento em batch. A Figura 2 visualiza este procedimento.

Figura 2: Sistema de processamento em lote.

1.3.4. Terceira Gerao (1966-1980) A terceira gerao conhecida com gerao dos circuitos integrados (CIs) e da multiprogramao, diminuindo

consideravelmente o preo do computador, possibilitando assim sua aquisio por empresas. Esta poca se caracteriza pelo grande aumento do poder de processamento e, tambm, a diminuio dos equipamentos. Nesta poca, a IBM lanou o System/360, que era uma srie de computadores pequena, poderosa e, sobre tudo, compatvel. O 360 foi projetado para manipular clculos tanto cientficos como

comerciais, ou seja, em uma nica famlia de mquinas era possvel satisfazer as necessidades de praticamente todos os clientes. Porm, para atender todas as aplicaes e perifricos disponveis por essa famlia de mquinas, a IBM teve que desenvolver um Sistema Operacional (OS/360) extremamente grande e complexo, posto que as aplicaes disponveis,

comumente, eram contraditrias. Este Sistema Operacional consistia de milhes de linhas de linguagem assembler escrita por milhares de programadores e muitos bugs, que exigiam verses e mais verses a fim de corrigi-los. Apesar de todos os problemas, o OS/360 e os Sistemas Operacionais semelhantes atenderam a maioria dos seus clientes razoavelmente bem. Alm disso, eles lanaram vrias tcnicas utilizadas at hoje, como exemplo a multiprogramao. A multiprogramao consistia em dividir a memria em vrias parties a fim de permitir que vrias tarefas sejam carregadas em cada partio. Enquanto uma tarefa esperava alguma operao de Entrada ou Sada, outra tarefa poderia usar o processador (CPU). Outro recurso disponvel nos Sistemas Operacionais da terceira gerao era a capacidade de ler jobs (tarefas) de cartes para o disco. Assim, sempre que um job acabava sua execuo, o Sistema Operacional podia carregar um novo job do disco para a partio e executa-lo. Esta tcnica conhecida como spooling. Entretanto, os Sistemas Operacionais ainda eram

basicamente sistemas em lote e que no exigiam comunicao com o usurio. Assim, muitos programadores sentiam falta das mquinas de primeira gerao, que eram disponibilizadas por completa para eles e, assim, podiam depurar seus programas. Assim, a multiprogramao evoluiu preocupada em oferecer aos usurios tempos de respostas razoveis e uma interface cada vez mais amigvel. Para tal, cada programa na memria utilizaria o processador em pequenos intervalos de tempo. Esse sistema de diviso de tempo ficou conhecido como compartilhamento de Tempo (time-sharing).

A terceira gerao tambm marcada pelo surgimento do Sistema Operacional UNIX, escrito em linguagem de programao de alto nvel, que se tornou popular no mundo acadmico, entre rgos do governo e entre muitas empresas.

1.3.5. Quarta Gerao (1981-Atual) De fato, a dcada de 1980 caracterizada pelo surgimento dos computadores pessoais. Os computadores pessoais se tornaram possveis devido ao advento de novas tecnologias, impulsionados pelo avano da indstria de hardware, com a introduo de novos circuitos integrados. Os computadores pessoais permitiram que as pessoas pudessem ter seu prprio computador. Os equipamentos desta gerao se tornaram cada vez menores, mais velozes e, principalmente, mais baratos. Esses novos equipamentos, com alta disponibilidade de poder de computao, especialmente a computao altamente interativa, normalmente com Computador Pessoal Moderno excelentes grficos, levaram ao crescimento de uma importante indstria, a indstria de softwares para computadores pessoais. Dois Sistemas Operacionais inicialmente dominaram o cenrio dos computadores pessoais: o MS-DOS (Microsoft) e o UNIX. O MS-DOS foi amplamente utilizado no IBM PC e em computadores com a tecnologia Intel. Esse Sistema Operacional evolui para o sistema conhecido como Windows. Outra evoluo que surgiu nesta gerao foi o crescimento de redes de computadores pessoais executando Sistemas

Operacionais de rede e Sistemas Operacionais distribudos. Em um Sistema Operacional de rede, os usurios podem conectar-se a mquinas remotas e copiar arquivos de uma mquina para a outra. Em um Sistema Operacional distribudo os programas dos usurios podem ser executados em vrios computadores, porm, estes vem o sistema como nico. Alguns autores ainda apontam uma quinta gerao, que engloba o desenvolvimento cada vez maior da indstria do hardware e do software, alm do desenvolvimento das telecomunicaes,

permitindo o funcionamento de sistemas e aplicaes distribudas, que figuram nossa realidade.

1.4. Classificao dos Sistemas Operacionais Os Sistemas Operacionais evoluram juntamente com a evoluo do hardware e das aplicaes por ele suportada. Muitos termos inicialmente introduzidos para definir conceitos e tcnicas foram substitudos por outros. Abordaremos neste tpico, os diversos tipos de Sistemas Operacionais classificados quanto ao seu tipo de processamento (Figura 3), apontando suas principais caractersticas.

Figura 3: Tipos de Sistemas Operacionais.

1.4.1. Sistemas Monoprogramveis ou Monotarefas Os Sistemas monoprogramveis ou monotarefas so

caracterizados por alocar o Sistema Computacional disponvel exclusivamente para um nico programa, ou seja, um programa tem todos os dispositivos, incluindo perifricos, memria e processador disponvel durante todo o tempo em que ele est ativo, mesmo se no estiver usando. Nesse caso, se o programa estivesse executando uma operao de entrada e sada, o processador continuaria disponvel e

alocado a ele, mesmo ele no estando utilizando (o processador ficaria ocioso). Os primeiros sistemas operacionais eram tipicamente

voltados para a execuo de um nico programa. Os sistemas monoprogramveis esto tipicamente relacionados ao surgimento dos primeiros computadores na dcada de 1960 e se caracterizam por permitir que todos os recursos do sistema fiquem

exclusivamente dedicados a uma nica tarefa, como ilustrado na Figura 4.

Figura 4: Sistemas Monoprogramveis.

Os

Sistemas

monoprogramveis

so

de

simples

implementao, comparado com sistemas multiprogramveis e multiprocessadores, posto que no necessite muita preocupao com compartilhamento e concorrncia.

1.4.2. Sistemas Multiprogramveis ou Multitarefas Os Sistemas multiprogramveis j so bem mais complexos que os Sistemas monoprogramveis. Neste tipo de sistema, os diversos recursos do Sistema Computacional so divididos pelas vrias tarefas ou programas que necessitam utiliza-los, como visualizado na Figura 5.

Figura 5: Sistemas Multiprogramveis.

A grande vantagem dos Sistemas multiprogramveis est no fato dos recursos poderem ser divididos entre os vrios programas, ganhando tempo e, naturalmente, aumentando a produtividade do usurio. Assim, por exemplo, em um caso onde um programa necessite fazer uma operao de E/S e no esteja utilizando a CPU, esta poder ser disponibilizada para outro programa. Os Sistemas multiprogramveis podem ser classificados pelo nmero de usurios que interagem com o sistema e pela forma com que suas aplicaes so gerenciadas. Os Sistemas multiprogramveis, quanto ao nmero de usurios que interagem com o Sistema, podem ser classificados a seguir: Sistemas monousurios: sistemas multiprogramveis onde apenas um usurio interage com o sistema, podendo realizar vrias atividades ao mesmo tempo, como edio de texto, impresso e acesso a Internet, por exemplo. Sistemas multiusurios: sistemas multiprogramveis onde vrios usurios podem estar conectados e interagindo com o sistema. Os Sistemas multiprogramveis, quanto forma que suas aplicaes so gerenciadas, podem ser classificados como: sistemas batch, de tempo compartilhado ou de tempo real.

Sistemas Batch Os sistemas batch foram os primeiros Sistemas Operacionais multiprogramveis. Este tipo de sistema no necessitava da interao do usurio, o qual o programa era carregado no computador a partir de algum tipo de memria secundria e eram executados sequencialmente.

Sistemas de Tempo Compartilhado Os Sistemas de tempo compartilhado (time-sharing) permitem que diversos programas sejam executados a partir da diviso do tempo do processador. Cada programa utiliza o processador por uma fatia de tempo e pode ser interrompido caso o seu tempo termine. O sistema cria um ambiente de trabalho prprio, dando a impresso para o usurio que o sistema est todo disponvel a ele.

Sistemas de Tempo Real Os sistemas de tempo real tm caractersticas semelhantes aos sistemas de tempo compartilhado, porm, suas aplicaes possuem requisitos temporais, ou seja, possuem um tempo mximo para serem executados. Em sistemas de tempo real, uma tarefa utiliza o processador o tempo que for necessrio ou at que uma outra tarefa mais prioritria aparea.

1.4.3. Sistemas Multiprocessadores Os sistemas multiprocessadores so caracterizados por possuir dois ou mais processadores interligados e trabalhando em conjunto. Esta caracterstica traz com principal vantagem a possibilidade de vrios programas serem executados ao mesmo tempo, de fato. Os conceitos aplicados ao projeto de sistemas com mltiplos processadores incorporam os mesmos princpios bsicos e

benefcios apresentados na multiprogramao, alm de outras caractersticas e vantagens especficas como escalabilidade,

disponibilidade e balanceamento de carga. Escalabilidade computacional do a capacidade apenas de ampliar o poder novos

sistema

adicionando

processadores. Disponibilidade a capacidade de manter o sistema em operao mesmo em casos de falhas. Balanceamento de carga a possibilidade de distribuir o processamento entre os diversos processadores da configurao a partir da carga de trabalho de cada processador, melhorando, assim, o desempenho do sistema como um todo.

1.5. Estrutura do Sistema Operacional O Sistema Operacional proporciona o ambiente pelo qual os programas so executados e composto por um conjunto de rotinas, conhecido como o ncleo, que so disponibilizadas para as aplicaes dos usurios e para o prprio sistema. A interface entre o Sistema Operacional e os programas dos usurios definida por um conjunto de instrues que o SO proporciona. Esse conjunto de instrues tradicionalmente chamado de chamadas de sistema (system calls). O Sistema Operacional no funciona como aplicaes comuns, formados de incio, meio e fim. Os procedimentos do sistema so executados concorrentemente sem seguir uma ordem, com base em eventos assncronos. Projetar um Sistema Operacional uma tarefa rdua e altamente importante, onde, em fase de projeto, devem-se definir todos os objetivos do sistema como um todo. As principais funes de um Sistema Operacional, presentes praticamente em todos os SO, podem ser visualizadas a seguir: Gerenciamento de Processos e Processador Gerenciamento da Memria

Gerenciamento dos dispositivos de entrada e sada Gerenciamento de Arquivos

Cada parte citada pode ser uma poro bem delineada do sistema, com entradas, sadas e funes bem definidas, o que facilita o seu estudo e detalhamento. Ao longo desta apostila, nas unidades seguintes, estudaremos cada poro citada.

1.5.1. Chamadas de Sistemas As chamadas de sistemas (system calls) constituem a interface entre um programa do usurio e o Sistema Operacional. Elas podem ser entendidas como uma porta de entrada para acesso ao ncleo do sistema, que contm suas funes. Sempre que o usurio necessitar de algum servio, o solicita atravs de uma chamada de sistema definida e especfica. Cada servio disponvel por um determinado Sistema Operacional possui uma chamada de sistema associada e cada SO possui seu prprio conjunto de chamadas (nomes, parmetros e formas de ativao especfica). As chamadas de sistemas, de fato, servem tambm para proteger o ncleo do Sistema Operacional, tentando impedir que um determinado programa realize alguma operao que altere a integridade do sistema.

WEBLIOGRAFIA

Universidade Aberta do Piau UAPI www.ufpi.br/uapi

Universidade Aberta do Brasil UAB www.uab.gov.br

Secretaria de Educao Distncia do MEC - SEED www.seed.mec.gov.br

Associao Brasileira de Educao Distncia ABED www.abed.org.br

Curso de Sistemas Operacionais DCA/UFRN Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira http://www.dca.ufrn.br/~affonso/DCA0108/curso.html

Home Page do Prof. Dr. Rmulo Silva de Oliveira http://www.das.ufsc.br/~romulo/

Home Page do Autor Andrew S. Tanenbaum http://www.cs.vu.nl/~ast/

Simulador de Ensino para Sistemas Operacionais http://www.training.com.br/sosim/

REFERNCIAS BIBLIOGRFICAS

BACON, J. e HARRIS, T. Operating Systems: Concurrent and Distributed Software Design. Addison Wesley, 2003.

DEITELL, H. M. & DEITEL, P. J. & CHOFFNES, D. R. Sistemas Operacionais. So Paulo, Ed. Prentice Hall, 2005.

MACHADO, F. e MAIA, L. Arquitetura de Sistemas Operacionais. 4 Edio, LTC, 2007

OLIVEIRA, R. S. e CARISSIMI, A. S. e TOSCANI, S. S. Sistemas Operacionais. 3 ed, volume 11, Ed. Bookman, 2008.

SHAW, A. C. Sistemas e software de tempo real. Porto Alegre, Ed. Bookman, 2003.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Fundamentos de Sistemas Operacionais. 6 Edio, Ed. LTC.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Sistemas Operacionais com Java. 7 Edio, Rio de Janeiro, Ed. Elsevier, 2008.

TANENBAUM, A. S. & WOODHULL, A. S. Sistemas Operacionais: Projeto e Implementao. 3 Edio, Porto Alegre, Ed. Bookman, 2008.

TANENBAUM, A. S. Sistemas Operacionais Modernos. 2 Edio, So Paulo, Ed. Prentice Hall, 2003.

O conceito bsico da maioria dos Sistemas Operacionais o conceito de processos. Os processos computacionais constituem a base de administrao de um sistema e, juntamente com eles, surgem vrios problemas, que devem ser tratados dentro do Sistema Operacional. Uma das principais funes de um Sistema Operacional gerenciar os processos ativos e todos os problemas correlacionados. Dentre esses problemas correlacionados podemos destacar a concorrncia entre os processos dos diversos dispositivos do sistema computacional, inclusive o processador (CPU). Nesta unidade trataremos da parte do Sistema Operacional conhecido como gerenciador de processos. Abordaremos o conceito de processos e a estrutura do modelo de processos. Mais adiante, trataremos da comunicao entre os processos, abordando os possveis problemas e alternativas para lidar com essa concorrncia. Por fim, trataremos do gerenciamento do processador, que a partir de uma lista de processos prontos para serem executados, qual deles escolhido para utilizar o processador.

SUMRIO

SUMRIO
UNIDADE II GERENCIAMENTO DE PROCESSOS

1. INTRODUO AO MODELO DE PROCESSOS 1.1. Conceito de Processos 1.2. Criao de Processos 1.3. Estados de um Processo 1.4. Tabelas de Processos 1.5. Threads 2. COMUNICAO INTERPROCESSO 2.1. Condies de Corrida 2.2. Sees Crticas 2.3. Excluso Mtua com Espera Ativa 2.3.1. Desativando Interrupes 2.3.2. Variveis de Bloqueio 2.3.3. Alternncia Estrita 2.3.4. A Soluo de Peterson 2.4. Problema dos Produtores e Consumidores 2.5. Semforos 3. PROBLEMAS CLSSICOS DE CIP 3.1. Problema do Jantar dos Filsofos 3.2. Problema do Barbeiro Adormecido 4. ESCALONAMENTO DE PROCESSOS 4.1. Algoritmo de Escalonamento FIFO (First in First out) 4.2. Algoritmo de Escalonamento Menor Tarefa Primeiro 4.3. Algoritmo de Escalonamento Round Robin 4.4. Algoritmo de Escalonamento por Prioridades 4.5. Algoritmo de Escalonamento Mltiplas Filas WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE II GERENCIAMENTO DE PROCESSOS

1. INTRODUO AO MODELO DE PROCESSOS

Os

primeiros

Sistemas

Operacionais

eram

caracterizados por apenas um programa poder ser executado de cada vez. Os computadores mais modernos so constitudos de Sistemas Operacionais com capacidade de executar vrias tarefas ao mesmo tempo. De fato, o processador pode ser alternado de um programa para o outro, executando cada um por um determinado tempo (comumente em milissegundos). Em outras palavras, para um determinado intervalo de tempo, vrios programas utilizam uma fatia desse tempo para realizar suas atividades, passando, assim, para o usurio a falsa impresso de que todos eles esto sendo executados ao mesmo tempo. Essa falsa impresso passada ao usurio de que vrios programas esto sendo executados ao mesmo tempo comumente conhecido por pseudoparalelismo. Para que isso seja possvel necessrio um monitoramento das mltiplas atividades entre os vrios programas, que trata-se de uma tarefa difcil e bastante complexa. Segundo Tanenbaum, os projetistas de Sistemas

Operacionais desenvolveram um modelo que torna o paralelismo mais fcil de tratar, conhecido como modelo de processos, assunto deste captulo.

1.1. Conceito de Processos No modelo de processo, todo programa executvel organizado em um nmero de processos seqenciais. Podemos definir processos como sendo a abstrao do programa, ou seja, um

programa em execuo, incluindo os valores do contador de programa atual, registradores e variveis. Em cada instante, o processador estar executando apenas um nico processo, porm, como ele alterna rapidamente entre vrios processos, para um determinado perodo de tempo, vrios processos tero progredido em sua execuo, passando assim a falsa impresso para o usurio que todos eles executaram em paralelo. A diferena entre processo e programa um ponto fundamental para o entendimento do modelo de processos. Alguns autores costumam utilizar uma analogia para facilitar esse entendimento: a receita de um bolo. Para se fazer um bolo, alm da receita contendo os passos a seguir, o confeiteiro ter sua disposio os ingredientes necessrios para o preparo. Dessa forma, a receita do bolo o programa, o confeiteiro o processador (CPU) e os ingredientes so os dados de entrada. O processo consiste de toda a atividade de preparao do bolo, ou seja, a leitura da receita, a busca e mistura dos ingredientes, levar a massa ao forno e todas as atividades necessrias para que o bolo seja fabricado. Agora, continuando com a analogia, imaginemos que o filho do confeiteiro aparea chorando por ter se cortado, por exemplo. O confeiteiro, no papel de um pai dedicado, deve guardar em que ponto da receita do bolo ele estava, procurar um kit de primeiros socorros e comear a seguir as orientaes nele. Neste ponto, podemos verificar o processador (confeiteiro) alternando de um processo (preparo do bolo) para outro processo (cuidar do corte do filho), no qual cada um tem o seu programa prprio (receita do bolo e o livro de primeiros socorros). Quando o filho estiver tratado e medicado, o confeiteiro poder continuar seu bolo do ponto onde parou.

1.2. Criao de Processos Outro ponto que podemos considerar sobre a criao de novos processos. O Sistema Operacional deve fornecer alguma maneira dos processos serem criados. Um processo pode dar origem a diversos novos processos durante sua execuo, atravs de uma chamada de sistema para criar um processo. Os processos criados so denominados processos filhos. O processo criador denominado de processo pai. Cada um dos novos processos tambm pode criar outros processos, formando uma rvore de processos, como visualizado na Figura 6.

Figura 6: rvore de Processos.

1.3. Estados de um Processo Um processo comumente muda de estado durante sua execuo. Dessa forma, um estado ativo pode estar no SO em trs estados diferentes: Executando: um processo est no estado executando quando ele, de fato, est sendo processado pela CPU. Em sistemas monoprocessados (nico processador), somente um processo por vez pode estar de posse da CPU em um

dado instante. Os processos se alternam na utilizao do processador. Pronto: um processo est no estado de pronto quando ele possui todas as condies necessrias para a sua execuo, porm, no est de posse do processador. Em geral, existem vrios processos no sistema prontos para serem executados e o Sistema Operacional responsvel por, dessa lista de processos, selecionar qual utilizar o processador em um determinado instante de tempo. Bloqueado: um processo est no estado de bloqueado quando ele aguarda por algum evento externo ou por algum recurso do sistema indisponvel no momento. Por exemplo, se um processo necessita de uma informao de algum dispositivo de E/S, enquanto essa informao no se torna disponvel, o processo entra no estado de bloqueado.

Os trs estados de um processo em um Sistema Operacional tornam possvel algumas transies, como ser observado na Figura 7.

Figura 7: Transies possveis entre os estados de um processo.

A transio 1 (Executando - Bloqueado) ocorre quando um processo que estava utilizando o processador precisou de algum

evento externo (operao de Entrada/Sada, por exemplo), no podendo continuar executando, passando, assim, para o estado de bloqueado. A transio 2 (Bloqueado - Pronto) ocorre quando o evento externo, no qual o processo bloqueado aguardava, acontece. Nesse caso, o processo passa para o estado de pronto e volta para a fila para poder concorrer novamente ao processador. Se no existir nenhum processo na fila de prontos, naturalmente, o processo desbloqueado utilizar a CPU. J as transies 3 (Pronto - Executando) e 4 (Executando Pronto) so realizados pelo escalonador de processos. Comumente, existem vrios processos prontos e esperando para serem executados. Cabe ento ao Sistema Operacional (escalonador) escolher, entre os processos prontos, qual utilizar o processador e poder executar suas atividades. O Sistema Operacional

(dependendo da poltica do escalonador) pode, tambm, retirar o processador de um determinado processo e disponibiliza-lo para outro processo. Este assunto, escalonamento de processos, ser tratado um pouco mais a frente, no captulo 4 desta unidade.

1.4. Tabelas de Processos Para ser possvel a implementao do modelo de processos, o Sistema Operacional mantm uma tabela conhecida como tabela de processos. Essa tabela contm informaes relevantes sobre os processos, como seu contador de programa, ponteiro da pilha, alocao de memria, status de arquivos abertos, dentre outros, que permite que um processo possa ser reiniciado do ponto de onde parou.

1.5. Threads Threads so fluxos de execuo (linha de controle) que rodam dentro de um processo. Em processos tradicionais, h uma nica linha de controle e um nico contador de programa. Porm,

alguns Sistemas Operacionais fornecem suporte para mltiplas linhas de controle dentro de um processo (sistemas multithread). Ter mltiplas linhas de controle ou threads executando em paralelo em um processo equivale a ter mltiplos processos executando em paralelo em um nico computador. Um exemplo tradicional do uso de mltiplas thread seria um navegador web, no qual pode ter uma thread para exigir imagens ou texto enquanto outro thread recupera dados de uma rede. importante destacar que as threads existem no interior de um processo e compartilham entre elas os recursos do processo, como o espao de endereamento (cdigo e dados).

2. COMUNICAO INTERPROCESSOS

Em um Sistema Operacional, frequentemente, os processos podem precisar trocar informaes entre eles ou podem solicitar a utilizao de um mesmo recurso simultaneamente, como arquivos, registros, dispositivos de E/S e memria. O compartilhamento de recursos entre vrios processos pode causar situaes indesejveis e, dependendo do caso, gerar o comprometimento da aplicao. O Sistema Operacional tem a funo de gerenciar e sincronizar processos concorrentes, com o objetivo de manter o bom funcionamento do sistema.

2.1. Condies de Corrida Podemos definir uma condio de corrida quando dois ou mais processos podem compartilhar algum espao de memria compartilhado no qual, o resultado da informao deste espao de armazenamento depende de quem executa e precisamente quando. Um exemplo tpico de condio de corrida, apontado por vrios autores, o spool de impresso.

Quando um processo deseja imprimir alguma informao, ele insere o nome de arquivo em um espao denominado diretrio de spooler. Existe outro processo, o servidor de impresso, que verifica periodicamente se h qualquer arquivo a ser impresso e, caso haja, ele os imprime e remove a informao do diretrio. Consideremos a seguinte situao: o diretrio de spooler contm um nmero de entradas numeradas e um processo, quando deseja imprimir alguma informao, consulta uma varivel (entrada) a fim de saber em qual posio inserir o nome de arquivo no diretrio. O diretrio de impresso est ilustrado na Figura 8.

Figura 8: Diretrio de spooler (impresso).

Podemos imaginar agora a seguinte situao: um processo A l a varivel entrada e armazena o valor dela (valor 0) em uma varivel local. Porm, o tempo de execuo do processo A termina e o Sistema Operacional o retira do processador, disponibilizando-o a um outro processo B. O processo B, por sua vez, tambm deseja imprimir um arquivo, acessa a rea do diretrio de impresso, verifica o valor da varivel entrada (valor 0), armazena este valor em uma varivel local e, por fim, insere o nome de seu arquivo a ser impresso na posio 0 do diretrio de impresso, mudando o valor da varivel entrada para 1. A Figura 9 visualiza esta situao atual.

Figura 9: Situao do Diretrio de impresso aps insero do nome de arquivo do processo B.

Por fim, o processo A retoma o processador, iniciando novamente de onde parou. Ao examinar em sua varivel local o valor da varivel entrada (esta informao ele guardou em sua tabela, momento em que ele parou a execuo), o processo observa o valor 0 e escreve seu nome de arquivo nessa posio, apagando o nome de arquivo do processo B. Em seguida, incrementa o valor da varivel entrada para 1. A Figura 10 mostra a nova situao do servidor de impresso.

Figura 10: Situao do Diretrio de impresso aps insero do nome de arquivo do processo A.

Internamente, o servidor de impresso continua consistente, porm o arquivo do processo B jamais ser impresso.

Caracterizamos este tipo de situao como uma condio de corrida.

2.2. Sees Crticas Para se evitar uma condio de corrida preciso definir mtodos que proba que mais de um processo acesse uma determinada rea de memria compartilhada ao mesmo tempo. Esses mtodos so conhecidos como excluso mtua. Um processo, durante seu tempo de execuo, pode realizar uma srie de computaes internas que no geram condies de corrida ou pode estar acessando memria compartilhada, que levam condio de corrida. A parte do programa no qual o processo acessa memria compartilhada chamada seo crtica ou regio crtica. Dessa forma, a soluo para se evitar uma condio de corrida seria organizar os problemas de tal forma que nenhum de dois ou mais processos estivessem em suas regies crticas ao mesmo tempo. Para se ter uma boa soluo de excluso mtua, precisamos evitar algumas situaes indesejveis, como: Nenhum processo que esteja fora de sua regio crtica pode bloquear a execuo de outro processo; Nenhum processo deve esperar indefinidamente para poder entrar em sua regio crtica.

Nos prximos tpicos, mostraremos algumas das diversas solues propostas para se evitar condies de corrida.

2.3. Excluso Mtua com Espera Ativa Mostraremos neste tpico algumas propostas de excluso mtua no qual, um processo quando est acessando sua regio crtica, outro processo que deseja entrar tambm em regio crtica fica aguardando.

2.3.1. Desativando Interrupes Uma simples soluo de excluso mtua seria desativar todas as interrupes do sistema quando um processo fosse acessar sua regio crtica, ativando-as imediatamente aps sair dela. Com as interrupes desativas, nenhuma interrupo de relgio pode ocorrer e, naturalmente, o processador no poder alternar entre processos, garantindo que nenhum outro processo ir executar sua regio crtica. Esta abordagem funcional, porm, pouco atraente, pois compromete o nvel de segurana do sistema. Caso as interrupes, por algum motivo, no sejam novamente ativadas, todo o sistema estar comprometido. Outro problema deste mtodo est em torno de sistemas com mais de um processador, pois, desativar as interrupes ir afetar apenas um processador. Com outros processadores livres, outros processos podero executar e, ocasionalmente, acessar suas regies crticas, tornando este mtodo ineficaz.

2.3.2. Variveis de Bloqueio Outra soluo de excluso mtua seria utilizar variveis de bloqueio (soluo de software). A soluo de varivel de bloqueio consiste de uma nica varivel compartilhada (bloqueio). Quando um processo desejar acessar sua regio crtica, ele inspeciona a varivel de bloqueio. Caso a varivel esteja definido com valor 0 (bloqueio livre), o processo define seu valor para 1 e acessa livremente sua regio crtica. Se a varivel estiver definida com valor 1, o processo deve esperar at ela se tornar 0. Essa idia gera o mesmo problema visto no diretrio de impresso. Suponha que o processo A testa o bloqueio e verifica que ele tem o valor 0. Porm, antes de definir o seu valor para 1, outro processo selecionado para utilizar o processador. Este novo processo testar o bloqueio, verifica que o seu valor 0, modifica para 1 e acessa sua regio crtica. O processo A, quando retomar o

processador, ele tambm definir a varivel de bloqueio para 1 (no momento que ele parou, ele j tinha verificado o seu valor, no momento, definido como 0) e acessa sua regio crtica. Sendo assim, teremos dois processos acessando suas regies crticas simultaneamente.

2.3.3. Alternncia Estrita Uma outra abordagem de excluso mtua a alternncia estrita. Esta abordagem utiliza uma varivel de bloqueio, que serve para indicar qual processo ir entrar em sua regio crtica. Vamos analisar este mtodo atravs do trecho em pseudo-linguagem apresentado a seguir:

Processo A Enquanto(VERDADEIRO){ Enquanto(bloqueio 0); //espera Regio_crtica_A; Bloqueio = 1; Regio_no_crtica_A; } }

Processo B Enquanto(VERDADEIRO){ Enquanto(bloqueio 1); //espera Regio_crtica_B; Bloqueio = 0; Regio_no_crtica_B;

Note atravs dos algoritmos, que quando o processo A desejar entrar em sua regio crtica, primeiramente, ele testa o bloqueio. Caso o bloqueio esteja com valor 0, o processo A passa o loop (enquanto), acessando sua regio crtica. Caso o processo B desejar entrar em sua regio crtica e testar o bloqueio, ir verificar que o valor consta como 0 e ficar preso no lao enquanto, no podendo entrar em sua regio crtica. O processo A, ao sair da sua regio crtica, ir definir o valor 1 para a varivel de bloqueio, passando a executar sua regio no-

crtica. Nesse ponto, o processo B ter caminho livre para acessar sua regio crtica. Agora vamos supor a seguinte situao: o processo A deseja acessar sua regio crtica, testa o bloqueio e verifica que tem permisso (valor 0). O processo, assim, acessa sua regio crtica, executa sua atividade, sai da regio crtica, define o valor do bloqueio para 1 e comea a acessar sua regio no-crtica. Nesse momento, o processo B testa o bloqueio, verifica que tem permisso, acessa sua regio crtica, executa suas atividades crticas, sai da regio crtica, define o bloqueio para 1 e comea a acessar sua regio no-crtica. Porm, o processo B executa em sua regio nocrtica rapidamente e, novamente, precisa entrar em sua regio nocrtica. Porm, ele no ter acesso, pois a varivel de bloqueio est com valor 0, mesmo o processo A no estando executando em sua regio crtica. Essa situao viola uma das condies para se ter uma boa soluo de excluso mtua, que define que nenhum processo que no esteja em sua regio crtica pode bloquear outro processo. No caso apresentado, o processo A, mesmo no executando em sua regio crtica, bloqueia o processo B, que deseja entrar em sua regio crtica.

2.3.4. A Soluo de Peterson Outra maneira de se implementar excluso mtua seria atravs da utilizao de um algoritmo, proposto em 1981 por G. L. Peterson, conhecido como a soluo de Peterson. Este algoritmo apresenta uma soluo para dois processos que pode ser facilmente generalizada para o caso de N processos. Este algoritmo se baseia na definio de duas primitivas, utilizadas pelos processos que desejam utilizar sua regio crtica. Essas primitivas, como podem ser visualizadas no trecho de cdigo a seguir (linguagem de programao C), so as funes entrar_regiao() e sair_regiao(), que so utilizadas pelos processos

para, respectivamente, entrarem em sua regio crtica e sair de sua regio crtica. #define FALSO 0 #define VERDADE 1 #define N 2 int bloqueio; int interesse[N]; void entrar_regiao(int processo){ int outro = 1 processo; interesse[processo] = VERDADE; bloqueio = processo; while(bloqueio == processo && interesse[outro] == VERDADE); //espera } void sair_regiao(int processo){ interesse[processo] = FALSO; }

Note atravs do cdigo apresentado, que quando o processo A desejar entrar em sua regio crtica, ele chamar a funo entrar_regiao() passando seu identificar (int processo, com valor 0) para a funo. Nesta funo, a varivel outro ser definido com valor 1, o vetor de interesse, posio 0 (do processo), ter valor VERDADE e a varivel bloqueio ser definido para o valor do identificador do processo, no caso, valor 0. Ao chegar no loop while (enquanto), ser testado se o bloqueio (valor 0) igual ao identificador do processo e se o vetor de interesse, na posio do outro, tem valor VERDADE. No caso apresentado, o valor do vetor interesse, posio outro, no ser valor VERDADE e o processo 0 no ficar preso ao loop, saindo da funo e, naturalmente, podendo entrar em sua regio crtica.

Agora vamos supor que o processo B tambm tem interesse de entrar em sua regio crtica, chamando a funo entrar_regiao() e passando seu identificador para a funo (int processo, com valor 1). Nesse caso, ele definir que a sua varivel outro ter valor 0, que o vetor interesse, posio 1, ter valor VERDADE e a varivel bloqueio ser definido com o valor 1. Ao chegar no lao while, o processo 1 ir verificar que o vetor de interesse, na posio outro (valor 0), ser VERDADE (processo 0), ficando, assim, preso no lao. Dessa forma, o processo 1 no poder acessar sua regio crtica. O processo 0, quando sair de sua seo crtica ir chamar a funo sair_regiao(), passando seu identificador como parmetro para a funo (int processo, com valor 0). Nesta funo, o vetor de interesse, na posio do processo, receber valor FALSO. Assim, o processo 1, que estava preso no loop pois o valor do vetor interesse, posio 0, tinha valor VERDADEIRO, agora poder sair do lao e acessar sua regio crtica.

2.4. Problema dos Produtores e Consumidores O problema dos produtores e consumidores muito comum em programas concorrentes, no qual exista um processo que produz continuamente informaes que sero usadas por outro processo. Esta informao produzida e consumida pode ser um nmero, string, registro ou qualquer outro tipo. Entre o processo que produz a informao (produtor) e o processo que consome a informao (consumidor) existe um espao de memria (buffer) que serve para armazenar temporariamente as informaes que ainda no foram consumidas. O problema surge quando o produtor deseja inserir um novo item, porm o buffer est cheio. De forma anloga, caso o consumidor deseje consumir alguma informao e o buffer estiver vazio. A soluo para este problema pode ser atravs de duas primitivas, conhecidas como sleep (dormir) e wakeup (acordar). Para o problema dos produtores e consumidores, caso o buffer esteja

vazio, o consumidor pode ser colocado para dormir, atravs da primitiva sleep e, de forma anloga, o produtor pode ser colocado para dormir, caso o buffer esteja cheio. Quando uma informao for produzida, o consumidor poder ser acordado pelo produtor atravs da primitiva wakeup. De forma anloga, o produtor pode ser acordado pelo consumidor caso uma informao seja retirado do buffer cheio. Esta situao conduz condio de corrida do servidor de impresso vista anteriormente. Supondo que utilizada uma varivel N para poder monitor a quantidade de informaes no buffer. Assim, quando o valor de N for a quantidade mxima do buffer, o produtor colocado para dormir. Da mesma forma, quando o valor de N for zero, o consumidor colocado para dormir. Agora imaginemos a seguinte situao: o buffer encontra-se vazio e o consumidor acabou de ler a varivel N para ver se ele zero. Nesse momento, o processador tomado do consumidor e passado para o produtor. O produtor realiza sua atividade, produzindo uma informao e incrementa o valor de N para 1. Considerando que o valor de N era zero, o produtor chama a primitiva wakeup para acordar o consumidor (presumindo que ele estava dormindo). Contudo, o consumidor no estava dormindo e o sinal de wakeup perdido. Quando o consumidor volta a utilizar a CPU, ele testar o valor de N anteriormente lido, verificando que trata-se de valor zero e, por fim, passa a dormir. O produtor, cedo ou tarde, ir encher o buffer com informaes produzidas e tambm ir dormir. Ambos dormiro para sempre.

2.5. Semforos O problema dos produtores e consumidores, alm dos vrios problemas de sincronizao entre processos, pode ser resolvido atravs de uma soluo conhecida por semforos. Ele foi proposto por E. W. Dijkstra em 1965. O semforo um tipo abstrato de dado composto por um valor inteiro e uma fila de processos. Dijkstra

props existir duas operaes bsicas sobre semforos: operao de testar e a operao de incrementar. Vrios autores utilizam nomenclaturas diferentes para representar essas operaes: DOWN e UP (Tanenbaum), wait e signal (Silberschatz) e P e V, originalmente designadas, que vem do holands proberen (testar) e verhogen (incrementar). Quando um processo executa a operao P sobre um semforo, o seu valor inteiro decrementado. Se o valor do semforo for negativo, o processo bloqueado e inserido no fim da fila desse semforo. Quando um processo executa a operao V sobre um semforo, o seu valor inteiro incrementado. Caso exista algum processo bloqueado na fila, o primeiro processo liberado. Para que a soluo atravs de semforos funcione

corretamente suas operaes so feitas como uma nica e indivisvel ao atmica, ou seja, uma vez que uma operao sobre semforos comece, ela no pode ser interrompida no meio e nenhuma outra operao sobre o semforo deve ser comeada. Dessa forma, para utilizar a soluo em uma aplicao que gere uma condio de corrida basta que, para cada estrutura de dados compartilhada, seja utilizado um semforo. Todo processo antes de acessar essa estrutura deve realizar uma operao de teste do semforo (P). Ao sair da seo crtica, o processo deve realizar uma operao V sobre o semforo.

3. PROBLEMAS CLSSICOS DE CIP

A literatura de Sistemas Operacionais est repleta de problemas que servem como ambiente de aplicao de novos mtodos de comunicao interprocessos. Segundo Tanenbaum, todo mundo que resolvia inventar algum mtodo para solucionar problemas de sincronizao entre processos sentia-se obrigado a

demonstrar o quo maravilhoso o seu mtodo era, aplicando sobre um desses problemas clssicos e mostrando o quo elegantemente seu mtodo resolvia. Neste tpico, examinaremos dois problemas clssicos de comunicao interprocessos conhecidos como:

Problema do jantar dos filsofos e o problema do barbeiro adormecido.

3.1. Problema do Jantar dos Filsofos

Diverso

O problema do Jantar dos Filsofos foi proposto e resolvido por Dijkstra em 1965. O problema foi modelado da seguinte forma: Cinco filsofos sentados ao redor de uma mesa circular, que contm cinco pratos de espaguete e cinco garfos. Entre cada prato de espaguete encontra-se um garfo. Para comer, um filsofo precisa de dois garfos.

O problema do jantar dos filsofos pode ser ilustrado atravs da Figura 11.

Figura 11: O problema clssico de comunicao interprocessos do Jantar dos Filsofos.

Segundo o problema, cada filsofo alterna perodos de comer e pensar. Assim, quando um filsofo fica com fome, ele tentar pegar os garfos da sua esquerda e direita, um de cada vez, para poder comer o espaguete. Se conseguir pegar os dois garfos, ele come por um tempo, liberando os garfos ao final e voltando sua atividade de pensar. O problema consiste em modelar uma situao que no gere o bloqueio dos filsofos. Vamos imaginar, por exemplo, a seguinte situao: suponha que todos os filsofos resolvem comer ao mesmo tempo e pegam seus garfos da direita. Nessa situao, nenhum ter condies de pegar o garfo da esquerda (indisponvel) e entraram em uma situao de impasse. Uma outra situao que poderamos imaginar para resolver o problema seria fazer com que o filsofo depois que pegasse o garfo da direita, verificar se o garfo da esquerda est disponvel. Se estiver disponvel, o filsofo poderia pegar e comer. Caso no estivesse disponvel, o filsofo colocaria o garfo da direita e esperaria algum tempo para, ento, tentar comer novamente. Esta proposta tambm geraria uma situao de impasse entre os filsofos. Imagine se todos resolvessem comer ao mesmo tempo, pegassem seus garfos da direita e, aps verificar que os garfos da esquerda no estavam disponveis, baixar o garfo da direita, esperar um tempo qualquer e todos, mais uma vez, resolvessem comer novamente. Poderamos pensar em uma soluo onde o tempo que o filsofo esperaria para comer novamente fosse aleatrio. Em geral, poderia funcionar, mas teramos, ainda, uma probabilidade de que o tempo aleatrio de cada um fosse o mesmo, gerando, assim, a situao de impasse. Uma provvel soluo para este problema pode ser pensada utilizando semforos.

3.2. Problema do Barbeiro Adormecido Outro problema clssico de CIP conhecido como o problema do barbeiro adormecido. Trata-se de uma barbearia que

contm um barbeiro, uma cadeira de barbeiro e n cadeiras de espera. O problema pode ser visualizado atravs da Figura 12.

Figura 12: O problema do Barbeiro Adormecido.

Para este problema, se no houver nenhum cliente na barbearia, o barbeiro senta-se e comea a dormir (o barbeiro, provavelmente, no dormiu direito durante a noite). Quando um cliente chega barbearia, ele acorda o barbeiro para poder cortar seu cabelo. Se outros clientes chegarem enquanto o barbeiro estiver cortando o cabelo de algum, o novo cliente observa se existe cadeira de espera livre. Caso exista, ele se senta e aguarda sua vez. Caso contrrio, ele obrigado a ir embora. Note que neste problema temos vrias reas compartilhadas e qualquer mtodo que tente resolver este problema dever considerar esses pontos.

4. ESCALONAMENTO DE PROCESSOS

Um ponto crucial no desenvolvimento de um Sistema Operacional como alocar de forma eficiente o processador (CPU) para os vrios processos prontos para serem executados. O escalonamento processadores de processos (um a ou forma vrios) com no que os

disponveis

Sistema

Computacional so distribudos ou alocados para os vrios processos prontos. Segundo Silberschatz, o objetivo da multiprogramao contar sempre com algum processo em execuo para maximizar a utilizao da CPU. Em um sistema com um nico processador, somente um processo pode ser executado de cada vez; quaisquer outros processos devem esperar at que a CPU esteja livre e possa ser redistribuda. A parte do Sistema Operacional responsvel por selecionar qual ser o processo que executar no processador chamado de escalonador ou agendador. Dessa forma, a ordem com que os processos sero executados pelo processador definida por um determinado algoritmo ou poltica de escalonamento de processos. O projeto de um algoritmo de escalonamento deve levar em conta uma srie de necessidades, no qual alguns so apontados a seguir: Utilizao da CPU: o intuito manter a CPU ocupada o tempo mximo possvel. Maximizar a produtividade (throughput): se a CPU estiver ocupada executando processos, ento o trabalho estar sendo realizado. Deve-se procurar maximizar o nmero de processos processados por unidade de tempo. Justia: o algoritmo de escalonamento deve ser justo com todos os processos, onde cada um deve ter uma chance de usar o processador.

Minimizar o tempo de resposta: intervalo de tempo entre a submisso de uma solicitao e o momento em que a primeira resposta produzida.

Outras necessidades podem ser apontadas, como tempo de espera, balanceamento do uso dos recursos, previsibilidade, dentre outros. Se observarmos, alguns desses objetivos de um algoritmo de escalonamento de processos so conflitantes. Alm disso, os processos so nicos e imprevisveis. Dessa forma, o grande desafio de se desenvolver algum algoritmo de escalonamento conseguir balancear todos esses objetivos conflitantes. Porm, segundo pesquisadores da rea, qualquer algoritmo de

escalonamento que tenta favorecer alguma classe de trabalho (sistemas interativos, por exemplo) acaba prejudicando outra classe de trabalho, ou seja, para dar mais a um usurio, voc tem que dar menos a outro, como dito por Tanenbaum. Os algoritmos de escalonamentos podem ser classificados em preemptveis e no-preemptveis. O algoritmo de escalonamento no-preemptvel quando o processador alocado para um determinado processo no pode ser retirado deste at que o processo seja finalizado. J o algoritmo de escalonamento dito preemptvel quando o processador alocado para um determinado processo pode ser retirado deste em favor de um outro processo. Este procedimento de tirar o processador de um processo e atribulo outro chamado por vrios autores da rea por troca de contexto. Nos tpicos a seguir, veremos com detalhes alguns algoritmos de escalonamento de processos.

4.1. Algoritmo de Escalonamento FIFO (First in First out) Trata-se do algoritmo de escalonamento de implementao mais simples. Com este algoritmo de escalonamento, o primeiro processo que solicita a CPU o primeiro a ser alocado. Dessa forma, os processos que esto prontos para serem executados pela

CPU so organizados numa fila, que funciona baseado na poltica FIFO (First in First out Primeiro a entrar o primeiro a sair). Vejamos um exemplo. Considere o seguinte conjunto de processos: Processo A B C D Durao de Execuo 12 8 15 5

Supondo que a ordem de chegada dos processos seja: A B C D. Dessa forma, baseado na poltica FIFO, a ordem de execuo dos processos mostrado atravs da Figura 13 (diagrama de tempo).

Figura 13: Diagrama de tempo usando a poltica FIFO.

Para este conjunto de tarefas o tempo de espera do processo A de 0 (zero) unidades de tempo; para o processo B de 12 unidades de tempo; para o processo C de 20 unidades de tempo; e para o processo D de 35 unidades de tempo. O tempo mdio de espera na fila de prontos de (0+12+20+35)/4, que equivale a 16,75 unidades de tempo. Nesta poltica de escalonamento o tempo mdio de espera , com frequncia, um tanto longo. Outro ponto que processos importantes podem ser obrigados a esperar devido execuo de outros processos menos importantes dado que o escalonamento

FIFO no considera qualquer mecanismo de distino entre processos.

4.2. Algoritmo de Escalonamento Menor Tarefa Primeiro Outra poltica de escalonamento de tarefas conhecido como algoritmo de escalonamento de Menor Tarefa Primeiro (SJF shortest job first), no qual o processo que tem o menor ciclo de processamento (tempo de execuo) ser selecionado para usar o processador. Considerando o mesmo conjunto de tarefas apresentados, teramos o diagrama de tempo apresentado na Figura 14.

Figura 14: Diagrama de tempo usando a poltica Menor Tarefa Primeiro.

Nesta poltica de escalonamento, o tempo de espera do processo A de 13 unidades de tempo; para o processo B de 5 unidades de tempo; para o processo C de 25 unidades de tempo; e para o processo D de 0 unidades de tempo. O tempo mdio de espera na fila de prontos de (13+5+25+0)/4, que equivale a 10,75 unidades de tempo. Em mdia, nessa poltica de escalonamento, os processos tiveram que esperar menos para serem executados pelo processador. Segundo Silberschatz, a dificuldade real com o algoritmo de Menor Tarefa Primeiro saber o tempo de durao da prxima solicitao de CPU. Assim, trata-se de um algoritmo timo porm, no pode ser implementado, pois no h modo de saber o tempo de durao do prximo pico de CPU. Uma abordagem possvel tentar aproximar-se do algoritmo de Menor Tarefa Primeiro.

4.3. Algoritmo de Escalonamento Round Robin O algoritmo Round Robin, conhecido tambm como algoritmo de escalonamento circular, tambm organiza a lista de processos prontos como uma fila simples, semelhante ao algoritmo FIFO. No entanto, cada processo recebe uma fatia de tempo do processador, comumente chamado de quantum. Assim, um processo executa durante um quantum especfico. Se o quantum for suficiente para este processo finalizar, outro processo do incio da fila selecionado para executar. Se durante sua execuo o processo se bloquear (antes do trmino do quantum), outro processo da fila de prontos tambm selecionado. Se terminar a fatia de tempo do processo em execuo, ele retirado do processador, que disponvel para outro processo. Note ento, que trata-se de um algoritmo de escalonamento preemptvel. Vamos considerar o mesmo conjunto de tarefas apresentado nesta apostila na seo correspondente ao algoritmo de

escalonamento FIFO. Para escalonar este conjunto de tarefas utilizando o algoritmo de escalonamento Round Robin, com quantum de 4 unidades de tempo, teramos o diagrama de tempo representado atravs da Figura 15.

Figura 15: Diagrama de tempo usando a poltica Round Robin (quantum 4 unidades de tempo).

Uma grande questo relacionada poltica de escalonamento Round Robin a definio do quantum. A troca de contexto (alternar entre um processo e outro) requer certa quantidade de tempo para

ser realizada. Sendo assim, se o quantum definido for muito pequeno, ocasiona uma grande quantidade de trocas de processos e a eficincia da CPU reduzida; de forma anloga, a definio do quantum muito grande pode tornar a poltica Round Robin numa FIFO comum.

4.4. Algoritmo de Escalonamento por Prioridades Outra poltica de escalonamento bem interessante a poltica por prioridades. Nesta poltica, os processos so organizados na fila de prontos baseado em prioridades. Quem tiver maior prioridade vai para o incio da fila. Quem tiver menor prioridade vai se encaixando no final da fila. Esta prioridade pode ser uma atribuio externa ao sistema. Vejamos um exemplo. Considere o seguinte conjunto de processos: Processo A B C D Prioridade 2 4 3 1 Durao de Execuo 10 8 6 4

Dessa forma, baseado na poltica de escalonamento por prioridades (quanto menor o nmero, maior a prioridade), a ordem de execuo dos processos mostrado atravs da Figura 16 (diagrama de tempo).

Figura 16: Diagrama de tempo usando a poltica por prioridades.

Alguns aspectos devem ser considerados na poltica de escalonamento por prioridades. Primeiro, se no sistema existir uma quantidade grande e interativa de processos de alta prioridade, podemos chegar a uma situao onde processos de baixa prioridade nunca executaro. Uma possvel soluo para este problema a utilizao de prioridades dinmicas. Dessa forma, os processos de baixa prioridade podem ter suas prioridades lentamente aumentadas, tendo, assim, chances de utilizar o processador. Segundo Oliveira, tipicamente, solues baseadas em

prioridades utilizam preempo, pois o mecanismo de preempo permite implementar o conceito de prioridades de uma maneira mais completa no sistema, posto que no faz sentido fazer todo um esforo para executar antes processos com prioridades alta e, ao mesmo tempo, permitir que um processo de baixa prioridade ocupe o processador indefinidamente (caso no haja preempo).

4.5. Algoritmo de Escalonamento Mltiplas Filas Comumente, em um Sistema Operacional, existem vrios processos de mesmo tipo (mesma categoria, baseado na prioridade e consumo de recursos). Dessa forma, ao invs de termos apenas uma nica fila de prontos, poderamos construir vrias filas de prontos e agrupar os processos de mesma categoria nessas filas. Para cada fila poderamos definir prioridades diferentes e polticas de escalonamentos especficas. Este tipo de algoritmo de

escalonamento conhecido como algoritmo de Mltiplas Filas. Um exemplo deste algoritmo seria considerar duas filas de prontos, uma com maior prioridade e outra de menor prioridade, as duas funcionando segunda a poltica Round Robin. Dessa forma, se a fila mais prioritria tiver processos, estes tero prioridade sobre o processador. Caso a fila mais prioritria estiver vazia, os processos prontos da fila menos prioritria iro concorrer ao processador.

Note que a partir dos vrios algoritmos apresentados, possvel desenvolver vrios outras combinaes e estratgias de escalonamento. Segundo Oliveira, tipicamente, a maioria dos sistemas trabalham com fatia de tempo, sendo muito comum utilizar prioridades para favorecer determinados processos que realizam tarefas para o prprio Sistema Operacional.

WEBLIOGRAFIA

Universidade Aberta do Piau UAPI www.ufpi.br/uapi

Universidade Aberta do Brasil UAB www.uab.gov.br

Secretaria de Educao Distncia do MEC - SEED www.seed.mec.gov.br

Associao Brasileira de Educao Distncia ABED www.abed.org.br

Curso de Sistemas Operacionais DCA/UFRN Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira http://www.dca.ufrn.br/~affonso/DCA0108/curso.html

Home Page do Prof. Dr. Rmulo Silva de Oliveira http://www.das.ufsc.br/~romulo/

Home Page do Autor Andrew S. Tanenbaum http://www.cs.vu.nl/~ast/

Simulador de Ensino para Sistemas Operacionais http://www.training.com.br/sosim/

REFERNCIAS BIBLIOGRFICAS

BACON, J. e HARRIS, T. Operating Systems: Concurrent and Distributed Software Design. Addison Wesley, 2003.

DEITELL, H. M. & DEITEL, P. J. & CHOFFNES, D. R. Sistemas Operacionais. So Paulo, Ed. Prentice Hall, 2005.

MACHADO, F. e MAIA, L. Arquitetura de Sistemas Operacionais. 4 Edio, LTC, 2007

OLIVEIRA, R. S. e CARISSIMI, A. S. e TOSCANI, S. S. Sistemas Operacionais. 3 ed, volume 11, Ed. Bookman, 2008.

SHAW, A. C. Sistemas e software de tempo real. Porto Alegre, Ed. Bookman, 2003.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Fundamentos de Sistemas Operacionais. 6 Edio, Ed. LTC.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Sistemas Operacionais com Java. 7 Edio, Rio de Janeiro, Ed. Elsevier, 2008.

TANENBAUM, A. S. & WOODHULL, A. S. Sistemas Operacionais: Projeto e Implementao. 3 Edio, Porto Alegre, Ed. Bookman, 2008.

TANENBAUM, A. S. Sistemas Operacionais Modernos. 2 Edio, So Paulo, Ed. Prentice Hall, 2003.

Uma das principais funes de um Sistema Operacional controlar e gerenciar todos os dispositivos de entrada e sada disponveis no Sistema de Computao. Os dispositivos de entrada e sada so responsveis por fazer a comunicao do sistema em si com o usurio ou meio externo. O Sistema Operacional deve ser responsvel por fazer a interface entre os dispositivos em si e o resto do Sistema Computacional, enviando comandos para os dispositivos, capturando interrupes e tratando possveis erros. Alm disso, o Sistema Operacional deve apresentar uma interface amigvel para o usurio, escondendo toda complexidade de hardware, tpico dos dispositivos de entrada e sada. Nessa unidade trataremos da parte do Sistema Operacional responsvel por fazer toda essa tarefa descrita, que chamada de gerenciamento de dispositivos de entrada e sada ou,

simplesmente, gerenciamento de entrada e sada. Trataremos tambm na unidade os impasses causados por tentativas de acesso concorrente aos vrios dispositivos disponveis no Sistema

Computacional.

SUMRIO

SUMRIO

UNIDADE III GERENCIAMENTO DE ENTRADA E SADA

1. INTRODUO 2. PRINCPIOS DE HARDWARE DE E/S 2.1. Dispositivos de Entrada e Sada 2.2. Controladoras de Dispositivos 2.2.1. Controladoras que suportam Acesso Direto Memria 3. PRINCPIOS DE SOFTWARE DE E/S 3.1. Manipuladores de Interrupes 3.2. Drivers de Dispositivos 3.3. Software de E/S Independente de Dispositivo 3.4. Software de E/S de Nvel de Usurio 4. DEADLOCKS 4.1. Condies para um Impasse 4.2. Modelagem de Impasses atravs de Grafos 4.3. Mtodos de Lidar com Deadlocks 4.3.1. Algoritmo do Avestruz 4.3.2. Deteco e Recuperao 4.3.3. Preveno de Impasses 4.3.4. Impedimento de Impasses WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE III GERENCIAMENTO DE ENTRADA E SADA

1. INTRODUO

Uma das principais funes de um Sistema Operacional, sem sombra de dvida, gerenciar e controlar todos os dispositivos de entrada e sada disponveis. Esta tarefa no nada simples, posto que o Sistema Operacional deve, para realizar esta atividade, enviar comandos para os dispositivos, capturar e enviar interrupes, alm de tratar possveis erros. O computador, de fato, se tornaria um equipamento intil se no existisse alguma forma do meio externo se comunicar com ele. Os dispositivos de entrada e sada (E/S) so responsveis por fazer essa comunicao entre o sistema, de modo geral, e o meio externo. Nesta unidade comearemos abordando os princpios de hardware de E/S. Logo em seguida, trataremos dos princpios de software de E/S, ou seja, como o software que controla e faz a comunicao com um dispositivo organizado. Esta organizao mostrada na Figura 17. Mais adiante, trataremos da concorrncia entre os processos para alocar os dispositivos em geral e como esse acesso pode gerar uma situao de impasse.

Figura 17: Princpios de hardware e de software de E/S.

2. PRINCPIOS DE HARDWARE DE E/S

Segundo Tanenbaum, o hardware de entrada e sada pode ser visto sob dois pontos de vista: Viso do Engenheiro Eltrico: v o hardware sob o ponto de vista de chips, fios, fontes de alimentao, de motores e de todos os componentes fsicos que o constituem. Viso do Programador: j o programador v a interface apresentada para o software (comandos que o hardware aceita, as funes que ele executa e os erros que podem ser retornados).

Nesta apostila, como no estudo de Sistemas Operacionais baseado no livro clssico de Sistemas Operacionais Modernos de Andrew Tanenbaum, abordaremos a programao de dispositivos de

E/S e no o seu funcionamento interno (assunto de maior interesse dos engenheiros eltricos).

2.1. Dispositivos de Entrada e Sada Como j dito anteriormente, o dispositivo de entrada e sada o mecanismo utilizado para fazer a interface entre o mundo exterior e o sistema e sem ele o computador no teria muita funcionalidade. possvel encontrar uma grande diversidade de dispositivos de entrada e sada, como: teclados, mouses, monitor de vdeo, impressora, scanners, dentre outros. Os dispositivos de entrada e sada, dependendo do sentido do fluxo de informaes entre o sistema e o dispositivo, podem ser divididos, grosso modo, em dispositivos de entrada, dispositivos de sada ou dispositivos de entrada e sada. Os dispositivos de entrada so caracterizados por conter um fluxo de informaes do dispositivo para o sistema, ou seja, so responsveis por inserir no sistema informao do mundo externo. J os dispositivos de sada so caracterizados pelo fluxo de informaes do sistema para o mundo externo, ou seja, responsveis por disponibilizar respostas ao mundo externo. J os dispositivos e entrada e sada contemplam os dois fluxos. Segundo Tanenbaum, os dispositivos tambm podem ser divididos, grosso modo, em duas categorias: dispositivos de bloco e dispositivos de caractere. Os dispositivos de bloco so caracterizados por armazenar informaes em blocos de tamanhos fixos, cada um com seu endereo prprio. A propriedade essencial desse tipo de dispositivos que possvel ler ou gravar blocos independentemente um do outro. O disco um bom exemplo deste tipo de dispositivo. J os dispositivos de caractere so caracterizados por aceitar ou entregar um fluxo de caracteres, sem considerar qualquer estrutura de bloco, sem endereamento ou qualquer operao de busca.

Embora esta classificao seja, de forma geral, muito utilizada, segundo o autor Tanenbaum, existem dispositivos que no so classificveis em nenhum desses tipos. Como exemplo, tomemos por base os relgios. Os relgios so dispositivos que geram interrupes em intervalos definidos de tempo. Este dispositivo no se encaixa nos dispositivos de bloco, pois no possuem estrutura de blocos e, tambm, no se encaixam como dispositivos de caractere, pois no gera nenhum fluxo de caracteres.

2.2. Controladoras de Dispositivos Para que os dispositivos se comuniquem com o sistema, eles so ligados ao computador atravs de um componente de hardware chamado de interface. Assim, os dispositivos no esto ligados diretamente aos barramentos do computador. Devido a diversidade de tipos de dispositivos, que abstrai diferentes formas de operaes e complexidade, as interfaces empregam no seu projeto um outro componente de hardware conhecido como controladora de dispositivo. A controladora de dispositivo (chamada tambm de

adaptador de dispositivo) trata-se de um componente eletrnico, comumente na forma de uma placa de circuito impresso, que pode ser inserido na placa me do computador. O dispositivo em si tratase de um componente mecnico. Uma controladora pode manipular mais de um dispositivo e, quando padronizadas, podem ser fabricadas por diversas empresas. Como exemplo de controladoras, temos as controladoras de disco IDE ou SCSI. Exemplo de um disco com interface IDE e SCSI, respectivamente Cada controladora deve saber especificamente como o dispositivo a ela relacionado funciona, a fim de que possa enviar comandos a serem realizados. Basicamente, uma controladora tem a funo de converter um fluxo serial de bits em um bloco de bytes e executar uma correo de erros. Este bloco de bytes, montado em um buffer interno da controladora, aps verificado erros, pode ser copiado para a memria principal. A maioria dos Sistemas

Operacionais quase sempre lidam com a controladora, no com o dispositivo. As controladoras so formadas de um conjunto de

registradores que so enxergados pelo processador. Esses registradores recebem ordens do processador, fornecem o estado de uma operao ou permitem a leitura ou escrita de dados do dispositivo. O Sistema Operacional quando deseja dar algum comando controladora acessam esses registradores (cada registrador possui um endereo). Os endereos dos registradores podem fazer parte do espao normal de endereamento de memria. Esse esquema conhecido como mapeamento de entrada e sada em memria.

2.2.1. Controladoras que suportam Acesso Direto Memria As controladoras comuns (sem acesso direto memria) recebem um fluxo de caracteres, converte para um bloco, armazenado em seu buffer, depois verifica possveis erros. Por seguinte, a controladora gera uma interrupo no Sistema Operacional, que por sua vez, comea a ler o bloco do buffer da controladora, cada byte por vez, e armazena-os na memria principal. Esta operao, naturalmente, exige desperdcio de CPU. O Acesso Direto Memria (DMA Direct Memory Access) um mecanismo criado para liberar a CPU do trabalho de cpia dos dados da controladora para a memria. O controlador DMA conectado diretamente ao barramento de dados e de endereos do computador, para ter a capacidade de acessar diretamente endereos de memria. Com a controladora DMA, aps o bloco ter sido lido do dispositivo completamente e verificado possveis erros, ela copia o primeiro byte para o endereo de memria principal especificado pelo endereo de memria DMA. Aps terminar a transferncias dos dados para a memria principal, a controladora DMA gera uma interrupo para o Sistema Operacional, que ao ser iniciado j encontra o dado em memria principal.

Segundo Oliveira, a tcnica de DMA mais eficiente quando a operao de entrada e sada envolve a leitura ou escrita de muitos dados, como exemplo, uma leitura de disco. Nem todos os computadores utilizam a tcnica de DMA. A justificativa disso o fato de que a CPU, comumente, bem mais rpida que a controladora DMA e pode fazer o trabalho de cpia de dados para a memria muito mais rpida.

3. PRINCPIOS DE SOFTWARE DE E/S

O software de entrada e sada, comumente, organizado em uma estrutura de camadas, no qual as camadas mais baixas tm como principal funo esconder das camadas mais altas as peculiaridades do hardware. J as camadas mais altas tm como principal funo apresentar uma interface amigvel e simples para o usurio final. Algumas metas de software de entrada e sada podem ser apontadas: Independncia de dispositivo: deve ser possvel escrever programas que podem, por exemplo, l arquivos de qualquer dispositivo. Atribuio uniforme de nomes: o nome de um arquivo ou de um dispositivo no pode depender do dispositivo. Tratamento de erros: os erros devem ser tratados o mais perto possvel do hardware. Transferncias sncronas ou assncronas: a maior parte dos dispositivos de E/S so assncronos e os programas dos usurios so mais fceis de implementar atravs de bloqueios. Assim o Sistema Operacional deve fazer com que as operaes paream, de fato, com bloqueios para os programas do usurio.

Dispositivos compartilhveis ou dedicados: O Sistema Operacional deve ser capaz de tratar dispositivos tanto dedicados como compartilhados de uma maneira que no gere problemas.

Trataremos neste tpico quatro camadas de software de entrada e sada: manipuladores de interrupes, os drivers de dispositivos, software de E/S independente de dispositivo e software de E/S de nvel de usurio.

3.1. Manipuladores de Interrupes As interrupes devem ser escondidas do sistema. O ideal bloquear um processo que inicia uma operao de E/S e mant-lo bloqueado at que a operao de E/S complete e a interrupo tenha ocorrido. O importante a se saber que quando uma interrupo gerada, o processo desbloqueado, passando para um estado capaz de ser executado.

3.2. Drivers de Dispositivos O driver de dispositivo (device driver) composto de um conjunto de mdulos de software cada um implementado para fornecer mecanismos de acesso a um dispositivo de entrada e sada especfico. Assim, cada driver de dispositivo trata de um tipo de dispositivo ou de uma classe de dispositivos correlacionados. De modo geral, um driver responsvel por aceitar uma solicitao abstrata (por exemplo, ler alguma informao) e cuidar para que esta solicitao seja atendida. Assim o driver de um dispositivo tem o conhecimento de como funciona a controladora funciona.

3.3. Software de E/S Independente de Dispositivo A principal funo do software de E/S independente de dispositivo executar funes que so comuns para vrios

dispositivos e oferecer uma interface uniforme para o software de nvel de usurio. Segundo Oliveira, podemos enumerar alguns servios sob responsabilidade dessa camada: Nomeao de Dispositivo: cada dispositivo deve receber um nome lgico e ser identificado a partir dele. Buferizao: buffer uma zona de memria temporria utilizada para armazenar dados enquanto eles esto sendo transferidos entre as diferentes camadas do software de E/S. Cache de Dados: armazenar na memria um conjunto de dados que esto sendo frequentemente utilizados. Alocao e Liberao: devido a alguns dispositivos admitirem, no mximo, um usurio por vez, o software de E/S deve gerenciar a alocao, liberao e uso destes dispositivos. Tratamento de Erros: o software de E/S deve fornecer mecanismos de manipulao de erros, informando camada superior o sucesso ou fracasso de uma operao.

3.4. Software de E/S de Nvel de Usurio A viso dos dispositivos de E/S para o usurio consiste de bibliotecas vinculadas em programas de usurios. Essas bibliotecas so fornecidas pelas linguagens de programao e podem ser utilizadas pelos usurios e ligadas com seus programas para compor o arquivo executvel. As funes de entrada e sada so dependentes e especficas de cada linguagem de programao. Por exemplo, na linguagem C as funes printf e scanf so utilizadas para impresso formatada e leitura, respectivamente. As bibliotecas de entrada e sada no fazem parte do ncleo do Sistema Operacional. Elas so associadas s vrias linguagens de programao.

4. DEADLOCKS

O Sistema Computacional est repleto de recursos, que podem ser utilizados pelos processos. Comumente, a quantidade de recursos disponveis muito menor que a quantidade de processos solicitando esse recurso. Dependendo do recurso, este fato pode gerar uma situao de bloqueio eterno do processo, o que muito ruim para os sistemas. Podemos, assim, definir que um conjunto de processos est em deadlock ou impasse quando cada um desses processos est bloqueado esperando um evento que s pode ser gerado por um outro processo desse conjunto. Como todos os processos esto bloqueados, nenhum deles poder gerar um evento e, naturalmente, todos continuaro nessa situao. Um bom exemplo apontado por Tanenbaum trata-se de dois processos querendo ler dados de um CD e imprimindo em uma impressora. Suponha que o processo A solicite a impressora, que disponibilizada. De forma anloga, o processo B solicita o CD-ROM, que lhe disponibilizado. Agora o processo A solicita o CD-ROM, enquanto que o processo B solicita a impressora. Como ambos os recursos j esto alocados, o processo A e B sero bloqueados. Nessa situao eles continuaro indefinidamente, pois nenhum processo ter como se finalizar e, por fim, liberar o recurso j alocado. Esses processos geram um deadlock. Uma ilustrao de deadlock bem interessante, trazida no livro de Silberschatz, seria a seguinte: Quando dois trens se

aproximarem um do outro em um cruzamento, ambos devero parar completamente e nenhum deles partir novamente at que o outro o tenha feito. importante destacar, que os impasses podem ser gerados tanto por recursos de hardware quanto por recursos de software. Um recurso de software seria um impasse gerado no acesso a registros

de um banco de dados. Sendo assim, trataremos o termo recurso de uma forma geral. Os recursos podem ser divididos em dois tipos: Recursos preemptveis: trata-se de recursos que podem ser retirados de um determinado processo sem gerar problema algum. Por exemplo, a memria. Recursos no-preemptveis: trata-se de recursos que no podem ser retirados de um determinado processo sem causar problemas. Por exemplo, invivel retirar a impressora de um determinado processo que comeou a imprimir sua sada.

4.1. Condies para um Impasse Coffman demonstrou em 1971 que existe quatro condies para que haja um impasse: Condio de excluso mtua: somente um processo de cada vez pode acessar um recurso. Caso contrrio, o recurso estar disponvel. Condio de posse e espera: um processo deve estar de posse de um recurso e solicitando novos recursos. Condio de no preempo: os recursos concedidos aos processos no podem ser retirados deles. Condio de espera circular: deve haver uma cadeia circular de dois ou mais processos, cada um dos quais est esperando um recurso j segurado pelo prximo membro da cadeia e, assim por diante.

4.2. Modelagem de Impasse atravs de Grafos Os deadlocks ou impasses podem ser modelados atravs de grafos dirigidos ou grafos de alocao de recursos. Esses grafos podem ter dois tipos de ns: processos e recursos. Os ns de processos so representados atravs de crculos e os ns de recursos atravs de quadrados, como mostrado na Figura 18.

Figura 18: Ns de processos e recursos na modelagem de deadlocks.

Adiante, um arco de um processo apontando para um recurso significa que o processo est bloqueado esperando esse recurso. J um arco de um recurso para um processo significa que este recurso est alocado para o processo. A Figura 19 ilustra estes dois arcos, respectivamente.

Figura 19: Arco de Processo para Recurso e de Recurso para Processo.

Definido a modelagem do grafo, podemos mostrar que se o grfico no contiver um ciclo fechado, nenhum processo estar em uma situao de impasse. Porm, se o ciclo fechado for formado, poderemos ter um deadlock. A Figura 20(a) mostra um grafo sem deadlock e a Figura 20(b) mostra uma situao de impasse.

Figura 20: Modelagem atravs de Grafos. (a) Situao onde no est caracterizado deadlock. (b) situao onde se caracteriza um deadlock.

4.3. Mtodos de Lidar com Deadlocks Existem vrias formas de lidar com deadlocks. Em geral, temos quatro mtodos: Ignorar completamente o problema. Detectar e recuperar uma situao de deadlock. Prevenir um deadlock atravs da negao das quatros condies de Coffman. Impedimento de um deadlock atravs de uma alocao dinmica cuidadosa de recursos.

Trataremos esses mtodos nos sub-tpicos a seguir.

4.3.1. Algoritmo do Avestruz A forma mais simples de lidar com deadlock chamada de Algoritmo do Avestruz. Reza a lenda, que o avestruz, em um problema qualquer, enfia sua cabea na areia e nem se preocupa com o que est acontecendo, ou seja, finge que no h nenhum O avestruz enfiar a cabea na areia no passa de uma lenda. Confesso que eu mesmo nunca vi um avestruz com a cabea na areia. problema. Esta soluo utilizada em muitos Sistemas Operacionais, inclusivo UNIX. Assim, quando acontece uma situao de impasse, o SO simplesmente ignora o problema, passando a responsabilidade do usurio para tomada de decises.

4.3.2. Deteco e Recuperao Uma outra tcnica para lidar com uma situao de impasse a tcnica de deteco e recuperao. Nessa tcnica, o Sistema Operacional no se preocupa em prevenir um deadlock. Ao invs disso, o sistema fica monitorando as solicitaes e liberaes de recursos. Caso um recurso seja solicitado e a nova situao gere um impasse, o Sistema Operacional tentar eliminar um processo do ciclo. Se o ciclo ainda existir, outro processo ser eliminado at que o ciclo seja quebrado.

4.3.3. Preveno de Impasses Outra estratgia impor situaes para os processos de tal forma que um impasse seja impossvel de acontecer. Essas situaes seria negar pelo menos uma das condies para que ocorra um deadlock, modeladas por Coffman. Abordaremos separadamente. ento cada condio de Coffman

Condio de excluso mtua Caso nenhum recurso fosse atribudo de forma exclusiva a um nico processo, negaramos essa condio e no teramos um impasse. S que existe recursos impossveis de serem atribudos a mais de um processo, como a impressora. Uma soluo seria utilizar tcnicas de spool, onde os processos, ao invs de acessar o recurso diretamente, acessariam um espao de memria e gravariam suas informaes. A partir desse espao de memria, um nico processo iria ler as informaes e enviar para o recurso especfico. Porm, nem todo recurso possvel se utilizar tcnicas de spool.

Condio de posse e espera

Na segunda condio, se for possvel fazer que um processo, que segure algum recurso, no solicite outros recursos,

eliminaramos esta condio e, naturalmente, uma possvel situao de impasse. Uma soluo seria fazer que, um processo solicite todos os seus recursos antes de iniciar a execuo. Caso os recursos estejam disponveis, ele executa. Caso contrrio, ele precisa esperar. O problema para esta alternativa que, na maioria dos casos, os processos no sabem a priori quais recursos ir precisar.

Condio de no preempo Atacar a terceira condio de Coffman, sem sombra de dvidas, uma das solues menos promissora, pois certos recursos so, intimamente, no preemptveis. Mais uma vez, tomemos como exemplo a impressora. Tomar a impressora de um processo no meio da impresso uma atitude um tanto sem lgica.

Condio de espera circular A ltima condio diz que, para se ter um deadlock, formado uma cadeia circular de dois ou mais processos, cada um dos quais est esperando um recurso j segurado pelo prximo membro da cadeia e, assim por diante. Consideraremos uma possibilidade: enumerar globalmente todos os recursos disponveis. Assim, a regra seria que processos podem solicitar recursos sempre que desejarem, mas todas as solicitaes devem ser feitas em ordem numrica. Com essa regra, nunca seria formado uma situao circular. Considere a situao de um processo 1, com um recurso 1 alocado e um processo 2 com um recurso 2 alocado. Se o processo 1 solicitar o recurso 2 e o processo 2 solicitar o recurso 1 formaramos um ciclo e teramos uma situao de impasse. Porm, com essa regra, o processo 2 (com recurso 2 alocado) no tem permisso para solicitar o recurso 1. Assim, o impasse impossvel. A Figura 21 ilustra essa soluo.

Figura 21: Recursos ordenados numericamente

4.3.4. Impedimento de Impasses O sistema pode evitar que um impasse ocorra mediante a alocao cuidadosa dos recursos disponveis. Para que isso ocorra, o sistema precisar de informaes adicionais a priori de quais recursos um processo ir requisitar e usar durante sua execuo. Analisaremos o algoritmo do banqueiro para um recurso e para mltiplos recursos, que so utilizados para avaliar se uma alocao de recursos considerada segura ou no.

Algoritmo do Banqueiro para um nico Recurso O algoritmo do banqueiro foi proposto por Dijkstra (1965). Este algoritmo baseado na mesma idia de um banqueiro de uma pequena cidade para garantir ou no crdito a seus clientes. A idia que um banco jamais possa alocar todo seu dinheiro disponvel em caixa de tal modo que no possa mais atender s necessidades de todos os seus clientes. Esta analogia pode ser utilizada pelo Sistema Operacional, considerando que os clientes so os processos, os recursos so as linhas de crdito e o banqueiro trata-se do Sistema Operacional em

si. Um processo ao entrar no sistema, declara a quantidade mxima de recursos que ele necessitar para executar. Esta quantidade no pode extrapolar a quantidade deste recurso disponvel no sistema. A Figura 22 ilustra quatro processos no sistema, com a quantidade de recursos alocados e a quantidade mxima que cada um necessita para poder executar, alm da disponibilidade desse recurso no sistema. Essa listagem apresentada na Figura 22 chamada de um estado.

Figura 22: Estado inicial contendo quatro processos e a quantidade mxima de recursos necessrios.

Quando um determinado processo solicitar uma quantidade dos recursos disponveis, o sistema dever determinar se esta alocao deixar o sistema em um estado seguro. Assim, considera-se um estado seguro se existir uma sequncia de outros estados que leva todos os processos a solicitarem seus recursos mximos.

Nesse caso, o estado representado pela Figura 23 considerado um estado seguro, pois o processo C ainda ter condio de alocar a sua quantidade de recursos mxima e, naturalmente, executar suas atividades, finalizar e liberar os

recursos para serem utilizados pelos outros processos. Dessa forma, com esse estado no teremos uma situao de deadlock.

Figura 23: Estado considerado seguro no Algoritmo do Banqueiro para nico Recurso.

Porm, se o sistema, ao invs de disponibilizar os dois recursos livres no sistema para o processo C, disponibilizasse um recurso para o processo B, o estado gerado seria um estado no seguro, pois com apenas um recurso disponvel, nenhum dos processos do conjunto iria conseguir finalizar e, consequentemente, teramos uma situao de impasse. A Figura 24 representa este estado no seguro.

Figura 24: Estado considerado no seguro no Algoritmo do Banqueiro para nico Recurso.

Algoritmo do Banqueiro para Mltiplos Recursos O algoritmo do banqueiro pode ser generalizado para vrios processos e vrias classes de recursos, cada um com uma quantidade diversificada. A modelagem desse algoritmo feito atravs de duas matrizes: a primeira contendo os recursos alocados aos processos e a segunda contendo a quantidade ainda necessria de cada recurso por processo. Temos, tambm, trs vetores: um vetor E que mostra a quantidade de recursos existentes no sistema, um vetor A que mostra a quantidade de recursos j alocados e um vetor L que mostra a quantidade de recursos livres. A Figura 26 mostra esta modelagem

Figura 25: Modelagem do Algoritmo do Banqueiro para Mltiplos Recursos.

Note a partir da Figura 25, que, por exemplo, o processo A necessita de 4 recursos R1, 1 recurso R2, 1 recurso R3 e 1 recurso R4 para executar. Note tambm que o sistema contm 6 recursos R1, 3 recursos R2, 4 recursos R3 e 2 recursos R4. O algoritmo do banqueiro para Mltiplos recursos funciona da seguinte forma:

Procurar

uma

linha

da

matriz

de

recursos

ainda

necessrios, no qual todas as posies sejam menores ou iguais ao vetor de recursos livres. Se no existir essa linha, nenhum recurso conseguir finalizar e teremos, enfim, um impasse. Caso um processe execute e se finalize, os recursos por ele alocados sero disponibilizados e podero ser utilizados por outro processo.

No caso de vrios processos (linhas da matriz) tiverem condies de se finalizarem, independente de qual ser escolhido, o algoritmo resultar em um estado seguro. A Figura 26 representa um estado seguro. Note, por exemplo, que o processo D, que j possui alocado um recurso R1, um recurso R2 e um recurso R4, precisa apenas de um recurso R3. Se verificarmos o vetor de recursos livres, podemos verificar que ainda existem dois recursos R3 livres, ou seja, a linha (0 0 1 0) menor que o vetor (1 0 2 0). Assim, este estado pode ser considerado seguro.

Figura 26: Estado considerado seguro no algoritmo do Banqueiro para Mltiplos Recursos.

Entretanto, se fosse atribudo um recurso R3 para os processos B e E, o novo estado gerado no seria seguro, pois no existiria uma linha menor que o vetor de recursos livre. Analise atravs da Figura 27 esta situao impasse.

Figura 27: Estado considerado no seguro no algoritmo do Banqueiro para Mltiplos Recursos.

WEBLIOGRAFIA

Universidade Aberta do Piau UAPI www.ufpi.br/uapi

Universidade Aberta do Brasil UAB www.uab.gov.br

Secretaria de Educao Distncia do MEC - SEED www.seed.mec.gov.br

Associao Brasileira de Educao Distncia ABED www.abed.org.br

Curso de Sistemas Operacionais DCA/UFRN Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira http://www.dca.ufrn.br/~affonso/DCA0108/curso.html

Home Page do Prof. Dr. Rmulo Silva de Oliveira http://www.das.ufsc.br/~romulo/

Home Page do Autor Andrew S. Tanenbaum http://www.cs.vu.nl/~ast/

Simulador de Ensino para Sistemas Operacionais http://www.training.com.br/sosim/

REFERNCIAS BIBLIOGRFICAS

BACON, J. e HARRIS, T. Operating Systems: Concurrent and Distributed Software Design. Addison Wesley, 2003.

DEITELL, H. M. & DEITEL, P. J. & CHOFFNES, D. R. Sistemas Operacionais. So Paulo, Ed. Prentice Hall, 2005.

MACHADO, F. e MAIA, L. Arquitetura de Sistemas Operacionais. 4 Edio, LTC, 2007

OLIVEIRA, R. S. e CARISSIMI, A. S. e TOSCANI, S. S. Sistemas Operacionais. 3 ed, volume 11, Ed. Bookman, 2008.

SHAW, A. C. Sistemas e software de tempo real. Porto Alegre, Ed. Bookman, 2003.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Fundamentos de Sistemas Operacionais. 6 Edio, Ed. LTC.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Sistemas Operacionais com Java. 7 Edio, Rio de Janeiro, Ed. Elsevier, 2008.

TANENBAUM, A. S. & WOODHULL, A. S. Sistemas Operacionais: Projeto e Implementao. 3 Edio, Porto Alegre, Ed. Bookman, 2008.

TANENBAUM, A. S. Sistemas Operacionais Modernos. 2 Edio, So Paulo, Ed. Prentice Hall, 2003.

Vimos no Capitulo II que na multiprogramao, os processos alternam suas execues na CPU, passando a impresso de que eles esto sendo executados ao mesmo tempo (pseudoparalelismo). Para que alternncia entre os processos para usar o processador seja rpido, esses processos precisam estar em memria. Porm, a memria um recurso escasso e manter uma quantidade cada vez maior de processos carregados em memria exige cada vez do Sistema Operacional capacidade de

gerenciamento correto e eficaz. Sendo assim, o bom mtodo de gerenciamento de memria influencia diretamente no desempenho de um Sistema Computacional. A parte do Sistema Operacional, responsvel por gerenciar a memria, controlar as partes de memria que esto e que no esto em uso e alocar e desalocar memria para os processos, conhecida como gerenciador de memria. Nesta unidade trataremos dos principais mtodos de

gerenciamento de memria, dos mais simples, atravs de alocao contgua, at os mais complexos, como exemplo o mtodo de memria virtual.

SUMRIO

SUMRIO

UNIDADE IV GERENCIAMENTO DE MEMRIA

1. INTRODUO 2. GERENCIAMENTO BSICO DE MEMRIA


3. GERENCIA DE MEMRIA PARA MULTIPROGRAMAO

3.1. Alocao com Parties Variveis 3.1.1. Gerenciamento de Memria com Mapa de Bits 3.1.2. Gerenciamento de Memria com Listas Encadeadas 4. MEMRIA VIRTUAL 4.1. Paginao 4.2. TLB Translation Lookside Buffers 5. ALGORITMOS DE SUBSTITUIO DE PGINAS 5.1. Algoritmo de Substituio de Pgina timo 5.2. Algoritmo de Substituio de Pgina No Recentemente Utilizada 5.3. Algoritmo de Substituio de Pgina FIFO
5.4. Algoritmo de Substituio de Pgina de Segunda Chance 5.5. Algoritmo de Substituio de Pgina do Relgio 5.6. Algoritmo de Substituio de Pgina menos

Recentemente Utilizada WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE IV GERENCIAMENTO DE MEMRIA

1. INTRODUO

A memria um recurso fundamental e de extrema importncia para a operao de qualquer Sistema Computacional, seja os mais antigos at os mais modernos. De fato a memria tratase de uma grande regio de armazenamento formada por bytes ou palavras, cada uma contendo seu prprio endereo. Os Sistemas Computacionais mais antigos possuam uma quantidade muito escassa de memria. Atualmente, a memria j um recurso bem mais acessvel e muito mais disponvel que antigamente. comum, por exemplo, uma pessoa ir at uma loja de informtica e comprar um computador com uma quantidade de memria RAM bem razovel (2GB). Porm, mesmo com o ambiente atual sendo muito mais favorvel que antigamente, o gerenciamento da memria um dos fatores mais importantes e complexos de qualquer projeto de Sistemas Operacionais, pois influencia diretamente no bom ou mau desempenho de um Sistema Computacional. Tanenbaum aponta uma situao que seria a mais favorvel: imagine que todo programador tivesse sua disposio uma memria muito rpida e infinitamente grande que tambm fosse novoltil (ou seja, no perde seus dados com a ausncia de energia) e, por aquele preo camarada. Essa situao chega a ser bastante utpico. De fato, essas caractersticas so, um tanto quanto, contraditrias. Por exemplo, quanto mais rpido e maior a memria, com certeza, muito maior o preo. A maioria dos computadores tem uma hierarquia de memria, que trata-se de uma pirmide, no qual em direo ao topo

esto as memrias mais rpidas, porm, mais caras. A Figura 28 esboa essa pirmide.

Figura 28: Hierarquia de Memria

O Sistema Operacional tem como principal funo gerenciar a hierarquia de memria. A parte do SO responsvel por essa funo chamada de gerenciamento de memria. Entre as funes do gerenciador de memria est em controlar as partes de memria utilizada e as partes no utilizadas, alocar (disponibilizar) memria para os processos, desalocar (retirar) memria de processos e gerenciar a troca entre memria principal (primria) e memria secundria. Segundo Tanenbaum, basicamente, os mtodos de

gerenciamento so divididos em duas grandes classes: os mtodos que fazem troca ou paginao e os que no fazem. Iremos estudar alguns desses mtodos adiantes.

2. GERENCIAMENTO BSICO DE MEMRIA

O esquema mais simples de gerenciamento de memria foi implementado nos primeiros Sistemas Operacionais, porm ainda est presente em alguns sistemas monoprogramveis. Este esquema chamado por alguns autores como alocao contgua. Basicamente, a memria principal disponvel dividida entre o Sistema Operacional e o programa em execuo. Como este esquema de gerenciamento utilizado em sistemas

monoprogramveis, temos apenas um processo em execuo por vez. A Figura 29 ilustra esse esquema de gerenciamento de memria principal.

Figura 29: Esquema Bsico de gerenciamento de memria

Neste tipo de gerenciamento, o usurio tem acesso a toda memria principal, inclusive o espao do Sistema Operacional. possvel proteger a rea de memria do Sistema Operacional utilizando registradores delimitadores de rea de usurio e do SO. Assim, os programas esto limitados ao tamanho de memria principal disponvel. Uma tcnica conhecida como overlay, permite que um programa seja dividido em mdulos, de forma que seja possvel a execuo independente de cada mdulo, utilizando uma mesma rea de memria.

3. GERENCIA DE MEMRIA PARA MULTIPROGRAMAO

Atualmente, os sistemas multiprogramveis so amplamente mais utilizados do que os sistemas monoprogramveis, devido a maior eficincia do uso do processador, pois permitem que mltiplos processos executem simultaneamente. A forma mais simples de gerenciar memria em sistemas multiprogramveis dividindo a memria principal em parties estticas e com tamanhos definidos, estabelecidas na fase de inicializao do sistema. Esse tipo de gerncia chamado por alguns autores por alocao particionada esttica ou alocao fixa. Quando um processo chega, ele colocado em uma fila de entrada da partio menor capaz de armazen-lo. Como o esquema prev que a partio fixa, se o processo no ocupar o espao total da sua partio, o resto de espao desperdiado. A Figura 30 mostra esse esquema de gerenciamento de memria.

Figura 30: Esquema de gerencia de memria para multiprogramao com Parties Fixas.

Assim, os programas eram carregados em uma partio especfica. Em algumas situaes, possvel que uma determinada fila exista uma quantidade grande de processos esperando pela partio enquanto que em outras filas de partio no exista nenhum processo. Isso era uma grande desvantagem para o sistema. Por exemplo, na Figura 30 podemos verificar que a partio 4 possui trs processos em espera, enquanto que na partio 2 no existe nenhum processo. Essa partio poderia, assim, ser utilizado por um desses processos na fila. Dessa forma, uma soluo para tentar contornar esse problema implementar este mtodo com uma nica fila. Assim, quando uma determinada partio estivesse livre, o processo mais prximo do incio da fila que melhor se ajusta essa partio poderia ser carregado nela. Este mtodo mostrado na Figura 31.

Figura 31: Mtodo de parties fixas com nica fila.

Este mtodo de gerncia de memria baseado em parties fixas, de uma forma ou de outra, gera um grande desperdcio de memria, posto que, um processo ao ser carregado em uma partio, se ele no ocupa todo o seu espao, o restante no poder ser utilizado por nenhum outro processo.

Para evitar esse desperdcio, foi desenvolvido um esquema de gerenciamento e alocao de memria dinamicamente,

dependendo da necessidade do processo. Este esquema conhecido como alocao com parties variveis. Estudaremos este mtodo no prximo tpico.

3.1. Alocao com Parties Variveis Quando o mtodo de alocao de parties variveis utilizado, o tamanho das parties de memria ajustado dinamicamente medida que os processos vo chegando. Nesse tipo de esquema, o processo utilizar um espao de memria necessrio, tornando esse espao sua partio. Isto resolve o problema da fragmentao, pois as parties passaro a ser definidas a partir da alocao dos processos na memria. O mtodo bem simples. Observe atravs da Figura 32, que um processo A ao chegar, carregado na memria e o seu tamanho define do tamanho da sua partio. O processo B e C, de forma anloga, so carregados no espao livre, ainda disponvel. Ao chegar o processo D, no existe espao livre contnuo suficiente para ele ser carregado.

Figura 32: Esquema de Alocao com Parties Variveis.

Note que, para inserir o novo processo D na memria foi preciso retirar o processo A, a fim de o espao de memria suficiente seja disponibilizado para o novo processo. Assim, o processo A atualizado em disco e o processo D carregado em memria principal, podendo executar suas atividades. Este processo de retirar um processo de memria, atualizar em disco e colocar outro no lugar chamado, segundo Tanenbaum, por mtodo de Troca. A troca consiste em trazer um processo inteiro, executa-lo temporariamente e, ento, devolve-lo ao disco. Isto acontece quando a memria principal disponvel insuficiente para manter todos os nossos processos carregados (situao que seria a tima). Existe outra estratgia, que permite que apenas parte do programa fique em memria principal. Esta estratgia, bem mais complexa que a troca, conhecida como Memria Virtual. Veremos esta estratgia um pouco mais a frente. Podemos notar atravs da Figura 32, que aps alocar e desalocar vrios processos, a memria pode se particionar (espao entre os processos D e B, por exemplo). Chamamos isso de fragmentao externa. Veja que essa fragmentao diferente da gerada na alocao esttica. Na alocao esttica, a fragmentao gerada pelo no uso total da partio pelo processo (fragmentao interna). Assim, quando a troca cria vrias lacunas na memria, possvel juntar todas essas lacunas em um grande espao, movimentando todos os processos para baixo o mximo possvel. Essa tcnica conhecida como compactao de memria e exige muito tempo de CPU. O mtodo de alocao dinmica da partio bem mais flexvel que o mtodo de alocao esttica. Porm, essa flexibilidade tambm complica mais a tarefa de alocar e desalocar a memria, assim como a monitorao da memria utilizada. O Sistema Operacional tem a funo de gerenciar essa memria. De modo geral, h duas maneiras de monitorar o uso da memria: atravs do

mapa de bits e listas encadeadas. Veremos essas duas estratgias nos sub-tpicos a seguir:

3.1.1. Gerenciamento de Memria com Mapa de Bits Com o mapa de bits, a memria dividida em unidades de alocao e para cada unidade associado um bit no mapa. Se este bit estiver com valor 0 implica que esta unidade de alocao est vazia. Se este bit estiver com valor 1 implica que esta unidade de alocao est preenchida por algum processo. Atravs da Figura 33 mais fcil compreender como essa estratgia de gerenciamento funciona. Considere a memria, particionada em XX unidades de alocao, com processos e espaos vazios (lacunas). O mapa de bits dessa memria ser configurado como mostrado na figura.

Figura 33: Memria dividida em unidade de alocao e o Mapa de bits correspondente.

O ponto crucial do mapa de bits a definio do tamanho da unidade de alocao. Se ele for muito pequeno, o mapa de bits poder ser muito grande. Se a unidade for muito grande, o mapa de bits ser menor, mas uma quantia de memria poder ser desperdiada na ltima unidade se o tamanho do processo no for um mltiplo exato da unidade de alocao.

3.1.2. Gerenciamento de Memria com Listas Encadeadas Outra estratgia manter uma lista encadeada dos segmentos de memria alocados e livres, onde um segmento pode ser um processo ou lacuna entre dois processos. Assim, cada n da lista seria formado por uma entrada especificando se um processo (P) ou uma lacuna (L), o endereo de onde se inicia, a quantidade de unidades de alocao e um ponteiro para a prxima entrada. A Figura 34 ilustra a mesma memria gerenciada atravs de listas encadeadas.

Figura 34: Memria dividida em unidade de alocao, monitorada atravs de Lista Encadeada.

4. MEMRIA VIRTUAL

Como foi dito nos tpicos anteriores, os programas esto limitados ao tamanho de memria principal disponvel. possvel utilizar a tcnica overlay, que permite que um programa seja dividido em mdulos, de forma que seja possvel a execuo independente de cada mdulo, utilizando uma mesma rea de memria. Trabalhar com overlays joga a responsabilidade para o programador de dividir o seu programa, o que trata-se de uma tarefa complexa e que exigia tempo do programador. O ideal seria que a diviso do programa fosse feito pelo sistema.

De fato, em 1961, Fotheringham desenvolveu um mtodo conhecido como memria virtual. O principal objetivo desta tcnica estender a memria principal atravs de memria secundria, dando impresso ao usurio que ele tem a disposio uma quantidade de memria maior do que a memria real disponvel. Em outras palavras, para facilitar o entendimento, a tcnica de memria virtual disponibiliza para o usurio uma memria de trabalho maior do que a memria principal (RAM). Esse espao de memria adicional implementado em disco conhecido como memria de swap. A Figura 35 mostra um desenho ilustrativo desta tcnica.

Figura 35: Ilustrao do mtodo de memria virtual.

Assim, o Sistema Operacional deve manter parte do programa que est em uso na memria principal e parte dele na memria swap. Na multiprogramao, partes de vrios processos podem ser mantidas em memria principal e partes em memria swap. Existem algumas estratgias para implementar o mtodo de memria virtual. A estratgia mais conhecida chamada de paginao. Veremos essa estratgia no tpico a seguir.

4.1. Paginao Segundo Silberstchaz, a paginao um esquema de gerenciamento de memria em que o espao de endereamento fsico (endereos de memria principal) de um processo no contguo. A paginao, assim, evita o problema da fragmentao externa gerado pela alocao de memria dinmica. Os programas so capazes de gerar endereos, chamados de endereos virtuais. Esse conjunto de endereos forma o que chamamos de espao de endereamento virtual. Em sistemas que no utilizam a tcnica de memria virtual, o endereo virtual equivale ao endereo fsico, especificando exatamente onde o programa ser armazenado na memria principal. Em computadores que utilizam a tcnica de memria virtual, os endereos virtuais no vo diretamente para o barramento de memria. Primeiramente, ele passa por uma unidade chamada de Unidade de Gerenciamento de Memria (MMU Memory Management Unit). A MMU tem como funo mapear um endereo virtual para um endereo lgico. Adiante, o espao de endereamento virtual dividido em unidade chamadas de pginas. A memria principal tambm dividida em unidades, do mesmo tamanho das pginas, chamadas de molduras de pgina (quadro). Assim, num sistema que contm pginas de 4k, as molduras tambm sero de 4k. Considere a Figura 36, com o espao de endereo virtual formado de 64k e o a memria fsica de 32k, com pginas de molduras de 4k. Note atravs da figura, que temos 16 pginas virtuais e 8 molduras de pginas. Quando um programa tenta acessar um endereo virtual, este passado para a MMU, que vai analisar o mapeamento deste endereo e descobrir a qual moldura pertence. A MMU mapeia este endereo virtual para o endereo fsico, que, por fim, colocado no barramento de memria.

Figura 36: Tcnica de Paginao

Vejamos um exemplo. Considere o mapeamento apresentado na Figura 37.

Figura 37: Mapeamento da memria virtual.

Com esse mapeamento, o endereo virtual 0, que encontrase na pgina 0 (0k-4k) mapeado pela MMU para a moldura 2 (8k12k). De forma anloga, o endereo virtual 8195, pertencente pgina 2 (8k-12k, correspondente a 8192-12287) mapeado para a moldura 6 (24576 at 28671), e seu endereo fsico ser 24576 (endereo inicial da moldura) adicionado do deslocamento dele na pgina (pgina comea com endereo 8192, como seu endereo 8195, ele est deslocado de 3). Assim, o endereo fsico ser 24576 + 3, que equivale a 24579. Vejamos atravs desse exemplo, como a MMU faz esse mapeamento. O endereo virtual 8195 corresponde, em codificao binria, a 0010000000000011. Este endereo virtual formado de 16 bits, no qual os quatros primeiros bits (0010) so utilizados para representar o nmero da pgina (0010 corresponde pgina 2) e o restante (12 bits) utilizado para representar o deslocamento na pgina. Como temos 4 bits para representar o nmero de pginas, com essa combinao, podemos gerar nmeros de 0 a 15, ou seja, as 16 pginas no espao de endereamento virtual. Com os 12 bits de deslocamento podemos ter endereos de 0 a 4k, ou seja, o tamanho das pginas. J no espao de endereamento fsico, como temos 8 molduras no exemplo apresentado, precisamos de 3 bits para represent-las. Com os 3 bits podemos representar as molduras 0 a 7. Como o tamanho de cada moldura corresponde tambm 4k, precisamos, assim, de 12 bits para representar endereos de 0 a 4k. Assim, o endereo fsico representado por 15 bits. Todo mapeamento realizado pela MMU feito atravs de uma tabela conhecida como tabela de pginas. Cada processo possui sua tabela prpria e cada pgina possui uma entrada nesta tabela. Cada entrada, ou seja, cada pgina na tabela possui um bit (bit de validade) que informa se a pgina est ou no mapeada na memria principal.

A Figura 38 mostra o exemplo do mapeamento do endereo virtual 8195 (0010000000000011) para o endereo fsico 24579 (110000000000011). Quando um programa tenta utilizar um endereo virtual e a MMU percebe que a pgina no qual o endereo pertence no possui mapeamento na memria principal, ela gera uma interrupo no Sistema Operacional, conhecido como falha de pgina (page fault). O Sistema Operacional, por sua vez, toma de conta do processador e seleciona uma das molduras, atualizando seu valor em disco. Ento, ele busca a pgina no mapeada, carrega ela na moldura, altera a tabela e reinicia o processo interrompido. A moldura a ser retirada escolhida baseada em algoritmos de escalonamento, chamados de algoritmos de substituio de pginas, que veremos mais a seguir.

Figura 38: Mapeamento de endereo virtual para endereo fsico

4.2. TLB Translation Lookside Buffers As tabelas de pginas, comumente, so mantidas em memria, o que influencia diretamente no desempenho, j que as tabelas so bastante grandes. Segundo Tanenbaum, um comportamento que foi verificado que programas tendem a fazer um grande nmero de referncias a um pequeno nmero de pginas. Assim, somente uma pequena frao de entradas da tabela de pginas intensamente lida. Com isso, foi desenvolvido um dispositivo de hardware capaz de mapear endereos virtuais em endereos fsicos sem passar pela tabela de pginas. Esse dispositivo conhecido como memria associativa ou Translation Lookside Buffers (TLB). Comumente, ele encontrado dentro da MMU.

5. ALGORITMOS DE SUBSTITUIO DE PGINAS

Como dito anteriormente, quando ocorre uma falha de pgina, o Sistema Operacional deve selecionar uma das molduras para disponibilizar para a pgina no mapeada. Se a pgina a ser retirada da moldura tiver sido modificada, ela deve ser atualizada em disco. Caso contrrio, a pgina pode ser retirada da moldura, ou seja, da memria principal, sem necessitar de atualizao em memria. A pgina escolhida , comumente, chamada de pgina vtima. A escolha aleatria de uma pgina vtima pode influenciar diretamente o desempenho do sistema. O ideal seria retirar uma pgina que no utilizada constantemente. Por exemplo, se for retirado uma pgina que muito utilizada, provavelmente ela seja logo referenciada e necessite voltar para a memria principal, gerando novamente uma falha de pgina. Para a escolha de qual pgina ser retirado da memria, temos vrios algoritmos de substituio de pginas, que sero descritos nos tpicos a seguir.

5.1. Algoritmo de Substituio de Pgina timo O algoritmo de substituio de pgina timo o melhor algoritmo possvel. A idia bsica deste algoritmo que, quando ocorrer uma falha de pgina, a pgina a ser substitudo na memria fsica ser a que for referenciada mais tardiamente. Em outras palavras, se tivermos uma quantidade x de pginas carregadas na memria fsicas (nas molduras), algumas pginas podero ser utilizadas logo em seguida, porm, algumas pginas s iro ser referenciadas depois de muito tempo. Dessa forma, se a pgina escolhida for a pgina que ser referenciada mais tardiamente, o algoritmo estar adiando o mximo possvel uma nova falha de pgina. Um exemplo mais prtico para que possamos entender este algoritmo, seria supor que temos 10 pginas na memria. Dessas 10 pginas, a pgina 5, por exemplo, ser a primeira a ser referenciada, ou seja, a prxima. Da mesma forma, a pgina 0, por exemplo, ser a ltima a ser referenciada, ou seja, do conjunto de pginas carregadas, ela ser a ultima. Ento, baseado no algoritmo de substituio de pgina tima, a pgina 0 ser a melhor escolha, pois estamos adiando o mximo possvel uma falha de pgina. visvel que este algoritmo no realizvel na prtica, pois seria necessrio, quem sabe, uma bola de cristal para podermos adivinhar qual seria a ltima pgina a ser referenciada. O fato de no termos como prev o futuro, esse algoritmo se torna no praticvel. Porm, este algoritmo muito utilizado para ser comparado com algoritmos realizveis.

5.2. Algoritmo de Substituio de Pgina No Recentemente Utilizada Alguns bits so utilizados na tabela de pginas e so utilizados com o objetivo de facilitar a implementao de algoritmos de substituio de pginas.

O primeiro bit conhecido como o bit sujeira (dirty bit) e indica se uma pgina foi alterada ou no durante a execuo do processo. Toda vez que uma determinada pgina gravada na memria secundria, o Sistema Operacional zera este bit. O segundo bit conhecido como o bit de referncia (reference bit) e serve para indicar se uma pgina foi referenciada (acessada) por um processo. Quando uma pgina carregada na memria, este bit zerado. Dessa forma, o algoritmo de substituio de pgina no recentemente define que, quando ocorre uma falha de pgina, o Sistema Operacional inspeciona todas as pginas e agrupa em quatros conjuntos, como segue: Conjunto 1: pginas no-referenciadas (bit de referncia com valor zero) e no-modificadas (bit sujeira com valor zero). Conjunto 2: pginas no-referenciadas (bit de referncia com valor zero) e modificadas (bit sujeira com valor 1). Conjunto 3: pginas referenciadas (bit de referncia com valor 1) e no-modificadas (bit sujeira com valor zero). Conjunto 4: pginas referenciadas (bit de referncia com valor 1) e modificadas (bit sujeira com valor 1). O conjunto 4, visivelmente, contm as pginas que so menos aconselhadas de serem retiradas. O conjunto que contm pginas modificadas que no foi referenciada uma escolha melhor do que pginas no-modificadas, mas que so constantemente referenciadas.

5.3. Algoritmo de Substituio de Pgina FIFO O algoritmo de substituio de pginas FIFO (first in first out) define que a pgina que ser retirada a pgina que est mais tempo na memria. Em suma, trata-se de uma fila, onde o primeiro que entra sempre o primeiro que sai. Para exemplificar este algoritmo, consideremos a sequncia de pginas solicitadas apresentada na Figura 39. Considere tambm

que existe apenas 3 molduras (m1, m2 e m3). Dessa forma, atravs do algoritmo de substituio de pgina FIFO temos a configurao de seleo de pginas a serem retiradas apresentadas. Note atravs da Figura 39, que as primeiras pginas, pelo fato de no estarem carregadas nas molduras, tambm geram uma falha de pgina e precisam, assim, serem mapeadas. Note tambm que a quarta pgina quando referenciada (pgina 3) no est mapeada. Como a pgina 0 foi a ltima a ser referenciada (mapeada), ela a pgina escolhida pelo algoritmo. Podemos verificar facilmente, que o algoritmo de substituio de pgina FIFO no leva em considerao se uma determinada pgina muito referenciada, ou seja, caso ela seja a escolhida para sair, ela ser substituda. Veja ainda na Figura 39, que a pgina 7 foi escolhida para sair e, logo aps, ela foi novamente referenciada.

Figura 39: Algoritmo de Substituio de Pgina FIFO

5.4. Algoritmo de Substituio de Pgina de Segunda Chance Como pudemos notar no algoritmo de substituio de pgina FIFO, este no leva em considerao se uma pgina muito utilizada. Assim, a fim de se tentar evitar que uma pgina muito utilizada seja selecionada, podemos inspecionar o bit de referncia antes de selecionar a pgina em questo. Este algoritmo comumente chamado de algoritmo de substituio de pgina de segunda chance. De fato, antes de se retirar uma pgina, verificado se seu bit de referncia tenha valor 1. Caso ele tenha valor 1, seu valor mudado para 0 e esta pgina no retirada. Note que este algoritmo uma pequena modificao do algoritmo FIFO.

5.5. Algoritmo de Substituio de Pgina do Relgio Outro algoritmo que utiliza os bits de referncia para selecionar a prxima pgina a ser retirada o algoritmo de substituio de pgina do relgio. A principal diferena para o algoritmo apresentado anteriormente est na implementao. O algoritmo de segunda chance implementado atravs de uma fila FIFO, utilizando os bits de referncia. J o algoritmo do relgio implementado a partir de uma fila circular. Assim, a prxima pgina a ser retirada ser a primeira pgina apontada pelo ponteiro do relgio que contiver o bit de referncia 0. A Figura 40 ilustra esse algoritmo. Note neste algoritmo, que a prxima pgina que ser retirada no ser nem as pginas 15, 16, 1 e 2, pois seus bits de referncia tem valores 1. Assim, a prxima vtima ser a pgina 3. A Figura 41 mostra essa configurao.

Figura 40: Algoritmo de Substituio de Pgina do Relgio

Observe na Figura 41 que os bits das pginas 15, 16, 1 e 2 foram zeradas e a pgina 17 entrou no lugar da pgina 3.

Figura 41: Seleo de pgina segundo o algoritmo de Substituio de Pgina do Relgio

5.6. Algoritmo de Substituio de Pgina menos Recentemente Utilizada O algoritmo de substituio de pgina menos recentemente utilizada (LRU Least Recently Used) trata-se do algoritmo que tem uma boa aproximao do algoritmo timo. O seu funcionamento bem simples: como impossvel olhar para o futuro, ou seja, no possvel saber das pginas carregadas, qual ser a ltima que ser

referenciada, olharemos para o passado. Assim, quando acontecer uma falha de pgina, o algoritmo selecionar para ser retirada a pgina que foi a mais tempo referenciada. A implementao do algoritmo LRU muito custoso, segundo Tanenbaum, pois preciso manter uma lista encadeada de todas as pginas na memria, com as pginas mais recentemente utilizadas na frente as menos recentemente utilizadas no fundo. Essa lista deve ser atualizada a cada referncia de pgina, o que pode gerar uma grande modificao na lista. Imagine que, uma pgina do fim da lista (pouco referenciada) seja referenciada. preciso, ento deslocar esta pgina para o incio da fila. Para exemplificar este algoritmo, consideremos a mesma sequncia de pginas solicitadas apresentada no algoritmo FIFO. A Figura 42 ilustra essa situao.

Figura 42: Algoritmo de Substituio de Pgina menos Recentemente Utilizada

Observe, que de forma anloga ao algoritmo FIFO, as primeiras pginas, pelo fato de no estarem carregadas nas molduras, tambm geram uma falha de pgina e precisam, assim, serem mapeadas. Veja que a pgina 3, que no algoritmo FIFO seria a pgina retirada para ser substituda pela pgina 5, pelo fato dela ter sido referenciada, o algoritmo LRU j escolheu outra pgina para ser retirada, no caso a pgina 4, que no momento era a menos referenciada.

WEBLIOGRAFIA

Universidade Aberta do Piau UAPI www.ufpi.br/uapi

Universidade Aberta do Brasil UAB www.uab.gov.br

Secretaria de Educao Distncia do MEC - SEED www.seed.mec.gov.br

Associao Brasileira de Educao Distncia ABED www.abed.org.br

Curso de Sistemas Operacionais DCA/UFRN Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira http://www.dca.ufrn.br/~affonso/DCA0108/curso.html

Home Page do Prof. Dr. Rmulo Silva de Oliveira http://www.das.ufsc.br/~romulo/

Home Page do Autor Andrew S. Tanenbaum http://www.cs.vu.nl/~ast/

Simulador de Ensino para Sistemas Operacionais http://www.training.com.br/sosim/

REFERNCIAS BIBLIOGRFICAS

BACON, J. e HARRIS, T. Operating Systems: Concurrent and Distributed Software Design. Addison Wesley, 2003.

DEITELL, H. M. & DEITEL, P. J. & CHOFFNES, D. R. Sistemas Operacionais. So Paulo, Ed. Prentice Hall, 2005.

MACHADO, F. e MAIA, L. Arquitetura de Sistemas Operacionais. 4 Edio, LTC, 2007

OLIVEIRA, R. S. e CARISSIMI, A. S. e TOSCANI, S. S. Sistemas Operacionais. 3 ed, volume 11, Ed. Bookman, 2008.

SHAW, A. C. Sistemas e software de tempo real. Porto Alegre, Ed. Bookman, 2003.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Fundamentos de Sistemas Operacionais. 6 Edio, Ed. LTC.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Sistemas Operacionais com Java. 7 Edio, Rio de Janeiro, Ed. Elsevier, 2008.

TANENBAUM, A. S. & WOODHULL, A. S. Sistemas Operacionais: Projeto e Implementao. 3 Edio, Porto Alegre, Ed. Bookman, 2008.

TANENBAUM, A. S. Sistemas Operacionais Modernos. 2 Edio, So Paulo, Ed. Prentice Hall, 2003.

O Sistema de Arquivo, sem sombra de dvida, a parte do Sistema Operacional mais visvel para o usurio. Por se tratar da parte mais visvel para usurios (alguns bastante experientes, outros, nem tanto), o sistema de Arquivo tem uma grande responsabilidade e desafio: apresentar uma interface fcil. A maioria dos programas manipulam informaes e

necessitam grava-las de forma permanente (atravs de unidades chamadas arquivos). Outra questo que deve ser considerada que, frequentemente, vrios processos acessem as informaes ou parte delas simultaneamente. A parte do Sistema Operacional responsvel por gerenciar os arquivos, o modo como eles so estruturados, nomeados, acessados, utilizados, protegidos e implementados conhecida como o Sistema de Arquivos e ser o assunto tratado nesta Unidade.

SUMRIO

SUMRIO

UNIDADE V SISTEMAS DE ARQUIVOS

1. INTRODUO AOS SISTEMAS DE ARQUIVOS 1.1. Arquivos 1.1.1. Nomeao de Arquivos 1.1.2. Estruturas de Arquivos 1.1.3. Tipos de Arquivos 1.1.4. Acesso aos Arquivos 1.1.5. Atributos de Arquivos 1.1.6. Operaes com Arquivos 1.2. Implementao de Arquivos 1.2.1. Alocao Contgua 1.2.2. Alocao por Lista Encadeada 1.2.3. Alocao por Lista Encadeada Usando ndice 1.3. Diretrios 1.3.1. Organizao de Sistemas de Diretrios 1.3.2. Nomes de Caminhos 1.3.3. Operaes com Diretrios 1.4. Implementao de Diretrios WEBLIOGRAFIA REFERNCIAS BIBLIOGRFICAS

UNIDADE V SISTEMAS DE ARQUIVOS

1. INTRODUO AOS SISTEMAS DE ARQUIVOS

Segundo Tanenbaum, existem trs requisitos essenciais para o armazenamento de informao por longo prazo: Deve ser possvel armazenar uma grande quantidade de informao; A informao deve sobreviver ao trmino do processo que a usa; Mltiplos processos tm de ser capazes de acessar a informao concorrentemente. A soluo encontrada usualmente para o armazenamento de informaes utilizar mdias externas e distintas da memria principal (voltil) em unidades chamadas arquivos, de modo que essas informaes devem ser armazenadas de forma persistente, ou seja, no pode ser afetada pela criao e trmino de um processo. Assim, um arquivo s ir ser destrudo quando seu proprietrio remov-lo explicitamente. Os arquivos so recipientes de dados, identificados por um nome e por uma srie de atributos, mantidos e gerenciados pelo Sistema Operacional. J os diretrios so conjuntos de referncias a arquivos. Os diretrios permitem agrupar arquivos, facilitando manuseio e localizao. Do ponto de vista do usurio, o aspecto mais importante do Sistema de Arquivos como aparece para ele, ou seja, como o Sistema de Arquivos implementado e quais estruturas so utilizadas no a questo primordial. O usurio est mais interessado no que o arquivo constitudo, nomeados e protegidos.

1.1. Arquivos Neste tpico veremos os arquivos do ponto de vista do usurio, abordando suas principais propriedades. importante lembrar que este captulo ir apresentar as caractersticas gerais de Sistemas de Arquivos, de uma forma geral. Porm, cada Sistema de Arquivo especfico contm caractersticas prprias. Caso o leitor tenha interesse em obter mais informaes de um determinado Sistema de Arquivo especfico, a webliografia desta unidade traz alguns links que direcionam sites com informaes dos Sistemas de Arquivos mais conhecidos: FAT32, NTFS e EXT.

1.1.1. Nomeao de Arquivos Segundo Tanenbaum, o arquivo um mecanismo de abstrao, no qual oferece meios de armazenar informaes no disco e l-las posteriormente. A caracterstica mais importante de qualquer mecanismo de abstrao o modo como os objetos so gerenciados e nomeados, isto , a nomeao de arquivos. Um processo ao criar um arquivo, atribui um nome a ele e quando o processo termina, este arquivo continua existindo, possibilitando que outros processos possam ter acesso a ele simplesmente buscando por seu nome. As regras de nomeao de arquivos variam de sistema para sistema, porm, como caracterstica comum, todos os Sistemas Operacionais atuais permitem cadeias de caracteres de um at oito letras como nomes vlidos de arquivos. Alguns Sistemas de Arquivos permite a utilizao de caracteres especiais, outros no; alguns Sistemas de Arquivos permitem nomes com tamanhos at 255 caracteres; alguns Sistemas de Arquivos fazem distino entre letras maisculas e minsculas (case sensitive), como exemplo o Sistema de Arquivo do Unix, enquanto que outros no diferenciam, como exemplo o Sistema de Arquivo do MS-DOS e do Windows. A maioria dos Sistemas Operacionais (na verdade, o Sistema de Arquivo do SO) suporta nomes de arquivos de duas partes, separados por um ponto. A parte que segue o ponto chamada de

extenso do arquivo e indica o tipo do arquivo. Essa extenso, em alguns Sistemas Operacionais, utilizada para atribuir qual programa deve abrir aquele arquivo em especfico.

1.1.2. Estruturas de Arquivos

Segundo Tanenbaum, os arquivos podem ser estruturados, basicamente, atravs de trs maneiras, como visualizados na Figura 43.

Figura 43: Estruturas de Arquivos.

Seqncia de bytes no-estruturada: nessa estrutura o SO no sabe o que o arquivo contm e tudo que ele enxerga uma sequncia de bytes. Tal estratgia apresenta uma mxima flexibilidade, uma vez que os programas dos usurios podem pr qualquer coisa que queiram em seus arquivos e cham-los do nome que lhes convier.

Seqncia de registro de comprimento fixo: Um arquivo uma seqncia de registros de tamanho fixo, cada um com alguma estrutura interna. A idia central que a operao de leitura retorna um registro e a operao de escrita sobrepe ou anexa um registro.

rvore de Registros: um arquivo constitudo de uma rvore de registros (no necessariamente do mesmo

tamanho), cada um contendo um campo-chave em uma posio fixa no registro, na qual a rvore ordenada pelo campo-chave para que se busque mais rapidamente por uma chave especfica. Alm disso, novos registros podem ser adicionados ao arquivo, decidindo o sistema

operacional onde coloc-los. Este tipo de arquivo amplamente aplicado em computadores de grande porte usados ainda para alguns processamentos de dados comerciais.

1.1.3. Tipos de Arquivos Vrios tipos de arquivos so suportados pelos Sistemas Operacionais. Podemos enumerar os principais tipos: Arquivos comuns: arquivos que contm informaes do usurio. Diretrios: arquivos do sistema que mantm a estrutura do sistema de arquivos. Arquivos especiais de caracteres: arquivos relacionados entrada e sada e usados para modelar dispositivos de E/S. Arquivos especiais de blocos: arquivos usados para modelar discos. Os arquivos comuns (informaes do usurio), em geral, so arquivos ASCII ou arquivos binrios. Os arquivos ASCII so constitudos de linhas de texto, possuindo como grande vantagem o fato de que eles podem ser mostrados e impressos como so e poder ser editados com qualquer editor de textos. Alm disso, facilita a conexo entre a sada de um programa e a entrada de um outro. J os arquivos binrios, em geral, possuem alguma estrutura interna, conhecida pelos programas que os usam. Todo Sistema Operacional deve reconhecer pelo menos um tipo de arquivo: seu prprio arquivo executvel.

1.1.4. Acesso aos Arquivos O acesso a arquivos pode ser realizado, basicamente, atravs de duas maneiras. Acesso seqencial: nesse tipo de acesso os arquivos so lidos em ordem sequencialmente, partindo do incio, mas nunca saltando e lendo fora de ordem. Esse tipo de acesso muito utilizado, como exemplo, leitura de mdias do tipo fita magntica, alm de leitura sequencial de programas fontes, realizada por vrios compiladores. Acesso Aleatrio: em alguns tipos de mdias possvel ler bytes ou registros de um arquivo fora da ordem. Esses arquivos so chamados de arquivos de acesso aleatrio. Segundo Tanenbaum, em alguns Sistemas Operacionais antigos, os arquivos eram classificados por acesso sequencial ou por acesso aleatrio no momento em que estavam sendo criados. Entretanto, os Sistemas Operacionais modernos no fazem distino, ou seja, todos os seus arquivos so, automaticamente, de acesso aleatrio.

1.1.5. Atributos de Arquivos A maioria dos Sistemas Operacionais associa vrias

informaes extras a um determinado arquivo. Essas informaes so, comumente, chamadas de atributos de um arquivo. Os tipos de atributos variam de sistema para sistema e nenhum sistema dispe de todos os tipos de atributos possveis. Podemos enumerar uma srie de atributos, como: pessoas que podem acessar, senhas, criador, proprietrio, comprimento do arquivo, tempo de criao, tempo do ltimo acesso, tempo da ltima atualizao, tamanho mximo, dentre outros.

1.1.6. Operaes com Arquivos A finalidade dos arquivos armazenar informao e permitir que ela seja recuperada posteriormente. Assim, os Sistemas de Arquivos oferecem diferentes operaes para armazenar e recuperar

informaes. Dentre as vrias operaes possveis sobre arquivos, podemos destacar: Criar: operao utilizada para criar o arquivo. Apagar: operao utilizada para excluir um determinado arquivo, liberando espao de memria. Abrir: operao utilizada para abrir um arquivo e permitir escrita ou leitura de informaes. Fechar: operao utilizada para fechar um arquivo e manter sua consistncia. Ler: operao disponibilizada para ler informaes do arquivo, para poderem ser utilizadas. Escrever: operao para incluir alguma informao no arquivo.

1.2. Implementao de Arquivos Vrios mtodos so utilizados para implementar arquivos e neste tpicos examinaremos alguns deles.

1.2.1. Alocao Contgua Trata-se do exemplo mais simples de implementar, no qual utilizado um bloco de dados contguo (sequencial) no disco para armazenar um arquivo. Por exemplo, considerando um disco com blocos de 1k, um arquivo com 20k ocuparia 20 blocos consecutivos. Este tipo de alocao traz como principal vantagens a simplicidade de implementao e o fato de ter um bom desempenho no acesso a um arquivo, pois um arquivo inteiro pode ser lido com apenas uma operao. Porm, a alocao contgua possui grandes desvantagens. A primeira est no fato de que este tipo de alocao s praticvel caso seja conhecido o tamanho do arquivo no momento de sua criao. Outra desvantagem que este tipo de alocao gera uma fragmentao no disco. A alocao contgua representada atravs da Figura 44.

Figura 44: Implementao de Arquivos por Alocao Contgua.

1.2.2. Alocao por Lista Encadeada Outro mtodo para armazenar um arquivo utilizando listas encadeadas de blocos de disco. Cada bloco conter, dessa forma, o seu dado armazenado e um ponteiro para o bloco seguinte. A principal vantagem de se utilizar a alocao por lista encadeada est no fato de evita o grande desperdcio em disco, comum na alocao contgua. Alm disso, para acessar todo o arquivo suficiente armazenar apenas o endereo de disco do primeiro bloco. Porm, a principal desvantagem da utilizao desse mtodo que o acesso aleatrio extremamente lento. Alm disso, considerando que cada bloco ter que guardar o endereo do bloco seguinte, existe um gasto de memria adiciona. A alocao por lista encadeada representada atravs da Figura 45.

Figura 45: Implementao de Arquivos por Alocao por Lista Encadeada.

1.2.3. Alocao por Lista Encadeada Usando ndice Uma maneira de tentar driblar as duas desvantagens de se utilizar alocao por lista encadeada seria utilizar a palavra ponteiro de cada bloco de disco de um arquivo e colocar em uma tabela ou em um ndice na memria. Dessa forma, o bloco inteiro no disco estar disponvel para armazenamento de dados (no necessrio armazenar mais o ponteiro para o prximo bloco). Alm disso, o acesso aleatrio muito mais fcil, pois a cadeia de blocos est toda em memria, no sendo necessrio qualquer referncia ao disco. A Figura 46 ilustra a tabela utilizada neste mtodo de alocao para armazenar a sequncia dos blocos do arquivo representado pela lista encadeada da Figura 45.

Figura 46: Implementao de Arquivos por Alocao por Lista Encadeada, utilizando ndice.

1.3. Diretrios Os sistemas de arquivos tm, em geral, diretrios ou pastas para controlar os arquivos, que, em muitos sistemas, tambm so considerados arquivos.

1.3.1. Organizao de Sistemas de Diretrios A maneira mais simples de se projetar um Sistema de Arquivos ter um diretrio contendo todos os arquivos, comumente chamado de diretrio-raiz. Esse sistema era muito comum, em parte, nos primeiros computadores pessoais, pois havia somente um usurio. Porm, em um sistema com vrios usurios o problema de haver somente um diretrio que diferentes usurios podem usar acidentalmente os mesmos nomes para seus arquivos. Em conseqncia disso, esse esquema no mais empregado em sistemas multiusurio, mas,

comumente empregado em sistemas embarcados (embedded Systems). Esse esquema demonstrado na Figura 47.

Figura 47: Projeto de Sistemas de Arquivos com um nvel.

Com a finalidade de evitar conflitos causados por diferentes usurios escolhendo o mesmo nome para seus arquivos, a soluo oferecer um diretrio privado para cada usurio. Dessa forma, os nomes escolhidos por um usurio no interferiria nos nomes escolhidos por outro usurio, podendo ocorrer de arquivos com o mesmo nome em dois ou mais diretrios sem causar nenhum problema. Este esquema est ilustrado na Figura 48.

Figura 48: Projeto de Sistemas de Arquivos com dois nveis.

Os conflitos de nomes entre os usurios so eliminados na hierarquia em dois nveis, mas tal hierarquia no satisfatria para os usurios com um nmero muito grande de arquivos ou que desejam agrupar seus arquivos de maneira lgica. Dessa forma, podemos utilizar uma hierarquia geral, ou seja, uma rvore de diretrios, no qual cada usurio pode ter tantos diretrios quanto necessrios para agrupar os seus arquivos de uma maneira natural. Assim, essa capacidade dos usurios criarem um nmero arbitrrio de subdiretrios constitui uma poderosa ferramenta de estruturao para organizar seus trabalhos. Por esse motivo, quase todos os modernos sistemas de arquivos so organizados dessa forma. A Figura 49 ilustra este tipo de projeto hierrquico.

Figura 49: Projeto de Sistemas de Arquivos hierrquico.

1.3.2. Nomes de Caminhos Quando organizamos um Sistema de arquivos baseado em uma rvore de diretrios, torna-se necessrio uma forma de especificar o nome dos arquivos, e para isso so usados, comumente, dois mtodos: nome de caminho absoluto e nome de caminho relativo.

Um nome de caminho absoluto formado pelo caminho entre o diretrio-raiz e o arquivo especfico. Os nomes de caminhos absolutos sempre iniciam no diretrio-raiz e so nicos. Em Sistemas de Arquivos do Windows os componentes do caminho so separados por \. J em Sistemas de Arquivos do Unix so separados por /. J o nome de caminho relativo utilizado em conjunto com o conceito de diretrio de trabalho (tambm chamado diretrio atual). Assim, um usurio pode designar um diretrio de trabalho especfico e quaisquer nomes de caminhos que no comecem a partir do diretrio-raiz so interpretados em relao ao diretrio do trabalho. Como exemplo, imagine que o diretrio de trabalho de um usurio UNIX seja /home/usurio, ento o arquivo, cujo nome de caminho absoluto seja /home/usurio/arquivo.txt pode, simplesmente, ser interpretado como arquivo.txt. Cada processo possui seu prprio diretrio de trabalho. Dessa forma, quando um processo altera seu diretrio de trabalho e depois sai, nenhum outro processo afetado e nenhum vestgio da mudana deixado no sistema de arquivos. Por outro lado, procedimentos de bibliotecas raramente alteram o diretrio de trabalho e, quando precisam faz-lo, eles sempre voltam para onde estavam, se no o resto do programa poder no funcionar. A maioria dos Sistemas Operacionais que suportam um sistema de diretrio hierrquico tem duas entradas especiais em cada diretrio: ponto (.) e o ponto-ponto (..). O ponto refere-se ao diretrio atual, enquanto que o ponto-ponto refere-se ao diretrio pai (diretrio anterior). Como exemplo, se um usurio tiver trabalhando no diretrio /home/usurio, caso utilize o ponto-ponto, ele estar subindo na rvore de diretrios, ou seja, referenciando o diretrio /home. Se ele utilizar o ponto, estar referenciando o prprio diretrio (/home/usurio).

1.3.3. Operaes com Diretrios Como os arquivos, existem diversas chamadas ao sistema para gerenciar diretrios, que, tambm, variam de sistema para sistema. As operaes mais importantes so: Criar: utilizado para criar um determinado diretrio. Inicialmente criado um diretrio vazio, contendo apenas o ponto e o ponto-ponto. Apagar: operao utilizada para apagar um determinado diretrio. Normalmente, s possvel excluir um diretrio vazio. Abrir diretrio: a partir desta operao possvel abrir um diretrio. Antes de ler um diretrio preciso, inicialmente, abri-lo. Fechar diretrio: operao utilizada para fechar um diretrio. Ler: esta chamada utilizada para ler o contedo de um diretrio. Renomear: fornece a possibilidade de alterar o nome do diretrio.

1.4. Implementao de Diretrios O Sistema Operacional utiliza o nome de caminho fornecido pelo usurio para poder localizar a entrada de diretrio. A entrada de diretrio contm informaes necessrias para a localizao dos blocos de disco. Essas informaes podem ser o endereo do arquivo inteiro ou o nmero do primeiro bloco, por exemplo. Assim, a principal funo do sistema de diretrio mapear o nome ASCII do arquivo para as informaes necessrias para localizar os dados em disco (Tanenbaum).

WEBLIOGRAFIA

Universidade Aberta do Piau UAPI www.ufpi.br/uapi

Universidade Aberta do Brasil UAB www.uab.gov.br

Secretaria de Educao Distncia do MEC - SEED www.seed.mec.gov.br

Associao Brasileira de Educao Distncia ABED www.abed.org.br

Curso de Sistemas Operacionais DCA/UFRN Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira http://www.dca.ufrn.br/~affonso/DCA0108/curso.html

Home Page do Prof. Dr. Rmulo Silva de Oliveira http://www.das.ufsc.br/~romulo/

Home Page do Autor Andrew S. Tanenbaum http://www.cs.vu.nl/~ast/

Simulador de Ensino para Sistemas Operacionais http://www.training.com.br/sosim/ NTFS New Technology File System http://www.ntfs.com/ FAT32 File System Specification http://www.microsoft.com/whdc/system/platform/firmware/fatgen.msp x

Ext2fs Home Page http://e2fsprogs.sourceforge.net/ext2.html

REFERNCIAS BIBLIOGRFICAS

BACON, J. e HARRIS, T. Operating Systems: Concurrent and Distributed Software Design. Addison Wesley, 2003.

DEITELL, H. M. & DEITEL, P. J. & CHOFFNES, D. R. Sistemas Operacionais. So Paulo, Ed. Prentice Hall, 2005.

MACHADO, F. e MAIA, L. Arquitetura de Sistemas Operacionais. 4 Edio, LTC, 2007

OLIVEIRA, R. S. e CARISSIMI, A. S. e TOSCANI, S. S. Sistemas Operacionais. 3 ed, volume 11, Ed. Bookman, 2008.

SHAW, A. C. Sistemas e software de tempo real. Porto Alegre, Ed. Bookman, 2003.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Fundamentos de Sistemas Operacionais. 6 Edio, Ed. LTC.

SILBERSCHATZ, A. & GALVIN, P. B. & GAGNE, G. Sistemas Operacionais com Java. 7 Edio, Rio de Janeiro, Ed. Elsevier, 2008.

TANENBAUM, A. S. & WOODHULL, A. S. Sistemas Operacionais: Projeto e Implementao. 3 Edio, Porto Alegre, Ed. Bookman, 2008.

TANENBAUM, A. S. Sistemas Operacionais Modernos. 2 Edio, So Paulo, Ed. Prentice Hall, 2003.

SOBRE O AUTOR Erico Meneses Leo

Possui Graduao em Bacharelado em Cincia da Computao pela Universidade Federal do Piau, Brasil, em 2005; Mestre em Cincias, pelo Programa de Ps-Graduao em Engenharia Eltrica, com nfase em Engenharia de Computao, da Universidade Federal do Rio Grande do Norte, Brasil, em 2007. Foi professor do curso de Cincia da Computao, do Centro de Ensino Unificado de Teresina CEUT, e do curso de Sistema de Informao, da Faculdade de Atividades Empresariais de Teresina - FAETE. Desde 2008, professor do quadro efetivo, e Assistente do Departamento de Informtica e Estatstica DIE, da Universidade Federal do Piau - UFPI. Seus principais interesses de pesquisa e atuao incluem arquitetura de sistemas distribudos de tempo real, sistemas operacionais, redes de computadores e sistemas de comunicao de tempo real para redes industriais.

Оценить