SISTEMA OPERACIONAIS TEMP 2 -1 COM RESPOSTA DE EXERCICIOS

Prévia do material em texto

Arquitetura de sistemas operacionais
Apresentação
No processo de desenvolvimento de qualquer software, é essencial para o sucesso do projeto a 
definição de uma arquitetura sólida que permita o desenvolvimento, a manutenção e a evolução do 
programa de forma adequada. Em Sistemas Operacionais, a definição da sua estrutura básica é 
ainda mais importante, visto o impacto que a arquitetura tem tanto no sistema operacional quanto 
no software que será executado.
De forma geral, existem alguns modelos arquiteturais que são seguidos no desenvolvimento de 
sistemas operacionais, dos quais três se destacam: arquitetura monolítica, em que todas as partes 
do sistema operacional podem interagir diretamente entre si; arquitetura em camadas, em que há 
uma definição mais clara de quais componentes podem trocar informações diretamente; e 
arquitetura de micronúcleo ou microkernel, que visa minimizar a quantidade de código do sistema 
operacional que precisa rodar com alto privilégio na máquina. A maioria dos sistemas operacionais 
existentes aderem a algum desses modelos, seja seguindo à risca uma das arquiteturas, seja de 
forma híbrida, mesclando as melhores propriedades de cada uma delas.
Nesta Unidade de Aprendizagem, você vai aprender as características da arquitetura monolítica em 
camada e de micronúcleo. Também será capaz de diferenciar cada um dos modelos e discutir suas 
vantagens e desvantagens.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Explicar a arquitetura monolítica de um sistema operacional.•
Identificar a abordagem de arquitetura em camadas de um sistema operacional.•
Discutir a arquitetura de um sistema operacional micronúcleo.•
Desafio
O desenvolvimento de qualquer software requer um planejamento bem feito, com questões 
arquiteturais definidas de acordo com os requisitos do sistema. Os sistemas operacionais têm um 
vasto conjunto de requisitos em comum, devido à sua função principal de gerenciar o hardware do 
computador e a execução de aplicativos nele. Apesar disso, esse tipo de software tem requisitos 
ligados ao hardware, ao ambiente de execução e ao tipo de aplicações que nele serão executadas, o 
que gera diferenças entre os sistemas disponíveis. 
Considere a seguinte situação:
Diante do caso apresentado, indique em quais modelos arquiteturais você se baseou e quais são as 
características deles que fazem com que essa seja uma boa opção para o cenário descrito.
Infográfico
Sistemas operacionais são geralmente software de grande porte com centenas de componentes 
interagindo entre si para prover o gerenciamento do computador, permitindo a execução de 
programas sem que haja interferências, garantindo a consistência das informações armazenadas e o 
bom funcionamento da máquina como um todo. Cada modelo de arquitetura define como esses 
módulos devem ser organizados e como deve ser permitida a comunicação entre eles. 
No Infográfico a seguir, você vai compreender a organização interna do sistema operacional de 
acordo com a arquitetura usada para estruturá-lo em seu projeto de desenvolvimento, por meio da 
interação entre as partes que compõem o sistema.
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/2ca7efd6-7cf1-4c4d-a30c-cabc341b0bef/396ac9d2-72f3-4c06-9aad-75f6ceecd2b2.png
Conteúdo do livro
O modelo de arquitetura aplicado durante a construção de um sistema operacional irá definir a 
maneira com que seus componentes são organizados, podendo contribuir para sua performance, 
capacidade de expansão e facilidade de manutenção. A definição da arquitetura de um sistema é 
uma decisão importante, pois alterá-la num momento posterior seria sinônimo de reescrever 
praticamente todo o sistema.
A arquitetura monolítica é bastante livre praticamente não impõe nenhuma estrutura rígida para o 
sistema. Nesse caso, o sistema é apenas um conjunto de módulos, que podem livremente fazer 
referência uns aos outros. A arquitetura em camadas, por sua vez, define uma organização em que 
alguns módulos fazem parte de cada camada, e módulos de uma camada podem chamar 
diretamente apenas outros módulos da camada imediatamente inferior. Por fim, a arquitetura de 
micronúcleo isola as responsabilidades que não são essenciais para o gerenciamento do 
computador para processos à parte, que não fazem parte do núcleo do sistema, minimizando o 
risco de que, em caso de falhas, todo o sistema pare de funcionar.
No trecho da obra Sistemas Operacionais: Projeto e Implementação, você vai aprender mais sobre os 
sistemas monolíticos em camadas e o modelo cliente-servidor, usado no desenvolvimento de 
sistemas que seguem a arquitetura de micronúcleo.
T164s Tanenbaum, Andrewa S.
 Sistemas operacionais [recurso eletrônico] : projeto e
 implementação / Andrew S. Tanenbaum, Albert S. Woodhull ;
 tradução João Tortello. – 3. ed. – Dados eletrônicos. – Porto
 Alegre : Bookman, 2008.
 Editado também como livro impresso em 2008.
 ISBN 978-85-7780-285-2
 1. Sistemas operacionais. I. Woodhull, Albert S. II. Título.
 CDU 004.4
