Sistemas Operacionais

SISTEMAS
OPERACIONAIS
Prof. Me. Cleber Jose Semensate Santos
AUTOR
Prof. Me. Cleber Jose Semensate Santos
Mestre em Desenvolvimento de Tecnologias, Especialista em Programação

Orientada a Objetos e Analista de Sistemas para Internet. Criador do SGA –
Sistema de Gestão de Aprendizes do Instituto INAMARE de Maringá (www.ina-
mare.org.br/sga). Por 10 anos foi Analista de Sistemas do PROE – Programa
de Estágio (www.proe.org.br), vinculado às ACEs – Associações Comerciais e
a FACIAP – Federações das Associações Comerciais do Paraná. Atualmente
é Diretor da CVC Software, empresa dedicada a desenvolvimento de Sistemas
para Internet. Atualmente está como Professor e Coordenador dos Cursos de
TI na modalidade Graduação-EaD da UniFCV.
INFORMAÇÕES RELEVANTES:
• Tecnólogo em Processamento de Dados (UNICESUMAR)

• Especialista em Programação Orientada a Objetos (UNICESUMAR)
• Especialista em Gestão de Projetos Sociais (UNIFCV)
• Mestre em Desenvolvimento de Tecnologias (LACTEC/UFPR)
• Coordenador dos Cursos ADS e GTI EaD
• Proprietário da Empresa CVC Softwares
• Desenvolvimento de Software e MKT Digital
• http://lattes.cnpq.br/7950356175153672
APRESENTAÇÃO DO MATERIAL
SEJA BEM-VINDO(A)!
Olá, esta apostila de Sistemas Operacionais (SO), foi elaborado especialmente

para você conhecer como este Sistema atua, gerencia e facilita a utilização dos
computadores.
A apostila está dividida em quatro unidades. Iremos abordar desde os concei-

tos básicos aos mais atuais como a utilização de máquinas virtuais/virtualiza-
ção.
O objetivo desta apostila não é ensinar como utilizar um SO, mas sim conhecer
os fundamentos que todos os SO’s devem seguir, não importando o fabrican-
te, tipo de licença ou onde ele é usado (em um notebook, celular ou desktop).
Logo na primeira unidade iremos aprender o que é um sistema operacional e
quais deles são mais utilizados.
A segunda unidade é dedicada exclusivamente ao gerenciamento de proces-

sos. Esta unidade será de vital importância para o andamento do curso, pois
iremos detalhar a forma como o SO desempenha uma das suas principais fun-
ções que é facilitar a comunicação do hardware com os programas do usuário.
A terceira unidade consistirá na apresentação do gerenciamento de memória

e dos sistemas de arquivos e com certeza as diferenças entre os SO’s ficarão
mais claras, pois iremos diferenciá-los por meio do detalhamento dos itens des-
ta unidade.
Da unidade II até a unidade IV descreveremos as funcionalidades que todos os

sistemas operacionais devem possuir. Na quarta unidade abordaremos como o
mouse, teclado e outros dispositivos de entrada/saída interagem com o sistema
operacional.
Querido(a) aluno(a), se prepare para esta grande viagem por dentro de um dos
itens mais importantes do computador.
Vamos lá?
SUMÁRIO
UNIDADE I
04 | INTRODUÇÃO AO ESTUDO DE SISTEMAS OPERACIONAIS
UNIDADE II
22 | PROCESSOS
UNIDADE III
42 | GERENCIAMENTO DE MEMÓRIA E SISTEMA DE ARQUIVOS
UNIDADE IV
64 | GERENCIAMENTO DE ENTRADA E SAÍDA E SISTEMAS
DISTRIBUÍDOS
UNIDADE l
INTRODUÇÃO AO ESTUDO DE
SISTEMAS OPERACIONAIS
Professor Mestre Cleber Semensate
Plano de Estudo:
• Conceitos Básicos
• Estrutura de um Sistema Operacional
• Serviços de Sistemas Operacionais
Objetivos de Aprendizagem:
• Apresentar conceitos e tipos de sistemas operacionais.
• Apresentar os sistemas operacionais de maior uso e influência.
SISTEMAS OPERACIONAIS 5
5
INTRODUÇÃO
Olá, caro(a) aluno(a)!
Seja bem-vindo(a) ao estudo dos sistemas operacionais (SO’s). Nesta unidade

iremos abordar as definições, tipos e os principais SO’s de mercado.
Para definirmos sistema operacional (SO), precisamos relembrar as definições

de hardware e software:
Hardware: parte física do computador. É tudo aquilo que pode ser tocado.
Exemplo: teclado, mouse, monitor, gabinete, processador, memória entre ou-
tros.
Software: parte lógica do computador. Ao contrário do hardware, esta parte

não pode ser tocada. Também chamado de programa ou aplicativo.
Exemplo: sistemas operacionais, processadores de textos, arquivos salvos,
planilhas eletrônicas entre outros.
Um computador moderno consiste em um ou mais processadores, uma memó-

ria principal, discos, impressoras, um teclado, um mouse, um monitor, interfa-
ces de rede e vários outros dispositivos de entrada e saída. Como um todo, tra-
ta-se de um sistema complexo. Se todo programador de aplicativos tivesse de
compreender como todas essas partes funcionam em detalhe, nenhum código
jamais seria escrito. Além disso, gerenciar todos esses componentes e usá-los
de maneira otimizada é um trabalho extremamente desafiador.
Por essa razão, computadores são equipados com um dispositivo de softwa-

re chamado de sistema operacional, cuja função é fornecer aos programas do
usuário um modelo do computador melhor, mais simples e mais limpo, assim
como lidar com o gerenciamento de todos os recursos mencionados.
1. Conceitos Básicos
Segundo Tanenbaum (2016), é difícil dizer com absoluta precisão o que é um

sistema operacional, além de ele ser o software que opera em modo núcleo —
e mesmo isso nem sempre é verdade. Parte do problema é que os sistemas
operacionais realizam duas funções essencialmente não relacionadas: fornecer
a programadores de aplicativos (e programas aplicativos, claro) um conjunto de
recursos abstratos limpo em vez de recursos confusos de hardware, e geren-
ciar esses recursos de hardware. Dependendo de quem fala, você poderá ouvir
mais a respeito de uma função do que de outra. Examinemos as duas então.
1.1. O Sistema operacional como uma máquina estendida
De acordo com Tanenbaum (2016), a arquitetura da maioria dos computadores

em nível de linguagem de máquina é primitiva e complicada de programar, es-
pecialmente para entrada/saída. Para deixar esse ponto mais claro, considere
os discos rígidos modernos do tipo SATA (Serial ATA) usados na maioria dos
computadores.
É claro que nenhum programador são iria querer lidar com esse disco em nível
de hardware. Em vez disso, um software, chamado driver de disco, lida com
o hardware e fornece uma interface para ler e escrever blocos de dados, sem
entrar nos detalhes. Sistemas operacionais contêm muitos drivers para contro-
lar dispositivos de E/S. Mas mesmo esse nível é baixo demais para a maioria
dos aplicativos. Por essa razão, todos os sistemas operacionais fornecem mais
um nível de abstração para se utilizarem discos: arquivos. Usando essa abstra-
ção, os programas podem criar, escrever e ler arquivos, sem ter de lidar com
os detalhes complexos de como o hardware realmente funciona. TANENBAUM
(2016).
Essa abstração é a chave para gerenciar toda essa complexidade. Boas abs-
trações transformam uma tarefa praticamente impossível em duas tarefas ge-
renciáveis. A primeira é definir e implementar as abstrações. A segunda é utili-
zá-las para solucionar o problema à mão. Uma abstração que quase todo usuá-
rio de computadores compreende é o arquivo, como mencionado anteriormen-
te. Trata-se de um fragmento de informação útil, como uma foto digital, uma
mensagem de e-mail, música ou página da web salvas. É muito mais fácil lidar
com fotos, e-mails, músicas e páginas da web do que com detalhes de discos
SATA (ou outros). A função dos sistemas operacionais é criar boas abstrações
e então implementar e gerenciar os objetos abstratos criados desse modo.
Neste material, falaremos muito sobre abstrações. Elas são uma das chaves
para compreendermos os sistemas operacionais. Processadores reais, memó-
rias, discos e outros dispositivos são muito complicados e apresentam inter-
faces difíceis, desajeitadas, idiossincráticas e inconsistentes para as pessoas
que têm de escrever softwares para elas utilizarem. Uma das principais tarefas
dos sistemas operacionais é esconder o hardware e em vez disso apresentar
programas (e seus programadores) com abstrações de qualidade, limpas, ele-
gantes e consistentes com as quais trabalhar. TANENBAUM (2016).
Deve ser observado que os clientes reais dos sistemas operacionais são os
programas aplicativos. São eles que lidam diretamente com as abstrações for-
necidas pela interface do usuário, seja uma linha de comandos (shell) ou uma
interface gráfica. Embora as abstrações na interface com o usuário possam ser
similares às abstrações fornecidas pelo sistema operacional, nem sempre esse
é o caso. Para esclarecer esse ponto, considere a área de trabalho normal do
Windows e o prompt de comando orientado a linhas. Ambos são programas
executados no sistema operacional Windows e usam as abstrações que o Win-
dows fornece, mas eles oferecem interfaces de usuário muito diferentes. De
modo similar, um usuário de Linux executando Gnome ou KDE vê uma interfa-
ce muito diferente daquela vista por um usuário Linux trabalhando diretamente
sobre o X Window System, mas as abstrações do sistema operacional subja-
cente são as mesmas em ambos os casos. TANENBAUM (2016).
1.2. O Sistema operacional como uma gerenciador de recur-
sos
Para Tanenbaum (2016), o conceito de um sistema operacional como funda-

mentalmente fornecendo abstrações para programas aplicativos é uma visão
top-down (abstração de cima para baixo). Uma visão alternativa, bottom-up
(abstração de baixo para cima), sustenta que o sistema operacional está ali
para gerenciar todas as partes de um sistema complexo. Computadores mo-
dernos consistem de processadores, memórias, temporizadores, discos, dispo-
sitivos apontadores do tipo mouse, interfaces de rede, impressoras e uma am-
pla gama de outros dispositivos. Na visão bottom-up, a função do sistema ope-
racional é fornecer uma alocação ordenada e controlada dos processadores,
memórias e dispositivos de E/S entre os vários programas competindo por eles.
Sistemas operacionais modernos permitem que múltiplos programas estejam

na memória e sejam executados ao mesmo tempo. Imagine o que acontece-
ria se três programas executados em um determinado computador tentassem
todos imprimir sua saída simultaneamente na mesma impressora. As primeiras
linhas de impressão poderiam ser do programa 1, as seguintes do programa
2, então algumas do programa 3 e assim por diante. O resultado seria o caos
absoluto. O sistema operacional pode trazer ordem para o caos em potencial
armazenando temporariamente toda a saída destinada para a impressora no
disco. Quando um programa é finalizado, o sistema operacional pode então co-
piar a sua saída do arquivo de disco onde ele foi armazenado para a impresso-
ra, enquanto ao mesmo tempo o outro programa pode continuar a gerar mais
saída, alheio ao fato de que a saída não está realmente indo para a impressora
(ainda). TANENBAUM (2016).
Quando um computador tem mais de um usuário, a necessidade de gerenciar e

proteger a memória, dispositivos de E/S e outros recursos é ainda maior, tendo
em vista que os usuários poderiam interferir um com o outro de outra maneira.
Além disso, usuários muitas vezes precisam compartilhar não apenas o har-
dware, mas a informação (arquivos, bancos de dados etc.) também. Resumin-
do, essa visão do sistema operacional sustenta que a sua principal função é
manter um controle sobre quais programas estão usando qual recurso, conce-
der recursos requisitados, contabilizar o seu uso, assim como mediar requisi-
ções conflitantes de diferentes programas e usuários. TANENBAUM (2016).
Tanenbaum (2016), afirma que o gerenciamento de recursos inclui comparti-

lhá-los de duas maneiras diferentes: no tempo e no espaço. Quando um re-
curso é multiplexado no tempo, diferentes programas ou usuários se revezam
usando-o. Primeiro, um deles usa o recurso, então outro e assim por diante.
Por exemplo, com apenas uma CPU e múltiplos programas querendo ser exe-
cutados nela, o sistema operacional primeiro aloca a CPU para um programa,
então, após ele ter sido executado por tempo suficiente, outro programa passa
a fazer uso da CPU, então outro, e finalmente o primeiro de novo. Determinar
como o recurso é multiplexado no tempo — quem vai em seguida e por quanto
tempo — é a tarefa do sistema operacional. Outro exemplo da multiplexação
no tempo é o compartilhamento da impressora. Quando múltiplas saídas de im-
pressão estão na fila para serem impressas em uma única impressora, uma
decisão tem de ser tomada sobre qual deve ser impressa em seguida.
O outro tipo é a multiplexação de espaço. Em vez de os clientes se revezarem,

cada um tem direito a uma parte do recurso. Por exemplo, a memória princi-
pal é normalmente dividida entre vários programas sendo executados, de modo
que cada um pode ser residente ao mesmo tempo (por exemplo, a fim de se
revezar usando a CPU). Presumindo que há memória suficiente para manter
múltiplos programas, é mais eficiente manter vários programas na memória ao
mesmo tempo do que dar a um deles toda ela, especialmente se o programa
precisa apenas de uma pequena fração do total. É claro, isso gera questões de
justiça, proteção e assim por diante, e cabe ao sistema operacional solucioná-
-las. Outro recurso que é multiplexado no espaço é o disco. Em muitos siste-
mas um único disco pode conter arquivos de muitos usuários ao mesmo tempo.
Alocar espaço de disco e controlar quem está usando quais blocos do disco é
uma tarefa típica do sistema operacional. TANENBAUM (2016).
2. Estrutura de um Sistema Operacional
Nas seções a seguir, examinaremos seis estruturas diferentes que foram tenta-
das, a fim de termos alguma ideia do espectro de possibilidades. Isso não quer
dizer que esgotaremos o assunto, mas elas dão uma ideia de alguns projetos
que foram tentados na prática. Os seis projetos apresentados por Tanenbaum
(2016) e que discutiremos aqui são: sistemas monolíticos, sistemas de cama-
das, micronúcleos, sistemas cliente-servidor, máquinas virtuais e exonúcleos.
2.1. Sistemas monolíticos
Nas palavras de Tanenbaum (2016), de longe a organização mais comum, na

abordagem monolítica todo o sistema operacional é executado como um único
programa em modo núcleo. O sistema operacional é escrito como uma coleção
de rotinas, ligadas a um único grande programa binário executável. Quando a
técnica é usada, cada procedimento no sistema é livre para chamar qualquer
outro, se este oferecer alguma computação útil de que o primeiro precisa. Ser
capaz de chamar qualquer procedimento que você quer é muito eficiente, mas
ter milhares de procedimentos que podem chamar um ao outro sem restrições
pode também levar a um sistema difícil de lidar e compreender. Também, uma
quebra em qualquer uma dessas rotinas derrubará todo o sistema operacional.
2.2. Sistemas de camadas
Como aponta Tanenbaum (2016), uma generalização da abordagem da Figura

1.1 é organizar o sistema operacional como uma hierarquia de camadas, cada
uma construída sobre a camada abaixo dela.
Figura 1.1 Um modelo de estruturação simples para um sistema monolítico.

Fonte: Elaborado pelo autor.
O primeiro sistema construído dessa maneira foi o sistema THE desenvolvido

na Technische Hogeschool Eindhoven na Holanda por E. W. Dijkstra (1968) e
seus estudantes. O sistema THE era um sistema em lote simples para um com-
putador holandês, o Electrologica X8, que tinha 32 K de palavras de 27 bits.
Outra generalização do conceito de camadas estava presente no sistema MUL-

TICS. Em vez de camadas, MULTICS foi descrito como tendo uma série de
anéis concêntricos, com os anéis internos sendo mais privilegiados do que os
externos (o que é efetivamente a mesma coisa). Quando um procedimento em
um anel exterior queria chamar um procedimento em um anel interior, ele ti-
nha de fazer o equivalente de uma chamada de sistema, isto é, uma instrução
de desvio, TRAP, cujos parâmetros eram cuidadosamente conferidos por sua
validade antes de a chamada ter permissão para prosseguir. Embora todo o
sistema operacional fosse parte do espaço de endereço de cada processo de
usuário em MULTICS, o hardware tornou possível que se designassem rotinas
individuais (segmentos de memória, na realidade) como protegidos contra leitu-
ra, escrita ou execução. TANENBAUM (2016).
2.3. Micronúcleos
De acordo com Tanenbaum (2016), a ideia básica por trás do projeto de micro-
núcleo é atingir uma alta confiabilidade através da divisão do sistema operacio-
nal em módulos pequenos e bem definidos, apenas um dos quais — o micro-
núcleo — é executado em modo núcleo e o resto é executado como proces-
sos de usuário comuns relativamente sem poder. Em particular, ao se executar
cada driver de dispositivo e sistema de arquivos como um processo de usuário
em separado, um erro em um deles pode derrubar esse componente, mas não
consegue derrubar o sistema inteiro. Desse modo, um erro no driver de áudio
fará que o som fique truncado ou pare, mas não derrubará o computador.
Em comparação, em um sistema monolítico, com todos os drivers no núcleo,

um driver de áudio com problemas pode facilmente referenciar um endereço de
memória inválido e provocar uma parada dolorosa no sistema instantaneamen-
te. TANENBAUM (2016).
O sistema tem muitas restrições limitando o poder de cada processo. Como

mencionado, os drivers podem tocar apenas portas de E/S autorizadas, mas o
acesso às chamadas de núcleo também é controlado processo a processo, as-
sim como a capacidade de enviar mensagens para outros processos. Proces-
sos também podem conceder uma permissão limitada para outros processos
para que o núcleo acesse seus espaços de endereçamento. Como exemplo,
um sistema de arquivos pode conceder uma permissão para que a unidade de
disco deixe o núcleo colocar uma leitura recente de um bloco do disco em um
endereço específico dentro do espaço de endereço do sistema de arquivos. A
soma de todas essas restrições é que cada driver e servidor têm exatamente
o poder de fazer o seu trabalho e nada mais, dessa maneira limitando muito o
dano que um componente com erro pode provocar. TANENBAUM (2016).
2.4. O modelo cliente-servidor
Para Tanenbaum (2016), uma ligeira variação da ideia do micronúcleo é distin-

guir duas classes de processos, os servidores, que prestam algum serviço, e
os clientes, que usam esses serviços. Esse modelo é conhecido como o mo-
delo cliente-servidor. Muitas vezes, a camada mais baixa é a do micronúcleo,
mas isso não é necessário. A essência encontra-se na presença de processos
clientes e processos servidores.
A comunicação entre clientes e servidores é realizada muitas vezes pela tro-

ca de mensagens. Para obter um serviço, um processo cliente constrói uma
mensagem dizendo o que ele quer e a envia ao serviço apropriado. O serviço
então realiza o trabalho e envia de volta a resposta. Se acontecer de o cliente
e o servidor serem executados na mesma máquina, determinadas otimizações
são possíveis, mas conceitualmente, ainda estamos falando da troca de men-
sagens aqui. TANENBAUM (2016).
Uma generalização óbvia dessa ideia é ter os clientes e servidores sendo exe-
cutados em computadores diferentes, conectados por uma rede local ou de
grande área, como descrito na Figura 1.2. Tendo em vista que os clientes co-
municam-se com os servidores enviando mensagens, os clientes não precisam
saber se as mensagens são entregues localmente em suas próprias máquinas,
ou se são enviadas através de uma rede para servidores em uma máquina re-
mota. No que diz respeito ao cliente, a mesma coisa acontece em ambos os
casos: pedidos são enviados e as respostas retornadas. Desse modo, o mode-
lo cliente-servidor é uma abstração que pode ser usada para uma única máqui-
na ou para uma rede de máquinas. TANENBAUM (2016).
Cada vez mais, muitos sistemas envolvem usuários em seus PCs em casa
como clientes e grandes máquinas em outra parte operando como servidores.
Na realidade, grande parte da web opera dessa maneira. Um PC pede uma
página na web para um servidor e ele a entrega. Esse é o uso típico do modelo
cliente-servidor em uma rede. TANENBAUM (2016).
Figura 1.2 O modelo cliente-servidor em uma rede.

Fonte: Elaborado pelo autor.
2.5. Máquinas virtuais
Os lançamentos iniciais do OS/360 foram estritamente sistemas em lote. Não

obstante isso, muitos usuários do 360 queriam poder trabalhar interativamen-
te em um terminal, de maneira que vários grupos, tanto dentro quanto fora da
IBM, decidiram escrever sistemas de compartilhamento de tempo para ele. O
sistema de compartilhamento de tempo oficial da IBM, TSS/360, foi lançado tar-
de, e quando enfim chegou, era tão grande e lento que poucos converteram-se
a ele. Ele foi finalmente abandonado após o desenvolvimento ter consumido
algo em torno de US$ 50 milhões (GRAHAM,1970). Mas um grupo no Centro
Científico da IBM em Cambridge, Massachusetts, produziu um sistema radical-
mente diferente que a IBM por fim aceitou como produto. Um descendente li-
near, chamado z/VM, é hoje amplamente usado nos computadores de grande
porte da IBM, os zSeries, que são intensamente usados em grandes centros de
processamento de dados corporativos, por exemplo, como servidores de co-
mércio eletrônico que lidam com centenas ou milhares de transações por se-
gundo e usam bancos de dados cujos tamanhos chegam a milhões de gigaby-
tes. TANENBAUM (2016).
2.6. Exonúcleos
Como aponta Tanenbaum (2016), em vez de clonar a máquina real, como é fei-
to com as máquinas virtuais, outra estratégia é dividi-la, ou em outras palavras,
dar a cada usuário um subconjunto dos recursos. Desse modo, uma máquina
virtual pode obter os blocos de disco de 0 a 1.023, a próxima pode ficar com os
blocos 1.024 a 2.047 e assim por diante.
Na camada de baixo, executando em modo núcleo, há um programa chamado

exonúcleo (ENGLER et al., 1995). Sua tarefa é alocar recursos às máquinas
virtuais e então conferir tentativas de usá-las para assegurar-se de que nenhu-
ma máquina esteja tentando usar os recursos de outra pessoa. Cada máqui-
na virtual no nível do usuário pode executar seu próprio sistema operacional,
como na VM/370 e no modo virtual 8086 do Pentium, exceto que cada uma
está restrita a usar apenas os recursos que ela pediu e foram alocados.
A vantagem do esquema do exonúcleo é que ele poupa uma camada de ma-

peamento. Nos outros projetos, cada máquina virtual pensa que ela tem seu
próprio disco, com blocos sendo executados de 0 a algum máximo, de maneira
que o monitor da máquina virtual tem de manter tabelas para remapear os en-
dereços de discos (e todos os outros recursos). Com o exonúcleo, esse rema-
peamento não é necessário. O exonúcleo precisa apenas manter o registro de
para qual máquina virtual foi atribuído qual recurso. Esse método ainda tem a
vantagem de separar a multiprogramação (no exonúcleo) do código do sistema
operacional do usuário (em espaço do usuário), mas com menos sobrecarga,
tendo em vista que tudo o que o exonúcleo precisa fazer é manter as máquinas
virtuais distantes umas das outras. TANENBAUM (2016).
3. Serviços de Sistemas Operacionais
De acordo com Tanenbaum (2016), o sistema operacional é formado por um

conjunto de rotinas (procedimentos) que oferecem serviços aos usuários do
sistema e suas aplicações, bem como outras rotinas do próprio sistema. Esse
conjunto de rotinas é chamado núcleo do sistema ou Kernel. O sistema opera-
cional é um prestador de serviços ao usuário. As principais funções do núcleo
são:
3.1. Execução de programas
O sistema operacional é o responsável pelo carregamento dos programas na

memória principal da máquina e executá-los. O programa é o responsável pelo
término de sua própria execução.
3.2. Operações de entrada e saída
Como aponta Tanenbaum (2016), durante a sua execução, um programa pode

ter necessidade de se comunicar com meios externos à máquina. Esta opera-
ção recebe o nome de entrada/saída (E/S) - input/output (I/O) e pode envolver
qualquer dispositivo de E/S (monitor, teclado). Como um programa não pode
executar estas operações diretamente, o sistema operacional é o responsável
por fornecer meios adequados para isso.
3.3. Gerência do sistema de arquivos
Segundo Tanenbaum (2016), os usuários de uma máquina têm necessidade de

realizar acessos aos arquivos pelo nome para saber se eles existem, para apa-
gá-los ou até para renomeá-los. Um programa em execução necessita realizar
a leitura ou escrita de um arquivo qualquer. O sistema operacional é o respon-
sável por gerenciar o sistema de arquivos da máquina. Este gerenciamento in-
clui a alocação de espaço no dispositivo de armazenamento (disco rígido), a
busca otimizada a um determinado arquivo e o armazenamento de todas as
informações necessárias sobre cada arquivo.
3.4. Detecção de erros
De acordo com Tanenbaum (2016), o sistema operacional é o responsável por

detectar erros possíveis que podem comprometer a execução de qualquer pro-
grama e a segurança da máquina. Esses erros podem envolver o próprio pro-
cessador, a memória principal (acesso a uma área proibida), os dispositivos
de entrada/saída (falta de papel na impressora), ou até mesmo o programa do
usuário (uma divisão por zero). Para cada tipo de erro, o sistema operacional
tem uma ação apropriada para garantir a exatidão e a consistência do processo
de execução.
3.5. Alocação de recursos
Tanenbaum (2016), afirma que o sistema operacional é o responsável pela alo-

cação dos diversos recursos em sistemas com um ou mais usuários. Tais re-
cursos incluem a memória principal, o próprio processador (CPU), arquivos e
os dispositivos de I/O. A alocação deve ser feita da forma mais eficiente possí-
vel para não prejudicar o desempenho do sistema.
3.6. Contabilização e segurança do sistema
De acordo com Tanenbaum (2016), o sistema operacional é o responsável pela

proteção a todo o sistema computacional. Essa proteção se torna necessária
tanto em sistemas monousuários quanto em sistemas multiusuários. A única di-
ferença é a sua complexidade. Quando vários usuários (sistema multiusuário)
estão usando o sistema, a execução de um programa não pode interferir na
execução de outro. Além disso, o próprio sistema operacional deve ser protegi-
do de erros cometidos pelos usuários.
SAIBA MAIS
Conheça um pouco mais sobre o Sistema Operacional QNX, desenvolvido

pela empresa canadense Research In Motion Limited (RIM).
<http://www.qnx.com/>.
Conheça os integrantes do consórcio de empresas que colaboram com o

desenvolvimento do SO Android. Este grupo é chamado OHA.
<http://www.openhandsetalliance.com/oha_members.html>.
REFLITA
Imagine como seria o desenvolvimento de programas se não existissem os sis-

temas operacionais?
Sem dúvida nenhuma seria um pouco mais demorado, tendo em vista que a
cada nova implementação, necessitaria de uma nova a programação e reconfi-
guração dos dispositivos/hardwares a serem utilizados.
CONSIDERAÇÕES FINAIS
Entender estes conceitos básicos e globais de sistemas operacionais é funda-

mental para a continuação das unidades que vem a seguir.
Conseguir entender os conceitos que serão passados nas unidades seguintes

e realizar uma analogia com as gerações de computadores e tipos de sistemas
operacionais será de suma importância para o entendimento dos itens a serem
apresentados.
A partir da unidade seguinte entraremos mais a fundo no conhecimento dos sis-

temas operacionais, não importando qual versão ou fabricante tenha desenvol-
vido.
Se prepare para conhecermos mais a fundo os conceitos sobre os sistemas

operacionais, sobre processos e a comunicação entre eles.
MATERIAL COMPLEMENTAR
LIVRO
• Título: Sistemas Operacionais Modernos

• Autor: Andrew S. Tanenbaum
• Editora: Person
• Sinopse: A 4ª edição de Sistemas operacionais modernos foi extensamente
revisada e atualizada para incorporar os últimos desenvolvimentos em tec-
nologias de sistemas operacionais. Além de tratar do sistema UNIX, o livro
traz como novidade a abordagem do Windows 8 e 8.1, assim como um foco
maior em Linux e a introdução da plataforma Android.
FILME/VÍDEO
• Título: Pirates of Silicon Valley

• Ano: 1999
• Sinopse: Pirates of Silicon Valley (Piratas da Informática BRA ou Piratas do
Vale do Silício PRT)[1][2][3][4] é um filme feito para a televisão, pela TNT,
escrito e dirigido por Martyn Burke. Baseado no livro Fire in the Valley: The
Making of The Personal Computer, de Paul Freiberger e Michael Swaine, o
filme oferece uma versão dramatizada do nascimento da era da informáti-
ca doméstica, desde o primeiro PC, através da histórica rivalidade entre a
Apple Inc. e seu Macintosh e a Microsoft, indo desde o Altair 8800 da em-
presa MITS, passando pelo MS-DOS, pelo IBM PC e terminando no Micro-
soft Windows.
• Link: <https://www.youtube.com/watch?v=exe1fRcW8X8>
REFERÊNCIAS
ENGLER, D. R.; KAASHOEK, M. F.; O’TOOLE JR., J.; ENGLER, D. R.; KAAS-
HOEK, M. F.; O’TOOLE JR. Exokernel: an operating system architecture
for application-level resource management, Exokernel: an operating sys-
tem architecture for application-level resource management. ACM SIGOPS
Operating Systems Review, (3 de dezembro de 1995)
GRAHAM, R. Use of high-level languages for system programming. Project

MAC Report TM-13, MIT, set. 1970.
TANENBAUM, A.; BOS, H. Sistemas operacionais modernos. 4. ed. [S.l.]:

Prentice-Hall do Brasil, 2016.
UNIDADE ll
PROCESSOS
Plano de Estudo:
• Definição de processos e threads
• Comunicação entre processos
• Escalonamento de processos
• Impasse I Deadlock
• Mostrar ao aluno definições de processos, bem como as técnicas que o sis-
tema operacional se faz uso para garantir rapidez e confiabilidade no que foi
requerido pelo usuário.
• Apontar as situações de conflitos possíveis entre processos e o comporta-
mento do sistema operacional com estes impasses.
22
INTRODUÇÃO
INTRODUÇÃO
Prezado(a) estudante, nesta unidade vamos estudar, de forma mais aprofunda-

da, a estrutura de um sistema operacional, que consiste em:
• Gerência do processador/processos.
• Gerência de dispositivos.
• Gerência de memória.
• Gerência de proteção.
• Gerência de arquivos.
Nesta Unidade II, vamos trabalhar exclusivamente Gerência do processador/

processos e suas definições.
A maioria de nós ao utilizamos os computadores pessoais, temos o costume

de realizar diversas atividades ao mesmo tempo. Podemos trazer aqui clássico
exemplo de navegar na internet, ouvindo uma música e nos conversando com
amigos por meio das redes sociais. Cada um destes comportamentos corres-
ponde a um processo que é gerenciado pelo Sistema Operacional - SO. É fun-
ção do SO prover processos que funcionem sem travamentos e demora. Além
dos processos, no computador existem diversos outros processos que são exe-
cutados de tempo em tempo, como por exemplo, o acionamento de um anti-
vírus, que é executada sem intervenção humana. A maneira e velocidade que
este processamento ocorre é muito rápida e temos a falsa sensação que tudo
está sendo executado todos juntos.
Assim sendo, vamos explorar estas definições de processos e os detalhes de

como o Sistema Operacional executa todos estes processos.
PROCESSOS
O conceito mais central em qualquer sistema operacional é o processo: uma

abstração de um programa em execução. Tudo o mais depende desse concei-
to, e o projetista do sistema operacional deve ter uma compreensão profunda
do que é um processo o mais cedo possível. Processos são uma das mais an-
tigas e importantes abstrações que os sistemas operacionais proporcionam.
Eles dão suporte à possibilidade de haver operações (pseudo) concorrentes
mesmo quando há apenas uma CPU disponível, transformando uma única
CPU em múltiplas CPUs virtuais. Sem a abstração de processo, a computação
moderna não poderia existir.
1. Conceito de Processo
De acordo com Tanenbaum (2016), todos os computadores modernos frequen-

temente realizam várias tarefas ao mesmo tempo. Considere um servidor da
web, em que solicitações de páginas da web chegam de toda parte. Quando
uma solicitação chega, o servidor confere para ver se a página requisitada está
em cache. Se estiver, ela é enviada de volta; se não, uma solicitação de aces-
so ao disco é iniciada para buscá-la. No entanto, do ponto de vista da CPU, as
solicitações de acesso ao disco levam uma eternidade. Enquanto espera que
uma solicitação de acesso ao disco seja concluída, muitas outras solicitações
podem chegar. Se há múltiplos discos presentes, algumas ou todas as solicita-
ções mais recentes podem ser enviadas para os outros discos muito antes de
a primeira solicitação ter sido concluída. Está claro que algum método é neces-
sário para modelar e controlar essa concorrência. Processos (e especialmente
threads) podem ajudar nisso.
Agora considere um PC de usuário. Quando o sistema é inicializado, muitos
processos são secretamente iniciados, quase sempre desconhecidos para
o usuário. Por exemplo, um processo pode ser inicializado para esperar pela
chegada de e-mails. Outro pode ser executado em prol do programa antivírus
para conferir periodicamente se há novas definições de vírus disponíveis. Além
disso, processos explícitos de usuários podem ser executados, imprimindo ar-
quivos e salvando as fotos do usuário em um pen- drive, tudo isso enquanto o
usuário está navegando na Web. Toda essa atividade tem de ser gerenciada, e
um sistema de multiprogramação que dê suporte a múltiplos processos é muito
útil nesse caso. TANENBAUM (2016).
Em qualquer sistema de multiprogramação, a CPU muda de um processo para

outro rapidamente, executando cada um por dezenas ou centenas de milis-
segundos. Enquanto, estritamente falando, em qualquer dado instante a CPU
está executando apenas um processo, no curso de 1s ela pode trabalhar em
vários deles, dando a ilusão do paralelismo. Às vezes, as pessoas falam em
pseudo paralelismo neste contexto, para diferenciar do verdadeiro paralelismo
de hardware dos sistemas multiprocessadores (que têm duas ou mais CPUs
compartilhando a mesma memória física). Ter controle sobre múltiplas ativida-
des em paralelo é algo difícil para as pessoas realizarem. Portanto, projetistas
de sistemas operacionais através dos anos desenvolveram um modelo concei-
tual (processos sequenciais) que torna o paralelismo algo mais fácil de lidar.
TANENBAUM (2016).
2. Estados de um Processo
Tanenbaum (2016), afirma que embora cada processo seja uma entidade in-
dependente, com seu próprio contador de programa e estado interno, proces-
sos muitas vezes precisam interagir entre si. Um processo pode gerar alguma
saída que outro processo usa como entrada. No comando shell “cat chapter1
chapter2 chapter3.
| grep tree” o primeiro processo, executando cat, gera como saída a concatena-
ção dos três arquivos. O segundo processo, executando grep, seleciona todas
as linhas contendo a palavra “tree”. Dependendo das velocidades relativas dos
dois processos (que dependem tanto da complexidade relativa dos programas,
quanto do tempo de CPU que cada um teve), pode acontecer que grep esteja
pronto para ser executado, mas não haja entrada esperando por ele. Ele deve
então ser bloqueado até que alguma entrada esteja disponível. TANENBAUM
(2016).
De acordo com Tanenbaum (2016), quando um processo bloqueia, ele o faz
porque logicamente não pode continuar, em geral porque está esperando pela
entrada que ainda não está disponível. Também é possível que um processo
que esteja conceitualmente pronto e capaz de executar seja bloqueado porque
o sistema operacional decidiu alocar a CPU para outro processo por um tempo.
Essas duas condições são completamente diferentes. No primeiro caso, a sus-
pensão é inerente ao problema (você não pode processar a linha de comando
do usuário até que ela tenha sido digitada). No segundo caso, trata-se de uma
tecnicalidade do sistema (não há CPUs suficientes para dar a cada processo
seu próprio processador privado). Na Figura 2.1 vemos um diagrama de estado
mostrando os três estados nos quais um processo pode se encontrar:
Figura 2.1 Estados de um processo.

Fonte: Elaborado pelo Autor.
1. Em execução (realmente usando a CPU naquele instante).

2. Pronto (executável, temporariamente parado para deixar outro processo ser
executado).
3. Bloqueado (incapaz de ser executado até que algum evento externo aconte-
ça).
Os primeiros dois estados são similares. Em ambos os casos, o processo está

disposto a ser executado, apenas no segundo temporariamente não há uma
CPU disponível para ele. O terceiro estado é fundamentalmente diferente dos
dois primeiros, pois o processo não pode ser executado, mesmo que a CPU
esteja ociosa e não tenha nada mais a fazer. Quatro transições são possíveis
entre esses três estados. A transição 1 ocorre quando o sistema operacional
descobre que um processo não pode continuar agora. Em alguns sistemas o
processo pode executar uma chamada de sistema, como em pause, para en-
trar em um estado bloqueado. Em outros, incluindo UNIX, quando um proces-
so lê de um pipe ou de um arquivo especial (por exemplo, um terminal) e não
há uma entrada disponível, o processo é automaticamente bloqueado. TA-
NENBAUM (2016).
As transições 2 e 3 são causadas pelo escalonador de processos, uma parte
do sistema operacional, sem o processo nem saber a respeito delas. A transi-
ção 2 ocorre quando o escalonador decide que o processo em andamento foi
executado por tempo suficiente, e é o momento de deixar outro processo ter
algum tempo de CPU. A transição 3 ocorre quando todos os outros processos
tiveram sua parcela justa e está na hora de o primeiro processo chegar à CPU
para ser executado novamente. O escalonamento, isto é, decidir qual processo
deve ser executado, quando e por quanto tempo, é um assunto importante que
será melhor abordados adiante. Muitos algoritmos foram desenvolvidos para
tentar equilibrar as demandas concorrentes de eficiência para o sistema como
um todo e justiça para os processos individuais. A transição 4 verifica quando o
evento externo pelo qual um processo estava esperando (como a chegada de
alguma entrada) acontece. Se nenhum outro processo estiver sendo executado
naquele instante, a transição 3 será desencadeada e o processo começará a
ser executado. Caso contrário, ele talvez tenha de esperar no estado de pronto
por um intervalo curto até que a CPU esteja disponível e chegue sua vez. TA-
NENBAUM (2016).
3. Escalonamento de Processos
Para Tanenbaum (2016), quando um computador é multiprogramado, ele fre-

quentemente tem múltiplos processos ou threads competindo pela CPU ao
mesmo tempo. Essa situação ocorre sempre que dois ou mais deles estão si-
multaneamente no estado pronto. Se apenas uma CPU está disponível, uma
escolha precisa ser feita sobre qual processo será executado em seguida. A
parte do sistema operacional que faz a escolha é chamada de escalonador, e o
algoritmo que ele usa é chamado de algoritmo de escalonamento.
Muitas das mesmas questões que se aplicam ao escalonamento de processos