Catalogação na publicação: Mônica Ballejo Canto – CRB 10/1023
58 SISTEMAS OPERACIONAIS
de CPU o sistema em si gastou em seu nome (manipulando suas chamadas de sistema). 
Também são fornecidos os tempos de usuário e de sistema totais utilizados por todos os seus 
fi lhos combinados.
 1.5 ARQUITETURA DE SISTEMAS OPERACIONAIS
Agora que vimos como os sistemas operacionais se parecem externamente (isto é, a interfa-
ce do programador), é hora de vê-los por dentro. Nas seções a seguir, examinaremos cinco 
arquiteturas diferentes que foram experimentadas, para termos uma idéia do espectro de pos-
sibilidades. De modo algum elas são exaustivas, mas dão uma idéia de alguns projetos que 
foram experimentados na prática. Os cinco projetos são os sistemas monolíticos, os sistemas 
em camadas, as máquinas virtuais, os exonúcleos e os sistemas cliente-servidor.
 1.5.1 Sistemas monolíticos
Com certeza, esta é a organização mais comum. Esta estratégia poderia muito bem ser deno-
minada “A Grande Bagunça”. Essa estruturação é tal que não há nenhuma estrutura. O siste-
ma operacional é escrito como um conjunto de rotinas, cada uma das quais podendo chamar 
qualquer uma das outras sempre que precisar. Quando essa técnica é utilizada, cada rotina do 
sistema tem uma interface bem-defi nida em termos de parâmetros e de resultados e cada uma 
está livre para chamar qualquer uma das outras, se a última fornecer alguma computação útil 
de que a primeira precise.
Para construir o programa-objeto do sistema operacional, quando essa estratégia é uti-
lizada, primeiro deve-se compilar todas as rotinas individualmente (ou os arquivos que con-
tenham as rotinas) e, então, ligá-las em um único arquivo objeto usando o ligador (linker) do 
sistema. Em termos de ocultação de informações, não há basicamente nenhuma–toda rotina 
é visível para todas as demais (em oposição a uma estrutura contendo módulos ou pacotes, 
na qual muitas informações são ocultadas dentro dos módulos e apenas os pontos de entrada 
ofi cialmente designados podem ser chamados de fora do módulo).
Contudo, mesmo nos sistemas monolíticos é possível ter pelo menos um pouco de es-
truturação. Os serviços (chamadas de sistema) fornecidos pelo sistema operacional são soli-
citados colocando-se os parâmetros em lugares bem defi nidos, como em registradores ou na 
pilha e, então, executando-se uma instrução de interrupção especial, conhecida como chama-
da de núcleo ou chamada de supervisor.
Essa instrução troca a máquina do modo usuário para modo núcleo e transfere o con-
trole para o sistema operacional. (A maioria das CPUs tem dois modos: modo núcleo, para o 
sistema operacional, no qual todas as instruções são permitidas, e modo usuário, para progra-
mas de usuário, no qual algumas instruções não são permitidas como as relacionadas a E/S, 
entreoutras.)
Este é um bom momento para vermos como as chamadas de sistema são executadas. 
Lembre-se de que a chamada read é usada como segue:
count = read(fd, buffer, nbytes);
Para executar a função de biblioteca read, que realmente faz a chamada de sistema read, 
o programa primeiro insere os parâmetros na pilha, como se vê nas etapas 1–3 da Figura 1-
16. Os compiladores C e C++ colocam os parâmetros na pilha na ordem inversa por motivos 
históricos (relacionados ao fato de fazer com que o primeiro parâmetro de printf, a string de 
formato, apareça no topo da pilha). O primeiro e o terceiro parâmetros são chamados por va-
lor, mas o segundo parâmetro é passado por referência, signifi cando que é passado o endereço 
CAPÍTULO 1 • INTRODUÇÃO 59
do buffer (indicado por &) e não o seu conteúdo. Em seguida, vem a chamada real para a 
função read da biblioteca (etapa 4) que é, essencialmente, uma chamada normal de execução 
de qualquer rotina.
A função da biblioteca, possivelmente escrita em linguagem assembly, normalmente 
coloca o código numérico correspondente à chamada de sistema em um lugar esperado pelo 
sistema operacional, como em um registrador (etapa 5). Em seguida, ela executa uma ins-
trução TRAP para trocar do modo usuário para o modo núcleo e iniciar a execução em um 
endereço fi xo dentro do núcleo (etapa 6). O núcleo inicia examinando o código numérico da 
chamada de sistema para depois chamar a rotina de tratamento correta. Normalmente, isso é 
feito através de uma tabela de ponteiros para rotinas de tratamento de chamada de sistema, 
indexada pelo número de chamada de sistema (etapa 7). Nesse ponto, a rotina de tratamento 
de chamada de sistema é executada (etapa 8). Quando a rotina de tratamento de chamada de 
sistema terminar seu trabalho, o controle poderá ser retornado para a função de biblioteca no 
espaço de usuário, na instrução que segue a instrução TRAP (etapa 9). Essa função então re-
torna para o programa do usuário, da maneira normal como as chamadas de função retornam 
(etapa 10).
Para concluir a tarefa, o programa do usuário precisa limpar a pilha, como faz após 
qualquer chamada de rotina (etapa 11). Supondo que a pilha cresça para baixo, como aconte-
ce freqüentemente, o código compilado incrementa o ponteiro da pilha exatamente o sufi cien-
te para remover os parâmetros colocados antes da chamada de read. Agora o programa está 
livre para fazer o que quiser em seguida.
Na etapa 9 anterior, dissemos que o controle “poderá ser retornado para a função de 
biblioteca no espaço de usuário”, por um bom motivo. A chamada de sistema pode bloquear o 
processo que fez a chamada, impedindo-o de continuar. Por exemplo, se ele estiver tentando 
ler o teclado e nada tiver sido digitado ainda, o processo que fez a chamada será bloqueado. 
Retorna para o invocador (rotina)
4
10
6
0
9
7 8
3
2
1
11
Despachante
Rotina de
chamada
de sistema
Endereço
0xFFFFFFFF
Espaço de usuário
Espaço de núcleo
(sistema operacional)
Função
read da
biblioteca
Programa do usuário
executando read
Desvio para o núcleo (trap)
Põe código da operação
read no registrador
Incrementa SP
Executa read
Empilha fd
Empilha &buffer
Empilha nbytes
5
Figura 1-16 As 11 etapas para fazer a chamada de sistema read(fd, buffer, nbytes).
60 SISTEMAS OPERACIONAIS
Nesse caso, o sistema operacional verifi cará se algum outro processo pode ser executado em 
seguida. Posteriormente, quando a entrada desejada estiver disponível, esse processo receberá 
a atenção do sistema e as etapas 9–11 ocorrerão.
Essa organização sugere uma estrutura básica para o sistema operacional:
 1. Um programa principal que ativa a função de serviço solicitada.
 2. Um conjunto de funções de serviço que executam as chamadas de sistema.
 3. Um conjunto de funções utilitárias que ajudam as funções de serviço.