também se aplicam ao escalonamento de threads, embora algumas sejam dife-
rentes. Quando o núcleo gerencia threads, o escalonamento é geralmente feito
por thread, com pouca ou nenhuma consideração sobre o processo ao qual o
thread pertence. TANENBAUM (2016).
Nos velhos tempos dos sistemas em lote com a entrada na forma de imagens
de cartões em uma fita magnética, o algoritmo de escalonamento era simples:
apenas execute o próximo trabalho na fita. Com os sistemas de multiprograma-
ção, ele tornou-se mais complexo porque geralmente havia múltiplos usuários
esperando pelo serviço. Como o tempo de CPU é um recurso escasso nessas
máquinas, um bom escalonador pode fazer uma grande diferença no desempe-
nho percebido e satisfação do usuário. Em consequência, uma grande quanti-
dade de trabalho foi dedicada ao desenvolvimento de algoritmos de escalona-
mento inteligentes e eficientes. TANENBAUM (2016).
Com o advento dos computadores pessoais, a situação mudou de duas manei-
ras. Primeiro, na maior parte do tempo há apenas um processo ativo. É impro-
vável que um usuário preparando um documento em um processador de texto
esteja simultaneamente compilando um programa em segundo plano. Quando
o usuário digita um comando ao processador de texto, o escalonador não preci-
sa fazer muito esforço para descobrir qual processo executar — o processador
de texto é o único candidato. TANENBAUM (2016).
Segundo, computadores tornaram-se tão rápidos com o passar dos anos que
a CPU dificilmente ainda é um recurso escasso. A maioria dos programas para
computadores pessoais é limitada pela taxa na qual o usuário pode apresentar
a entrada (digitando ou clicando), não pela taxa na qual a CPU pode processá-
-la. Mesmo as compilações, um importante sorvedouro de ciclos
de CPUs no passado, levam apenas alguns segundos hoje. Mesmo quando

dois programas estão de fato sendo executados ao mesmo tempo, como um
processador de texto e uma planilha, dificilmente importa qual deles vai primei-
ro, pois o usuário provavelmente está esperando que ambos terminem. Como
consequência, o escalonamento não importa muito em PCs simples. É claro
que há aplicações que praticamente devoram a CPU viva. Por exemplo, repro-
duzir uma hora de vídeo de alta resolução enquanto se ajustam as cores em
cada um dos 107.892 quadros (em NTSC) ou 90.000 quadros (em PAL) exige
uma potência computacional de nível industrial. No entanto, aplicações simila-
res são a exceção em vez de a regra. TANENBAUM (2016).
Quando voltamos aos servidores em rede, a situação muda consideravelmente.

Aqui, múltiplos processos muitas vezes competem pela CPU, de maneira que
o escalonamento importa outra vez. Por exemplo, quando a CPU tem de esco-
lher entre executar um processo que reúne as estatísticas diárias e um que ser-
ve a solicitações de usuários, estes ficarão muito mais contentes se o segundo
receber a primeira chance de acessar a CPU. TANENBAUM (2016).
Além de escolher o processo certo a ser executado, o escalonador também

tem de se preocupar em fazer um uso eficiente da CPU, pois o chaveamento
de processos é algo caro. Para começo de conversa, uma troca do modo usuá-
rio para o modo núcleo precisa ocorrer. Então o estado do processo atual pre-
cisa ser salvo, incluindo armazenar os seus registros na tabela de processos
para que eles possam ser recarregados mais tarde. TANENBAUM (2016).
Em alguns sistemas, o mapa de memória precisa ser salvo da mesma manei-

ra. Em seguida, um novo processo precisa ser selecionado executando o algo-
ritmo de escalonamento. Após isso, a unidade de gerenciamento de memória
precisa ser recarregada com o mapa de memória do novo processo. Por fim,
o novo processo precisa ser inicializado. Além de tudo isso, a troca de proces-
so pode invalidar o cache de memória e as tabelas relacionadas, forçando-o
a ser dinamicamente recarregado da memória principal duas vezes (ao entrar
no núcleo e ao deixá-lo). De modo geral, realizar muitas trocas de processos
por segundo pode consumir um montante substancial do tempo da CPU. TA-
NENBAUM (2016).
4. Comunicação de Processos
Segundo Tanenbaum (2016), processos quase sempre precisam comunicar-se

com outros processos. Há três questões aqui. A primeira, como um processo
pode passar informações para outro. A segunda tem a ver com certificar-se de
que dois ou mais processos não se atrapalhem, por exemplo, dois processos
em um sistema de reserva de uma companhia aérea cada um tentando ficar
com o último assento em um avião para um cliente diferente. A terceira diz res-
peito ao sequenciamento adequado quando dependências estão presentes: se
o processo A produz dados e o processo B os imprime, B tem de esperar até
que A tenha produzido alguns dados antes de começar a imprimir.
Em alguns sistemas operacionais, processos que estão trabalhando juntos po-

dem compartilhar de alguma memória comum que cada um pode ler e escre-
ver. A memória compartilhada pode encontrar-se na memória principal (possi-
velmente em uma estrutura de dados de núcleo) ou ser um arquivo comparti-
lhado; o local da memória compartilhada não muda a natureza da comunicação
ou os problemas que surgem. Para ver como a comunicação entre processos
funciona na prática, vamos considerar um exemplo simples, mas comum: um
spool de impressão. Quando um processo quer imprimir um arquivo, ele entra
com o nome do arquivo em um diretório de spool especial. Outro processo, o
daemon de impressão, confere periodicamente para ver se há quaisquer arqui-
vos a serem impressos, e se houver, ele os imprime e então remove seus no-
mes do diretório. TANENBAUM (2016).
Às vezes é necessário manter um recurso de maneira exclusiva para impedir

que outros processos tenham acesso ao mesmo simultaneamente. Em um sis-
tema operacional multitarefa, a execução de processos de maneira intercala-
da ou paralela pode ocasionar situações imprevisíveis. Quando existe intera-
ção com o usuário e esta é a responsável pelo acesso e uso do recurso, fica
mais difícil para um projetista de SO’s predizer quando o processo irá aces-
sar o recurso. Além disso, quando são considerados sistemas multipro-
cessadores, dois processos executando em paralelo poderiam acessar um re-
curso simultaneamente. Com todos estes fatores, um método garantido para
impedir que dois processos acessem um recurso crítico faz-se necessário. TA-
NENBAUM (2016).
A solução teórica para o problema do recurso crítico é simples: antes de entrar
na região crítica de código, aquela em que o recurso é manipulado, o recur-
so é tornado indisponível (“locked”). Indisponibilizando o recurso, nenhum outro
processo pode entrar na sua região crítica. Uma vez que o processo acabe de
ter sua região crítica executada, o mesmo disponibiliza (“unlocked”) o recurso,
de forma que outros processos possam ter acesso. Um processo desejando
acessar o recurso compartilhado necessita apenas verificar a disponibilidade
do mesmo antes de ter sua região crítica executada. TANENBAUM (2016).
1.1. Exclusão mútua
Segundo Tanenbaum (2016), exclusão mútua é o princípio de que só um pro-

cesso tem acesso à região crítica em um dado momento. Sempre que um pro-
cesso está entre a fase de fazer o teste e a de indisponibilizar o recurso, há
uma chance da exclusão mútua ser violada. Então, devem ser executados o
teste e a indisponibilização em uma única e atômica operação. Uma operação
atômica é aquela que é inteiramente completada antes que um processo perca
a CPU. Implementando uma operação teste-e-atribua de forma atômica em sof-
tware é uma tarefa difícil. Até existem algoritmos para isto, mas são grandes e
lentos. Uma operação teste-e-atribua atômica é tipicamente implementada ou
por uma instrução de processador de máquina (test_and_set) ou pelo núcleo
do sistema operacional, que usa operadores de hardware. O sistema operacio-
nal pode controlar o escalonamento de um processo e pode garantir então que
este não seja interrompido.
1.2. Semáforos
Como aponta Tanenbaum (2016), em 1965, E. W. Dijkstra sugeriu um novo tipo

de variável, que ele chamava de semáforo. Semáforos são mecanismos que
resolvem o problema de exclusão mútua. Dijkstra propôs ter duas operações
nos semáforos, hoje normalmente chamadas de down e up (generalizações de
sleep e wakeup, respectivamente). A operação down em um semáforo confere
para ver se o valor é maior do que 0. Se for, ele decrementará o valor (isto é,
gasta um sinal de acordar armazenado) e apenas continua. Se o valor for 0,
o processo é colocado para dormir sem completar o down para o momento.
Conferir o valor, modificá-lo e possivelmente dormir são feitos como uma única
ação atômica indivisível. É garantido que uma vez que a operação de semáfo-
ro tenha começado, nenhum outro processo pode acessar o semáforo até que
a operação tenha sido concluída ou bloqueada. Essa atomicidade é absoluta-
mente essencial para solucionar problemas de sincronização e evitar condições
de corrida. Ações atômicas, nas quais um grupo de operações relacionadas
são todas realizadas sem interrupção ou não são executadas em absoluto, são
extremamente importantes em muitas outras áreas da ciência de computação
também.
A operação up incrementa o valor de um determinado semáforo. Se um ou

mais processos estiverem dormindo naquele semáforo, incapaz de completar
uma operação down anterior, um deles é escolhido pelo sistema (por exemplo,
ao acaso) e é autorizado a completar seu down. Desse modo, após um up com
processos dormindo em um semáforo, ele ainda estará em 0, mas haverá me-
nos processos dormindo nele. A operação de incrementar o semáforo e desper-
tar um processo também é indivisível. Nenhum processo é bloqueado realizan-
do um up, assim como nenhum processo é bloqueado realizando um wakeup
no modelo anterior. TANENBAUM (2016).
Semáforos são implementados no sistema operacional e são considerados

uma forma de comunicação entre processos (semáforos também podem ser
usados para sincronização tão bem como para obtenção de exclusão mútua).
Da mesma maneira que SO’s diferentes implementam versões diferentes de
memória compartilhada e filas de mensagens, há várias implementações de se-
máforos. TANENBAUM (2016).
1.3. Monitores
Para facilitar a escrita de programas corretos, Brinch Hansen (1973) e Hoare

(1974) propuseram uma primitiva de sincronização de nível mais alto chamada
monitor. Um monitor é uma coleção de rotinas, variáveis e estruturas de dados
que são reunidas em um tipo especial de módulo ou pacote. Processos podem
chamar as rotinas em um monitor sempre que eles quiserem, mas eles não po-
dem acessar diretamente as estruturas de dados internos do monitor a partir de
rotinas declaradas fora dele.
Os monitores têm uma propriedade importante que os torna úteis para realizar
a exclusão mútua: apenas um processo pode estar ativo em um monitor em
qualquer dado instante. Monitores são uma construção da linguagem de pro-
gramação, então o compilador sabe que eles são especiais e podem lidar com
chamadas para rotinas de monitor diferentemente de outras chamadas de roti-
na. Tipicamente, quando um processo chama uma rotina do monitor, as primei-
ras instruções conferirão para ver se qualquer outro processo está ativo no mo-
mento dentro do monitor. Se isso ocorrer, o processo que chamou será suspen-
so até que o outro processo tenha deixado o monitor. Se nenhum outro proces-
so está usando o monitor, o processo que chamou pode entrar. TANENBAUM
(2016).
Cabe ao compilador implementar a exclusão mútua nas entradas do monitor,
mas uma maneira comum é usar um mutex ou um semáforo binário. Como o
compilador, não o programador, está arranjando a exclusão mútua, é muito me-
nos provável que algo dê errado. De qualquer maneira, a pessoa escrevendo
o monitor não precisa ter ciência de como o compilador arranja a exclusão mú-
tua. Basta saber que ao transformar todas as regiões críticas em rotinas de mo-
nitores, dois processos jamais executarão suas regiões críticas ao mesmo tem-
po. TANENBAUM (2016).
Embora os monitores proporcionem uma maneira fácil de alcançar a exclusão

mútua, isso não é suficiente. Também precisamos de uma maneira para os pro-
cessos bloquearem quando não puderem prosseguir. TANENBAUM (2016).
1.4. Problemas clássicos de sincronização de processos
A literatura de sistemas operacionais está cheia de problemas interessantes

que foram amplamente discutidos e analisados usando variados métodos de
sincronização. Nas seções a seguir, examinaremos 2 dos problemas mais co-
nhecidos.
1.4.1. O problema do jantar dos filósofos
Em 1965, Dijkstra formulou e então solucionou um problema de sincronização

que ele chamou de problema do jantar dos filósofos. Desde então, todos os
que inventaram mais uma primitiva de sincronização sentiram- se obrigados a
demonstrar quão maravilhosa é a nova primitiva exibindo quão elegantemente
ela soluciona o problema do jantar dos filósofos. O problema consiste de: cinco
filósofos estão sentados em torno de uma mesa circular. Cada filósofo tem um
prato de espaguete. O espaguete é tão escorregadio que um filósofo precisa de
dois garfos para comê-lo. Entre cada par de pratos há um garfo.
Figura 2.2 Jantar dos filósofos.
Fonte: Adaptado de Tanenbaum (2016).
A vida de um filósofo consiste em alternar períodos de alimentação e pensa-

mento. Quando um filósofo fica suficientemente faminto, ele tenta pegar seus
garfos à esquerda e à direita, um de cada vez, não importa a ordem. Se for
bem-sucedido em pegar dois garfos, ele come por um tempo, então larga os
garfos e continua a pensar. A questão fundamental é se existe a possibilidade
de escrever um programa para cada filósofo que faça o que deve fazer e ja-
mais fique travado. Suponha que todos os cinco filósofos peguem seus garfos
esquerdos simultaneamente. Nenhum será capaz de pegar seus garfos direi-
tos, e haverá um impasse. TANENBAUM (2016).
Poderíamos facilmente modificar o programa de maneira que após pegar o
garfo esquerdo, o programa confere para ver se o garfo direito está disponível.
Se não estiver, o filósofo coloca de volta o esquerdo sobre a mesa, espera por
um tempo, e repete todo o processo. Essa proposta também fracassa, embora
por uma razão diferente. Com um pouco de azar, todos os filósofos poderiam
começar o algoritmo simultaneamente, pegando seus garfos esquerdos, ven-
do que seus garfos direitos não estavam disponíveis, colocando seus garfos
esquerdos de volta sobre a mesa, esperando, pegando seus garfos esquerdos
de novo ao mesmo tempo, assim por diante, para sempre. Uma situação como
essa, na qual todos os programas continuam a executar indefinidamente, mas
fracassam em realizar qualquer progresso, é chamada de inanição (starvation).
TANENBAUM (2016).
Agora você pode pensar que se os filósofos simplesmente esperassem um

tempo aleatório em vez de ao mesmo tempo fracassarem em conseguir o gar-
fo direito, a chance de tudo continuar em um impasse mesmo por uma hora é
muito pequena. Essa observação é verdadeira, e em quase todas as aplica-
ções tentar mais tarde não é um problema. Por exemplo, na popular rede de
área local Ethernet, se dois computadores enviam um pacote ao mesmo tem-
po, cada um espera um tempo aleatório e tenta de novo; na prática essa so-
lução funciona bem. No entanto, em algumas aplicações você preferiria uma
solução que sempre funcionasse e não pudesse fracassar por uma série impro-
vável de números aleatórios. Pense no controle de segurança em uma usina de
energia nuclear. TANENBAUM (2016).
A maneira de não apresentar impasse nem inanição é proteger os cinco co-

mandos seguindo a chamada think com um semáforo binário. Antes de come-
çar a pegar garfos, um filósofo realizaria um down em mutex. Após substituir
os garfos, ele realizaria um up em mutex. Do ponto de vista teórico, essa so-
lução é adequada. Do ponto de vista prático, ela tem um erro de desempenho:
apenas um filósofo pode estar comendo a qualquer dado instante. Com cinco
garfos disponíveis, deveríamos ser capazes de ter dois filósofos comendo ao
mesmo tempo. TANENBAUM (2016).
1.4.2. O problema dos leitores e escritores
O problema do jantar dos filósofos é útil para modelar processos que estão
competindo pelo acesso exclusivo a um número limitado de recursos, como em
dispositivos de E/S. Outro problema famoso é o problema dos leitores e escri-
tores (COURTOIS et al., 1971), que modela o acesso a um banco de dados.
Imagine, por exemplo, um sistema de reservas de uma companhia aérea, com
muitos processos competindo entre si desejando ler e escrever. É aceitável ter
múltiplos processos lendo o banco de dados ao mesmo tempo, mas se um pro-
cesso está atualizando (escrevendo) o banco de dados, nenhum outro pode ter
acesso, nem mesmo os leitores. TANENBAUM (2016).
Para conseguir acesso ao banco de dados, o primeiro leitor realiza um down no

semáforo. Leitores subsequentes apenas incrementam um contador. À medida
que os leitores saem, eles decrementam o contador, e o último a deixar realiza
um up no semáforo, permitindo que um escritor bloqueado, se houver, entre.
Suponha que enquanto um leitor está usando o banco de dados, aparece outro
leitor. Visto que ter dois leitores ao mesmo tempo não é um problema, o segun-
do leitor é admitido. Leitores adicionais também podem ser admitidos se apare-
cerem. TANENBAUM (2016).
Suponha que um escritor apareça. O escritor pode não ser admitido ao banco
de dados, já que escritores precisam ter acesso exclusivo, então ele é suspen-
so. Depois, leitores adicionais aparecem. Enquanto pelo menos um leitor ainda
estiver ativo, leitores subsequentes serão admitidos. Como consequência des-
sa estratégia, enquanto houver uma oferta uniforme de leitores, todos eles en-
trarão assim que chegarem. O escritor será mantido suspenso até que nenhum
leitor esteja presente. Se um novo leitor aparecer, digamos, a cada 2 segundos,
e cada leitor levar 5 segundos para realizar o seu trabalho, o escritor jamais en-
trará. TANENBAUM (2016).
Para evitar essa situação, o programa poderia ser escrito de maneira que
quando um leitor chega e um escritor está esperando, o leitor é suspenso atrás
do escritor em vez de ser admitido imediatamente. Dessa maneira, um escritor
precisa esperar por leitores que estavam ativos quando ele chegou, mas não
precisa esperar por leitores que chegaram depois dele. A desvantagem dessa
solução é que ela alcança uma concorrência menor e assim tem um desempe-
nho mais baixo. Courtois et al. (1971) apresentam uma solução que dá priorida-
de aos escritores. TANENBAUM (2016).
1.5. Alocação de recursos e impasses
Tanenbaum (2016), afirma que os sistemas computacionais estão cheios de re-

cursos que podem ser usados somente por um processo de cada vez. Exem-
plos comuns incluem as impressoras. Ter dois processos escrevendo simulta-
neamente para a impressora gera uma saída ininteligível. Em consequência,
todos os sistemas operacionais têm a capacidade de conceder (temporaria-
mente) acesso exclusivo a um processo a determinados recursos. Para muitas
aplicações, um processo precisa de acesso exclusivo a não somente um recur-
so, mas a vários.
1.5.1. Recursos
Segundo Tanenbaum (2016), uma classe importante de impasses envolve re-

cursos para os quais algum processo teve acesso exclusivo concedido. Esses
recursos incluem dispositivos, registros de dados, arquivos e assim por diante.
Um recurso pode ser um dispositivo de hardware (por exemplo, uma unidade
de Blu-ray) ou um fragmento de informação (por exemplo, um registro em um
banco de dados). Um computador normalmente terá muitos recursos diferentes
que um processo pode adquirir. Para alguns recursos, várias instâncias idênti-
cas podem estar disponíveis, como três unidades de Blu-rays. Quando várias
cópias de um recurso encontram-se disponíveis, qualquer uma delas pode ser
usada para satisfazer qualquer pedido pelo recurso. Resumindo, um recurso
é qualquer coisa que precisa ser adquirida, usada e liberada com o passar do
tempo.
Há dois tipos de recursos: preemptíveis e não preemptíveis. Um recurso