Nesse modelo, para cada chamada de sistema há uma função de serviço que cuida dela. 
As funções utilitárias fazem coisas que são necessárias para várias funções de serviço, como 
buscar dados de programas de usuário. Essa divisão das funções em três camadas aparece na 
Figura 1-17.
Função
principal
Funções
de serviço
Funções
utilitárias
Figura 1-17 Um modelo simples de estruturação para um sistema monolítico.
 1.5.2 Sistemas em camadas
Uma generalização da estratégia da Figura 1-17 é organizar o sistema operacional como uma 
hierarquia de camadas, cada uma construída sobre a outra. O primeiro sistema feito dessa 
maneira foi o THE, construído no Technische Hogeschool Eindhoven, na Holanda, por E. 
W. Dijkstra (1968) e seus alunos. O sistema THE era um sistema em lote simples para um 
computador holandês, o Electrologica X8, que tinha 32K de palavras de 27 bits (os bits eram 
caros naquela época).
O sistema tinha seis camadas, como mostrado na Figura 1-18. A camada 0 tratava da 
alocação do processador, alternando entre processos quando ocorriam interrupções ou quan-
do temporizadores expiravam. Acima da camada 0, o sistema possuía processos seqüenciais, 
cada um dos quais podia ser programado sem se preocupar com o fato de que vários pro-
cessos estavam sendo executados num único processador. Em outras palavras, a camada 0 
proporcionava a multiprogramação básica da CPU.
A camada 1 fazia o gerenciamento de memória. Ela alocava espaço para processos na 
memória principal e em um tambor* com 512K de palavras, utilizado para conter partes dos 
processos (páginas) para os quais não havia espaço na memória principal. Acima da camada 
1, os processos não tinham que se preocupar com o fato de estarem na memória ou no tambor; 
o software da camada 1 tratava de assegurar que as páginas fossem levadas para a memória 
sempre que fossem necessárias.
 * N. de R. T.: Antigo meio magnético de armazenamento de dados.