preemptível é aquele que pode ser retirado do processo proprietário sem cau-
sar-lhe prejuízo algum. A memória é um exemplo de um recurso preemptível.
Já um recurso não preemptível, por sua vez, é um recurso que não pode ser
tomado do seu proprietário atual sem potencialmente causar uma falha. TA-
NENBAUM (2016).
1.5.2. Impasses (Deadlocks)
De acordo com Tanenbaum (2016), um impasse pode ser definido formalmente

como a seguir: Um conjunto de processos estará em situação de impasse se
cada processo no conjunto estiver esperando por um evento que apenas outro
processo no conjunto pode causar.
Como todos os processos estão esperando, nenhum deles jamais causará

qualquer evento que possa despertar um dos outros membros do conjunto, e
todos os processos continuam a esperar para sempre. Para esse modelo, pre-
sumimos que os processos têm um único thread e que nenhuma interrupção
é possível para despertar um processo bloqueado. A condição de não haver
interrupções é necessária para evitar que um processo em situação de impas-
se seja acordado por, digamos, um alarme, e então cause eventos que liberem
outros processos no conjunto. TANENBAUM (2016).
Na maioria dos casos, o evento que cada processo está esperando é a libera-
ção de algum recurso atualmente possuído por outro membro do conjunto. Em
outras palavras, cada membro do conjunto de processos em situação de im-
passe está esperando por um recurso que é de propriedade do processo em si-
tuação de impasse. Nenhum dos processos pode executar, nenhum deles pode
liberar quaisquer recursos e nenhum pode ser desperto. O número de proces-
sos e o número e tipo de recursos possuídos e solicitados não têm importância.
Esse resultado é válido para qualquer tipo de recurso, incluindo hardwares e
softwares. Esse tipo de impasse é chamado de impasse de recurso, e é prova-
velmente o tipo mais comum. TANENBAUM (2016).
SAIBA MAIS
Entenda um pouco mais de processos no Windows e como o gerenciador de

tarefa pode ser o seu grande aliado:
<http://www.tecmundo.com.br/memoria/3197-o-que-sao-processos-de-um-sis-
tema- -operacional-e-por-que-e-importante-saber.htm>.
Acompanhe no portar InfoQ Brasil as últimas novidades sobre Sistemas Opera-

cionais e como eles pode refletir no nosso dia-a-dia como usuários:
< https://www.infoq.com/br/os/>.
REFLITA
Um processo poderá executar a chamada a uma impressora em primeiro plano

e posteriormente o scanner, todavia jamais o scanner e depois a impressora.
Um processo pode ser considerado um programa em execução. Por exemplo:

imagine que desejamos ler um e-book(livro) em nosso computador. Este livro
somente poderá ser visto por você na tela quando ele estiver em execução e
para isto ocorra geralmente será necessário clicar duas vezes rapidamente sob
ele para a sua abertura. Sendo assim, o processador de texto o abrirá. A partir
deste instante temos um processo em execução. Como será que ele entrou em
execução?
Nesta Unidade você acabou de ter a percepção do quanto é difícil o trabalho de

um sistema operacional dentro do computador para prover e gerenciar os diver-
sos programas executados pelos usuários.
Qual Sistema Operacional você está utilizando neste momento? Caso esteja
utilizando Windows ou Linux, este é um SO que consegue executar diversos
processos ao mesmo tempo. E cada um destes processos irão possuir pelo
menos um thread e cabe aos algoritmos escalonar e gerenciar a utilização de
forma ordenada os processos dentro da CPU.
Esta estratégia de ordenação entre processos serve para evitar uma condição
de disputa entre os recursos. Dentre estas estratégias vale a pena citar os se-
máforos. Caso estas estratégias ou escalonamento falhem, iremos ter sérios
problemas causando os famosos travamentos nos programas e consecutiva-
mente os travamentos do sistema operacional. Se for no Windows, a famosa
“tela azul”.
Os assuntos trazidos nesta unidade são de vital importância para que você
consiga garantir rapidez, confiabilidade e disponibilidade em sistemas operacio-
nais.
LIVRO

• Editora: Person
FILME/VÍDEO
• Título: Revolution_OS
• Ano: 2001
• Sinopse: O Documentário “Revolution OS” trata da história do Software
Livre, de como surgiu, a filosofia por trás do projeto, a história de Richard
Stallman, o surgimento do Linux, entrevistas com Linux Torvalds, a criação
da GPL e a carta malcriada feita por Bill Gates à FOSS e outras figuras im-
portantes do Software Livre. Sem dúvida, um excelente documentário para
aqueles que gostam de Software Livre mas não conhecem sua história e
mesmo para aqueles que não gostam de SL, mas têm curiosidade em saber
como surgiu.
• Link: < https://www.youtube.com/watch?v=plMxWpXhqig>
REFERÊNCIAS

UNIDADE lll
GERENCIAMENTO DE MEMÓRIA
E SISTEMA DE ARQUIVOS
Plano de Estudo:
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
• Organização de Memória
• Swapping
• Paginação
• Segmentação
• Memória virtual
• Conceito de Arquivo
• Métodos de Acesso
• Atributos de arquivos
• Operações com arquivos
• Diretórios
42
• Apresentar definições de memória e as técnicas que o sistema operacional
utiliza para garantir o armazenamento dos dados utilizados pelos proces-
sos.
• Diferenciar endereços lógicos dos endereços físicos, quem os cria e como
são utilizados pela memória.
• Explicar como as informações são armazenadas/alocadas na memória e
como elas podem se fragmentar.
• Identificar quais estratégias de alocação são utilizadas pelos principais
sistemas operacionais.
• Apresentar o uso da técnica de memória virtual.
• Apresentar conceitos de arquivos.
• Apresentar e diferenciar os sistemas de arquivos utilizados pelos principais
sistemas operacionais.
INTRODUÇÃO
A memória principal de um computador tem como tarefa a alocação dos sof-

twares que estão em execução pelo sistema operacional. Nos Programas, por
certo período, ficam os processos que estão em execução, tanto do sistema
operacional, quanto nos softwares que estão sendo utilizados pelos usuários.
De forma geral, os programas são armazenados na memória secundária, para

que possam ser acessados sempre que necessário. Memória secundária são
os discos rígidos, pen drives, CDs, DVDs, entre outros. Estes dispositivos pos-
suem um espaço generoso de armazenamento a preços bem reduzidos se
comparados a memória principal de um computador, além de armazenar os da-
dos de forma não-volátil, ou seja, estes dados não se apagam depois que o
computador é desligado.
Outra questão a ser discutida, está relacionada à memória e que está no con-
texto da gerência de memória é a de permitir a execução de programas que
sejam maiores do que a memória física disponível, utilizando técnicas como a
memória virtual e o overlay.
Veremos também nesta Unidade III os sistemas de arquivos dos sistemas ope-
racionais. Os arquivos são gerenciados pelo sistema operacional de forma a
auxiliar a utilização pelos usuários. O sistema de arquivos caracteriza-se como
a parte mais visível de um sistema operacional, uma vez que os usuários ma-
nipulam arquivos a todo o momento. Abordaremos nesta Unidade as principais
formas para organização de arquivos, métodos de acesso, assim como, as
principais técnicas de alocação.
1. GERENCIAMENTO DE MEMÓRIA
A memória principal (RAM) é um recurso importante que deve ser cuidadosa-
mente gerenciado. Apesar de o computador pessoal médio hoje em dia ter
10.000 vezes mais memória do que o IBM 7094, o maior computador no mundo
no início da década de 1960, os programas estão ficando maiores mais rápido
do que as memórias. A parte do sistema operacional que gerencia (parte da)
hierarquia de memórias é chamada de gerenciador de memória. Sua função
é gerenciar eficientemente a memória: controlar quais partes estão sendo us-
adas, alocar memória para processos quando eles precisam dela e liberá-la
quando tiverem terminado.
1.1. Organização de Memória
Conforme Tanenbaum (2016), o valor de um bit tem pouco significado, as

memórias são estruturadas e divididas em conjuntos ordenados de bits, de-
nominados células, cada uma podendo armazenar uma parte da informação.
Se uma célula consiste em k beta.bits ela pode conter uma em 2k diferente
combinação de bits, sendo que todas as células possuem a mesma quantidade
de bits.
Cada célula deve ficar num local certo e sabido, ou seja, a cada célula asso-
cia-se um número chamado de seu endereço. Só assim torna-se possível a
busca na memória exatamente do que se estiver querendo a cada momen-
to(acesso aleatório). Sendo assim, célula pode ser definida como a menor par-
te de memória endereçável. TANENBAUM (2016).
Se uma memória tem “n” células o sistema de endereçamento numera as célu-

las sequencialmente a partir de zero até “n-1”, sendo que esses endereços são
fixos e representados por números binários. A quantidade de bits em um en-
dereço está relacionado a máxima quantidade de células endereçáveis. Por
exemplo, se um endereço possui “m” bits o número máximo de células direta-
mente endereçáveis é “2m”.
A maioria dos fabricantes de computador padronizaram o tamanho da célula

em 8 bits (Byte). Bytes são agrupados em palavras, ou seja, a um grupo de
bytes (2,4,6,8 Bytes) é associado um endereço particular. O significado de uma
palavra é que a maioria das instruções operam em palavras inteiras. TANEN-
BAUM (2016).
Os bytes em uma palavra podem ser numerados da esquerda para direita ou

da direita para esquerda. O primeiro sistema, onde a numeração começa no
lado de alta ordem, é chamado de computador big-endian, e o outro de little-en-
dian. Ambas representações são boas mas quando uma máquina de um tipo
tenta enviar dados para outra, problemas de posicionamento podem surgir. A
falta de um padrão para ordenar os bytes é um grande problema na troca de
dados entre máquinas diferentes.
1.2. Swapping
Nas palavras de Tanenbaum (2016), se a memória física do computador for

grande o suficiente para armazenar todos os processos, os diversos esquemas
existentes bastarão de certa forma. Mas na prática, o montante total de RAM
demandado por todos os processos é muitas vezes bem maior do que pode
ser colocado na memória. Em sistemas típicos Windows, OS X ou Linux, algo
como 50-100 processos ou mais podem ser iniciados tão logo o computador
for ligado. Por exemplo, quando uma aplicação do Windows é instalada, ela
muitas vezes emite comandos de tal forma que em inicializações subsequentes
do sistema, um processo será iniciado somente para conferir se existem atual-
izações para as aplicações. Um processo desses pode facilmente ocupar 5-10
MB de memória. Outros processos de segundo plano conferem se há e-mails,
conexões de rede chegando e muitas outras coisas. E tudo isso antes de o
primeiro programa do usuário ter sido iniciado. Programas sérios de aplicação
do usuário, como o Photoshop, podem facilmente exigir 500 MB apenas para
serem inicializados e muitos gigabytes assim que começam a processar dados.
Em consequência, manter todos os processos na memória o tempo inteiro ex-
ige um montante enorme de memória e é algo que não pode ser feito se ela for
insuficiente.
Duas abordagens gerais para lidar com a sobrecarga de memória foram desen-
volvidas ao longo dos anos. A estratégia mais simples, chamada de swapping
(troca de processos), consiste em trazer cada processo em sua totalidade,
executá-lo por um tempo e então colocá-lo de volta no disco. Processos ocio-
sos estão armazenados em disco em sua maior parte, portanto não ocupam
qualquer memória quando não estão sendo executados (embora alguns “des-
pertem” periodicamente para fazer seu trabalho, e então voltam a “dormir”).
A outra estratégia, chamada de memória virtual, estudaremos mais adiante.
TANENBAUM (2016).
A operação de um sistema de troca de processos pode ser descrito assim: de

início, somente o processo A está na memória. Então os processos B e C são
criados ou trazidos do disco. O processo A é devolvido ao disco. Então o pro-
cesso D é inserido e o processo B tirado. Por fim, o processo A volta nova-
mente. Como A está agora em uma posição diferente, os endereços contidos
nele devem ser realocados, seja pelo software quando ele é trazido ou (mais
provável) pelo hardware durante a execução do programa. TANENBAUM
(2016).
Quando as trocas de processos criam múltiplos espaços na memória, é pos-
sível combiná-los em um grande espaço movendo todos os processos para
baixo, o máximo possível. Essa técnica é conhecida como compactação de
memória. Em geral ela não é feita porque exige muito tempo da CPU. TANEN-
BAUM (2016).
Um ponto que vale a pena considerar diz respeito a quanta memória deve ser
alocada para um processo quando ele é criado ou trocado. Se os processos
são criados com um tamanho fixo que nunca muda, então a alocação é sim-
ples: o sistema operacional aloca exatamente o que é necessário, nem mais
nem menos. TANENBAUM (2016).
1.3. Paginação
Segundo Tanenbaum (2016), a maioria dos sistemas de memória virtual usa

uma técnica chamada de paginação. Em qualquer computador, programas ref-
erenciam um conjunto de endereços de memória. Quando um programa exe-
cuta uma instrução como “MOV REG,1000” ele o faz para copiar o conteúdo
do endereço de memória 1000 para REG (ou vice-versa, dependendo do com-
putador).
Esses endereços gerados por computadores são chamados de endereços vir-

tuais e formam o espaço de endereçamento virtual. Em computadores sem
memória virtual, o endereço virtual é colocado diretamente no barramento de
memória e faz que a palavra de memória física com o mesmo endereço seja
lida ou escrita. Quando a memória virtual é usada, os endereços virtuais não
vão diretamente para o barramento da memória. Em vez disso, eles vão
para uma MMU (Memory Management Unit — unidade de gerenciamento de
memória) que mapeia os endereços virtuais em endereços de memória física.
TANENBAUM (2016).
O espaço de endereçamento virtual consiste em unidades de tamanho fixo

chamadas de páginas. As unidades correspondentes na memória física são
chamadas de quadros de página. As páginas e os quadros de página são
geralmente do mesmo tamanho. TANENBAUM (2016).
1.4. Segmentação
Como aponta Tanenbaum (2016), considere o que acontece se um programa

tiver um número muito maior do que o usual de variáveis, mas uma quantidade
normal de todo o resto. A região do espaço de endereçamento alocada para
a tabela de símbolos pode se esgotar, mas talvez haja muito espaço nas out-
ras tabelas. É necessário encontrar uma maneira de liberar o programador de
ter de gerenciar as tabelas em expansão e contração, da mesma maneira que
a memória virtual elimina a preocupação de organizar o programa em sobre-
posições (overlays).
Uma solução direta e bastante geral é fornecer à máquina espaços de en-

dereçamento completamente independentes, que são chamados de seg-
mentos. Cada segmento consiste em uma sequência linear de endereços,
começando em 0 e indo até algum valor máximo. O comprimento de cada seg-
mento pode ser qualquer coisa de 0 ao endereço máximo permitido. Diferentes
segmentos podem e costumam ter comprimentos diferentes. Além disso, com-
primentos de segmentos podem mudar durante a execução. O comprimento de
um segmento de pilha pode ser aumentado sempre que algo é colocado sobre
a pilha e diminuído toda vez que algo é retirado dela. TANENBAUM (2016).
Como cada segmento constitui um espaço de endereçamento separado, difer-

entes segmentos podem crescer ou encolher independentemente sem afetar
um ao outro. Se uma pilha em um determinado segmento precisa de mais es-
paço de endereçamento para crescer, ela pode tê-lo, pois não há nada mais at-
rapalhando em seu espaço de endereçamento. Claro, um segmento pode ficar
cheio, mas segmentos em geral são muito grandes, então essa ocorrência é
rara. Para especificar um endereço nessa memória segmentada ou bidimen-
sional, o programa precisa fornecer um endereço em duas partes, um número
de segmento e um endereço dentro do segmento. TANENBAUM (2016).
Uma memória segmentada tem outras vantagens além de simplificar o trata-

mento das estruturas de dados que estão crescendo ou encolhendo. Se cada
rotina ocupa um segmento em separado, com o endereço 0 como o de partida,
a ligação das rotinas compiladas separadamente é bastante simplificada. Afinal
de contas, todos os procedimentos que constituem um programa foram compi-
lados e ligados, uma chamada para a rotina no segmento “n” usará o endereço
de duas partes (n, 0) para endereçar a palavra 0 (o ponto de entrada). TANEN-
BAUM (2016).
1.5. Memória virtual
De acordo com Tanenbaum (2016), apesar de os tamanhos das memórias au-

mentarem depressa, os tamanhos dos softwares estão crescendo muito mais
rapidamente. Nos anos 1980, muitas universidades executavam um sistema
de compartilhamento de tempo com dúzias de usuários (mais ou menos sat-
isfeitos) executando simultaneamente em um VAX de 4 MB. Agora a Microsoft
recomenda no mínimo 2 GB para o Windows 8 de 64 bits. A tendência à multi-
mídia coloca ainda mais demandas sobre a memória.
Como consequência desses desenvolvimentos, há uma necessidade de exe-

cutar programas que são grandes demais para se encaixar na memória e há
certamente uma necessidade de ter sistemas que possam dar suporte a múl-
tiplos programas executando em simultâneo, cada um deles encaixando-se na
memória, mas com todos coletivamente excedendo-a. A troca de processos
não é uma opção atraente, visto que o disco SATA típico tem um pico de taxa
de transferência de várias centenas de MB/s, o que significa que demora se-
gundos para retirar um programa de 1 GB e o mesmo para carregar um pro-
grama de 1 GB. TANENBAUM (2016).
O problema dos programas maiores do que a memória existe desde o início da

computação, embora em áreas limitadas, como a ciência e a engenharia (sim-
ular a criação do universo, ou mesmo um avião novo, exige muita memória).
Uma solução adotada nos anos 1960 foi dividir os programas em módulos
pequenos, chamados de sobreposições. Quando um programa inicializava,
tudo o que era carregado na memória era o gerenciador de sobreposições,
que imediatamente carregava e executava a sobreposição 0. Quando termina-
va, ele dizia ao gerenciador de sobreposições para carregar a sobreposição 1,
acima da sobreposição 0 na memória (se houvesse espaço para isso), ou em
cima da sobreposição 0 (se não houvesse). Alguns sistemas de sobreposições
eram altamente complexos, permitindo muitas sobreposições na memória ao
mesmo tempo. As sobreposições eram mantidas no disco e transferidas para
dentro ou para fora da memória pelo gerenciador de sobreposições. TANEN-
BAUM (2016).
Embora o trabalho real de troca de sobreposições do disco para a memória e

vice-versa fosse feito pelo sistema operacional, o trabalho da divisão do pro-
grama em módulos tinha de ser feito manualmente pelo programador. Divid-
ir programas grandes em módulos pequenos era uma tarefa cansativa, chata
e propensa a erros. Poucos programadores eram bons nisso. Não levou mui-
to tempo para alguém pensar em passar todo o trabalho para o computador.
TANENBAUM (2016).
O método encontrado (FOTHERINGHAM, 1961) ficou conhecido como
memória virtual. A ideia básica é que cada programa tem seu próprio espaço
de endereçamento, o qual é dividido em blocos chamados de páginas. Cada
página é uma série contígua de endereços. Elas são mapeadas na memória
física, mas nem todas precisam estar na memória física ao mesmo tempo para
executar o programa. Quando o programa referência uma parte do espaço de
endereçamento que está na memória física, o hardware realiza o mapeamento
necessário rapidamente. Quando o programa referência uma parte de seu es-
paço de endereçamento que não está na memória física, o sistema operacional
é alertado para ir buscar a parte que falta e reexecuta a instrução que falhou.
De certa maneira, a memória virtual é uma generalização da ideia do registra-

dor base e registrador limite. O 8088 tinha registradores base separados (mas
não registradores limite) para texto e dados. Com a memória virtual, em vez de
ter realocações separadas apenas para os segmentos de texto e dados, todo o
espaço de endereçamento pode ser mapeado na memória física em unidades
razoavelmente pequenas. A memória virtual funciona bem em um sistema de
multiprogramação, com pedaços e partes de muitos programas na memória
simultaneamente. Enquanto um programa está esperando que partes de si
mesmo sejam lidas, a CPU pode ser dada para outro processo. TANENBAUM
(2016).
1. SISTEMA DE ARQUIVOS
Para Tanenbaum (2016), todas as aplicações de computadores precisam ar-

mazenar e recuperar informações. Enquanto um processo está sendo executa-
do, ele pode armazenar uma quantidade limitada de informações dentro do seu
próprio espaço de endereçamento. No entanto, a capacidade de armazena-
mento está restrita ao tamanho do espaço do endereçamento virtual. Para al-
gumas aplicações esse tamanho é adequado, mas, para outras, ele é pequeno
demais. Um segundo problema em manter informações dentro do espaço de
endereçamento de um processo é que, quando o processo é concluído, as in-
formações são perdidas. Para muitas aplicações (por exemplo, bancos de da-
dos), as informações precisam ser retidas por semanas, meses, ou mesmo
para sempre. Perdê-las quando o processo que as está utilizando é concluído
é algo inaceitável. Além disso, elas não devem desaparecer quando uma falha
no computador mata um processo.
Um terceiro problema é que frequentemente é necessário que múltiplos proces-

sos acessem (partes de) uma informação ao mesmo tempo. Se temos um di-
retório telefônico on-line armazenado dentro do espaço de um único processo,
apenas aquele processo pode acessá-lo. A maneira para solucionar esse prob-
lema é tornar a informação em si independente de qualquer processo. TANEN-
BAUM (2016).
Assim, temos três requisitos essenciais para o armazenamento de informações

por um longo prazo:
1. Deve ser possível armazenar uma quantidade muito grande de informações.

2. As informações devem sobreviver ao término do processo que as está utili-
zando.
3. Múltiplos processos têm de ser capazes de acessá-las ao mesmo tempo.
Da mesma maneira que vimos como o sistema operacional abstraía o conceito

do processador para criar a abstração de um processo e como ele abstraía o
conceito da memória física para oferecer aos processos espaços de endereça-
mento (virtuais), podemos solucionar esse problema com uma nova abstração:
o arquivo. Juntas, as abstrações de processos (e threads), espaços de en-
dereçamento e arquivos são os conceitos mais importantes relacionados com
os sistemas operacionais. TANENBAUM (2016).
Conceito de Arquivo
Nas palavras de Tanenbaum (2016), arquivos são unidades lógicas de infor-

mação criadas por processos. Um disco normalmente conterá milhares ou
mesmo milhões deles, cada um independente dos outros. Processos podem ler
arquivos existentes e criar novos se necessário. Informações armazenadas em
arquivos devem ser persistentes, isto é, não devem ser afetadas pela criação e
término de um processo. Um arquivo deve desaparecer apenas quando o seu
proprietário o remove explicitamente. Embora as operações para leitura e es-
crita de arquivos sejam as mais comuns, existem muitas outras, algumas das
quais examinaremos a seguir.
Arquivos são gerenciados pelo sistema operacional. Como são estruturados,

nomeados, acessados, usados, protegidos, implementados e gerenciados são
tópicos importantes no projeto de um sistema operacional. Como um todo,
aquela parte do sistema operacional lidando com arquivos é conhecida como
sistema de arquivos. TANENBAUM (2016).
Do ponto de vista do usuário, o aspecto mais importante de um sistema de ar-

quivos é como ele aparece, em outras palavras, o que constitui um arquivo,
como os arquivos são nomeados e protegidos, quais operações são permitidas
e assim por diante. Os detalhes sobre se listas encadeadas ou mapas de bits
são usados para o armazenamento disponível e quantos setores existem em
um bloco de disco lógico não interessam, embora sejam de grande importância
para os projetistas do sistema de arquivos. TANENBAUM (2016).
1.1 Métodos de Acesso
Como aponta Tanenbaum (2016), os primeiros sistemas operacionais forneci-

am apenas um tipo de acesso aos arquivos: acesso sequencial. Nesses siste-
mas, um processo podia ler todos os bytes ou registros em um arquivo em or-
dem, começando do princípio, mas não podia pular nenhum ou lê-los fora de
ordem. No entanto, arquivos sequenciais podiam ser trazidos de volta para o
ponto de partida, então eles podiam ser lidos tantas vezes quanto necessário.
Arquivos sequenciais eram convenientes quando o meio de armazenamento
era uma fita magnética, em vez de um disco.
Quando os discos passaram a ser usados para armazenar arquivos, tornou-se

possível ler os bytes ou registros de um arquivo fora de ordem, ou acessar os
registros pela chave em vez de pela posição. Arquivos ou registros que podem
ser lidos em qualquer ordem são chamados de arquivos de acesso aleatório.
Eles são necessários para muitas aplicações. Arquivos de acesso aleatório são
essenciais para muitas aplicações, por exemplo, sistemas de bancos de da-
dos. Se um cliente de uma companhia aérea liga e quer reservar um assento
em um determinado voo, o programa de reservas deve ser capaz de acessar
o registro para aquele voo sem ter de ler primeiro os registros para milhares de
outros voos. Dois métodos podem ser usados para especificar onde começar
a leitura. No primeiro, cada operação read fornece a posição no arquivo onde
começar a leitura. No segundo, uma operação simples, seek, é fornecida para
estabelecer a posição atual. Após um seek, o arquivo pode ser lido sequencial-
mente da posição agora atual. O segundo método é usado no UNIX e no Win-
dows. TANENBAUM (2016).
1.2 Atributos de arquivos

Tanenbaum (2016), afirma que, todo arquivo possui um nome e sua data. Além
disso, todos os sistemas operacionais associam outras informações com cada
arquivo, por exemplo, a data e o horário em que foi modificado pela última vez,
assim como o tamanho do arquivo. Chamamos esses itens extras de atributos
do arquivo. Algumas pessoas os chamam de metadados. A lista de atributos
apresentada na Tabela 5.1, varia bastante de um sistema para outro. Nenhum
sistema existente tem todos os atributos, mas cada um está presente em algum
sistema.
Os primeiros quatro atributos concernem à proteção do arquivo e dizem quem

pode acessá-lo e quem não pode. Todos os tipos de esquemas são possíveis,
alguns dos quais estudaremos mais tarde. Em alguns sistemas o usuário deve
apresentar uma senha para acessar um arquivo, caso em que a senha deve
ser um dos atributos. TANENBAUM (2016).
As sinalizações (flags) são bits ou campos curtos que controlam ou habilitam

alguma propriedade específica. Arquivos ocultos, por exemplo, não aparecem
nas listagens de todos os arquivos. A sinalização de arquivamento é um bit que
controla se foi feito um backup do arquivo recentemente. O programa de back-
up remove esse bit e o sistema operacional o recoloca sempre que um arquivo
for modificado. Dessa maneira, o programa consegue dizer quais arquivos pre-
cisam de backup. A sinalização temporária permite que um arquivo seja mar-
cado para ser deletado automaticamente quando o processo que o criou for
concluído. TANENBAUM (2016).
O tamanho do registro, posição da chave e tamanho dos campos-chave es-

tão presentes apenas em arquivos cujos registros podem ser lidos usando uma
chave. Eles proporcionam a informação necessária para encontrar as chaves.
TANENBAUM (2016).
Os vários registros de tempo controlam quando o arquivo foi criado, acessa-
do e modificado pela última vez, os quais são úteis para uma série de finali-
dades. Por exemplo, um arquivo-fonte que foi modificado após a criação do ar-
quivo-objeto correspondente precisa ser recompilado. Esses campos fornecem
as informações necessárias. TANENBAUM (2016).
Atributo Significado
Proteção Quem tem acesso ao arquivo e de que modo
Senha Necessidade de senha para acesso ao arquivo
Criador ID do criador do arquivo
Proprietário Proprietário atual
Flag de somente leitura 0 para leitura/escrita; 1 para somente leitura
Flag de oculto 0 para normal; 1 para não exibir o arquivo
Flag de sistema 0 para arquivos normais; 1 para arquivos de sistema
Flag de arquivamento 0 para arquivos com backup; 1 para arquivos sem

backup
Flag de ASCII/binário 0 para arquivos ASCII; 1 para arquivos binários
Flag de acesso aleatório 0 para acesso somente sequencial; 1 para acesso

aleatório
Flag de temporário 0 para normal; 1 para apagar o arquivo ao sair do
processo
Flag de travamento 0 para destravados; diferente de 0 para travados
Tamanho do registro Número de bytes em um registro
Posição da chave Posição da chave em cada registro
Tamanho da chave Número de bytes na chave
Momento de criação Data e hora de criação do arquivo
Momento do último acesso Data e hora do último acesso do arquivo
Momento da última alteração Data e hora da última modificação do arquivo
Tamanho atual Número de bytes no arquivo
Tamanho máximo Número máximo de bytes no arquivo

Tabela 4.1 Alguns possíveis atributos de arquivos.
O tamanho atual nos informa o tamanho que o arquivo tem no momento. Al-
guns sistemas operacionais de antigos computadores de grande porte exigiam
que o tamanho máximo fosse especificado quando o arquivo fosse criado, a
fim de deixar que o sistema operacional reservasse a quantidade máxima de
memória antecipadamente. Sistemas operacionais de computadores pessoais
e de estações de trabalho são inteligentes o suficiente para não precisarem
desse atributo. TANENBAUM (2016).
1.3 Operações com arquivos
Segundo Tanenbaum (2016), arquivos existem para armazenar informações e

permitir que elas sejam recuperadas depois. Sistemas diferentes proporcionam
operações diferentes para permitir armazenamento e recuperação. A seguir
uma discussão das chamadas de sistema mais comuns relativas a arquivos.
1. Create: o arquivo é criado sem dados. A finalidade dessa chamada é anun-

ciar que o arquivo está vindo e estabelecer alguns dos atributos.
2. Delete: quando o arquivo não é mais necessário, ele tem de ser removido
para liberar espaço para o disco. Há sempre uma chamada de sistema para
essa finalidade.
3. Open: antes de usar um arquivo, um processo precisa abri-lo. A finalidade

da chamada open é permitir que o sistema busque os atributos e lista de
endereços do disco para a memória principal a fim de tornar mais rápido o
acesso em chamadas posteriores.
4. Close: quando todos os acessos são concluídos, os atributos e endereços

de disco não são mais necessários, então o arquivo deve ser fechado para
liberar espaço da tabela interna. Muitos sistemas encorajam isso impondo
um número máximo de arquivos abertos em processos. Um disco é escrito
em blocos, e o fechamento de um arquivo força a escrita do último bloco
dele, mesmo que não esteja inteiramente cheio ainda.
5. Read: dados são lidos do arquivo. Em geral, os bytes vêm da posição atual.
Quem fez a chamada deve especificar a quantidade de dados necessária e
também fornecer um buffer para colocá-los.
6. Write: dados são escritos para o arquivo de novo, normalmente na posição

atual. Se a posição atual for o final do arquivo, seu tamanho aumentará. Se
estiver no meio do arquivo, os dados existentes serão sobrescritos e perdi-
dos para sempre.
7. Append: essa chamada é uma forma restrita de write. Ela pode acrescentar
dados somente para o final do arquivo. Sistemas que fornecem um conjunto
mínimo de chamadas do sistema raramente têm append, mas muitos siste-
mas fornecem múltiplas maneiras de fazer a mesma coisa, e esses às vez-
es têm append.
8. Seek: para arquivos de acesso aleatório, é necessário um método para es-

pecificar de onde tirar os dados. Uma abordagem comum é uma chamada
de sistema, seek, que reposiciona o ponteiro de arquivo para um local espe-
cífico dele. Após essa chamada ter sido completa, os dados podem ser lidos
da, ou escritos para, aquela posição.
9. Get attributes: processos muitas vezes precisam ler atributos de arquivos

para realizar seu trabalho. Por exemplo, o programa make da UNIX costu-
ma ser usado para gerenciar projetos de desenvolvimento de software con-
sistindo de muitos arquivos-fonte. Quando make é chamado, ele examina
os momentos de alteração de todos os arquivos- fonte e objetos e organiza
o número mínimo de compilações necessárias para atualizar tudo. Para re-
alizar o trabalho, o make deve examinar os atributos, a saber, os momentos
de alteração.
10. Set attributes: alguns dos atributos podem ser alterados pelo usuário e mod-
ificados após o arquivo ter sido criado. Essa chamada de sistema torna isso
possível. A informação sobre o modo de proteção é um exemplo óbvio. A
maioria das sinalizações também cai nessa categoria.
11. Rename: acontece com frequência de um usuário precisar mudar o nome

de um arquivo. Essa chamada de sistema torna isso possível. Ela nem sem-
pre é estritamente necessária, porque o arquivo em geral pode ser copiado
para um outro com um nome novo, e o arquivo antigo é então deletado.
1.4 Diretórios
Para controlar os arquivos, sistemas de arquivos normalmente têm diretórios

ou pastas, que são em si arquivos. Nesta seção discutiremos diretórios, sua
organização, suas propriedades e as operações que podem ser realizadas por
eles.
1.4.1 Sistemas de diretório em nível único
Nas palavras de Tanenbaum (2016), a forma mais simples de um sistema de

diretório é ter um diretório contendo todos os arquivos. Às vezes ele é chama-
do de diretório-raiz, mas como ele é o único, o nome não importa muito. Nos
primeiros computadores pessoais, esse sistema era comum, em parte porque
havia apenas um usuário. Curiosamente, o primeiro supercomputador do mun-
do, o CDC 6600, também tinha apenas um único diretório para todos os arqui-
vos, embora fosse usado por muitos usuários ao mesmo tempo. Essa decisão
foi tomada sem dúvida para manter simples o design do software.
Figura 4.1 Um sistema de diretório em nível único contendo quatro arquivos.

Um exemplo de um sistema com um diretório é dado na Figura 4.1. Aqui o di-

retório contém quatro arquivos. As vantagens desse esquema são a sua sim-
plicidade e a capacidade de localizar arquivos rapidamente — há apenas um
lugar para se procurar, afinal. Às vezes ele ainda é usado em dispositivos em-
barcados simples como câmeras digitais e alguns players portáteis de música.
TANENBAUM (2016).
1.4.2 Sistemas de diretórios hierárquicos
Para Tanenbaum (2016), o nível único é adequado para aplicações dedicadas

muito simples (e chegou a ser usado nos primeiros computadores pessoais),
mas para os usuários modernos com milhares de arquivos seria impossível en-
contrar qualquer coisa se todos os arquivos estivessem em um único diretório.
Em consequência, é necessária uma maneira para agrupar arquivos relaciona-

dos em um mesmo local. Um professor, por exemplo, pode ter uma coleção de
arquivos que juntos formam um livro que ele está escrevendo, uma segunda
coleção contendo programas apresentados por estudantes para outro curso,
um terceiro grupo contendo o código de um sistema de escrita de compiladores
avançado que ele está desenvolvendo, um quarto grupo contendo propostas
de doações, assim como outros arquivos para correio eletrônico, minutas de
reuniões, estudos que ele está escrevendo, jogos e assim por diante. TANEN-
BAUM (2016).
Figura 4.2 Um sistema hierárquico de diretórios.
Faz-se necessária uma hierarquia (isto é, uma árvore de diretórios). Com essa
abordagem, o usuário pode ter tantos diretórios quantos forem necessários
para agrupar seus arquivos de maneira natural. Além disso, se múltiplos usuári-
os compartilham um servidor de arquivos comum, como é o caso em muitas
redes de empresas, cada usuário pode ter um diretório-raiz privado para sua
própria hierarquia. Essa abordagem é mostrada na Figura 4.2. Aqui, cada di-
retório A, B e C contido no diretório- -raiz pertence a um usuário diferente, e
dois deles criaram subdiretórios para projetos nos quais estão trabalhando.
TANENBAUM (2016).
A capacidade dos usuários de criarem um número arbitrário de subdiretórios

proporciona uma ferramenta de estruturação poderosa para eles organizarem
o seu trabalho. Por essa razão, quase todos os sistemas de arquivos modernos
são organizados dessa maneira. TANENBAUM (2016).
SAIBA MAIS
Memória virtual. O que é? Como configurar.

<https://www.youtube.com/watch?v=7EQaEaDibpg>.
Você conhece a memória cache? Aprenda mais sobre ela neste vídeo.
<https://www.youtube.com/watch?v=Yucz5VVxcuE&feature=youtu.be>.
Que tal consolidar o seu conhecimento sobre sistema de arquivos, em especial

sobre FAT? Confira neste vídeo mais sobre este assunto em:
<https://www.youtube.com/watch?v=FUrucbfS0WM&feature=youtu.be>
REFLITA
Atenção, não confunda as alocações de memória primária (RAM), e as alo-

cações para memória secundária (disco rígido, por exemplo).
A velocidade dos processadores cresce muito mais rápida do que a quantidade

de armazenamento das memórias RAM. E com isto, mais processos precisam
de espaço na memória. Sem a memória virtual, dificilmente conseguiríamos ter
um bom desempenho nos computadores.
Nesta Unidade III, tivemos a oportunidade de entender como o gerenciamen-

to de memória é fundamental para que o sistema operacional possa executar
suas tarefas de maneira eficiente. Também foi possível entender as principais
técnicas utilizadas para a alocação e gerenciamento de memória pelo SO. Para
entender melhor e fixar o conteúdo visto, é fundamental que você execute os
exercícios proposta na sequência dos estudos.
Vimos também nesta Unidade III como funciona a organização de arquivos e

diretórios dentro de um SO e como estas técnicas de alocação de espaço em
disco são de suma importantes para que a leitura e gravação dos dados ocor-
ram de maneira objetiva. Relembro que é primordial o aprofundamento do con-
teúdo através de exercícios e matérias propostos.
LIVRO
• Título: Arquitetura de Sistemas Operacionais

• Autor: Francis Berenger Machado e Luiz Paulo Maia
• Editora: LTC
• Sinopse: O estudo de sistemas operacionais ganha importância à medida
que diversos profissionais da área de computação necessitam deste conhe-
cimento para exercer suas atividades, como administradores de sistemas,
programadores de aplicações concorrentes e gerentes de segurança.
FILME/VÍDEO
• Título: A Rede Social

• Ano: 2010
• Sinopse: Em 2003, o estudante de Harvard e gênio da computação Mark
Zuckerberg começa a trabalhar em um novo conceito que acaba se trans-
formando em uma rede social global, o Facebook. Seis anos mais tarde, ele
é um dos bilionários mais jovens do planeta. Mas seu sucesso sem prece-
dentes traz complicações legais e pessoais.
• Link: < https://www.netflix.com/br/title/70132721 >
REFERÊNCIAS
MAIA, Luiz Paulo. Introdução à arquitetura de sistemas operacionais. São

Paulo: LTC, 2007.

UNIDADE lV
GERENCIAMENTO DE
ENTRADA E SAÍDA E
SISTEMAS DISTRIBUÍDOS
Plano de Estudo:
• Princípios do Hardware de Entrada e Saída
• Princípios do Software de Entrada e Saída
• Atributos de Sistemas Distribuídos
• Sistemas Operacionais de Rede
• Comunicação em Sistemas Distribuídos
64
• Diferenciar hardware de entrada/saída do software de entrada/saída.
• Apresentar como o sistema operacional se comunica com os dispositivos de
entrada/saída.
• Entender como uma coleção de nós computacionais independentes, sepa-
rados fisicamente, entretanto conectados.
• Perceber como usuários com um único dispositivo provendo serviços ou re-
solvendo algum problema.
INTRODUÇÃO
Nesta unidade iremos abordar os temas Gerenciamento de Entrada e Saída, e