CAPÍTULO 1 • INTRODUÇÃO 61
A camada 2 manipulava a comunicação entre cada processo e o console do operador. 
Acima dessa camada, cada processo tinha efetivamente seu próprio console de operador. A 
camada 3 gerenciava os dispositivos de E/S e armazenava em buffer os fl uxos de informação. 
Acima da camada 3, cada processo podia lidar com dispositivos de E/S abstratos com inter-
faces amigáveis, em vez de dispositivos reais cheios de peculiaridades. A camada 4 era onde 
fi cavam os programas de usuário. Eles não tinham de preocupar-se com gerenciamento de 
processos, de memória, de console ou de E/S. O processo do operador do sistema localizava-
se na camada 5.
Uma generalização maior do conceito de camadas estava presente no sistema MUL-
TICS. Em vez de camadas, o MULTICS era organizado como uma série de anéis concêntri-
cos, com os anéis internos sendo mais privilegiados do que os externos. Quando uma função 
em um anel externo queria chamar uma função em um anel interno, ela tinha de fazer o 
equivalente de uma chamada de sistema; isto é, uma instrução TRAP cuja validade dos parâ-
metros era cuidadosamente verifi cada, antes de permitir que a chamada prosseguisse. Embora 
no MULTICS o sistema operacional inteiro fi zesse parte do espaço de endereçamento de cada 
processo de usuário, o hardware tornava possível designar individualmente funções (na reali-
dade, segmentos de memória) como protegidas contra leitura, escrita ou execução.
Embora o esquema em camadas do THE fosse, na verdade, apenas um auxílio para 
projeto, porque todas as partes do sistema estavam, em última análise, ligadas a um único 
programa objeto, no MULTICS o mecanismo de anéis estava muito presente em tempo de 
execução e era imposto pelo hardware. A vantagem do mecanismo de anéis é que ele podia 
ser estendido facilmente para estruturar subsistemas de usuário. Por exemplo, um professor 
podia escrever um programa para testar e avaliar programas dos alunos e executar esse pro-
grama no anel n, com os programas dos alunos sendo executado no anel n + 1, de modo que 
eles não podiam alterar suas avaliações. O hardware Pentium suporta a estrutura em anéis do 
MULTICS, mas atualmente nenhum sistema operacional importante a utiliza.1.5.3 Máquinas virtuais
As versões iniciais do OS/360 eram estritamente sistemas de lote. Não obstante, muitos usuá-
rios do 360 queriam ter tempo compartilhado; assim, vários grupos, tanto de dentro como 
de fora da IBM, decidiram escrever sistemas de tempo compartilhado para ele. O sistema 
de tempo compartilhado ofi cial da IBM, o TSS/360, foi lançado tardiamente e quando fi -
nalmente chegou era tão grande e lento que poucos ambientes foram convertidos para ele. 
Finalmente, ele acabou sendo abandonado depois que seu desenvolvimento tinha consumido 
algo em torno de US$ 50 milhões (Graham, 1970). Mas um grupo no Centro Científi co da 
IBM em Cambridge, Massachusetts, produziu um sistema radicalmente diferente que a IBM 
acabou aceitando como produto e que agora é amplamente utilizado em seus computadores 
de grande porte.
Camada Função
5 Operador
4 Programas de usuário
3 Gerenciamento de entrada/saída
2 Comunicação operador-processo
1 Gerenciamento de memória e tambor
0 Alocação do processador e multiprogramação
Figura 1-18 Estrutura do sistema operacional THE.
62 SISTEMAS OPERACIONAIS
Esse sistema, originalmente chamado CP/CMS e posteriormente rebatizado como 
VM/370 (Seawright e MacKinnon, 1979), foi baseado em uma observação muito perspicaz: 
um sistema de tempo compartilhado fornece (1) multiprogramação e (2) uma máquina esten-
dida com uma interface mais conveniente que o hardware básico. A característica básica do 
VM/370 foi separar completamente essas duas funções.
O centro do sistema, conhecido como monitor de máquina virtual, era executado no 
hardware básico e fazia a multiprogramação, oferecendo não uma, mas várias máquinas vir-
tuais à camada superior seguinte, como mostrado na Figura 1-19. Entretanto, ao contrário de 
todos os outros sistemas operacionais, essas máquinas virtuais não eram máquinas estendi-
das, com arquivos e com outros recursos interessantes. Em vez disso, elas eram cópias exatas 
do hardware básico, incluindo os modos núcleo e usuário, E/S, interrupções e tudo mais que 
uma máquina real tem.
Instruções de E/S
Interrupção (trap)
Interrupção (trap)
Chamadas de sistema
370s virtuais
CMS CMS CMS
VM/370
Hardware básico do 370
Figura 1-19 A estrutura do VM/370 com CMS.
Como cada máquina virtual é idêntica ao hardware verdadeiro, cada uma pode executar 
qualquer sistema operacional que fosse executado diretamente no hardware básico. Dife-
rentes máquinas virtuais podem executar (e freqüentemente executam) diferentes sistemas 
operacionais. Algumas executam um dos descendentes do OS/360 para processamento de 
transações ou de lote, enquanto outras executam um sistema interativo monousuário chamado 
CMS (Conversational Monitor System) para usuários de tempo compartilhado.
Quando um programa CMS executa uma chamada de sistema, a chamada é capturada 
pelo sistema operacional em sua própria máquina virtual e não pelo VM/370, exatamente 
como aconteceria se estivesse executando em uma máquina real. Então, o CMS envia as 
instruções normais de E/S de hardware para ler seu disco virtual ou o que for necessário 
para executar a chamada. Essas instruções de E/S são capturadas pelo VM/370, que então as 
executa como parte de sua simulação do hardware real. Fazendo uma separação completa das 
funções de multiprogramação e fornecendo uma máquina estendida, cada uma das partes se 
torna muito mais simples, mais fl exível e mais fácil de manter.
A idéia de máquina virtual é utilizada hoje em dia em um contexto diferente: na execu-
ção de programas antigos do MS-DOS em um processador Pentium. Ao projetar o Pentium e o 
seu software, a Intel e a Microsoft perceberam que haveria uma grande demanda para executar 
software antigo (legado) no novo hardware. Por essa razão, a Intel fornece um modo virtual do 
8086 no Pentium. Nesse modo, a máquina age como um 8086 (que é idêntico a um 8088 do 
ponto de vista do software), incluindo o endereçamento de 16 bits com um limite de 1MB.
Este modo é utilizado pelo Windows e por outros sistemas operacionais para execu-
tar programas antigos do MS-DOS. Esses programas são iniciados no modo 8086 virtual. 
Contanto que executem instruções normais, eles funcionam no hardware básico. Entretanto, 
quando um programa tenta interromper o sistema operacional para fazer uma chamada de 
sistema, ou tenta fazer E/S protegida diretamente, ocorre uma interrupção no monitor da 
máquina virtual.
CAPÍTULO 1 • INTRODUÇÃO 63
Duas variantes desse projeto são possíveis. Na primeira, o próprio MS-DOS é carrega-
do no espaço de endereçamento do 8086 virtual, de modo que o monitor da máquina virtual 
apenas refl ete a interrupção para o MS-DOS, exatamente como aconteceria em um 8086 real. 
Quando, posteriormente, o próprio MS-DOS tentar fazer a E/S, essa operação será capturada 
e executada pelo monitor da máquina virtual.
Na outra variante, o monitor da máquina virtual apenas captura a primeira interrupção 
e faz a E/S sozinho, pois conhece todas as chamadas de sistema do MS-DOS e, portanto, o 
que cada interrupção deve fazer. Esta variante é menos pura do que a primeira, já que simula 
corretamente apenas o MS-DOS e não outros sistemas operacionais, como acontece com a 
primeira. Por outro lado, ela é muito mais rápida, pois elimina o problema de iniciar o MS-
DOS para fazer a E/S. Uma desvantagem de executar o MS-DOS no modo 8086 virtual é que 
o MS-DOS desperdiça muito tempo habilitando e desabilitando interrupções, o que implica 
em custo considerável (em tempo) para simular um processo.
Vale notar que nenhuma dessas estratégias é realmente igual à do VM/370, pois a má-
quina que está sendo simulada não é um Pentium completo, mas apenas um 8086. No sistema 
VM/370 é possível executar o próprio VM/370 na máquina virtual. Até as primeiras versões 
do Windows exigem pelo menos um 286 e não podem ser executadas em um 8086 virtual.
Diversas implementações de máquina virtual são vendidas comercialmente. Para em-
presas que fornecem serviços de hospedagem web, pode ser mais econômico executar várias 
máquinas virtuais em um único servidor rápido (talvez com várias CPUs) do que executar 
muitos computadores pequenos, cada um hospedando um único site web. O VMWare e o 
Virtual PC da Microsoft são comercializados para tais instalações. Esses programas utili-
zam arquivos grandes no sistema hospedeiro (host) para simular os discos de seus sistemas 
convidados (guest); aqueles que são executados pela máquina virtual. Para obter efi ciência, 
eles analisam os arquivos binários do programa de sistema convidado e permitem que código 
seguro seja executado diretamente no hardware do hospedeiro, capturando instruções que 
fazem chamadas de sistema operacional. Tais sistemas também são úteis para fi ns didáticos. 
Por exemplo, alunos que estejam trabalhando em tarefas de laboratório no MINIX 3 podem 
usar esse sistema operacional como convidado no VMWare em um hospedeiro Windows, 
Linux ou UNIX, sem correrem o risco de danifi car outro software instalado no mesmo PC. 
A maioria dos professores que dão aulas sobre outros temas fi caria muito preocupada com o 
fato de compartilhar computadores do laboratório com um curso sobre sistemas operacionais, 
onde erros dos alunos poderiam corromper ou apagar dados do disco.
Outra área onde as máquinas virtuais são usadas, mas de uma maneira um tanto dife-
rente, é na execução de programas Java. Quando a Sun Microsystems inventou a linguagem 
de programação Java, inventou também uma máquina virtual (isto é, uma arquitetura de com-
putador) chamada JVM (Java Virtual Machine – máquina virtual Java). O compilador Java 
produz código para a JVM, o qual então é normalmente executado por um interpretador JVM, 
em software. A vantagem dessa estratégia é que o código da JVM pode ser enviado pela Inter-
net para qualquer computador que tenha um interpretador JVM e executado no destino. Se o 
compilador tivesse produzido programas binários em SPARC ou Pentium, por exemplo, eles 
não poderiam ser enviados e executadosem qualquer lugar tão facilmente. (É claro que a Sun 
poderia ter produzido um compilador que gerasse binários em SPARC e depois distribuído 
um interpretador SPARC, mas a JVM é uma arquitetura muito mais simples de interpretar.) 
Outra vantagem de usar a JVM é que, se o interpretador for implementado corretamente, o 
que não é totalmente simples, a segurança dos programas JVM recebidos poderá ser verifi -
cada e eles poderão ser executados em um ambiente protegido, para que não possam roubar 
dados ou causar qualquer dano.
64 SISTEMAS OPERACIONAIS
 1.5.4 Exonúcleos