veremos também sobre Sistemas Distribuídos.
Além de oferecer abstrações como processos, espaços de endereçamentos e

arquivos, um sistema operacional também controla todos os dispositivos de E/S
(entrada/saída) do computador. Ele deve emitir comandos para os dispositivos,
interceptar interrupções e lidar com erros. Também deve fornecer uma interface
entre os dispositivos e o resto do sistema que seja simples e fácil de usar. Na
medida do possível, a interface deve ser a mesma para todos os dispositivos
(independentemente do dispositivo). O código de E/S representa uma fração
significativa do sistema operacional total.
Sobre Sistemas Distribupidos, notamos que à medida que a velocidade e a

confiabilidade das redes eram aprimoradas, computadores do mundo inteiro
tornavam-se cada vez mais interconectados. A comunicação remota via rede,
originalmente reservada para grandes instalações de computadores e ambien-
tes acadêmicos, foi amplamente difundida. Em sistemas distribuídos, computa-
dores remotos cooperam via rede de modo que pareçam uma máquina local.
Tanto os sistemas distribuídos quanto os sistemas de rede estendem computa-
ção e armazenamento por toda uma rede de computadores. Entretanto, usuá-
rios de sistemas operacionais distribuídos têm a impressão de que estão inte-
ragindo com apenas uma máquina, ao passo que os de sistemas operacionais
de rede devem estar conscientes da implementação distribuída. Aplicações de
sistemas distribuídos podem executar código em máquinas locais e remotas e
compartilhar dados, arquivos e outros recursos entre máquinas.
1. GERENCIAMENTO DE ENTRADA E SAÍDA
1.1. Princípios do Hardware de Entrada e Saída
Segundo Tanenbaum (2016), diferentes pessoas veem o hardware de E/S de

maneiras diferentes. Engenheiros elétricos o veem em termos de chips, cabos,
motores, suprimento de energia e todos os outros componentes físicos que
compreendem o hardware. Programadores olham para a interface apresentada
ao software - os comandos que o hardware aceita, as funções que ele realiza e
os erros que podem ser reportados de volta. Neste livro, estamos interessados
na programação de dispositivos de E/S, e não em seu projeto, construção ou
manutenção; portanto, nosso interesse é saber como o hardware é programa-
do, não como ele funciona por dentro. Não obstante isso, a programação de
muitos dispositivos de E/S está muitas vezes intimamente ligada à sua ope-
ração interna. Nas próximas três seções, apresentaremos uma pequena visão
geral sobre hardwares de E/S à medida que estes se relacionam com a progra-
mação.
1.1.1 Dispositivos de E/S
Para Tanenbaum (2016), dispositivos de E/S podem ser divididos de modo ge-
ral em duas categorias: dispositivos de blocos e dispositivos de caractere. O
primeiro armazena informações em blocos de tamanho fixo, cada um com seu
próprio endereço. Tamanhos de blocos comuns variam de 512 a 65.536 bytes.
Todas as transferências são em unidades de um ou mais blocos inteiros (con-
secutivos). A propriedade essencial de um dispositivo de bloco é que cada blo-
co pode ser lido ou escrito independentemente de todos os outros. Discos rígi-
dos, discos blu-ray e pen drives são dispositivos de bloco comuns.
O limite entre dispositivos que são endereçáveis por blocos e aqueles que não
são não é bem definido. Um disco é um dispositivo endereçável por bloco, pois
não importa a posição em que se encontra o braço no momento, é sempre pos-
sível buscar em outro cilindro e então esperar que o bloco solicitado gire sob a
cabeça. Agora considere um velho dispositivo de fita magnética ainda usado,
às vezes, para realizar backups de disco (porque fitas são baratas). Fitas con-
têm uma sequência de blocos. Se o dispositivo de fita receber um comando
para ler o bloco “N”, ele sempre pode rebobiná-la e ir direto até chegar ao bloco
“N”. Essa operação é análoga a um disco realizando uma busca, exceto por le-
var muito mais tempo. Também pode ou não ser possível reescrever um bloco
no meio de uma fita. Mesmo que fosse possível usar as fitas como dispositivos
de bloco com acesso aleatório, isso seria forçar o ponto de algum modo: em
geral elas não são usadas dessa maneira. TANENBAUM (2016).
O outro dispositivo de E/S é o de caractere. Um dispositivo de caractere envia
ou aceita um fluxo de caracteres, desconsiderando qualquer estrutura de bloco.
Ele não é endereçável e não tem qualquer operação de busca. Impressoras, in-
terfaces de rede, mouses (para apontar), ratos (para experimentos de psicolo-
gia em laboratórios) e a maioria dos outros dispositivos que não são parecidos
com discos podem ser vistos como dispositivos de caracteres. TANENBAUM
(2016).
Esse esquema de classificação não é perfeito. Alguns dispositivos não se en-

quadram nele. Relógios, por exemplo, não são endereçáveis por blocos. Tam-
pouco geram ou aceitam fluxos de caracteres. Tudo o que fazem é causar in-
terrupções em intervalos bem definidos. TANENBAUM (2016).
As telas mapeadas na memória não se enquadram bem no modelo também.

Tampouco as telas de toque, quanto a isso. Ainda assim, o modelo de dispositi-
vos de blocos e de caractere é suficientemente geral para ser usado como uma
base para fazer alguns dos softwares do sistema operacional que tratam de
E/S independentes dos dispositivos. O sistema de arquivos, por exemplo, lida
apenas com dispositivos de blocos abstratos e deixa a parte dependente de
dispositivos para softwares de nível mais baixo. TANENBAUM (2016).
Dispositivos de E/S cobrem uma ampla gama de velocidades, o que coloca

uma pressão considerável sobre o software para desempenhar bem através
de muitas ordens de magnitude em taxas de transferência de dados. A Figura
5.1 mostra as taxas de dados de alguns dispositivos comuns. A maioria desses
dispositivos tende a ficar mais rápida com o passar do tempo. TANENBAUM
(2016).
1.1.2 Controladores de dispositivos
Nas palavras de Tanenbaum (2016), unidades de E/S consistem, em geral, de

um componente mecânico e um componente eletrônico. É possível separar as
duas porções para permitir um projeto mais modular e geral. O componente
eletrônico é chamado de controlador do dispositivo ou adaptador. Em computa-
dores pessoais, ele muitas vezes assume a forma de um chip na placa-mãe ou
um cartão de circuito impresso que pode ser inserido em um slot de expansão
(PCIe). O componente mecânico é o dispositivo em si.
O cartão controlador costuma ter um conector, no qual um cabo levando ao dis-

positivo em si pode ser conectado. Muitos controladores podem lidar com dois,
quatro ou mesmo oito dispositivos idênticos. Se a interface entre o controla-
dor e o dispositivo for padrão, seja um padrão oficial ANSI, IEEE ou ISO, então
as empresas podem produzir controladores ou dispositivos que se enquadrem
àquela interface. Muitas empresas, por exemplo, produzem controladores de
disco compatíveis com as interfaces SATA, SCSI, USB, Thunderbolt ou FireWi-
re (IEEE 1394). TANENBAUM (2016).
A interface entre o controlador e o dispositivo muitas vezes é de nível muito

baixo. Um disco, por exemplo, pode ser formatado com 2 milhões de setores
de 512 bytes por trilha. No entanto, o que realmente sai da unidade é um fluxo
serial de bits, começando com um preâmbulo, então os 4096 bits em um setor,
e por fim uma soma de verificação (checksum), ou código de correção de erro
(ECC — Error Correcting Code). O preâmbulo é escrito quando o disco é for-
matado e contém o cilindro e número de setor, e dados similares, assim como
informações de sincronização. TANENBAUM (2016).
O trabalho do controlador é converter o fluxo serial de bits em um bloco de

bytes, assim como realizar qualquer correção de erros necessária. O bloco de
bytes é tipicamente montado primeiro, bit por bit, em um buffer dentro do con-
trolador. Após a sua soma de verificação ter sido verificada e o bloco ter sido
declarado livre de erros, ele pode então ser copiado para a memória principal.
TANENBAUM (2016).
O controlador para um monitor LCD também funciona um pouco como um dis-

positivo serial de bits em um nível igualmente baixo. Ele lê os bytes contendo
os caracteres a serem exibidos da memória e gera os sinais para modificar a
polarização da retroiluminação para os pixels correspondentes a fim de escre-
vê-los na tela. Se não fosse pelo controlador de tela, o programador do sistema
operacional teria de programar explicitamente os campos elétricos de todos os
pixels. Com o controlador, o sistema operacional o inicializa com alguns parâ-
metros, como o número de caracteres ou pixels por linha e o número de linhas
por tela, e deixa o controlador cuidar realmente da orientação dos campos elé-
tricos. TANENBAUM (2016).
1.1.3 E/S mapeada na memória
Tanenbaum (2016), afirma que cada controlador tem alguns registradores que
são usados para comunicar-se com a CPU. Ao escrever nesses registradores,
o sistema operacional pode comandar o dispositivo a fornecer e aceitar dados,
ligar-se e desligar-se, ou de outra maneira realizar alguma ação. Ao ler a partir
desses registradores, o sistema operacional pode descobrir qual é o estado do
dispositivo, se ele está preparado para aceitar um novo comando e assim por
diante.
Além dos registradores de controle, muitos dispositivos têm um buffer de dados
a partir do qual o sistema operacional pode ler e escrever. Por exemplo, uma
maneira comum para os computadores exibirem pixels na tela é ter uma RAM
de vídeo, que é basicamente apenas um buffer de dados, disponível para ser
escrita pelos programas ou sistema operacional. TANENBAUM (2016).
A questão que surge então é como a CPU se comunica com os registradores

de controle e também com os buffers de dados do dispositivo. Existem duas
alternativas. Na primeira abordagem, para cada registrador de controle é de-
signado um número de porta de E/S, um inteiro de 8 ou 16 bits. O conjunto de
todas as portas de E/S formam o espaço de E/S, que é protegido de maneira
que programas de usuário comuns não consigam acessá-lo (apenas o sistema
operacional). TANENBAUM (2016).
A segunda abordagem, introduzida com o PDP-11, é mapear todos os regis-

tradores de controle no espaço da memória. Para cada registrador de controle
é designado um endereço de memória único para o qual nenhuma memória é
designada. Esse sistema é chamado de E/S mapeada na memória. Na maio-
ria dos sistemas, os endereços designados estão no — ou próximos do topo
do espaço de endereçamento. Um esquema híbrido, com buffers de dados de
E/S mapeados na memória e portas de E/S separadas para os registradores de
controle. TANENBAUM (2016).
Em todos os casos, quando a CPU quer ler uma palavra, seja da memória ou
de uma porta de E/S, ela coloca o endereço de que precisa nas linhas de en-
dereçamento do barramento e então emite um sinal READ sobre uma linha de
controle do barramento. Uma segunda linha de sinal é usada para dizer se o
espaço de E/S ou o espaço de memória é necessário. Se for o espaço de me-
mória, a memória responde ao pedido. Se for o espaço de E/S, o dispositivo de
E/S responde ao pedido. Se houver apenas espaço de memória, cada módulo
de memória e cada dispositivo de E/S comparam as linhas de endereços com
a faixa de endereços que elas servem. Se o endereço cair na sua faixa, ela
responde ao pedido. Tendo em vista que nenhum endereço jamais é designado
tanto à memória quanto a um dispositivo de E/S, não há ambiguidade ou confli-
to. TANENBAUM (2016).
1.2. Princípios do Software de Entrada e Saída
Vamos agora deixar de lado o hardware de E/S e examinar o software de E/S.

Primeiro analisaremos suas metas e então as diferentes maneiras que a E/S
pode ser feita do ponto de vista do sistema operacional.
1.1.4 Objetivos do software de E/S
Um conceito fundamental, Tanenbaum (2016) recorda que o projeto de softwa-

re de E/S é conhecido como independência de dispositivo. O que isso significa
é que devemos ser capazes de escrever programas que podem acessar qual-
quer dispositivo de E/S sem ter de especificá-lo antecipadamente. Por exem-
plo, um programa que lê um arquivo como entrada deve ser capaz de ler um
arquivo em um disco rígido, um DVD ou em um pen-drive sem ter de ser modi-
ficado para cada dispositivo diferente.
Similarmente, deveria ser possível digitar um comando como “sort <input >ou-
tput” que trabalhe com uma entrada vinda de qualquer tipo de disco ou teclado
e a saída indo para qualquer tipo de disco ou tela. Fica a cargo do sistema
operacional cuidar dos problemas causados pelo fato de que esses dispositivos
são realmente diferentes e exigem sequências de comando muito diferentes
para ler ou escrever. TANENBAUM (2016).
Um objetivo muito relacionado com a independência do dispositivo é a nomea

ção uniforme. O nome de um arquivo ou um dispositivo deve simplesmente ser
uma cadeia de caracteres ou um número inteiro e não depender do dispositivo
de maneira alguma. No UNIX, todos os discos podem ser integrados na hierar-
quia do sistema de arquivos de maneiras arbitrárias, então o usuário não preci-
sa estar ciente de qual nome corresponde a qual dispositivo. Por exemplo, um
pen-drive pode ser montado em cima do diretório /usr/ast/backup de maneira
que, ao copiar um arquivo para /usr/ast/backup/Monday, você copia o arquivo
para o pen-drive. Assim, todos os arquivos e dispositivos são endereçados da
mesma maneira: por um nome de caminho. TANENBAUM (2016).
Outra questão importante para o software de E/S é o tratamento de erros. Em

geral, erros devem ser tratados o mais próximo possível do hardware. Se o
controlador descobre um erro de leitura, ele deve tentar corrigi-lo se puder. Se
ele não puder, então o driver do dispositivo deverá lidar com ele, talvez sim-
plesmente tentando ler o bloco novamente. Muitos erros são transitórios, como
erros de leitura causados por grãos de poeira no cabeçote de leitura, e muitas
vezes desaparecerão se a operação for repetida. Apenas se as camadas mais
baixas não forem capazes de lidar com o problema as camadas superiores de-
vem ser informadas a respeito. Em muitos casos, a recuperação de erros pode
ser feita de modo transparente em um nível baixo sem que os níveis superiores
sequer tomem conhecimento do erro. TANENBAUM (2016).
Ainda outra questão importante é a das transferências síncronas (bloqueantes)
versus assíncronas (orientadas à interrupção). A maioria das E/S físicas são
assíncronas - a CPU inicializa a transferência e vai fazer outra coisa até a che-
gada da interrupção. Programas do usuário são muito mais fáceis de escrever
se as operações de E/S forem bloqueantes — após uma chamada de sistema
read, o programa é automaticamente suspenso até que os dados estejam dis-
poníveis no buffer. Fica a cargo do sistema operacional fazer operações que
são realmente orientadas à interrupção parecerem bloqueantes para os pro-
gramas do usuário. No entanto, algumas aplicações de muito alto desempenho
precisam controlar todos os detalhes da E/S, então alguns sistemas operacio-
nais disponibilizam a E/S assíncrona para si. TANENBAUM (2016).
Outra questão para o software de E/S é a utilização de buffer. Muitas vezes,

dados provenientes de um dispositivo não podem ser armazenados diretamen-
te em seu destino final. Por exemplo, quando um pacote chega da rede, o sis-
tema operacional não sabe onde armazená-lo definitivamente até que o tenha
colocado em algum lugar para examiná-lo. Também, alguns dispositivos têm
severas restrições de tempo real (por exemplo, dispositivos de áudio digitais),
portanto os dados devem ser colocados antecipadamente em um buffer de sa-
ída para separar a taxa na qual o buffer é preenchido da taxa na qual ele é
esvaziado, a fim de evitar seu completo esvaziamento. A utilização do buffer
envolve consideráveis operações de cópia e muitas vezes tem um impacto im-
portante sobre o desempenho de E/S. TANENBAUM (2016).
1.1.5 E/S programada
Tanenbaum (2016), afirma que a forma mais simples de E/S é ter a CPU rea-
lizando todo o trabalho. Esse método é chamado de E/S programada. É mais
simples ilustrar como a E/S programada funciona mediante um exemplo. Con-
sidere um processo de usuário que quer imprimir a cadeia de oito caracteres
“ABCDEFGH” na impressora por meio de uma interface serial. Telas em peque-
nos sistemas embutidos funcionam assim às vezes. O software primeiro monta
a cadeia de caracteres em um buffer no espaço do usuário.
O processo do usuário requisita então a impressora para escrita fazendo uma

chamada de sistema para abri-la. Se a impressora estiver atualmente em uso
por outro processo, a chamada fracassará e retornará um código de erro ou
bloqueará até que a impressora esteja disponível, dependendo do sistema ope-
racional e dos parâmetros da chamada. Uma vez que ele tenha a impresso-
ra, o processo do usuário faz uma chamada de sistema dizendo ao sistema
operacional para imprimir a cadeia de caracteres na impressora. TANENBAUM
(2016).
O sistema operacional então copia o buffer com a cadeia de caracteres para
um vetor no espaço do núcleo, onde ele é mais facilmente acessado (pois o nú-
cleo talvez tenha de mudar o mapa da memória para acessar o espaço do usu-
ário). Ele então confere para ver se a impressora está disponível no momento.
Se não estiver, ele espera até que ela esteja. TANENBAUM (2016).
Tão logo a impressora esteja disponível, o sistema operacional copia o primeiro

caractere para o registrador de dados da impressora, nesse exemplo usando
a E/S mapeada na memória. Essa ação ativa a impressora. O caractere pode
não aparecer ainda porque algumas impressoras armazenam uma linha ou
uma página antes de imprimir qualquer coisa. Na Figura 5.1(b), no entanto, ve-
mos que o primeiro caractere foi impresso e que o sistema marcou o “B” como
o próximo caractere a ser impresso. TANENBAUM (2016).
Figura 5.1 Estágios na impressão de uma cadeia de caracteres.

Tão logo copiado o primeiro caractere para a impressora, o sistema operacio-

nal verifica se ela está pronta para aceitar outro. Geralmente, a impressora tem
um segundo registrador, que contém seu estado. O ato de escrever para o re-
gistrador de dados faz que o estado torne-se “indisponível”. Quando o controla-
dor da impressora tiver processado o caractere atual, ele indica a sua disponi-
bilidade marcando algum bit em seu registrador de status ou colocando algum
valor nele. TANENBAUM (2016).
Nesse ponto, o sistema operacional espera que a impressora fique pronta de

novo. Quando isso acontece, ele imprime o caractere seguinte. Esse laço conti-
nua até que a cadeia inteira tenha sido impressa. Então o controle retorna para
o processo do usuário. TANENBAUM (2016).
Quanto as ações seguidas pelo sistema operacional, primeiro os dados são co-
piados para o núcleo. Então o sistema operacional entra em um laço fechado,
enviando um caractere de cada vez para a saída. O aspecto essencial da E/S
programada, claramente ilustrado nessa figura, é que, após a saída de um ca-
ractere, a CPU continuamente verifica o dispositivo para ver se ele está pron-
to para aceitar outro. Esse comportamento é muitas vezes chamado de espe-
ra ocupada (busy waiting) ou polling. A E/S programada é simples, mas tem a
desvantagem de segurar a CPU o tempo todo até que toda a E/S tenha sido
feita. Se o tempo para “imprimir” um caractere for muito curto (pois tudo o que
a impressora está fazendo é copiar o novo caractere para um buffer interno),
então a espera ocupada estará bem. No entanto, em sistemas mais complexos,
em que a CPU tem outros trabalhos a fazer, a espera ocupada será ineficiente,
e será necessário um método de E/S melhor. TANENBAUM (2016).
1.1.6 E/S orientada a interrupções
Agora vamos considerar o caso da impressão em uma impressora que não ar-
mazena caracteres, mas imprime cada um à medida que ele chega. Se a im-
pressora puder imprimir, digamos, 100 caracteres/segundo, cada caractere le-
vará 10 ms para imprimir. Isso significa que após cada caractere ter sido escri-
to no registrador de dados da impressora, a CPU vai permanecer em um laço
ocioso por 10 ms esperando a permissão para a saída do próximo caractere.
Isso é mais tempo do que o necessário para realizar um chaveamento de con-
texto e executar algum outro processo durante os 10ms que de outra maneira
seriam desperdiçados. TANENBAUM (2016).
A maneira de permitir que a CPU faça outra coisa enquanto espera que a im-
pressora fique pronta é usar interrupções. Quando a chamada de sistema para
imprimir a cadeia é feita, o buffer é copiado para o espaço do núcleo, como já
mostramos, e o primeiro caractere é copiado para a impressora tão logo ela
esteja disposta a aceitar um caractere. Nesse ponto, a CPU chama o esca-
lonador e algum outro processo é executado. O processo que solicitou que a
cadeia seja impressa é bloqueado até que a cadeia inteira seja impressa. TA-
NENBAUM (2016).
Quando a impressora imprimiu o caractere e está preparada para aceitar o pró-

ximo, ela gera uma interrupção. Essa interrupção para o processo atual e salva
seu estado. Então a rotina de tratamento de interrupção da impressora é exe-
cutada. Uma versão simples desse código é mostrada na Figura 5.9(b). Se não
houver mais caracteres a serem impressos, o tratador de interrupção executa
alguma ação para desbloquear o usuário. Caso contrário, ele sai com o carac-
tere seguinte, reconhece a interrupção e retorna ao processo que estava sendo
executado um momento antes da interrupção, o qual continua a partir do ponto
em que ele parou. TANENBAUM (2016).
1.1.7 E/S usando DMA
Nas palavras de Tanenbaum (2016), uma desvantagem óbvia do mecanismo

de E/S orientado a interrupções é que uma interrupção ocorre em cada ca-
ractere. Interrupções levam tempo; portanto, esse esquema desperdiça certa
quantidade de tempo da CPU. Uma solução é usar o acesso direto à memória
(DMA). Aqui a ideia é deixar que o controlador de DMA alimente os caracteres
para a impressora um de cada vez, sem que a CPU seja incomodada. Na es-
sência, o DMA executa E/S programada, apenas com o controlador do DMA
realizando todo o trabalho, em vez da CPU principal. Essa estratégia exige um
hardware especial (o controlador de DMA), mas libera a CPU durante a E/S
para fazer outros trabalhos.
A grande vantagem do DMA é reduzir o número de interrupções de uma por

caractere para uma por buffer impresso. Se houver muitos caracteres e as in-
terrupções forem lentas, esse sistema poderá representar uma melhoria impor-
tante. Por outro lado, o controlador de DMA normalmente é muito mais lento do
que a CPU principal. Se o controlador de DMA não é capaz de dirigir o dispo-
sitivo em velocidade máxima, ou a CPU normalmente não tem nada para fazer
de qualquer forma enquanto esperando pela interrupção do DMA, então a E/S
orientada à interrupção ou mesmo a E/S programada podem ser melhores. Na
maioria das vezes, no entanto, o DMA vale a pena. TANENBAUM (2016).
2. SISTEMAS DISTRIBUÍDOS
2.1 Atributos de Sistemas Distribuídos

Durante décadas, pesquisadores e profissionais enfatizaram a importância de
sistemas distribuídos. A explosão da Internet que ocorreu com a popularização
da World Wide Web, em 1993, tomou os sistemas distribuídos comuns. Esta
seção discute desempenho, escalabilidade, conectividade, segurança, confiabi-
lidade e tolerância a falhas em sistemas distribuídos. TANENBAUM (2016).
2.1.1 Desempenho e escalabilidade
Para Tanenbaum (2016), em um sistema centralizado, um único servidor trata

todas as requisições de usuários. Com um sistema distribuído, as requisições
de usuários podem ser enviadas a diferentes servidores que trabalham em pa-
ralelo para aumentar o desempenho. Escalabilidade permite que um sistema
distribuído cresça (adicione mais máquinas ao sistema) sem afetar as aplica-
ções e os usuários existentes.
2.1.2 Conectividade e segurança
De acordo com Tanenbaum (2016), um sistema distribuído pode fornecer aces-

so sem descontinuidade a recursos distribuídos através da rede. Se o recur-
so for um processador, o sistema distribuído deverá permitir que tarefas sejam
executadas em qualquer máquina. Se o recurso for um sistema de arquivos
globalmente compartilhado, usuários remotos poderão acessá-lo como aces-
sam um sistema de arquivo local, privado. Por exemplo, um usuário deve poder
navegar pelo sistema de arquivo e abri-lo por meio de um navegador gráfico ou
interpretador de comandos em vez de conectar-se a um programa FTP.
Conectividade em sistemas distribuídos requer protocolos de comunicação.

Protocolos devem fornecer interfaces comuns a todos os computadores do sis-
tema. Muitos sistemas distribuídos requerem comunicação de informação de
estado para manter uma operação eficiente. Informação de estado consiste em
dados que descrevem o estado de um ou mais recursos.
Informação de estado inadequada pode resultar em inconsistência; muitas ve-

zes transmitir esse tipo de informação pode inundar a rede e reduzir a escala-
bilidade. Projetistas de sistemas distribuídos devem determinar que informação
de estado manter e com que frequência o sistema deve tomar conhecimento
dela. TANENBAUM (2016).
Sistemas distribuídos podem ser suscetíveis a ataques de usuários mal- inten-
cionados se dependerem de meios de comunicação inseguros (por exemplo,
uma rede pública). Para melhorar a segurança, sistemas distribuídos devem
permitir que apenas usuários autorizados acessem recursos e garantir que a
informação transmitida pela rede somente possa ser lida pelos recipientes pre-
tendidos. E, também, pelo fato de muitos usuários ou objetos poderem requisi-
tar recursos, o sistema deverá fornecer mecanismos para protegê-los contra-a-
taques. TANENBAUM (2016).
2.1.3 Confiabilidade e tolerância a falhas
Para Tanenbaum (2016), a falha de um ou mais recursos em máquinas isola-

das pode fazer com que todo o sistema tenha problemas ou pode afetar o de-
sempenho de processos que executam no sistema. Sistemas distribuídos estão
mais propensos a falhas do que os de uma máquina isolada, pois têm mais
componentes sujeitos a pane.
Sistemas distribuídos implementam tolerância a falhas fornecendo replicação

de recursos através do sistema. A falha de qualquer um dos computadores iso-
lados não afetará a disponibilidade dos recursos do sistema. Por exemplo, um
sistema de arquivo distribuído poderia manter cópias do mesmo arquivo em
servidores diferentes. Se um usuário estiver usando um arquivo de um servidor
que falhar, o sistema de arquivo distribuído poderá dirigir futuras requisições a
um servidor que tenha uma cópia do arquivo original. A replicação oferece aos
usuários maior confiabilidade e disponibilidade em relação a implementações
de máquinas isoladas. TANENBAUM (2016).
Contudo, isso tem um custo. Projetistas de sistemas distribuídos devem desen-

volver software que detecta e reaja a falhas de sistema. E devem, ainda, forne-
cer mecanismos para assegurar a consistência entre informações de estado de
máquinas diferentes. Esses sistemas também precisam estar equipados para
reintegrar recursos que falharam, logo que sejam reparados. TANENBAUM
(2016).
2.1.4 Transparência
Segundo Tanenbaum (2016), um dos objetivos de sistemas distribuídos é for-

necer transparência, ocultando os aspectos distribuídos dos usuários do siste-
ma. O acesso a um sistema de arquivo distribuído por diversos computadores
remotos não deve ser diferente do acesso a um sistema de arquivo local. O
usuário de um sistema de arquivo distribuído deve poder acessar seus recur-
sos sem precisar saber nada sobre a comunicação entre os processos, quais
processos executam a requisição do usuário e a localização física dos recur-
sos.
O ISO Open Distributed Processing Reference Model define oito tipos de trans-
parência que sistemas distribuídos podem fornecer:
• transparência de acesso
• transparência de localização
• transparência de falha
• transparência de replicação
• transparência de persistência
• transparência de migração
• transparência de relocação
• transparência de transação
Transparência de acesso oculta os detalhes de protocolos de rede que habili-

tam a comunicação entre computadores distribuídos. Também fornece um meio
universal de acesso a dados armazenados em diferentes formatos de dados
em todo o sistema. TANENBAUM (2016).
Transparência de localização aproveita a transparência de acesso para ocul-

tar a localização de recursos no sistema distribuído daqueles que estão ten-
tando acessá-los. Um sistema de arquivo distribuído que fornece transparência
de localização permite acesso a arquivos remotos como se fossem locais. TA-
NENBAUM (2016).
Transparência de falha é o método pelo qual um sistema distribuído fornece to-

lerância a falhas. Se um ou mais recursos ou computadores da rede falharem,
os usuários do sistema perceberão apenas a redução do desempenho. Trans-
parência de falha normalmente é implementada por replicação ou por ponto de
verificação/recuperação. Com replicação, um sistema fornece vários recursos
que executam a mesma função. Mesmo que todos os recursos, exceto um, de
um conjunto de recursos replicados falhem, um sistema distribuído poderá con-
tinuar a funcionar. Sistemas que empregam ponto de verificação periodicamen-
te armazenam a informação de estado de um objeto (como um processo) de tal
maneira que esse pode ser restaurado (recuperado) se uma falha no sistema
distribuído resultar na perda do objeto. TANENBAUM (2016).
Transparência de replicação oculta o fato de que há várias cópias de um recur-
so disponíveis no sistema; todos os acessos a um grupo de recursos replicados
ocorrem como se houvesse um só desses recursos disponível. Transparência
de persistência oculta a informação sobre o lugar onde esse recurso está arma-
zenado na memória ou em disco. TANENBAUM (2016).
Transparência de migração ou transparência de relocação ocultam a movi-

mentação de componentes através de um sistema distribuído. Transparência
de migração máscara a movimentação de um objeto de uma localização para
outra no sistema, tal como a transferência de um arquivo de um servidor para
outro; transparência de relocação máscara a relocação de um objeto por meio
de outros objetos que se comunicam com ele. Por fim, transparência de tran-
sação permite que um sistema obtenha consistência mascarando a coordena-
ção entre um conjunto de recursos. Transações incluem requisições de servi-
ços (como acesso a arquivos e chamadas à função) que mudam o estado do
sistema. Consequentemente, transações muitas vezes requerem ponto de ve-
rificação ou replicação para cumprir outras metas do sistema distribuído; trans-
parência de transação oculta a implementação desses serviços. TANENBAUM
(2016).
2.2 Sistemas Operacionais de Rede
Tanenbaum (2016), afirma que sistemas distribuídos são construídos sobre

redes de computadores, então é necessária uma breve introdução para o as-
sunto. As redes existem em duas variedades principais, LANs (Local Area Ne-
tworks — redes locais), que cobrem um prédio ou um campus e WANs (Wide
Area Networks — redes de longa distância), que podem cobrir uma cida-
de inteira, um país inteiro, ou todo o mundo. O tipo mais importante de LAN
é a Ethernet, então a examinaremos como um exemplo de LAN. Como nos-
so exemplo de WAN, examinaremos a internet, embora tecnicamente a internet
não seja apenas uma rede, mas uma federação de milhares de redes separa-
das. No entanto, para os nossos propósitos, é suficiente pensá-la como uma
WAN.
2.2.1 Ethernet
Como aponta Tanenbaum (2016), a Ethernet clássica, que é descrita no padrão

IEEE Standard 802.3, consiste em um cabo coaxial ao qual uma série de com-
putadores está ligada. O cabo é chamado de Ethernet, em referência ao éter
luminoso (luminiferous ether) através do qual acreditava-se antigamente que a
radiação eletromagnética se propagava. (Quando o físico britânico do século
XIX James Clerk Maxwell descobriu que a radiação eletromagnética podia ser
descrita por uma equação de onda, os cientistas presumiram que o espaço de-
via estar cheio com algum elemento etéreo no qual a radiação estava se propa-
gando.
Apenas após o famoso experimento de Michelson-Morley em 1887, que fracas-

sou em detectar o éter, os físicos perceberam que a radiação podia propagar-
-se no vácuo). TANENBAUM (2016).
Na primeiríssima versão da Ethernet, um computador era ligado ao cabo lite-

ralmente abrindo um buraco no meio do cabo e enfiando um fio que levava ao
computador. Esse conector era chamado de conector. Esses conectores eram
difíceis de acertar direito, então não levou muito tempo para que conectores
apropriados fossem usados. Mesmo assim, eletricamente, todos os computa-
dores eram conectados como se os cabos em suas placas de interface de rede
estivessem soldados juntos. TANENBAUM (2016).
Com muitos computadores conectados ao mesmo cabo, um protocolo é neces-

sário para evitar o caos. Para enviar um pacote na Ethernet, um computador
primeiro escuta o cabo para ver se algum outro computador está transmitindo
no momento. Se não estiver, ele começa a transmitir um pacote, que consiste
em um cabeçalho curto seguido de 0 a 1.500 bytes de informação. Se o cabo
estiver em uso, o computador apenas espera até a transmissão atual terminar,
então ele começa a enviar. TANENBAUM (2016).
Se dois computadores começam a transmitir simultaneamente, resulta em uma

colisão, que ambos detectam. Ambos respondem terminando suas transmis-
sões, esperando por um tempo aleatório entre 0 e T μs e então iniciando de
novo. Se outra colisão ocorrer, todos os computadores esperam um tempo ale-
atório no intervalo de 0 a 2T μs, e então tentam novamente. Em cada colisão
seguinte, o intervalo de espera máximo é dobrado, reduzindo a chance de mais
colisões. Esse algoritmo é conhecido como recuo exponencial binário. Nós o
mencionamos anteriormente para reduzir a sobrecarga na espera por variáveis
de travamento. TANENBAUM (2016).
Uma rede Ethernet tem um comprimento de cabo máximo e também um nú-

mero máximo de computadores que podem ser conectadas a ela. Para superar
qualquer um desses limites, um prédio grande ou campus podem ser ligados a
várias Ethernets, que são então conectadas por dispositivos chamados de pon-
tes. Uma ponte é um dispositivo que permite o tráfego passar de uma Ethernet
para outra quando a fonte está de um lado e o destino do outro. TANENBAUM
(2016).
Para evitar o problema de colisões, Ethernets modernas usam comutadores.
Cada comutador tem algum número de portas, às quais podem ser ligados
computadores, uma Ethernet, ou outro comutador. Quando um pacote evita
com sucesso todas as colisões e chega ao comutador, ele é armazenado em
um buffer e enviado pela porta que acessa a máquina destinatária. Ao dar a
cada computador a sua própria porta, todas as colisões podem ser eliminadas,
ao custo de comutadores maiores. Um meio-termo, com apenas alguns compu-
tadores por porta, também é possível. TANENBAUM (2016).
2.2.2 Internet
Como aponta Tanenbaum (2016), a internet evoluiu da ARPANET, uma rede

experimental de comutação de pacotes fundada pela Agência de Projetos de
Pesquisa Avançados do Departamento de Defesa dos Estados Unidos. Ela foi
colocada em funcionamento em dezembro de 1969 com três computadores na
Califórnia e um em Utah. Ela foi projetada no auge da Guerra Fria para ser
uma rede altamente tolerante a falhas que continuaria a transmitir tráfego mi-
litar mesmo no evento de ataques nucleares diretos sobre múltiplas partes da
rede ao automaticamente desviar o tráfego das máquinas atingidas.
A ARPANET cresceu rapidamente na década de 1970, por fim compreendendo

centenas de computadores. Então uma rede de pacotes via rádio, uma rede de
satélites e por fim milhares de Ethernets foram ligadas a ela, levando à federa-
ção de redes que conhecemos hoje como internet. TANENBAUM (2016).
A internet consiste em dois tipos de computadores, hospedeiros (hosts) e rote-

adores. Hospedeiros são PCs, notebooks, smartphones, servidores, computa-
dores de grande porte e outros computadores de propriedade de indivíduos ou
companhias que querem conectar-se à internet. Roteadores são computadores
de comutação especializados que aceitam pacotes que chegam de uma das
muitas linhas de entrada e os enviam para fora ao longo das muitas linhas de
saída.
Um roteador é similar ao comutador da Figura 8.28(b), mas também difere dele

de maneiras que não abordaremos aqui. Roteadores são conectados em gran-
des redes, com cada roteador tendo cabos ou fibras para muitos outros rotea-
dores e hospedeiros. Grandes redes de roteadores nacionais ou mundiais são
operadas por companhias telefônicas e ISPs (Internet Service Providers — pro-
vedores de serviços de internet) para seus clientes. TANENBAUM (2016).
Todo tráfego na internet é enviado na forma de pacotes. Cada pacote carrega
dentro de si seu endereço de destino, e esse endereço é usado para o rote-
amento. Quando um pacote chega a um roteador, este extrai o endereço de
destino e o compara (parte dele) em uma tabela para encontrar para qual linha
de saída enviar o pacote e assim para qual roteador. Esse procedimento é re-
petido até o pacote chegar ao hospedeiro de destino. TANENBAUM (2016).
As tabelas de roteamento são altamente dinâmicas e atualizadas continua-

mente à medida que os roteadores e as conexões caem e voltam, assim como
quando as condições de tráfego mudam. Os algoritmos de roteamento foram
intensamente estudados e modificados com o passar dos anos. TANENBAUM
(2016).
2.3 Comunicação em Sistemas Distribuídos
Segundo Tanenbaum (2016), um dos desafios primordiais do projeto de siste-

mas distribuídos é gerenciar a comunicação entre computadores. Projetistas
devem estabelecer interoperabilidade entre computadores e aplicações hetero-
gêneas. Nos primeiros anos da computação distribuída, processos se comuni-
cavam chamando funções por meio de processos localizados em computado-
res remotos. Muitas das aplicações atuais, contudo, requerem interação entre
objetos remotos via chamadas a método.
Interoperabilidade permite que componentes de software interajam entre har-

dwares e plataformas de software diferentes, linguagens de programação e
protocolos de comunicação distintos. Uma interface permite que sistemas hete-
rogêneos se comuniquem de modo significativo para ambos os lados — promo-
vendo a interoperabilidade. TANENBAUM (2016).
No modelo cliente/servidor, o cliente emite uma requisição ao servidor através

da rede e este processa a requisição e envia a resposta de volta ao computa-
dor cliente, frequentemente usando uma interface para auxiliar a comunicação.
Uma interface padronizada permite que cada par cliente/servidor se comuni-
que utilizando uma interface única, comum, entendida por ambos os lados. TA-
NENBAUM (2016).
2.3.1 Middleware
De acordo com Tanenbaum (2016), as máquinas que compõem sistemas dis-

tribuídos em geral são heterogêneas - hardware diferente executando sistemas
operacionais diferentes e se comunicando através de arquiteturas diferentes.
Em tais ambientes, o programador de aplicações tende a gastar muito tempo
e a cometer erros para fornecer as rotinas de conversão de mensagens entre
computadores.
Softwares conhecidos como middleware ajudam a fornecer portabilidade, trans-