Com o VM/370, cada processo de usuário recebe uma cópia exata do hardware real. No modo 
8086 virtual do Pentium, cada processo de usuário recebe uma cópia exata de um computador 
diferente. Indo um pouco mais longe, os pesquisadores do M.I.T. construíram um sistema 
que fornece um clone do computador real para cada usuário, mas com um subconjunto dos 
recursos (Engler et al., 1995 e Leschke, 2004). Assim, uma máquina virtual poderia receber 
os blocos de disco de 0 a 1023, a seguinte poderia receber os blocos de 1024 a 2047 e assim 
por diante.
Na camada inferior, executando em modo núcleo, existe um programa chamado exo-
núcleo (exokernel). Sua tarefa é alocar recursos para as máquinas virtuais e, então, verifi car 
tentativas de utilizá-los para garantir que nenhuma máquina use recursos pertencentes à outra 
pessoa. Cada máquina virtual em nível de usuário pode executar seu próprio sistema opera-
cional, como no VM/370 e nos 8086 virtuais do Pentium, exceto que cada uma está limitada 
a usar apenas os recursos que solicitou e que foram alocados.
A vantagem do esquema de exonúcleo é que ele economiza uma camada de mapea-
mento. Em outros projetos, cada máquina virtual “enxerga” um disco próprio, com blocos 
que vão de 0 até algum máximo, de modo que o monitor de máquina virtual precisa manter 
tabelas para fazer um novo mapeamento dos endereços de disco (e todos os outros recursos). 
Com o exonúcleo, esse novo mapeamento não é necessário. O exonúcleo só precisa monito-
rar qual recurso foi designado para qual máquina virtual. Esse método tem ainda a vantagem 
de separar a multiprogramação (no exonúcleo) do código do sistema operacional do usuário 
(no espaço de usuário), mas com menor sobrecarga, pois o exonúcleo precisa apenas manter 
as máquinas virtuais separadas.
 1.5.5 Modelo cliente-servidor