parência e interoperabilidade em sistemas distribuídos. Portabilidade habilita a
mudança de um sistema ou componente (incluindo ambos, software e hardwa-
re) de um ambiente para outro sem alterar o sistema ou componente que está
sendo transferido. TANENBAUM (2016).
Considere um cliente que pague as mercadorias que comprou com um che-

que (emitido por um banco para que ele possa usar em suas transações). Ao
receber o cheque, o comerciante pode compensá-lo em qualquer banco (mes-
mo por aquele que não tenha emitido o cheque), que executa operações trans-
parentemente para validar a transação e processar a transferência de fundos.
Nesse exemplo, o banco (ou bancos) representa o middleware, e o comercian-
te e o cliente representam dois computadores de um sistema distribuído. Se-
melhante aos bancos, o middleware executa operações de maneira transparen-
te para validar transações e iniciar comunicação na rede. TANENBAUM (2016).
O middleware fornece o mecanismo para simplificar transações. Em vez de ir

ao banco para sacar fundos, pagar o comerciante e fazer com que este vá a
outro banco para depositar o dinheiro, o cliente pode simplesmente preencher
um cheque que o comerciante deposita diretamente. De modo similar, o mid-
dleware facilita comunicação e cooperação entre os vários componentes de
um sistema distribuído ocultando detalhes de implementação de baixo nível de
usuários e desenvolvedores de aplicações. TANENBAUM (2016).
Middleware fornece interfaces de programação padronizadas para habilitar co-

municação interprocessos entre computadores remotos. Essas interfaces pro-
porcionam portabilidade e transparência. TANENBAUM (2016).
2.3.2 Chamada a procedimento remoto (RPC)
Para Tanenbaum (2016), em meados da década de 1970 foi proposto o con-

ceito de chamada a procedimento remoto para proporcionar uma abordagem
estruturada, de alto nível, à comunicação entre processos em sistemas distri-
buídos. Uma chamada a procedimento remoto permite que um processo que
esteja em execução em um computador invoque um procedimento (ou função)
de um processo que esteja em execução em outro computador. Esse mecanis-
mo pressupõe um modelo cliente/servidor: o computador cliente que emite a
chamada ao procedimento remoto envia seus parâmetros pela rede ao servidor
onde reside o procedimento chamado. A execução ocorre no servidor, e o re-
sultado (o valor de retorno da função) então é transmitido pela rede ao cliente.
Um objetivo da RPC era simplificar o processo de escrita de aplicações dis-

tribuídas preservando a sintaxe de uma chamada a procedimento (ou função)
local e, ao mesmo tempo, iniciar transparentemente uma comunicação de rede.
Além da meta primária de simplicidade, a RPC também buscava ser eficiente e
segura. TANENBAUM (2016).
Para fornecer transparência aos programadores de sistemas distribuídos, a

RPC introduz o conceito de stub. Um stub prepara dados de saída para trans-
missão e traduz dados de entrada para que possam ser interpretados correta-
mente. Para emitir uma RPC, o processo cliente faz uma chamada (passando
os parâmetros apropriados) ao procedimento no stub do cliente. TANENBAUM
(2016).
O stub do cliente executa a montagem de dados, que empacota argumentos

de procedimento juntamente com o nome do procedimento em uma mensagem
para transmissão por uma rede. TANENBAUM (2016).
Para fazer a chamada ao procedimento remoto, o stub do cliente passa a men-

sagem (com parâmetros preparados) ao servidor. Ao receber a mensagem do
stub do cliente, o sistema operacional do servidor transmite a mensagem ao
stub do servidor. Então a mensagem é desmontada, e o stub envia os parâme-
tros ao procedimento local apropriado. Quando o procedimento for concluído, o
stub do servidor monta o resultado e o envia de volta ao cliente. Por fim, o stub
do cliente desmonta o resultado, notifica o processo e passa o resultado para
ele. Do ponto de vista do cliente, tudo isso parece apenas fazer uma chamada
ao procedimento local e receber o resultado de retorno — os elaborados meca-
nismos da RPC ficam ocultos.
Há diversas complicações associadas à RPC. Ela pode executar sobre TCP ou

UDP, o que significa que implementações diferentes podem oferecer níveis va-
riáveis de confiabilidade. Se a RPC estiver operando sobre UDP, então a imple-
mentação da RPC deve fornecer confiabilidade de comunicação. Além disso,
cada implementação de RPC pode oferecer um nível diferente de segurança.
TANENBAUM (2016).
Um outro problema é que o processo de emissão de uma RPC e de seu corres-

pondente stub de cliente residem em diferentes espaços de endereçamento de
memória. Isso dificulta a passagem de ponteiros como parâmetros, o que pode
limitar a transparência e a capacidade da RPC. Similarmente, a RPC não su-
porta variáveis globais, portanto, cada variável usada pelo procedimento deve
ser passada a ele como um argumento. TANENBAUM (2016).
Embora chamadas a procedimento remoto promovam interoperação em siste-

mas distribuídos, elas não são uma solução suficiente para o problema geral
da comunicação distribuída. Questões de desempenho e segurança levaram
ao desenvolvimento de protocolos de comunicação adicionais. TANENBAUM
(2016).
2.3.3 Invocação a método remoto (RMI)
Como aponta Tanenbaum (2016), o protocolo RPC Java, conhecido como invo-
cação a método remoto (Remote Method Invocation — RMI), habilita um pro-
cesso Java que está executando em um computador a invocar um método de
um objeto em um computador remoto usando a mesma sintaxe de uma chama-
da a método local.
Similar à RPC, os detalhes da montagem de parâmetros e transporte de men-

sagens por RMI são transparentes para o programa que emite a chamada. Um
benefício decisivo da RMI é que ela permite transmissão de objetos entre pro-
cessos remotos. A RMI permite que programadores Java implementem siste-
mas distribuídos sem ter de programar soquetes explicitamente. Três camadas
distintas de software caracterizam a arquitetura RMI: a camada de stub/esque-
leto, a camada remota de referência {Remote Reference Layer — RRL) e a ca-
mada de transporte. A camada de stub/esqueleto contém estruturas de mon-
tagem de parâmetros análogas às dos stubs de cliente e de servidor da RPC.
Um stub RMI é um objeto Java que reside na máquina cliente e que fornece
uma interface entre o processo cliente e o objeto remoto. Quando um processo
cliente invoca um método em um objeto remoto, o método do stub é chama-
do primeiro. O stub emprega serialização de objeto para criar sua mensagem
montada, característica que permite que objetos sejam codificados em corren-
tes de bytes e transmitidos de um espaço de endereçamento para outro. Seria-
lização de objetos habilita programas a passar objetos Java como parâmetros e
receber objetos como valores de retomo. TANENBAUM (2016).
Uma vez serializados pelo stub, parâmetros são enviados ao componente da
RRL do sistema RMI do lado cliente. A RRL usa a camada de transporte para
enviar a mensagem montada entre o cliente e o servidor. Quando o componen-
te da RRL do lado servidor recebe os parâmetros montados, ele os dirige ao
esqueleto, que desmonta os parâmetros, identifica o objeto sobre o qual o mé-
todo deve ser invocado e chama o método. Ao concluir o método, o esqueleto
monta o resultado e o devolve ao cliente via RRL e stub. TANENBAUM (2016).
2.3.4 CORBA (Common Object Request Broker Architecture)

Segundo Tanenbaum (2016), é uma especificação padrão de arquitetura de sis-
temas distribuídos que conquistou ampla aceitação. Concebida no início da dé-
cada de 1990 pelo Object Management Group (OMG), CORBA é um padrão
aberto elaborado para habilitar interoperação entre programas em sistemas he-
terogêneos, bem como homogêneos. Similar à RMI, CORBA suporta objetos
como parâmetros ou valores de retomo em procedimentos remotos durante co-
municação interprocessos. Entretanto, diferentemente da RMI (que é baseada
em Java), CORBA é independente de linguagem e de sistema, o que significa
que aplicações escritas em linguagens de programação diferentes e em siste-
mas operacionais diferentes operam entre si por meio de acesso a um núcleo
comum da arquitetura CORBA.
A estrutura dos sistemas distribuídos baseados em CORBA é relativamente

simples. O processo no cliente passa a chamada a procedimento juntamente
com os argumentos requeridos ao stub do cliente. O stub do cliente monta os
parâmetros e envia a chamada ao procedimento por meio de seu agente de
solicitação de objetos (Object Request Broker — ORB), que se comunica com
o ORB no servidor. O ORB no servidor então passa a chamada a procedimento
ao esqueleto do servidor, que desmonta os parâmetros e passa a chamada ao
procedimento remoto. TANENBAUM (2016).
CORBA fornece a seus usuários independência de linguagem por intermédio

da IDL (Interface Definition Language — linguagem de definição de interface).
A IDL permite que programadores definam estritamente os procedimentos que
podem ser chamados no objeto, o que é conhecido como a interface daque-
le objeto. Aplicações escritas em qualquer linguagem podem comunicar-se por
meio de CORBA seguindo a especificação IDL de cada objeto. TANENBAUM
(2016).
2.3.5 DCOM (Distributed Component Object Model)
Na década de 1990 a Microsoft desenvolveu sua própria arquitetura de objeto

distribuído denominada modelo de objeto componente distribuído (Distributed
Component Object Model — DCOM). O DCOM foi incluído no sistema opera-
cional Windows desde o Windows 95, e é o principal concorrente da CORBA
em computação de objeto distribuído. O DCOM é a extensão distribuída do mo-
delo de objeto componente (Component Object Model — COM) da Microsoft,
introduzido em 1993 para facilitar o desenvolvimento baseado em componen-
tes no ambiente Windows. A especificação COM foi elaborada para permitir que
componentes de software que residem em um único espaço de endereçamento
ou em diferentes espaços de endereçamento dentro de um computador isolado
interagem uns com os outros. OGLETREE (2002).
Como na CORBA, objetos DCOM são acessados via interfaces, o que permite
que objetos DCOM sejam escritos em várias linguagens de programação e em
diversas plataformas. Quando um cliente requisita um objeto DCOM de um ser-
vidor, também deve requisitar uma interface específica do objeto. A requisição
do cliente é enviada primeiramente ao stub do cliente (denominado proxy). O
stub do cliente se comunica através de uma rede com o stub do servidor que
repassa a requisição ao objeto DCOM específico. Quando o objeto DCOM con-
clui a requisição, envia o valor de retomo de volta ao stub do servidor. O stub
do servidor envia esse valor de volta pela rede ao proxy, que por fim retoma o
valor ao processo que chamou. TANENBAUM (2016).
SAIBA MAIS
Identifique e saiba como economizar energia utilizando de maneira consciente

os recursos do seu computador
< https://olhardigital.com.br/dicas_e_tutoriais/noticia/saiba-como-reduzir-o-con-
sumo-de-energia-do-seu-pc/66607 >.
5 dicas para reduzir gasto de energia no front office.

< http://computerworld.com.br/gestao/2007/12/13/idgnoti-
cia.2007-12-11.8087696216 >
REFLITA
Hora do planeta.
<https://www.youtube.com/watch?v=-WTJmkcUHvI&feature=youtu.be>.
Fonte: <http://www.tecmundo.com.br/energia/2145-mito-ou-verdade-o-compu-
tador-consome-muita-energia-e-aumenta-a-conta-de-luz-.htm>. Acesso em: 13
Jul. 2019.
Muitos são os dispositivos de entrada/saída e cada um possui uma finalidade.

O sistema operacional tem a difícil tarefa de entender o funcionamento de to-
dos eles. Esta tarefa é minimizada com o uso de drivers.
Entendemos como o controle do que foi solicitado chega até o processador e

as memórias principais e secundárias. Sem estes chipsets o sistema operacio-
nal iria ter uma sobrecarga de trabalho, pois além de gerenciar processos e a
memória, iria ter que cuidar das diversas requisições dos dispositivos e todo o
percurso na placa-mãe. Com estes chipsets o SO fica somente responsável por
monitorar as requisições de entrada e de saída dos diversos dispositivos co-
nectados no computador.
Além disto, vale a pena se atentar para o gerenciamento correto de energia

destes dispositivos. O sistema operacional oferece vários softwares para este
controle.
Entendendo também como os Sistemas Distribuídos quase sempre surgem

pela necessidade de melhorar a capacidade (por exemplo, capacidade de pro-
cessamento e tamanho do armazenamento) e a confiabilidade de uma única
máquina. Vimos também que fatores econômicos podem limitar a capacidade
de um sistema. Ao implementarmos um sistema operacional através de várias
máquinas baratas, é possível projetarmos um sistema poderoso sem o uso de
equipamentos dispendiosos.
Desta forma, outra razão para adotar sistemas distribuídos é atender a uma
grande base de usuários. Sistemas de arquivos distribuídos utilizam arquivos
em máquinas separadas e proporciona a visualização de um único sistema de
arquivo. Sistemas de arquivos distribuídos permitem que grandes números de
usuários acessem o mesmo conjunto de arquivos de modo confiável e eficien-
te.
LIVRO

• Editora: Person
FILME/VÍDEO
• Título: Her
• Ano: 2013
• Sinopse: Em Los Angeles, o escritor solitário Theodore desenvolve uma re-
lação de amor especial com o novo sistema operacional do seu computa-
dor. Surpreendentemente, ele acaba se apaixonando pela voz deste progra-
ma, uma entidade intuitiva e sensível, chamada Samantha.
• Link: < https://www.youtube.com/watch?v=2N6H9jFvMXY>
REFERÊNCIAS

OGLETREE, Terry William. Dominando o Windows XP. São Paulo: Pearson

Education do Brasil, 2002. Disponível em: https://bv4.digitalpages.com.br
CONCLUSÃO
Prezado(a) aluno(a), chegamos ao final de nossos estudos. A esperança é que

a partir deste momento você esteja pronto para operar com maior astúcia este
sistema tão importante, chamado Sistema Operacional.
Neste livro aprendemos que existem diversos tipos de sistemas operacionais

e cada um atende um tipo de computador. Conhecemos também os principais
sistemas operacionais
Conhecemos funções que o sistema operacional deve realizar. No primeiro

momento estudamos o gerenciamento de processos e verificamos como
o sistema operacional coordena as requisições de execuções de CPU. No
gerenciamento de memória, aprendemos sobre como as informações geradas
pelos processos ficam armazenadas e caso elas precisem ficar armazenadas
por mais tempo, aprendemos como elas ficam guardadas em memórias de
massa.
Em seguida, vimos como o sistema operacional cuida das solicitações dos

usuários por meio de dispositivos de entrada e como as informações são
apresentadas as saídas.
Com esta bagagem de conhecimento, você está apto a solucionar problemas

de
desempenho, de segurança e de disponibilidade em sistemas operacionais. E

ao desenvolver um software você poderá utilizar o potencial máximo do SO,
pois saberá como a informação gerada pelo programa está sendo gerenciada.
Mas esta apostila não é tudo. Desafio você, aluno(a), a continuar a caminhada
nos estudos referentes a sistemas operacionais. Quem sabe você queira
especializar-se em sistemas operacionais de servidores ou de algum outro tipo.
Ou quem sabe se aprofundar em sistemas operacionais Linux e obter até quem
sabe uma certificação.
Mantenha o foco e mantenha-se atualizado nas novidades que são lançadas

no mundo tecnológico.

Sistemas Operacionais

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sistemas Operacionais

Enviado por

Direitos autorais:

Formatos disponíveis

SISTEMAS

Prof. Me. Cleber Jose Semensate Santos

Mestre em Desenvolvimento de Tecnologias, Especialista em Programação

• Tecnólogo em Processamento de Dados (UNICESUMAR)

Olá, esta apostila de Sistemas Operacionais (SO), foi elaborado especialmente

A apostila está dividida em quatro unidades. Iremos abordar desde os concei-

A segunda unidade é dedicada exclusivamente ao gerenciamento de proces-

A terceira unidade consistirá na apresentação do gerenciamento de memória

Da unidade II até a unidade IV descreveremos as funcionalidades que todos os

Olá, caro(a) aluno(a)!

Seja bem-vindo(a) ao estudo dos sistemas operacionais (SO’s). Nesta unidade

Para definirmos sistema operacional (SO), precisamos relembrar as definições

Software: parte lógica do computador. Ao contrário do hardware, esta parte

Um computador moderno consiste em um ou mais processadores, uma memó-

Por essa razão, computadores são equipados com um dispositivo de softwa-

Segundo Tanenbaum (2016), é difícil dizer com absoluta precisão o que é um

1.1. O Sistema operacional como uma máquina estendida

De acordo com Tanenbaum (2016), a arquitetura da maioria dos computadores

Para Tanenbaum (2016), o conceito de um sistema operacional como funda-

Sistemas operacionais modernos permitem que múltiplos programas estejam

Quando um computador tem mais de um usuário, a necessidade de gerenciar e

Tanenbaum (2016), afirma que o gerenciamento de recursos inclui comparti-

O outro tipo é a multiplexação de espaço. Em vez de os clientes se revezarem,

2. Estrutura de um Sistema Operacional

2.1. Sistemas monolíticos

Nas palavras de Tanenbaum (2016), de longe a organização mais comum, na

Como aponta Tanenbaum (2016), uma generalização da abordagem da Figura

Figura 1.1 Um modelo de estruturação simples para um sistema monolítico.

O primeiro sistema construído dessa maneira foi o sistema THE desenvolvido

Outra generalização do conceito de camadas estava presente no sistema MUL-

Em comparação, em um sistema monolítico, com todos os drivers no núcleo,

O sistema tem muitas restrições limitando o poder de cada processo. Como

2.4. O modelo cliente-servidor

Para Tanenbaum (2016), uma ligeira variação da ideia do micronúcleo é distin-

A comunicação entre clientes e servidores é realizada muitas vezes pela tro-

Figura 1.2 O modelo cliente-servidor em uma rede.

2.5. Máquinas virtuais

Os lançamentos iniciais do OS/360 foram estritamente sistemas em lote. Não

Na camada de baixo, executando em modo núcleo, há um programa chamado

A vantagem do esquema do exonúcleo é que ele poupa uma camada de ma-

De acordo com Tanenbaum (2016), o sistema operacional é formado por um

3.1. Execução de programas

O sistema operacional é o responsável pelo carregamento dos programas na

3.2. Operações de entrada e saída

Como aponta Tanenbaum (2016), durante a sua execução, um programa pode

3.3. Gerência do sistema de arquivos

Segundo Tanenbaum (2016), os usuários de uma máquina têm necessidade de

De acordo com Tanenbaum (2016), o sistema operacional é o responsável por

3.5. Alocação de recursos

Tanenbaum (2016), afirma que o sistema operacional é o responsável pela alo-

3.6. Contabilização e segurança do sistema

De acordo com Tanenbaum (2016), o sistema operacional é o responsável pela

Conheça um pouco mais sobre o Sistema Operacional QNX, desenvolvido

Conheça os integrantes do consórcio de empresas que colaboram com o

Imagine como seria o desenvolvimento de programas se não existissem os sis-

Entender estes conceitos básicos e globais de sistemas operacionais é funda-

Conseguir entender os conceitos que serão passados nas unidades seguintes

A partir da unidade seguinte entraremos mais a fundo no conhecimento dos sis-

Se prepare para conhecermos mais a fundo os conceitos sobre os sistemas

• Título: Sistemas Operacionais Modernos

• Título: Pirates of Silicon Valley

GRAHAM, R. Use of high-level languages for system programming. Project

TANENBAUM, A.; BOS, H. Sistemas operacionais modernos. 4. ed. [S.l.]:

Prezado(a) estudante, nesta unidade vamos estudar, de forma mais aprofunda-