O VM/370 ganha muito em simplicidade, movendo grande parte do código do sistema opera-
cional tradicional (implementando a máquina estendida) para uma camada mais alta, a CMS. 
Entretanto, o VM/370 em si ainda é um programa complexo, pois simular diversos 370 vir-
tuais não é tão simples assim (especialmente se você quiser fazer isso de maneira razoavel-
mente efi ciente).
Uma tendência nos sistemas operacionais modernos é levar ainda mais longe essa idéia 
de mover código para camadas mais altas e remover o máximo possível do sistema opera-
cional, deixando um núcleo mínimo, o micronúcleo (microkernel). A estratégia normal é 
implementar a maior parte das funções do sistema operacional em processos de usuário. Para 
solicitar um serviço, como ler um bloco de um arquivo, um processo de usuário (agora conhe-
cido como processo cliente) envia uma requisição para um processo servidor, o qual então 
realiza o trabalho e devolve a resposta.
Nesse modelo, ilustrado na Figura 1-20, tudo que o núcleo faz é gerenciar a comunica-
ção entre clientes e servidores. Dividir o sistema operacional em partes, cada uma gerencian-
do apenas uma faceta do sistema, como serviços de arquivo, serviços de processo, serviços 
de terminal ou serviços de memória, torna cada parte pequena e gerenciável. Além disso, 
como todos os servidores são executados como processos em modo usuário e não em modo 
núcleo, eles não têm acesso direto ao hardware. Como conseqüência, se ocorrer um erro no 
servidor de arquivos, o serviço de arquivos pode falhar, mas isso normalmente não derrubará 
a máquina inteira.
Dica do professor
Cada modelo de arquitetura existente para a organização e estruturação de sistemas operacionais 
possui um conjunto de vantagens que pode ser explorada por seus projetistas, assim como 
desvantagens que devem ser mitigadas. Além dos profissionais que trabalham na criação dos 
sistemas operacionais, conhecer essas características das arquiteturas é importante para que 
profissionais de TI possam tomar decisões acertadas na escolha de sistemas operacionais para 
situações distintas.
Nesta Dica do Professor, veja as principais vantagens e desvantagens de sistemas implementados 
seguindo o modelo monolítico, em camadas e de micronúcleo.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://fast.player.liquidplatform.com/pApiv2/embed/cee29914fad5b594d8f5918df1e801fd/dea41ae677a023b6923f6459a65761d6
Exercícios
1) Sistema monolíticos são caracterizados por não impor uma estrutura fixa para seus 
componentes, sendo o sistema um grande conjunto de módulos, sem regras que limitem a 
comunicação entre eles. Sobre a execução de sistemas monolíticos, assinale a alternativa 
correta:
A) Todo o sistema é executado em Espaço de Usuário, assim como suas aplicações.
B) Todo o sistema é executado em Espaço de Núcleo, assim como suas aplicações.
C) Parte do sistema e das aplicações são executadas em Espaço de Núcleo, o resto do sistema 
em Espaço de Usuário.
D) O sistema é executado em Espaço de Núcleo, mas suas aplicações são executadas em Espaço 
de Usuário
E) O sistema é executado em Espaço de Usuário, mas suas aplicações são executadas em Espaço 
de Núcleo.
2) Ao definir uma arquitetura em camadas, os projetistas de um sistema operacional optam por 
uma organização mais restrita, com uma definição clara de quais módulos podem ter acesso 
direto aos outros. Caso uma aplicação necessite de um serviço, de uma funcionalidade do 
sistema a qual não tem acesso direto, ela deve solicitar o serviço por meio de uma chamada 
para algum dos módulos com os quais ela pode se comunicar, que irá encaminhar para as 
camadas inferiores e o processo se repetirá até que a chamada chegue na funcionalidade 
desejada. Sobre este mecanismo em sistemas em camadas, assinale a alternativa correta:
A) Sistemas em camadas são mais lentos, devido à necessidade de repassar as chamadas entre 
as camadas.
B) Sistemas em camadas são mais difíceis de evoluir, devido ao excesso de código.
C) Sistemas em camadas são mais difíceis de manter, devido à estrutura rígida aplicada.
D) Sistemas em camadas são mais resilientes, pois pouco código executa em espaço de núcleo.
E) Sistemas em camadas são mais simples pois são baseados em micronúcleo.
3) A arquitetura de micronúcleo orienta a organização do sistema operacional de forma que 
apenas as funções de mais baixo nível sejam executadas em Espaço de Núcleo, minimizando 
o risco de erros críticos durante a execução do sistema. Sobre o relacionamento entre 
arquitetura de micronúcleo e o modelo cliente-servidor, assinale a alternativa correta:
A) O modelo cliente-servidor define que o sistema operacional de micronúcleo deve oferecer 
chamadas de sistema para acesso às suas funcionalidades internas.
B) Sistemas de micronúcleo usam processos servidores executando em Espaço de Usuário como 
intermediários para as funcionalidades do sistema. As aplicações são os processos clientes.
C) Sistemas de micronúcleo usam processos servidores executando em Espaço de Núcleo como 
intermediários para as funcionalidades do sistema. As aplicações são os processos clientes.
D) Sistemas de micronúcleo usam processos clientes executando em Espaço de Usuário como 
intermediários para as funcionalidades do sistema. As aplicações são os processos servidores.
E) Sistemas de micronúcleo usam processos clientes executando em Espaço de Núcleo como 
intermediários para as funcionalidades do sistema. As aplicações são os processos servidores.
4) Sistemas operacionais de grande porte e com múltiplos usos,como Windows e Linux, 
executam uma grande quantidade de código em Espaço de Núcleo, uma característica de 
sistemas monolíticos. Assinale a alternativa que melhor define o motivo dessa decisão de 
projeto nesses sistemas.
A) Com o passar do tempo não se consegue manter e evoluir arquiteturas mais rígidas, migrando 
os sistemas para a arquitetura monolítica.
B) Funções executando em Espaço de Núcleo são mais seguras, logo o sistema se beneficia por 
ter menos aplicações executando em Espaço de Usuário.
C) Mesmo com uma redução da performance, as vantagens de ter todo o sistema operacional 
executando em Espaço de Núcleo compensam a migração.
D) Sistemas modernos possuem um número maior de funções, então o risco de uma função 
executando em Espaço de Usuário quebrar todo o sistema é muito grande.
E) Com mais funções executando em Espaço de Núcleo, a performance do sistema tende a ser 
melhor, por necessitar de menos comunicação entre processos.
5) 
Considere um sistema operacional que deve permitir a integração de várias peças de 
hardware de diferentes fabricantes, inclusive componentes que nem existam durante o 
desenvolvimento do sistema. O ambiente de execução desse sistema não tem uma 
necessidade de performance ótima, mas é necessário que o sistema seja bastante resistente 
a erros, não falhando devido a um problema em uma aplicação ou driver isolado. A partir do 
cenário descrito, assinale a alternativa que descreve o modelo arquitetural mais adequado 
para um novo sistema que será desenvolvido para esse ambiente.
A) Monolítico.
B) Em Camadas.
C) Micronúcleo.
D) Máquina Virtual.
E) Híbrido entre Monolítico e Em Camadas.
Na prática
É difícil encontrar sistemas operacionais reais que sejam totalmente aderentes a apenas um dos 
possíveis modelos arquiteturais disponíveis. O mais comum é que os projetistas desses sistemas 
busquem mesclar características positivas de cada um desses modelos para chegar a uma solução 
ideal para as necessidades do sistema operacional que estão criando. 
Neste Na Prática, você verá como se deu a evolução da arquitetura do sistema operacional 
Windows.
Aponte a câmera para o 
código e acesse o link do 
conteúdo ou clique no 
código para acessar.
https://statics-marketplace.plataforma.grupoa.education/sagah/94d405b8-f67c-46f6-9027-219470c5669e/35edb391-4982-4cc8-af57-8543ff6bc5f1.png
Saiba +
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do professor:
Projeto de Sistemas Operacionais
A seção 8.2.2 do Livro Princípios Básicos de Arquitetura e Organização de Computadores (Null e 
Lobur) possui um resumo sobre os modelos de arquitetura geralmente usados em sistemas 
operacionais, incluindo alguns exemplos de sistemas reais que seguem as arquiteturas de 
microkernel e monolítica. Acesse para saber mais.
Conteúdo interativo disponível na plataforma de ensino!
Sistema operacional monolítico e em camadas
Clique para assistir a este vídeo, que apresenta explicação sobre o conceito de núcleos baseados 
em arquitetura monolítica e em camadas.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
Sistemas Operacionais – Tipos e Estruturas de SO
Acesse esta videoaula do curso de Sistemas Operacionais da Universidade Virtual do Estado de São 
Paulo, que apresenta explicação detalhada do modelo monolítico, de microkernel e em camadas.
Aponte a câmera para o código e acesse o link do conteúdo ou clique no código para acessar.
https://www.youtube.com/embed/SXTZVHr13hQ
https://www.youtube.com/embed/_J4CVHgXQ1c