So Livro A5 PDF

#include <pthread.
h>
#include <semaphore.h>
#define NUM_THREADS 100
#define NUM_STEPS 100000
int sum = 0, lock = 0 ;
void enter_cs (int *l)
{
// busy waiting
using atomic
add
Sistemas
Operacionais:
Conceitos
e
while (__sync_fetch_and_add (l, 1)) ;
Mecanismos
}
void leave_cs (int *l)
Prof. Carlos A. Maziero, Dr.
{
(*l) = 0 ; DAINF UTFPR
}
2 de maio de 2014
void *threadBody(void *id)
{
int i ;
for (i=0; i< NUM_STEPS; i++)
{
enter_cs (&lock) ;
soma += 1 ;
leave_cs (&lock) ;
}
Sistemas Operacionais: Conceitos e Mecanismos

c Carlos Alberto Maziero, 2013

Sobre o autor: Carlos Alberto Maziero professor adjunto do Departamento
Acadmico de Informtica da Universidade Tecnolgica Federal do Paran
(UTFPR) desde julho de 2011. Anteriormente, foi professor titular do
Programa de Ps-Graduao em Informtica da Pontifcia Universidade
Catlica do Paran (PUCPR), entre 1998 e 2011, e professor adjunto do
Departamento de Automao e Sistemas da Universidade Federal de Santa
Catarina (UFSC), de 1996 a 1998. Formado em Engenharia Eltrica (UFSC,
1988), tem Mestrado em Engenharia Eltrica (UFSC, 1990), Doutorado em
Informtica (Universit de Rennes I - Frana, 1994) e Ps-Doutorado em
Segurana da Informao (Universit degli Studi di Milano Italia, 2009).
Tem atuao em pesquisa nas reas de sistemas operacionais, segurana de
sistemas e sistemas distribudos.
Este texto est licenciado sob a Licena AttributionNonCommercial-ShareAlike 3.0 Unported da Creative
Commons (CC). Em resumo, voc deve creditar a
obra da forma especificada pelo autor ou licenciante
(mas no de maneira que sugira que estes concedem qualquer aval a
voc ou ao seu uso da obra). Voc no pode usar esta obra para fins
comerciais. Se voc alterar, transformar ou criar com base nesta obra, voc
poder distribuir a obra resultante apenas sob a mesma licena, ou sob
uma licena similar presente. Para ver uma cpia desta licena, visite
http://creativecommons.org/licenses/by-nc-sa/3.0/.
Este texto foi produzido usando exclusivamente software livre: Sistema
Operacional GNU/Linux (distribuies Fedora e Ubuntu), compilador de texto
LATEX 2 , gerenciador de referncias BibTeX, editor grfico Inkscape, criadores
de grficos GNUPlot e GraphViz e processador PS/PDF GhostScript, entre
outros.
Lucia, Henrique e Daniel, as estrelas mais brilhantes do meu firmamento...
Prefcio
Os sistemas operacionais so elementos fundamentais para o funcionamento de praticamente qualquer sistema de computao, dos minsculos
sistemas embarcados e telefones celulares aos gigantescos centros de processamento de dados das grandes empresas. Apesar da imensa diversidade
de sistemas operacionais existentes, eles tentam resolvem problemas de
mesma natureza e seguem basicamente os mesmos princpios.
Conhecer Sistemas Operacionais a fundo no algo reservado a hackers,
mas importante para todo profissional de computao, pois os mecanismos
implementados pelo sistema operacional afetam diretamente o comportamento e o desempenho das aplicaes. Alm disso, o sistema operacional
uma pea chave na configurao de servios de rede e na segurana do
sistema.
Existem muitos livros de sistemas operacionais disponveis no mercado,
quase todos excelentes, escritos por profissionais reconhecidos mundialmente. Entretanto, bons livros de Sistemas Operacionais podem custar
centenas de reais, o que os torna inacessveis a uma parcela significativa
da populao. Este livro seria apenas mais uma opo nas livrarias, no
fosse por um pequeno detalhe: foi concebido como um Livro Aberto, desde
seu incio. Um Livro Aberto (do ingls Open Book) um livro amplamente
disponvel na Internet em formato digital, sem custo. No exterior, muitos
open books esto tambm disponveis nas livrarias, para aquisio em formato
impresso.
Eu acredito que incluso digital no significa somente permitir o
acesso a computadores parcela mais pobre da populao, mas tambm
desmistificar o funcionamento dessa tecnologia e incentivar seu estudo,
para fomentar as prximas geraes de tcnicos, engenheiros e cientistas da
computao, vindas de todas as classes sociais. Nosso pas no pode mais
se dar ao luxo de desperdiar pessoas inteligentes s porque so pobres.
c Carlos Maziero
iv
0:
Prof. Carlos Maziero, Dr.

Curitiba PR, Outubro de 2011
Agradecimentos
Este texto fruto de alguns anos de trabalho. Embora eu o tenha redigido
sozinho, ele nunca teria se tornado uma realidade sem a ajuda e o apoio
de muitas pessoas, de vrias formas. Em primeiro lugar, agradeo minha
famlia, pelas incontveis horas em que me subtra de seu convvio para me
dedicar a este trabalho.
Agradeo tambm a todos os docentes e estudantes que utilizaram este
material, pelas inmeras correes e sugestes de melhoria. Em particular,
meus agradecimentos a Alexandre Koutton, Altair Santin, Carlos Silla,
Diogo Olsen, Douglas da Costa, Fabiano Beraldo, Jeferson Amend, Marcos
Pchek Laureano, Paulo Resende, Rafael Hamasaki, Richard Reichardt,
Tadeu Ribeiro Reis, Thayse Solis, Thiago Ferreira, Urlan de Barros e Vagner
Sacramento.
Desejo expressar meu mais profundo respeito pelos autores dos grandes
clssicos de Sistemas Operacionais, como Andrew Tanenbaum e Abraham
Silberschatz, que iluminaram meus primeiros passos nesta rea e que
seguem como referncias inequvocas e incontornveis.
Agradeo Pontifcia Universidade Catlica do Paran, onde fui professor de Sistemas Operacionais por 13 anos, pelas condies de trabalho
que me permitiram dedicar-me a esta empreitada. Tambm Universidade
Tecnolgica Federal do Paran, onde atuo desde julho de 2011, pelas mesmas
razes.
Dedico o Captulo 8 deste livro aos colegas docentes e pesquisadores
do Departamento de Tecnologias da Informao da Universidade de Milo em Crema, onde estive em um ps-doutorado no ano de 2009, com
uma bolsa CAPES/MEC1 . O Captulo 9 deste livro dedicado equipe
1
Dedico il Capitolo 8 ai colleghi docenti e ricercatori del Dipartimento di Technologie

dellInformazione de lUniversit degli Studi di Milano Crema, dove sono stato per un
soggiorno sabbatico nell 2009, con una borsa di post-dottorato CAPES/MEC.
c Carlos Maziero
vi
0:
ADEPT IRISA/INRIA, Universit de Rennes 1 - Frana, na qual pude passar trs meses agradveis e produtivos durante o inverno 2007-08, como
professor/pesquisador convidado2 .
Carlos Maziero
Curitiba PR, Outubro de 2011
Je ddie le Chapitre 9 lquipe ADEPT IRISA/INRIA Rennes - France, au sein de

laquelle jai pu passer trois mois trs agrables et productifs dans lhiver 2007-08, en tant
quenseignant/chercheur invit.
Sumrio
1
Conceitos bsicos
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . .
1.1.1 Abstrao de recursos . . . . . . . . .
1.1.2 Gerncia de recursos . . . . . . . . . .
1.2 Tipos de sistemas operacionais . . . . . . . .
1.3 Funcionalidades . . . . . . . . . . . . . . . . .
1.4 Estrutura de um sistema operacional . . . . .
1.5 Conceitos de hardware . . . . . . . . . . . . .
1.5.1 Interrupes . . . . . . . . . . . . . . .
1.5.2 Proteo do ncleo . . . . . . . . . . .
1.5.3 Chamadas de sistema . . . . . . . . .
1.6 Arquiteturas de Sistemas Operacionais . . . .
1.6.1 Sistemas monolticos . . . . . . . . . .
1.6.2 Sistemas em camadas . . . . . . . . .
1.6.3 Sistemas micro-ncleo . . . . . . . . .
1.6.4 Mquinas virtuais . . . . . . . . . . .
1.7 Um breve histrico dos sistemas operacionais
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
4
5
8
11
12
14
17
19
22
23
24
25
27
31
Gerncia de atividades
2.1 Objetivos . . . . . . . . . . . . . . . . . . .
2.2 O conceito de tarefa . . . . . . . . . . . . .
2.3 A gerncia de tarefas . . . . . . . . . . . .
2.3.1 Sistemas mono-tarefa . . . . . . .
2.3.2 Sistemas multi-tarefa . . . . . . . .
2.3.3 Sistemas de tempo compartilhado
2.3.4 Ciclo de vida das tarefas . . . . . .
2.4 Implementao de tarefas . . . . . . . . .
2.4.1 Contextos . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
35
38
38
40
40
42
45
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
c Carlos Maziero
viii
2.5
0: SUMRIO
2.4.2 Trocas de contexto . . . . . . . . . . . . . . . .

2.4.3 Processos . . . . . . . . . . . . . . . . . . . . .
2.4.4 Threads . . . . . . . . . . . . . . . . . . . . . .
Escalonamento de tarefas . . . . . . . . . . . . . . . .
2.5.1 Objetivos e mtricas . . . . . . . . . . . . . . .
2.5.2 Escalonamento preemptivo e cooperativo . . .
2.5.3 Escalonamento FCFS (First-Come, First Served)
2.5.4 Escalonamento SJF (Shortest Job First) . . . . .
2.5.5 Escalonamento por prioridades . . . . . . . . .
2.5.6 Outros algoritmos de escalonamento . . . . . .
2.5.7 Um escalonador real . . . . . . . . . . . . . . .
Comunicao entre tarefas

3.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . .
3.2 Escopo da comunicao . . . . . . . . . . . . . .
3.3 Caractersticas dos mecanismos de comunicao
3.3.1 Comunicao direta ou indireta . . . . . .
3.3.2 Sincronismo . . . . . . . . . . . . . . . . .
3.3.3 Formato de envio . . . . . . . . . . . . . .
3.3.4 Capacidade dos canais . . . . . . . . . . .
3.3.5 Confiabilidade dos canais . . . . . . . . .
3.3.6 Nmero de participantes . . . . . . . . .
3.4 Exemplos de mecanismos de comunicao . . .
3.4.1 Filas de mensagens UNIX . . . . . . . . .
3.4.2 Pipes . . . . . . . . . . . . . . . . . . . . .
3.4.3 Memria compartilhada . . . . . . . . . .
Coordenao entre tarefas
4.1 Objetivos . . . . . . . . . . . . .
4.2 Condies de disputa . . . . . .
4.3 Sees crticas . . . . . . . . . .
4.4 Inibio de interrupes . . . .
4.5 Solues com espera ocupada .
4.5.1 A soluo bvia . . . . .
4.5.2 Alternncia de uso . . .
4.5.3 O algoritmo de Peterson
4.5.4 Instrues Test-and-Set .
4.5.5 Problemas . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
48
54
60
62
63
64
67
69
80
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
82
82
83
85
85
85
87
89
90
92
93
93
97
98
.
.
.
.
.
.
.
.
.
.
102
102
102
106
108
108
109
109
111
111
113
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
c Carlos Maziero
ix
0: SUMRIO
4.6
4.7
4.8
4.9
Semforos . . . . . . . . . . . . . . . . . . . . . . .
Variveis de condio . . . . . . . . . . . . . . . . .
Monitores . . . . . . . . . . . . . . . . . . . . . . .
Problemas clssicos de coordenao . . . . . . . .
4.9.1 O problema dos produtores/consumidores
4.9.2 O problema dos leitores/escritores . . . . .
4.9.3 O jantar dos filsofos . . . . . . . . . . . . .
4.10 Impasses . . . . . . . . . . . . . . . . . . . . . . . .
4.10.1 Caracterizao de impasses . . . . . . . . .
4.10.2 Grafos de alocao de recursos . . . . . . .
4.10.3 Tcnicas de tratamento de impasses . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
118
120
122
123
125
128
130
132
133
135
Gerncia de memria
5.1 Estruturas de memria . . . . . . . . . . . . . .
5.2 Endereos, variveis e funes . . . . . . . . .
5.2.1 Endereos lgicos e fsicos . . . . . . . .
5.2.2 Modelo de memria dos processos . . .
5.3 Estratgias de alocao . . . . . . . . . . . . . .
5.3.1 Parties fixas . . . . . . . . . . . . . . .
5.3.2 Alocao contgua . . . . . . . . . . . .
5.3.3 Alocao por segmentos . . . . . . . . .
5.3.4 Alocao paginada . . . . . . . . . . . .
5.3.5 Alocao segmentada paginada . . . .
5.4 Localidade de referncias . . . . . . . . . . . .
5.5 Fragmentao . . . . . . . . . . . . . . . . . . .
5.6 Compartilhamento de memria . . . . . . . . .
5.7 Memria virtual . . . . . . . . . . . . . . . . . .
5.7.1 Mecanismo bsico . . . . . . . . . . . .
5.7.2 Eficincia de uso . . . . . . . . . . . . .
5.7.3 Algoritmos de substituio de pginas
5.7.4 Conjunto de trabalho . . . . . . . . . . .
5.7.5 A anomalia de Belady . . . . . . . . . .
5.7.6 Thrashing . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
141
141
143
147
148
150
151
152
154
157
168
169
173
177
180
181
184
186
195
198
199
Gerncia de arquivos
6.1 Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 O conceito de arquivo . . . . . . . . . . . . . . . . . .
6.1.2 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . .
202
202
203
204
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
c Carlos Maziero
x
6.2
6.3
6.4
6.5
7
6.1.3 Operaes . . . . . . . . . . . .
6.1.4 Formatos . . . . . . . . . . . . .
6.1.5 Arquivos especiais . . . . . . .
Uso de arquivos . . . . . . . . . . . . .
6.2.1 Abertura de um arquivo . . . .
6.2.2 Formas de acesso . . . . . . . .
6.2.3 Controle de acesso . . . . . . .
6.2.4 Compartilhamento de arquivos
6.2.5 Exemplo de interface . . . . . .
Organizao de volumes . . . . . . . .
6.3.1 Diretrios . . . . . . . . . . . .
6.3.2 Caminhos de acesso . . . . . .
6.3.3 Atalhos . . . . . . . . . . . . . .
6.3.4 Montagem de volumes . . . . .
Sistemas de arquivos . . . . . . . . . .
6.4.1 Arquitetura geral . . . . . . . .
6.4.2 Blocos fsicos e lgicos . . . . .
6.4.3 Alocao fsica de arquivos . .
6.4.4 O sistema de arquivos virtual .
Tpicos avanados . . . . . . . . . . .
0: SUMRIO
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Gerncia de entrada/sada
7.1 Introduo . . . . . . . . . . . . . . . . .
7.2 Dispositivos de entrada/sada . . . . . .
7.2.1 Componentes de um dispositivo
7.2.2 Barramentos . . . . . . . . . . . .
7.2.3 Interface de acesso . . . . . . . .
7.2.4 Endereamento . . . . . . . . . .
7.2.5 Interrupes . . . . . . . . . . . .
7.3 Software de entrada/sada . . . . . . . .
7.3.1 Classes de dispositivos . . . . . .
7.3.2 Estratgias de interao . . . . .
7.4 Discos rgidos . . . . . . . . . . . . . . .
7.4.1 Estrutura fsica . . . . . . . . . .
7.4.2 Interface de hardware . . . . . .
7.4.3 Escalonamento de acessos . . . .
7.4.4 Caching de blocos . . . . . . . . .
7.4.5 Sistemas RAID . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
205
206
211
213
213
215
217
219
222
224
225
227
231
233
234
235
237
238
252
254
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
255
255
257
257
258
260
264
266
271
272
274
284
285
286
287
291
292
c Carlos Maziero
xi
7.5
7.6
7.7
7.8
7.9
7.10
8
Interfaces de rede .
Dispositivos USB .
Interfaces de udio
Interface grfica . .
Mouse e teclado . .
Outros tpicos . . .
0: SUMRIO
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
299
299
299
299
299
299
Segurana de sistemas
300
8.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
8.2 Conceitos bsicos . . . . . . . . . . . . . . . . . . . . . . . . . 301
8.2.1 Propriedades e princpios de segurana . . . . . . . . 301
8.2.2 Ameaas . . . . . . . . . . . . . . . . . . . . . . . . . . 304
8.2.3 Vulnerabilidades . . . . . . . . . . . . . . . . . . . . . 305
8.2.4 Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . 307
8.2.5 Malwares . . . . . . . . . . . . . . . . . . . . . . . . . 310
8.2.6 Infraestrutura de segurana . . . . . . . . . . . . . . . 312
8.3 Fundamentos de criptografia . . . . . . . . . . . . . . . . . . 314
8.3.1 Cifragem e decifragem . . . . . . . . . . . . . . . . . . 314
8.3.2 Criptografia simtrica e assimtrica . . . . . . . . . . 315
8.3.3 Resumo criptogrfico . . . . . . . . . . . . . . . . . . 319
8.3.4 Assinatura digital . . . . . . . . . . . . . . . . . . . . . 320
8.3.5 Certificado de chave pblica . . . . . . . . . . . . . . 321
8.4 Autenticao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
8.4.1 Usurios e grupos . . . . . . . . . . . . . . . . . . . . 324
8.4.2 Tcnicas de autenticao . . . . . . . . . . . . . . . . . 325
8.4.3 Senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
8.4.4 Senhas descartveis . . . . . . . . . . . . . . . . . . . 327
8.4.5 Tcnicas biomtricas . . . . . . . . . . . . . . . . . . . 328
8.4.6 Desafio-resposta . . . . . . . . . . . . . . . . . . . . . 330
8.4.7 Certificados de autenticao . . . . . . . . . . . . . . . 331
8.4.8 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . 332
8.4.9 Infra-estruturas de autenticao . . . . . . . . . . . . 335
8.5 Controle de acesso . . . . . . . . . . . . . . . . . . . . . . . . 337
8.5.1 Polticas, modelos e mecanismos de controle de acesso 338
8.5.2 Polticas discricionrias . . . . . . . . . . . . . . . . . 340
8.5.3 Polticas obrigatrias . . . . . . . . . . . . . . . . . . . 345
8.5.4 Polticas baseadas em domnios e tipos . . . . . . . . 349
8.5.5 Polticas baseadas em papis . . . . . . . . . . . . . . 351
c Carlos Maziero
xii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
352
360
364
364
368
369
Virtualizao de sistemas
9.1 Conceitos bsicos . . . . . . . . . . . . . . . . . .
9.1.1 Um breve histrico . . . . . . . . . . . . .
9.1.2 Interfaces de sistema . . . . . . . . . . . .
9.1.3 Compatibilidade entre interfaces . . . . .
9.1.4 Virtualizao de interfaces . . . . . . . . .
9.1.5 Virtualizao versus abstrao . . . . . .
9.2 A construo de mquinas virtuais . . . . . . . .
9.2.1 Definio formal . . . . . . . . . . . . . .
9.2.2 Suporte de hardware . . . . . . . . . . . .
9.2.3 Formas de virtualizao . . . . . . . . . .
9.3 Tipos de mquinas virtuais . . . . . . . . . . . .
9.3.1 Mquinas virtuais de processo . . . . . .
9.3.2 Mquinas virtuais de sistema operacional
9.3.3 Mquinas virtuais de sistema . . . . . . .
9.4 Tcnicas de virtualizao . . . . . . . . . . . . . .
9.4.1 Emulao completa . . . . . . . . . . . . .
9.4.2 Virtualizao da interface de sistema . . .
9.4.3 Traduo dinmica . . . . . . . . . . . . .
9.4.4 Paravirtualizao . . . . . . . . . . . . . .
9.4.5 Aspectos de desempenho . . . . . . . . .
9.5 Aplicaes da virtualizao . . . . . . . . . . . .
9.6 Ambientes de mquinas virtuais . . . . . . . . .
9.6.1 VMware . . . . . . . . . . . . . . . . . . .
9.6.2 FreeBSD Jails . . . . . . . . . . . . . . . .
9.6.3 Xen . . . . . . . . . . . . . . . . . . . . . .
9.6.4 User-Mode Linux . . . . . . . . . . . . . .
9.6.5 QEMU . . . . . . . . . . . . . . . . . . . .
9.6.6 Valgrind . . . . . . . . . . . . . . . . . . .
9.6.7 JVM . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
371
371
372
373
374
377
379
381
382
385
388
390
391
394
398
400
400
402
402
404
405
408
411
411
412
413
414
416
417
418
8.6
8.5.6 Mecanismos de controle de acesso

8.5.7 Mudana de privilgios . . . . . .
Auditoria . . . . . . . . . . . . . . . . . . .
8.6.1 Coleta de dados . . . . . . . . . . .
8.6.2 Anlise de dados . . . . . . . . . .
8.6.3 Auditoria preventiva . . . . . . . .
0: SUMRIO
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
c Carlos Maziero
xiii
0: SUMRIO
Referncias Bibliogrficas
419
A O Task Control Block do Linux
432
Captulo 1
Conceitos bsicos
Um sistema de computao constitudo basicamente por hardware e software. O hardware composto por circuitos eletrnicos
(processador, memria, portas de entrada/sada, etc.) e perifricos
eletro-ptico-mecnicos (teclados, mouses, discos rgidos, unidades
de disquete, CD ou DVD, dispositivos USB, etc.). Por sua vez, o
software de aplicao representado por programas destinados ao
usurio do sistema, que constituem a razo final de seu uso, como
editores de texto, navegadores Internet ou jogos. Entre os aplicativos
e o hardware reside uma camada de software multi-facetada e complexa, denominada genericamente de Sistema Operacional. Neste
captulo veremos quais os objetivos bsicos do sistema operacional,
quais desafios ele deve resolver e como ele estruturado para alcanar
seus objetivos.
1.1
Objetivos
Existe uma grande distncia entre os circuitos eletrnicos e dispositivos

de hardware e os programas aplicativos em software. Os circuitos so
complexos, acessados atravs de interfaces de baixo nvel (geralmente
usando as portas de entrada/sada do processador) e muitas vezes suas
caractersticas e seu comportamento dependem da tecnologia usada em
sua construo. Por exemplo, a forma de acesso de baixo nvel a discos
rgidos IDE difere da forma de acesso a discos SCSI ou leitores de CD.
Essa grande diversidade pode ser uma fonte de dores de cabea para o
desenvolvedor de aplicativos. Portanto, torna-se desejvel oferecer aos
c Carlos Maziero
2
1: Objetivos
programas aplicativos uma forma de acesso homognea aos dispositivos

fsicos, que permita abstrair as diferenas tecnolgicas entre eles.
O sistema operacional uma camada de software que opera entre o
hardware e os programas aplicativos voltados ao usurio final. O sistema
operacional uma estrutura de software ampla, muitas vezes complexa, que
incorpora aspectos de baixo nvel (como drivers de dispositivos e gerncia
de memria fsica) e de alto nvel (como programas utilitrios e a prpria
interface grfica).
A Figura 1.1 ilustra a arquitetura geral de um sistema de computao tpico. Nela, podemos observar elementos de hardware, o sistema operacional
e alguns programas aplicativos.
editor de
textos
aplicativos
Ad augusta per
angusta.
De omni re scibili, et
quibusdam aliis.
Felix qui potuit rerum
cognoscere causas.
In medio stat virtus.
Labor omnia vincit
improbus.
Non nova, sed nove.
Qui scribit bis legit.
reprodutor
de mdia
editor
grco
sistema operacional
hardware
discos
memria
portas
USB
rede
Figura 1.1: Estrutura de um sistema de computao tpico

Os objetivos bsicos de um sistema operacional podem ser sintetizados
em duas palavras-chave: abstrao e gerncia, cujos principais aspectos
so detalhados a seguir.
c Carlos Maziero
3
1.1.1
1: Abstrao de recursos
Abstrao de recursos
Acessar os recursos de hardware de um sistema de computao pode

ser uma tarefa complexa, devido s caractersticas especficas de cada
dispositivo fsico e a complexidade de suas interfaces. Por exemplo, a
sequncia a seguir apresenta os principais passos envolvidos na abertura de
um arquivo (operao open) em um leitor de disquete:
1. verificar se os parmetros informados esto corretos (nome do arquivo,
identificador do leitor de disquete, buffer de leitura, etc.);
2. verificar se o leitor de disquetes est disponvel;
3. verificar se o leitor contm um disquete;
4. ligar o motor do leitor e aguardar atingir a velocidade de rotao
correta;
5. posicionar a cabea de leitura sobre a trilha onde est a tabela de
diretrio;
6. ler a tabela de diretrio e localizar o arquivo ou subdiretrio desejado;
7. mover a cabea de leitura para a posio do bloco inicial do arquivo;
8. ler o bloco inicial do arquivo e deposit-lo em um buffer de memria.
Assim, o sistema operacional deve definir interfaces abstratas para os
recursos do hardware, visando atender os seguintes objetivos:
Prover interfaces de acesso aos dispositivos, mais simples de usar que as
interfaces de baixo nvel, para simplificar a construo de programas
aplicativos. Por exemplo: para ler dados de um disco rgido, uma
aplicao usa um conceito chamado arquivo, que implementa uma
viso abstrata do disco rgido, acessvel atravs de operaes como
open, read e close. Caso tivesse de acessar o disco diretamente, teria
de manipular portas de entrada/sada e registradores com comandos
para o controlador de disco (sem falar na dificuldade de localizar os
dados desejados dentro do disco).
c Carlos Maziero
4
1: Gerncia de recursos
Tornar os aplicativos independentes do hardware. Ao definir uma interface

abstrata de acesso a um dispositivo de hardware, o sistema operacional
desacopla o hardware dos aplicativos e permite que ambos evoluam de
forma mais autnoma. Por exemplo, o cdigo de um editor de textos
no deve ser dependente da tecnologia de discos rgidos utilizada no
sistema.
Definir interfaces de acesso homogneas para dispositivos com tecnologias
distintas. Atravs de suas abstraes, o sistema operacional permite
aos aplicativos usar a mesma interface para dispositivos diversos. Por
exemplo, um aplicativo acessa dados em disco atravs de arquivos e
diretrios, sem precisar se preocupar com a estrutura real de armazenamento dos dados, que podem estar em um disquete, um disco IDE,
uma mquina fotogrfica digital conectada porta USB, um CD ou
mesmo um disco remoto, compartilhado atravs da rede.
1.1.2
Gerncia de recursos
Os programas aplicativos usam o hardware para atingir seus objetivos:

ler e armazenar dados, editar e imprimir documentos, navegar na Internet,
tocar msica, etc. Em um sistema com vrias atividades simultneas, podem
surgir conflitos no uso do hardware, quando dois ou mais aplicativos
precisam dos mesmos recursos para poder executar. Cabe ao sistema
operacional definir polticas para gerenciar o uso dos recursos de hardware
pelos aplicativos, e resolver eventuais disputas e conflitos. Vejamos algumas
situaes onde a gerncia de recursos do hardware se faz necessria:
Cada computador normalmente possui menos processadores que o
nmero de tarefas em execuo. Por isso, o uso desses processadores
deve ser distribudo entre os aplicativos presentes no sistema, de
forma que cada um deles possa executar na velocidade adequada para
cumprir suas funes sem prejudicar os demais. O mesmo ocorre com
a memria RAM, que deve ser distribuda de forma justa entre as
aplicaes.
A impressora um recurso cujo acesso deve ser efetuado de forma
mutuamente exclusiva (apenas um aplicativo por vez), para no
ocorrer mistura de contedo nos documentos impressos. O sistema
operacional resolve essa questo definindo uma fila de trabalhos a
c Carlos Maziero
5
1: Tipos de sistemas operacionais
imprimir (print jobs) normalmente atendidos de forma sequencial

(FIFO).
Ataques de negao de servio (DoS Denial of Service) so comuns
na Internet. Eles consistem em usar diversas tcnicas para forar um
servidor de rede a dedicar seus recursos a atender um determinado
usurio, em detrimento dos demais. Por exemplo, ao abrir milhares
de conexes simultneas em um servidor de e-mail, um atacante pode
reservar para si todos os recursos do servidor (processos, conexes de
rede, memria e processador), fazendo com que os demais usurios
no sejam mais atendidos. responsabilidade do sistema operacional
do servidor detectar tais situaes e impedir que todos os recursos
do sistema sejam monopolizados por um s usurio (ou um pequeno
grupo).
Assim, um sistema operacional visa abstrair o acesso e gerenciar os
recursos de hardware, provendo aos aplicativos um ambiente de execuo
abstrato, no qual o acesso aos recursos se faz atravs de interfaces simples,
independentes das caractersticas e detalhes de baixo nvel, e no qual os
conflitos no uso do hardware so minimizados.
1.2
Tipos de sistemas operacionais
Os sistemas operacionais podem ser classificados segundo diversos

parmetros e perspectivas, como tamanho, velocidade, suporte a recursos
especficos, acesso rede, etc. A seguir so apresentados alguns tipos de
sistemas operacionais usuais (muitos sistemas operacionais se encaixam
bem em mais de uma das categorias apresentadas):
Batch (de lote) : os sistemas operacionais mais antigos trabalhavam por
lote, ou seja, todos os programas a executar eram colocados em
uma fila, com seus dados e demais informaes para a execuo. O
processador recebia os programas e os processava sem interagir com
os usurios, o que permitia um alto grau de utilizao do sistema. Atualmente, este conceito se aplica a sistemas que processam tarefas sem
interao direta com os usurios, como os sistemas de processamento
de transaes em bancos de dados. Alm disso, o termo em lote
tambm usado para designar um conjunto de comandos que deve
c Carlos Maziero
6
ser executado em sequncia, sem interferncia do usurio. Exemplos

desses sistemas incluem o OS/360 e VMS, entre outros.
De rede : um sistema operacional de rede deve possuir suporte operao
em rede, ou seja, a capacidade de oferecer s aplicaes locais recursos
que estejam localizados em outros computadores da rede, como
arquivos e impressoras. Ele tambm deve disponibilizar seus recursos
locais aos demais computadores, de forma controlada. A maioria dos
sistemas operacionais atuais oferece esse tipo de funcionalidade.
Distribudo : em um sistema operacional distribudo, os recursos de cada
mquina esto disponveis globalmente, de forma transparente aos
usurios. Ao lanar uma aplicao, o usurio interage com sua janela, mas no sabe onde ela est executando ou armazenando seus
arquivos: o sistema quem decide, de forma transparente. Os
sistemas operacionais distribudos j existem h tempos (Amoeba
[Tanenbaum et al., 1991] e Clouds [Dasgupta et al., 1991], por exemplo), mas ainda no so uma realidade de mercado.
Multi-usurio : um sistema operacional multi-usurio deve suportar a
identificao do dono de cada recurso dentro do sistema (arquivos,
processos, reas de memria, conexes de rede) e impor regras de
controle de acesso para impedir o uso desses recursos por usurios
no autorizados. Essa funcionalidade fundamental para a segurana
dos sistemas operacionais de rede e distribudos. Grande parte dos
sistemas atuais so multi-usurios.
Desktop : um sistema operacional de mesa voltado ao atendimento
do usurio domstico e corporativo para a realizao de atividades
corriqueiras, como edio de textos e grficos, navegao na Internet
e reproduo de mdias simples. Suas principais caractersticas so
a interface grfica, o suporte interatividade e a operao em rede.
Exemplos de sistemas desktop so os vrios sistemas Windows (XP,
Vista, 7, etc.), o MacOS X e Linux.
Servidor : um sistema operacional servidor deve permitir a gesto eficiente
de grandes quantidades de recursos (disco, memria, processadores),
impondo prioridades e limites sobre o uso dos recursos pelos usurios
e seus aplicativos. Normalmente um sistema operacional servidor
tambm tem suporte a rede e multi-usurios.
c Carlos Maziero
7
Embarcado : um sistema operacional dito embarcado (embutido ou embedded) quando construdo para operar sobre um hardware com poucos
recursos de processamento, armazenamento e energia. Aplicaes
tpicas desse tipo de sistema aparecem em telefones celulares, sistemas
de automao industrial e controladores automotivos, equipamentos
eletrnicos de uso domstico (leitores de DVD, TVs, fornos-microondas, centrais de alarme, etc.). Muitas vezes um sistema operacional
embarcado se apresenta na forma de uma biblioteca a ser ligada ao
programa da aplicao (que fixa). LynxOS, C/OS, Xylinx e VxWorks
so exemplos de sistemas operacionais embarcados para controle e
automao. Sistemas operacionais para telefones celulares inteligentes
(smartphones) incluem o Symbian e o Android, entre outros.
Tempo real : ao contrrio da concepo usual, um sistema operacional
de tempo real no precisa ser necessariamente ultra-rpido; sua
caracterstica essencial ter um comportamento temporal previsvel
(ou seja, seu tempo de resposta deve ser conhecido no melhor e pior
caso de operao). A estrutura interna de um sistema operacional
de tempo real deve ser construda de forma a minimizar esperas e
latncias imprevisveis, como tempos de acesso a disco e sincronizaes
excessivas.
Existem duas classificaes de sistemas de tempo real: soft real-time
systems, nos quais a perda de prazos implica na degradao do servio
prestado. Um exemplo seria o suporte gravao de CDs ou
reproduo de msicas. Caso o sistema se atrase, pode ocorrer a perda
da mdia em gravao ou falhas na msica que est sendo tocada.
Por outro lado, nos hard real-time systems a perda de prazos pelo
sistema pode perturbar o objeto controlado, com graves consequncias
humanas, econmicas ou ambientais. Exemplos desse tipo de sistema
seriam o controle de funcionamento de uma turbina de avio a jato ou
de uma caldeira industrial.
Exemplos de sistemas de tempo real incluem o QNX, RT-Linux e
VxWorks. Muitos sistemas embarcados tm caractersticas de tempo
real, e vice-versa.
c Carlos Maziero
8
1.3
1: Funcionalidades
Funcionalidades
Para cumprir seus objetivos de abstrao e gerncia, o sistema operacional

deve atuar em vrias frentes. Cada um dos recursos do sistema possui
suas particularidades, o que impe exigncias especficas para gerenciar
e abstrair os mesmos. Sob esta perspectiva, as principais funcionalidades
implementadas por um sistema operacional tpico so:
Gerncia do processador : tambm conhecida como gerncia de processos
ou de atividades, esta funcionalidade visa distribuir a capacidade
de processamento de forma justa1 entre as aplicaes, evitando que
uma aplicao monopolize esse recurso e respeitando as prioridades
dos usurios. O sistema operacional prov a iluso de que existe um
processador independente para cada tarefa, o que facilita o trabalho
dos programadores de aplicaes e permite a construo de sistemas
mais interativos. Tambm faz parte da gerncia de atividades fornecer
abstraes para sincronizar atividades inter-dependentes e prover
formas de comunicao entre elas.
Gerncia de memria : tem como objetivo fornecer a cada aplicao uma
rea de memria prpria, independente e isolada das demais aplicaes e inclusive do ncleo do sistema. O isolamento das reas de
memria das aplicaes melhora a estabilidade e segurana do sistema
como um todo, pois impede aplicaes com erros (ou aplicaes maliciosas) de interferir no funcionamento das demais aplicaes. Alm
disso, caso a memria RAM existente seja insuficiente para as aplicaes, o sistema operacional pode aument-la de forma transparente
s aplicaes, usando o espao disponvel em um meio de armazenamento secundrio (como um disco rgido). Uma importante abstrao
construda pela gerncia de memria a noo de memria virtual,
que desvincula os endereos de memria vistos por cada aplicao
dos endereos acessados pelo processador na memria RAM. Com
isso, uma aplicao pode ser carregada em qualquer posio livre da
memria, sem que seu programador tenha de se preocupar com os
endereos de memria onde ela ir executar.
1
Distribuir de forma justa, mas no necessariamente igual, pois as aplicaes tm

demandas de processamento distintas; por exemplo, um navegador de Internet demanda
menos o processador que um aplicativo de edio de vdeo, e por isso o navegador pode
receber menos tempo de processador.
c Carlos Maziero
9
1: Funcionalidades
Gerncia de dispositivos : cada perifrico do computador possui suas

peculiaridades; assim, o procedimento de interao com uma placa
de rede completamente diferente da interao com um disco rgido
SCSI. Todavia, existem muitos problemas e abordagens em comum
para o acesso aos perifricos. Por exemplo, possvel criar uma
abstrao nica para a maioria dos dispositivos de armazenamento
como pen-drives, discos SCSI ou IDE, disquetes, etc., na forma de
um vetor de blocos de dados. A funo da gerncia de dispositivos
(tambm conhecida como gerncia de entrada/sada) implementar a
interao com cada dispositivo por meio de drivers e criar modelos
abstratos que permitam agrupar vrios dispositivos distintos sob a
mesma interface de acesso.
Gerncia de arquivos : esta funcionalidade construda sobre a gerncia de
dispositivos e visa criar arquivos e diretrios, definindo sua interface
de acesso e as regras para seu uso. importante observar que
os conceitos abstratos de arquivo e diretrio so to importantes e
difundidos que muitos sistemas operacionais os usam para permitir o
acesso a recursos que nada tem a ver com armazenamento. Exemplos
disso so as conexes de rede (nos sistemas UNIX e Windows, cada
socket TCP visto como um descritor de arquivo no qual pode-se ler
ou escrever dados) e as informaes do ncleo do sistema (como o
diretrio /proc do UNIX). No sistema operacional experimental Plan 9
[Pike et al., 1993], todos os recursos do sistema operacional so vistos
como arquivos.
Gerncia de proteo : com computadores conectados em rede e compartilhados por vrios usurios, importante definir claramente os recursos
que cada usurio pode acessar, as formas de acesso permitidas (leitura,
escrita, etc.) e garantir que essas definies sejam cumpridas. Para
proteger os recursos do sistema contra acessos indevidos, necessrio:
a) definir usurios e grupos de usurios; b) identificar os usurios que
se conectam ao sistema, atravs de procedimentos de autenticao; c)
definir e aplicar regras de controle de acesso aos recursos, relacionando
todos os usurios, recursos e formas de acesso e aplicando essas regras
atravs de procedimentos de autorizao; e finalmente d) registrar o
uso dos recursos pelos usurios, para fins de auditoria e contabilizao.
c Carlos Maziero
10
1: Funcionalidades
Alm dessas funcionalidades bsicas oferecidas pela maioria dos sistemas

operacionais, vrias outras vm se agregar aos sistemas modernos, para
cobrir aspectos complementares, como a interface grfica, suporte de rede,
fluxos multimdia, gerncia de energia, etc.
As funcionalidades do sistema operacional geralmente so interdependentes: por exemplo, a gerncia do processador depende de aspectos
da gerncia de memria, assim como a gerncia de memria depende
da gerncia de dispositivos e da gerncia de proteo. Alguns autores
[Silberschatz et al., 2001, Tanenbaum, 2003] representam a estrutura do sistema operacional conforme indicado na Figura 1.2. Nela, o ncleo central
implementa o acesso de baixo nvel ao hardware, enquanto os mdulos
externos representam as vrias funcionalidades do sistema.
gerncia do
processador
gerncia de
memria
suporte
de rede
gerncia de
dispositivos
ncleo
gerncia de
proteo
gerncia de
arquivos
interface
grca
etc
Figura 1.2: Funcionalidades do sistema operacional

Uma regra importante a ser observada na construo de um sistema
operacional a separao entre os conceitos de poltica e mecanismo2 . Como
poltica consideram-se os aspectos de deciso mais abstratos, que podem ser
resolvidos por algoritmos de nvel mais alto, como por exemplo decidir a
quantidade de memria que cada aplicao ativa deve receber, ou qual o
prximo pacote de rede a enviar para satisfazer determinadas especificaes
de qualidade de servio.
Por outro lado, como mecanismo consideram-se os procedimentos de
baixo nvel usados para implementar as polticas, ou seja, atribuir ou re2
Na verdade essa regra to importante que deveria ser levada em conta na construo
de qualquer sistema computacional complexo.
c Carlos Maziero
11
1: Estrutura de um sistema operacional
tirar memria de uma aplicao, enviar ou receber um pacote de rede,

etc. Os mecanismos devem ser suficientemente genricos para suportar
mudanas de poltica sem necessidade de modificaes. Essa separao
entre os conceitos de poltica e mecanismo traz uma grande flexibilidade
aos sistemas operacionais, permitindo alterar sua personalidade (sistemas mais interativos ou mais eficientes) sem ter de alterar o cdigo que
interage diretamente com o hardware. Alguns sistemas, como o InfoKernel [Arpaci-Dusseau et al., 2003], permitem que as aplicaes escolham as
polticas do sistema mais adequadas s suas necessidades.
1.4
Estrutura de um sistema operacional
Um sistema operacional no um bloco nico e fechado de software

executando sobre o hardware. Na verdade, ele composto de diversos
componentes com objetivos e funcionalidades complementares. Alguns dos
componentes mais relevantes de um sistema operacional tpico so:
Ncleo : o corao do sistema operacional, responsvel pela gerncia dos
recursos do hardware usados pelas aplicaes. Ele tambm implementa as principais abstraes utilizadas pelos programas aplicativos.
Drivers : mdulos de cdigo especficos para acessar os dispositivos fsicos.
Existe um driver para cada tipo de dispositivo, como discos rgidos
IDE, SCSI, portas USB, placas de vdeo, etc. Muitas vezes o driver
construdo pelo prprio fabricante do hardware e fornecido em forma
compilada (em linguagem de mquina) para ser acoplado ao restante
do sistema operacional.
Cdigo de inicializao : a inicializao do hardware requer uma srie de
tarefas complexas, como reconhecer os dispositivos instalados, testlos e configur-los adequadamente para seu uso posterior. Outra tarefa
importante carregar o ncleo do sistema operacional em memria e
iniciar sua execuo.
Programas utilitrios : so programas que facilitam o uso do sistema computacional, fornecendo funcionalidades complementares ao ncleo,
como formatao de discos e mdias, configurao de dispositivos,
manipulao de arquivos (mover, copiar, apagar), interpretador de
comandos, terminal, interface grfica, gerncia de janelas, etc.
c Carlos Maziero
12
1: Conceitos de hardware
As diversas partes do sistema operacional esto relacionadas entre

si conforme apresentado na Figura 1.3. A forma como esses diversos
componentes so interligados e se relacionam varia de sistema para sistema;
algumas possibilidades so discutidas na Seo 1.6.
aplicativos
programas
utilitrios
nvel de usurio
nvel de sistema
ncleo
software
cdigo de
inicializao
drivers de
dispositivos
controladoras de dispositivos
hardware
dispositivos fsicos
Figura 1.3: Estrutura de um sistema operacional
1.5
Conceitos de hardware
O sistema operacional interage diretamente com o hardware para fornecer servios s aplicaes. Para a compreenso dos conceitos implementados
pelos sistemas operacionais, necessrio ter uma viso clara dos recursos
fornecidos pelo hardware e a forma de acess-los. Esta seo apresenta uma
reviso dos principais aspectos do hardware de um computador pessoal
convencional.
Um sistema de computao tpico constitudo de um ou mais processadores, responsveis pela execuo das instrues das aplicaes, uma
rea de memria que armazena as aplicaes em execuo (seus cdigos e
dados) e dispositivos perifricos que permitem o armazenamento de dados
e a comunicao com o mundo exterior, como discos rgidos, terminais e
c Carlos Maziero
13
1: Conceitos de hardware
teclados. A maioria dos computadores mono-processados atuais segue uma

arquitetura bsica definida nos anos 40 por Jnos (John) Von Neumann,
conhecida por arquitetura Von Neumann. A principal caracterstica desse
modelo a ideia de programa armazenado, ou seja, o programa a ser
executado reside na memria junto com os dados. Os principais elementos
constituintes do computador esto interligados por um ou mais barramentos
(para a transferncia de dados, endereos e sinais de controle). A Figura 1.4
ilustra a arquitetura de um computador tpico.
Memria
processador
MMU
mouse
teclado
controladora
USB
monitor
unidade
de disco
conexo
de rede
control.
de vdeo
control.
de disco
control.
de rede
dados
endereos
controle
Figura 1.4: Arquitetura de um computador tpico

O ncleo do sistema de computao o processador. Ele responsvel
por continuamente ler instrues e dados da memria ou de perifricos,
process-los e enviar os resultados de volta memria ou a outros perifricos.
Um processador convencional normalmente constitudo de uma unidade
lgica e aritmtica (ULA), que realiza os clculos e operaes lgicas, um
conjunto de registradores para armazenar dados de trabalho e alguns
registradores para funes especiais (contador de programa, ponteiro de
pilha, flags de status, etc.).
Todas as transferncias de dados entre processador, memria e perifricos
so feitas atravs dos barramentos: o barramento de endereos indica a
posio de memria (ou o dispositivo) a acessar, o barramento de controle
indica a operao a efetuar (leitura ou escrita) e o barramento de dados
transporta a informao indicada entre o processador e a memria ou um
controlador de dispositivo.
c Carlos Maziero
14
1: Interrupes
O acesso memria geralmente mediado por um controlador especfico

(que pode estar fisicamente dentro do prprio processador): a Unidade de
Gerncia de Memria (MMU - Memory Management Unit). Ela responsvel
por analisar cada endereo solicitado pelo processador, valid-los, efetuar as
converses de endereamento necessrias e executar a operao solicitada
pelo processador (leitura ou escrita de uma posio de memria).
Os perifricos do computador (discos, teclado, monitor, etc.) so acessados atravs de circuitos especficos genericamente denominados controladores: a placa de vdeo permite o acesso ao monitor, a placa ethernet
d acesso rede, o controlador USB permite acesso ao mouse, teclado e
outros dispositivos USB externos. Para o processador, cada dispositivo
representado por seu respectivo controlador. Os controladores podem ser
acessados atravs de portas de entrada/sada endereveis: a cada controlador
atribuda uma faixa de endereos de portas de entrada/sada. A Tabela 1.1
a seguir apresenta alguns endereos portas de entrada/sada para acessar
controladores em um PC tpico:
dispositivo
endereos de acesso
teclado
0060h-006Fh
barramento IDE primrio
0170h-0177h
barramento IDE secundrio
01F0h-01F7h
porta serial COM1
02F8h-02FFh
porta serial COM2
03F8h-03FFh
Tabela 1.1: Endereos de acesso a dispositivos
1.5.1
Interrupes
Quando um controlador de perifrico tem uma informao importante a

fornecer ao processador, ele tem duas alternativas de comunicao:
Aguardar at que o processador o consulte, o que poder ser demorado
caso o processador esteja ocupado com outras tarefas (o que geralmente
ocorre);
Notificar o processador atravs do barramento de controle, enviando
a ele uma requisio de interrupo (IRQ Interrupt ReQuest).
c Carlos Maziero
15
1: Interrupes
Ao receber a requisio de interrupo, os circuitos do processador

suspendem seu fluxo de execuo corrente e desviam para um endereo prdefinido, onde se encontra uma rotina de tratamento de interrupo (interrupt
handler). Essa rotina responsvel por tratar a interrupo, ou seja, executar
as aes necessrias para atender o dispositivo que a gerou. Ao final da
rotina de tratamento da interrupo, o processador retoma o cdigo que
estava executando quando recebeu a requisio.
A Figura 1.5 representa os principais passos associados ao tratamento
de uma interrupo envolvendo a placa de rede Ethernet, enumerados a
seguir:
programa
em execuo
Memria
1
rotina de
tratamento de
interrupo
5
6
rede
2
MMU
processador
dados
endereos
controladora
de rede
controle
Figura 1.5: Roteiro tpico de um tratamento de interrupo

1. O processador est executando um programa qualquer (em outras
palavras, um fluxo de execuo);
2. Um pacote vindo da rede recebido pela placa Ethernet;
3. A placa envia uma solicitao de interrupo (IRQ) ao processador;
c Carlos Maziero
16
1: Interrupes
4. O processamento desviado do programa em execuo para a rotina

de tratamento da interrupo;
5. A rotina de tratamento executada para receber as informaes da
placa de rede (via barramentos de dados e de endereos) e atualizar as
estruturas de dados do sistema operacional;
6. A rotina de tratamento da interrupo finalizada e o processador
retorna execuo do programa que havia sido interrompido.
Esse roteiro de aes ocorre a cada requisio de interrupo recebida
pelo processador. Cada interrupo geralmente corresponde a um evento
ocorrido em um dispositivo perifrico: a chegada de um pacote de rede,
um click no mouse, uma operao concluda pelo controlador de disco, etc.
Isso representa centenas ou mesmo milhares de interrupes recebidas por
segundo, dependendo da carga e da configurao do sistema (nmero e
natureza dos perifricos). Por isso, as rotinas de tratamento de interrupo
devem ser curtas e realizar suas tarefas rapidamente (para no prejudicar o
desempenho do sistema).
Normalmente o processador recebe e trata cada interrupo recebida,
mas nem sempre isso possvel. Por exemplo, receber e tratar uma interrupo pode ser problemtico caso o processador j esteja tratando outra
interrupo. Por essa razo, o processador pode decidir ignorar temporariamente algumas interrupes, se necessrio. Isso feito ajustando o bit
correspondente interrupo em um registrador especfico do processador.
Para distinguir interrupes geradas por dispositivos distintos, cada
interrupo identificada por um inteiro, normalmente com 8 bits. Como
cada interrupo pode exigir um tipo de tratamento diferente (pois os
dispositivos so diferentes), cada IRQ deve disparar sua prpria rotina
de tratamento de interrupo. A maioria das arquiteturas atuais define
um vetor de endereos de funes denominado Vetor de Interrupes (IV Interrupt Vector); cada entrada desse vetor aponta para a rotina de tratamento
da interrupo correspondente. Por exemplo, se a entrada 5 do vetor contm
o valor 3C20h, ento a rotina de tratamento da IRQ 5 iniciar na posio
3C20h da memria RAM. O vetor de interrupes reside em uma posio
fixa da memria RAM, definida pelo fabricante do processador, ou tem sua
posio indicada pelo contedo de um registrador da CPU especfico para
esse fim.
c Carlos Maziero
17
1: Proteo do ncleo
As interrupes recebidas pelo processador tm como origem eventos

externos a ele, ocorridos nos dispositivos perifricos e reportados por seus
controladores. Entretanto, alguns eventos gerados pelo prprio processador
podem ocasionar o desvio da execuo usando o mesmo mecanismo das
interrupes: so as excees. Eventos como instrues ilegais (inexistentes
ou com operandos invlidos), tentativa de diviso por zero ou outros erros
de software disparam excees no processador, que resultam na ativao
de uma rotina de tratamento de exceo, usando o mesmo mecanismo das
interrupes (e o mesmo vetor de endereos de funes). A Tabela 1.2
representa o vetor de interrupes do processador Intel Pentium (extrada
de [Patterson and Henessy, 2005]).
O mecanismo de interrupo torna eficiente a interao do processador
com os dispositivos perifricos. Se no existissem interrupes, o processador perderia muito tempo varrendo todos os dispositivos do sistema
para verificar se h eventos a serem tratados. Alm disso, as interrupes
permitem construir funes de entrada/sada assncronas, ou seja, o processador no precisa esperar a concluso de cada operao solicitada a
um dispositivo, pois o dispositivo gera uma interrupo para avisar o
processador quando a operao for concluda. Interrupes no so raras,
pelo contrrio: em um computador pessoal, o processador trata de centenas
a milhares de interrupes por segundo, dependendo da carga do sistema e
dos perifricos instalados.
1.5.2
Proteo do ncleo
Um sistema operacional deve gerenciar os recursos do hardware,

fornecendo-os s aplicaes conforme suas necessidades. Para assegurar a integridade dessa gerncia, essencial garantir que as aplicaes
no consigam acessar o hardware diretamente, mas sempre atravs de
pedidos ao sistema operacional, que avalia e intermedeia todos os acessos
ao hardware. Mas como impedir as aplicaes de acessar o hardware
diretamente?
Ncleo, drivers, utilitrios e aplicaes so constitudos basicamente de
cdigo de mquina. Todavia, devem ser diferenciados em sua capacidade de
interagir com o hardware: enquanto o ncleo e os drivers devem ter pleno
acesso ao hardware, para poder configur-lo e gerenci-lo, os utilitrios
e os aplicativos devem ter acesso mais restrito a ele, para no interferir
nas configuraes e na gerncia, o que acabaria desestabilizando o sistema
c Carlos Maziero
18
1: Proteo do ncleo
Tabela 1.2:
Vetor de Interrupes
[Patterson and Henessy, 2005]
IRQ
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19-31
32-255
do
processador
Pentium
Descrio
divide error
debug exception
null interrupt
breakpoint
INTO-detected overflow
bound range exception
invalid opcode
device not available
double fault
coprocessor segment overrun
invalid task state segment
segment not present
stack fault
general protection
page fault
Intel reserved
floating point error
alignment check
machine check
Intel reserved
maskable interrupts (devices & exceptions)
inteiro. Alm disso, aplicaes com acesso pleno ao hardware tornariam

inteis os mecanismos de segurana e controle de acesso aos recursos (tais
como arquivos, diretrios e reas de memria).
Para permitir diferenciar os privilgios de execuo dos diferentes tipos
de software, os processadores modernos contam com dois ou mais nveis
de privilgio de execuo. Esses nveis so controlados por flags especiais
nos processadores, e as formas de mudana de um nvel de execuo
para outro so controladas estritamente pelo processador. O processador
Pentium, por exemplo, conta com 4 nveis de privilgio (sendo 0 o nvel
mais privilegiado), embora a maioria dos sistemas operacionais construdos
c Carlos Maziero
19
1: Chamadas de sistema
para esse processador s use os nveis extremos (0 para o ncleo e drivers do

sistema operacional e 3 para utilitrios e aplicaes). Na forma mais simples
desse esquema, podemos considerar dois nveis bsicos de privilgio:
Nvel ncleo : tambm denominado nvel supervisor, sistema, monitor ou
ainda kernel space. Para um cdigo executando nesse nvel, todo o
processador est acessvel: todos os recursos internos do processador
(registradores e portas de entrada/sada) e reas de memria podem
ser acessados. Alm disso, todas as instrues do processador podem
ser executadas. Ao ser ligado, o processador entra em operao neste
nvel.
Nvel usurio (ou userspace): neste nvel, somente um sub-conjunto das
instrues do processador, registradores e portas de entrada/sada esto
disponveis. Instrues perigosas como HALT (parar o processador)
e RESET (reiniciar o processador) so proibidas para todo cdigo
executando neste nvel. Alm disso, o hardware restringe o uso da
memria, permitindo o acesso somente a reas previamente definidas.
Caso o cdigo em execuo tente executar uma instruo proibida ou
acessar uma rea de memria inacessvel, o hardware ir gerar uma
exceo, desviando a execuo para uma rotina de tratamento dentro
do ncleo, que provavelmente ir abortar o programa em execuo (e
tambm gerar a famosa frase este programa executou uma instruo
ilegal e ser finalizado, no caso do Windows).
fcil perceber que, em um sistema operacional convencional, o ncleo
e os drivers operam no nvel ncleo, enquanto os utilitrios e as aplicaes operam no nvel usurio, confinados em reas de memria distintas,
conforme ilustrado na Figura 1.6. Todavia, essa separao nem sempre
segue uma regra to simples; outras opes de organizao de sistemas
operacionais sero abordadas na Seo 1.6.
1.5.3
Chamadas de sistema
O confinamento de cada aplicao em sua rea de memria, imposto

pelos mapeamentos de memria realizados pela MMU nos acessos em nvel
usurio, prov robustez e confiabilidade ao sistema, pois garante que uma
aplicao no poder interferir nas reas de memria de outras aplicaes
ou do ncleo. Entretanto, essa proteo introduz um novo problema: como
c Carlos Maziero
20
nvel
usurio
nvel
ncleo
aplicao
aplicao
aplicao
aplicao
ncleo
hardware
Figura 1.6: Separao entre o ncleo e as aplicaes

chamar, a partir de uma aplicao, as rotinas oferecidas pelo ncleo para
o acesso ao hardware e suas abstraes? Em outras palavras, como uma
aplicao pode acessar a placa de rede para enviar/receber dados, se no
tem privilgio para acessar as portas de entrada/sada correspondentes nem
pode invocar o cdigo do ncleo que implementa esse acesso (pois esse
cdigo reside em outra rea de memria)?
A resposta a esse problema est no mecanismo de interrupo, apresentado na Seo 1.5.1. Os processadores implementam uma instruo especial
que permite acionar o mecanismo de interrupo de forma intencional, sem
depender de eventos externos ou internos. Ao ser executada, essa instruo
(int no Pentium, syscall no MIPS) comuta o processador para o nvel
privilegiado e procede de forma similar ao tratamento de uma interrupo.
Por essa razo, esse mecanismo denominado interrupo de software, ou trap.
Processadores modernos oferecem instrues especficas para entrar/sair
do modo privilegiado, como SYSCALL e SYSRET (nos processadores Intel 64
bits) e tambm um conjunto de registradores especficos para essa operao,
o que permite a transferncia rpida do controle para o ncleo, com custo
menor que o tratamento de uma interrupo.
A ativao de procedimentos do ncleo usando interrupes de software
(ou outros mecanismos correlatos) denominada chamada de sistema (system
call ou syscall). Os sistemas operacionais definem chamadas de sistema
para todas as operaes envolvendo o acesso a recursos de baixo nvel
(perifricos, arquivos, alocao de memria, etc.) ou abstraes lgicas
(criao e finalizao de tarefas, operadores de sincronizao e comunicao,
etc.). Geralmente as chamadas de sistema so oferecidas para as aplicaes
c Carlos Maziero
21
em modo usurio atravs de uma biblioteca do sistema (system library), que

prepara os parmetros, invoca a interrupo de software e retorna aplicao
os resultados obtidos.
A Figura 1.7 ilustra o funcionamento bsico de uma chamada de sistema
(a chamada read, que l dados de um arquivo previamente aberto). Os
seguintes passos so realizados:
1. No nvel usurio, a aplicao invoca a funo read(fd, &buffer, bytes)

da biblioteca de sistema (no Linux a biblioteca GNU C Library,
ou glibc; no Windows, essas funes so implementadas pela API
Win32).
2. A funo read preenche uma rea de memria com os parmetros
recebidos e escreve o endereo dessa rea em um registrador da CPU.
Em outro registrador, ela escreve o cdigo da chamada de sistema
desejada (no caso do Linux, seria 03h para a syscall read).
3. A funo read invoca uma interrupo de software (no caso do Linux,
sempre invocada a interrupo 80h).
4. O processador comuta para o nvel privilegiado (kernel level) e transfere o controle para a rotina apontada pela entrada 80h do vetor de
interrupes.
5. A rotina obtm o endereo dos parmetros, verifica a validade de cada
um deles e realiza (ou agenda para execuo posterior) a operao
desejada pela aplicao.
6. Ao final da execuo da rotina, eventuais valores de retorno so
escritos na rea de memria da aplicao e o processamento retorna
funo read, em modo usurio.
7. A funo read finaliza sua execuo e retorna o controle aplicao.
8. Caso a operao solicitada no possa ser realizada imediatamente,
a rotina de tratamento da interrupo de software passa o controle
para a gerncia de atividades, ao invs de retornar diretamente da
interrupo de software para a aplicao solicitante. Isto ocorre, por
exemplo, quando solicitada a leitura de uma entrada do teclado.
c Carlos Maziero
22
1: Arquiteturas de Sistemas Operacionais
9. Na sequncia, a gerncia de atividades devolve o controle do processador a outra aplicao que tambm esteja aguardando o retorno de
uma interrupo de software, e cuja operao solicitada j tenha sido
concluda.
aplicao
read(...)
2
nvel usurio
nvel ncleo
chamada 5
de sistema
gerncia de
atividades
vetor de interrupes
79h
80h
81h
82h
Figura 1.7: Roteiro tpico de uma chamada de sistema

A maioria dos sistemas operacionais implementa centenas de chamadas
de sistema distintas, para as mais diversas finalidades. O conjunto de
chamadas de sistema oferecidas por um ncleo define a API (Application
Programming Interface) desse sistema operacional. Exemplos de APIs bem
conhecidas so a Win32, oferecida pelos sistemas Microsoft derivados do
Windows NT, e a API POSIX [Gallmeister, 1994], que define um padro de
interface de ncleo para sistemas UNIX.
1.6
Arquiteturas de Sistemas Operacionais
Embora a definio de nveis de privilgio (Seo 1.5.3) imponha uma estruturao mnima a um sistema operacional, as vrias partes que compem
c Carlos Maziero
23
1: Sistemas monolticos
o sistema podem ser organizadas de diversas formas, separando suas funcionalidades e modularizando seu projeto. Nesta seo sero apresentadas as
arquiteturas mais populares para a organizao de sistemas operacionais.
1.6.1
Sistemas monolticos
Em um sistema monoltico, todos os componentes do ncleo operam

em modo ncleo e se inter-relacionam conforme suas necessidades, sem
restries de acesso entre si, pois o cdigo no nvel ncleo tem acesso pleno
a todos os recursos e reas de memria. A Figura 1.8 ilustra essa arquitetura.
nvel
usurio
aplicao
aplicao
memory
operations
le
operations
aplicao
process
manager
CPU
scheduler
aplicao
network
operations
memory
manager
access
control
nvel
ncleo
network
protocols
kernel data structures
NTFS
le system
MMU
control
block I/O
operations
USB
driver
VFAT
le system
SATA
driver
Bluetooth
driver
network
driver
hardware
Figura 1.8: Uma arquitetura monoltica

A grande vantagem dessa arquitetura seu desempenho: qualquer
componente do ncleo pode acessar os demais componentes, toda a memria ou mesmo dispositivos perifricos diretamente, pois no h barreiras
impedindo esse acesso. A interao direta entre componentes tambm leva
a sistemas mais compactos.
Todavia, a arquitetura monoltica pode pagar um preo elevado por
seu desempenho: a robustez e a facilidade de desenvolvimento. Caso
c Carlos Maziero
24
1: Sistemas em camadas
um componente do ncleo perca o controle devido a algum erro, esse

problema pode se alastrar rapidamente por todo o ncleo, levando o sistema
ao colapso (travamento, reinicializao ou funcionamento errtico). Alm
disso, a manuteno e evoluo do ncleo se tornam mais complexas, porque
as dependncias e pontos de interao entre os componentes podem no ser
evidentes: pequenas alteraes na estrutura de dados de um componente
podem ter um impacto inesperado em outros componentes, caso estes
acessem aquela estrutura diretamente.
A arquitetura monoltica foi a primeira forma de organizar os sistemas
operacionais; sistemas UNIX antigos e o MS-DOS seguiam esse modelo.
Atualmente, apenas sistemas operacionais embarcados so totalmente
monolticos, devido s limitaes do hardware sobre o qual executam.
O ncleo do Linux nasceu monoltico, mas vem sendo paulatinamente
estruturado e modularizado desde a verso 2.0 (embora boa parte de seu
cdigo ainda permanea no nvel de ncleo).
1.6.2
Sistemas em camadas
Uma forma mais elegante de estruturar um sistema operacional faz

uso da noo de camadas: a camada mais baixa realiza a interface com o
hardware, enquanto as camadas intermedirias provem nveis de abstrao
e gerncia cada vez mais sofisticados. Por fim, a camada superior define
a interface do ncleo para as aplicaes (as chamadas de sistema). Essa
abordagem de estruturao de software fez muito sucesso no domnio das
redes de computadores, atravs do modelo de referncia OSI (Open Systems
Interconnection) [Day, 1983], e tambm seria de se esperar sua adoo no
domnio dos sistemas operacionais. No entanto, alguns inconvenientes
limitam sua aceitao nesse contexto:
O empilhamento de vrias camadas de software faz com que cada
pedido de uma aplicao demore mais tempo para chegar at o dispositivo perifrico ou recurso a ser acessado, prejudicando o desempenho
do sistema.
No bvio como dividir as funcionalidades de um ncleo de sistema
operacional em camadas horizontais de abstrao crescente, pois essas
funcionalidades so inter-dependentes, embora tratem muitas vezes
de recursos distintos.
c Carlos Maziero
25
1: Sistemas micro-ncleo
Em decorrncia desses inconvenientes, a estruturao em camadas apenas parcialmente adotada hoje em dia. Muitos sistemas implementam uma
camada inferior de abstrao do hardware para interagir com os dispositivos
(a camada HAL Hardware Abstraction Layer, implementada no Windows NT
e seus sucessores), e tambm organizam em camadas alguns sub-sistemas
como a gerncia de arquivos e o suporte de rede (seguindo o modelo OSI).
Como exemplos de sistemas fortemente estruturados em camadas podem
ser citados o IBM OS/2 e o MULTICS [Corbat and Vyssotsky, 1965].
1.6.3
Sistemas micro-ncleo
Uma outra possibilidade de estruturao consiste em retirar do ncleo

todo o cdigo de alto nvel (normalmente associado s polticas de gerncia
de recursos), deixando no ncleo somente o cdigo de baixo nvel necessrio
para interagir com o hardware e criar as abstraes fundamentais (como
a noo de atividade). Por exemplo, usando essa abordagem o cdigo de
acesso aos blocos de um disco rgido seria mantido no ncleo, enquanto as
abstraes de arquivo e diretrio seriam criadas e mantidas por um cdigo
fora do ncleo, executando da mesma forma que uma aplicao do usurio.
Por fazer os ncleos de sistema ficarem menores, essa abordagem foi
denominada micro-ncleo (ou -kernel). Um micro-ncleo normalmente implementa somente a noo de atividade, de espaos de memria protegidos
e de comunicao entre atividades. Todos os aspectos de alto nvel, como
polticas de uso do processador e da memria, o sistema de arquivos e
o controle de acesso aos recursos so implementados fora do ncleo, em
processos que se comunicam usando as primitivas do ncleo. A Figura 1.9
ilustra essa abordagem.
Em um sistema micro-ncleo, as interaes entre componentes e aplicaes so feitas atravs de trocas de mensagens. Assim, se uma aplicao
deseja abrir um arquivo no disco rgido, envia uma mensagem para o gerente
de arquivos que, por sua vez, se comunica com o gerente de dispositivos
para obter os blocos de dados relativos ao arquivo desejado. Os processos
no podem se comunicar diretamente, devido s restries impostas pelos mecanismos de proteo do hardware. Por isso, todas as mensagens
so transmitidas atravs de servios do micro-ncleo, como mostra a Figura 1.9. Como os processos tm de solicitar servios uns dos outros,
para poder realizar suas tarefas, essa abordagem tambm foi denominada
cliente-servidor.
c Carlos Maziero
26
1: Sistemas micro-ncleo
user
application
user
application
user
application
aplicaes
sistema operacional
process
manager
memory
manager
MMU
control
le
system
protection
manager
network
protocols
block IO
operations
network
driver
disk
driver
nvel usurio
nvel ncleo
micro-kernel
hardware
Figura 1.9: Viso geral de uma arquitetura micro-ncleo

O micro-ncleos foram muito investigados durante os anos 80.
Dois exemplos clssicos dessa abordagem so os sistemas Mach
[Rashid et al., 1989] e Chorus [Rozier et al., 1992]. As principais vantagens dos sistemas micro-ncleo so sua robustez e flexibilidade: caso um
sub-sistema tenha problemas, os mecanismos de proteo de memria
e nveis de privilgio iro confin-lo, impedindo que a instabilidade se
alastre ao restante do sistema. Alm disso, possvel customizar o sistema
operacional, iniciando somente os componentes necessrios ou escolhendo
os componentes mais adequados s aplicaes que sero executadas.
Vrios sistemas operacionais atuais adotam parcialmente essa estruturao; por exemplo, o MacOS X da Apple tem suas razes no sistema Mach,
ocorrendo o mesmo com o Digital UNIX. Todavia, o custo associado s
trocas de mensagens entre componentes pode ser bastante elevado, o que
prejudica seu desempenho e diminui a aceitao desta abordagem. O QNX
um dos poucos exemplos de micro-ncleo amplamente utilizado, sobretudo
em sistemas embarcados e de tempo-real.
c Carlos Maziero
27
1.6.4
1: Mquinas virtuais
Mquinas virtuais
Para que programas e bibliotecas possam executar sobre uma determinada plataforma computacional, necessrio que tenham sido compilados
para ela, respeitando o conjunto de instrues do processador e o conjunto de chamadas do sistema operacional. Da mesma forma, um sistema
operacional s poder executar sobre uma plataforma de hardware se for
compatvel com ela. Nos sistemas atuais, as interfaces de baixo nvel so
pouco flexveis: geralmente no possvel criar novas instrues de processador ou novas chamadas de sistema, ou mudar sua semntica. Por isso, um
sistema operacional s funciona sobre o hardware para o qual foi construdo,
uma biblioteca s funciona sobre o hardware e sistema operacional para
os quais foi projetada e as aplicaes tambm tm de obedecer a interfaces
pr-definidas.
Todavia, possvel contornar os problemas de compatibilidade entre os
componentes de um sistema atravs de tcnicas de virtualizao. Usando os
servios oferecidos por um determinado componente do sistema, possvel
construir uma camada de software que oferea aos demais componentes
servios com outra interface. Essa camada permitir assim o acoplamento
entre interfaces distintas, de forma que um programa desenvolvido para
uma plataforma A possa executar sobre uma plataforma distinta B. O
sistema computacional visto atravs dessa camada denominado mquina
virtual.
A Figura 1.10, extrada de [Smith and Nair, 2004], mostra um exemplo
de mquina virtual, onde uma camada de virtualizao permite executar
um sistema operacional Windows e suas aplicaes sobre uma plataforma
de hardware Sparc, distinta daquela para a qual foi projetado (Intel/AMD).
sistema
convidado
monitor
sistema
hospedeiro
Aplics Windows
Aplics Windows
Windows
Windows
camada de
virtualizao
Sparc
x86
Mquina
Virtual
Figura 1.10: Uma mquina virtual [Smith and Nair, 2004].
c Carlos Maziero
28
1: Mquinas virtuais
Um ambiente de mquina virtual consiste de trs partes bsicas, que

podem ser observadas na Figura 1.10:
O sistema real, ou sistema hospedeiro (host system), que contm os
recursos reais de hardware e software do sistema;
o sistema virtual, tambm denominado sistema convidado (guest
system), que executa sobre o sistema virtualizado; em alguns casos,
vrios sistemas virtuais podem coexistir, executando sobre o mesmo
sistema real;
a camada de virtualizao, denominada hipervisor ou monitor de virtualizao (VMM - Virtual Machine Monitor), que constri as interfaces
virtuais a partir da interface real.
Na dcada de 1970, os pesquisadores Popek & Goldberg formalizaram
vrios conceitos associados s mquinas virtuais, e definiram as condies
necessrias para que uma plataforma de hardware suporte de forma eficiente
a virtualizao [Popek and Goldberg, 1974]. Nessa mesma poca surgem
as primeiras experincias concretas de utilizao de mquinas virtuais
para a execuo de aplicaes, com o ambiente UCSD p-System, no qual
programas Pascal so compilados para execuo sobre um hardware abstrato
denominado P-Machine. Com o aumento de desempenho e funcionalidades
do hardware PC e o surgimento da linguagem Java, no incio dos anos 90, o
interesse pelas tecnologias de virtualizao voltou tona. Atualmente, as
solues de virtualizao de linguagens e de plataformas vm despertando
grande interesse do mercado. Vrias linguagens so compiladas para
mquinas virtuais portveis e os processadores mais recentes trazem um
suporte nativo virtualizao de hardware, finalmente respeitando as
condies conceituais definidas no incio dos anos 70.
Existem diversas possibilidades de implementao de sistemas de mquinas virtuais. De acordo com o tipo de sistema convidado suportado,
os ambientes de mquinas virtuais podem ser divididos em duas grandes
famlias (Figura 1.11):
Mquinas virtuais de aplicao : so ambientes de mquinas virtuais destinados a suportar apenas um processo ou aplicao convidada especfica. A mquina virtual Java um exemplo desse tipo de ambiente.
c Carlos Maziero
29
1: Mquinas virtuais
Mquinas virtuais de sistema : so construdos para suportar sistemas

operacionais convidados completos, com aplicaes convidadas executando sobre eles. Como exemplos podem ser citados os ambientes
VMWare, Xen e VirtualBox.
Espao de
usurio
Aplics Linux
Aplic
Java
Aplics Linux
Aplics Windows
ncleo Linux
ncleo Windows
JVM
ncleo Linux
hipervisor
hardware x86
hardware x86
VM de aplicao
VM de sistema
Figura 1.11: Mquinas virtuais de aplicao e de sistema.

As mquinas virtuais de aplicao so geralmente usadas como suporte
de execuo de linguagens de programao. As primeiras experincias
com linguagens usando mquinas virtuais remontam aos anos 1970, com a
linguagem UCSD Pascal (da Universidade da Califrnia em San Diego). Na
poca, um programa escrito em Pascal era compilado em um cdigo binrio
denominado P-Code, que executava sobre o processador abstrato P-Machine.
O interpretador de P-Codes era bastante compacto e facilmente portvel, o
que tornou o sistema P muito popular. Hoje, muitas linguagens adotam
estratgias similares, como Java, C#, Python, Perl, Lua e Ruby. Em C#, o
cdigo-fonte compilado em um formato intermedirio denominado CIL
(Common Intermediate Language), que executa sobre uma mquina virtual
CLR (Common Language Runtime). CIL e CLR fazem parte da infraestrutura
.NET da Microsoft.
Mquinas virtuais de sistema suportam um ou mais sistemas operacionais convidados, com suas respectivas aplicaes, que executam de forma
isolada e independente. Em uma mquina virtual, cada sistema operacional convidado tem a iluso de executar sozinho sobre uma plataforma de
hardware exclusiva. Como o sistema operacional convidado e o ambiente
de execuo dentro da mquina virtual so idnticos ao da mquina real,
possvel usar os softwares j construdos para a mquina real dentro das
c Carlos Maziero
30
1: Mquinas virtuais
mquinas virtuais. Essa transparncia evita ter de construir novas aplicaes

ou adaptar as j existentes.
As mquinas virtuais de sistema constituem a primeira abordagem
usada para a construo de hipervisores, desenvolvida na dcada de 1960.
No que diz respeito sua arquitetura, existem basicamente dois tipos de
hipervisores de sistema, apresentados na Figura 1.12:
Hipervisores nativos (ou de tipo I): o hipervisor executa diretamente sobre
o hardware da mquina real, sem um sistema operacional subjacente. A
funo do hipervisor multiplexar os recursos de hardware (memria,
discos, interfaces de rede, etc.) de forma que cada mquina virtual veja
um conjunto de recursos prprio e independente. Alguns exemplos de
sistemas que empregam esta abordagem so o IBM OS/370, o VMWare
ESX Server e o ambiente Xen.
Hipervisores convidados (ou de tipo II): o hipervisor executa como um processo normal sobre um sistema operacional hospedeiro. O hipervisor
usa os recursos oferecidos pelo sistema operacional real para oferecer
recursos virtuais ao sistema operacional convidado que executa sobre ele. Exemplos de sistemas que adotam esta estrutura incluem o
VMWare Workstation, o QEmu e o VirtualBox.
aplics
OS 1
aplics
aplics
aplics
guest OS
OS 2
hipervisor
host OS
hipervisor
hardware
hardware
hipervisor nativo
hipervisor convidado
Figura 1.12: Arquiteturas de mquinas virtuais de sistema.

Os trabalhos [Goldberg, 1973, Blunden, 2002] relacionam algumas vantagens para a utilizao de mquinas virtuais em sistemas de computao:
c Carlos Maziero
31
1: Um breve histrico dos sistemas operacionais
Aperfeioamento e testes de novos sistemas operacionais;

Ensino prtico de sistemas operacionais e programao de baixo nvel;
Executar diferentes sistemas operacionais sobre o mesmo hardware,
simultaneamente;
Simular configuraes e situaes diferentes do mundo real, como por
exemplo, mais memria disponvel, outros dispositivos de E/S;
Simular alteraes e falhas no hardware para testes ou reconfigurao
de um sistema operacional, provendo confiabilidade e escalabilidade
para as aplicaes;
Garantir a portabilidade das aplicaes legadas (que executariam
sobre uma VM simulando o sistema operacional original);
Desenvolvimento de novas aplicaes para diversas plataformas,
garantindo a portabilidade destas aplicaes;
Diminuir custos com hardware.
A principal desvantagem do uso de mquinas virtuais o custo adicional de execuo dos processos na mquina virtual em comparao com
a mquina real. Esse custo muito varivel, podendo passar de 50% em
plataformas sem suporte de hardware virtualizao, como os PCs de plataforma Intel mais antigos [Dike, 2000, Blunden, 2002]. Todavia, pesquisas
recentes tm obtido a reduo desse custo a patamares abaixo de 20%, graas sobretudo a ajustes no cdigo do sistema hospedeiro [King et al., 2003].
Esse problema no existe em ambientes cujo hardware oferece suporte
virtualizao, como o caso dos mainframes e dos processadores Intel/AMD
mais recentes.
1.7
Um breve histrico dos sistemas operacionais
Os primeiros sistemas de computao, no final dos anos 40 e incio dos

anos 50, no possuam sistema operacional. Por outro lado, os sistemas de
computao atuais possuem sistemas operacionais grandes, complexos e
em constante evoluo. A seguir so apresentados alguns dos marcos mais
relevantes na histria dos sistemas operacionais [Foundation, 2005]:
c Carlos Maziero
32
Anos 40 : cada programa executava sozinho e tinha total controle do computador. A carga do programa em memria, a varredura dos perifricos
de entrada para busca de dados, a computao propriamente dita e o
envio dos resultados para os perifrico de sada, byte a byte, tudo devia
ser programado detalhadamente pelo desenvolvedor da aplicao.
Anos 50 : os sistemas de computao fornecem bibliotecas de sistema
(system libraries) que encapsulam o acesso aos perifricos, para facilitar
a programao de aplicaes. Algumas vezes um programa monitor
(system monitor) auxilia a carga e descarga de aplicaes e/ou dados
entre a memria e perifricos (geralmente leitoras de carto perfurado,
fitas magnticas e impressoras de caracteres).
1961 : o grupo do pesquisador Fernando Corbat, do MIT, anuncia o desenvolvimento do CTSS Compatible Time-Sharing System
[Corbat et al., 1962], o primeiro sistema operacional com compartilhamento de tempo.
1965 : a IBM lana o OS/360, um sistema operacional avanado, com
compartilhamento de tempo e excelente suporte a discos.
1965 : um projeto conjunto entre MIT, GE e Bell Labs define o sistema
operacional Multics, cujas ideias inovadoras iro influenciar novos
sistemas durante dcadas.
1969 : Ken Thompson e Dennis Ritchie, pesquisadores dos Bell Labs, criam
a primeira verso do UNIX.
1981 : a Microsoft lana o MS-DOS, um sistema operacional comprado da
empresa Seattle Computer Products em 1980.
1984 : a Apple lana o sistema operacional Macintosh OS 1.0, o primeiro a
ter uma interface grfica totalmente incorporada ao sistema.
1985 : primeira tentativa da Microsoft no campo dos sistemas operacionais
com interface grfica, atravs do MS-Windows 1.0.
1987 : Andrew Tanenbaum, um professor de computao holands, desenvolve um sistema operacional didtico simplificado, mas respeitando
a API do UNIX, que foi batizado como Minix.
c Carlos Maziero
33
1987 : IBM e Microsoft apresentam a primeira verso do OS/2, um sistema

multitarefa destinado a substituir o MS-DOS e o Windows. Mais tarde,
as duas empresas rompem a parceria; a IBM continua no OS/2 e a
Microsoft investe no ambiente Windows.
1991 : Linus Torvalds, um estudante de graduao finlands, inicia o
desenvolvimento do Linux, lanando na rede Usenet o ncleo 0.01,
logo abraado por centenas de programadores ao redor do mundo.
1993 : a Microsoft lana o Windows NT, o primeiro sistema 32 bits da
empresa.
1993 : lanamento dos UNIX de cdigo aberto FreeBSD e NetBSD.
2001 : a Apple lana o MacOS X, um sistema operacional derivado da
famlia UNIX BSD.
2001 : lanamento do Windows XP.
2004 : lanamento do ncleo Linux 2.6.
2006 : lanamento do Windows Vista.
Esse histrico reflete apenas o surgimento de alguns sistemas operacionais relativamente populares; diversos sistemas acadmicos ou industriais
de grande importncia pelas contribuies inovadoras, como Mach, Chorus,
QNX e Plan 9, no esto representados.
Captulo 2
Gerncia de atividades
Um sistema de computao quase sempre tem mais atividades
a executar que o nmero de processadores disponveis. Assim,
necessrio criar mtodos para multiplexar o(s) processador(es)
da mquina entre as atividades presentes. Alm disso, como as
diferentes tarefas tm necessidades distintas de processamento, e
nem sempre a capacidade de processamento existente suficiente
para atender a todos, estratgias precisam ser definidas para que
cada tarefa receba uma quantidade de processamento que atenda
suas necessidades. Este mdulo apresenta os principais conceitos,
estratgias e mecanismos empregados na gesto do processador e das
atividades em execuo em um sistema de computao.
2.1
Objetivos
Em um sistema de computao, frequente a necessidade de executar

vrias tarefas distintas simultaneamente. Por exemplo:
O usurio de um computador pessoal pode estar editando uma
imagem, imprimindo um relatrio, ouvindo msica e trazendo da
Internet um novo software, tudo ao mesmo tempo.
Em um grande servidor de e-mails, centenas de usurios conectados
remotamente enviam e recebem e-mails atravs da rede.
c Carlos Maziero
35
2: O conceito de tarefa
Um navegador Web precisa buscar os elementos da pgina a exibir,

analisar e renderizar o cdigo HTML e o grficos recebidos, animar os
elementos da interface e responder aos comandos do usurio.
No entanto, um processador convencional somente trata um fluxo de
instrues de cada vez. At mesmo computadores com vrios processadores
(mquinas Dual Pentium ou processadores com tecnologia hyper-threading,
por exemplo) tm mais atividades a executar que o nmero de processadores disponveis. Como fazer para atender simultaneamente as mltiplas
necessidades de processamento dos usurios? Uma soluo ingnua seria
equipar o sistema com um processador para cada tarefa, mas essa soluo
ainda invivel econmica e tecnicamente. Outra soluo seria multiplexar o processador entre as vrias tarefas que requerem processamento. Por
multiplexar entendemos compartilhar o uso do processador entre as vrias
tarefas, de forma a atend-las da melhor maneira possvel.
Os principais conceitos abordados neste captulo compreendem:
Como as tarefas so definidas;
Quais os estados possveis de uma tarefa;
Como e quando o processador muda de uma tarefa para outra;
Como ordenar (escalonar) as tarefas para usar o processador.
2.2
O conceito de tarefa
Uma tarefa definida como sendo a execuo de um fluxo sequencial

de instrues, construdo para atender uma finalidade especfica: realizar
um clculo complexo, a edio de um grfico, a formatao de um disco,
etc. Assim, a execuo de uma sequncia de instrues em linguagem de
mquina, normalmente gerada pela compilao de um programa escrito
em uma linguagem qualquer, denominada tarefa ou atividade (do
ingls task).
importante ressaltar as diferenas entre os conceitos de tarefa e de
programa:
Um programa um conjunto de uma ou mais sequncias de instrues escritas para resolver um problema especfico, constituindo assim uma aplicao ou utilitrio. O programa representa um conceito esttico, sem
c Carlos Maziero
36
um estado interno definido (que represente uma situao especfica da

execuo) e sem interaes com outras entidades (o usurio ou outros
programas). Por exemplo, os arquivos C:\Windows\notepad.exe e
/usr/bin/nano so programas de edio de texto.
Uma tarefa a execuo, pelo processador, das sequncias de instrues
definidas em um programa para realizar seu objetivo. Trata-se de
um conceito dinmico, que possui um estado interno bem definido a
cada instante (os valores das variveis internas e a posio atual da
execuo) e interage com outras entidades: o usurio, os perifricos
e/ou outras tarefas. Tarefas podem ser implementadas de vrias
formas, como processos (Seo 2.4.3) ou threads (Seo 2.4.4).
Fazendo uma analogia clssica, pode-se dizer que um programa o
equivalente de uma receita de torta dentro de um livro de receitas (um
diretrio) guardado em uma estante (um disco) na cozinha (o computador).
Essa receita de torta define os ingredientes necessrios e o modo de preparo
da torta. Por sua vez, a ao de executar a receita, providenciando os
ingredientes e seguindo os passos definidos na receita, a tarefa propriamente dita. A cada momento, a cozinheira (o processador) est seguindo
um passo da receita (posio da execuo) e tem uma certa disposio dos
ingredientes e utenslios em uso (as variveis internas da tarefa).
Assim como uma receita de torta pode definir vrias atividades interdependentes para elaborar a torta (preparar a massa, fazer o recheio, decorar,
etc.), um programa tambm pode definir vrias sequncias de execuo
inter-dependentes para atingir seus objetivos. Por exemplo, o programa do
navegador Web ilustrado na Figura 2.1 define vrias tarefas que uma janela
de navegador deve executar simultaneamente, para que o usurio possa
navegar na Internet:
1. Buscar via rede os vrios elementos que compem a pgina Web;
2. Receber, analisar e renderizar o cdigo HTML e os grficos recebidos;
3. Animar os diferentes elementos que compem a interface do navegador;
4. Receber e tratar os eventos do usurio (clicks) nos botes do navegador;
c Carlos Maziero
37
4
2
1
3
Figura 2.1: Tarefas de um navegador Internet

Dessa forma, as tarefas definem as atividades a serem realizadas dentro
do sistema de computao. Como geralmente h muito mais tarefas a
realizar que processadores disponveis, e as tarefas no tm todas a mesma
importncia, a gerncia de tarefas tem uma grande importncia dentro de
um sistema operacional.
c Carlos Maziero
38
2.3
2: A gerncia de tarefas
A gerncia de tarefas
Em um computador, o processador tem de executar todas as tarefas

submetidas pelos usurios. Essas tarefas geralmente tm comportamento,
durao e importncia distintas. Cabe ao sistema operacional organizar
as tarefas para execut-las e decidir em que ordem faz-lo. Nesta seo
ser estudada a organizao bsica do sistema de gerncia de tarefas e sua
evoluo histrica.
2.3.1
Sistemas mono-tarefa
Os primeiros sistemas de computao, nos anos 40, executavam apenas

uma tarefa de cada vez. Nestes sistemas, cada programa binrio era
carregado do disco para a memria e executado at sua concluso. Os dados
de entrada da tarefa eram carregados na memria juntamente com a mesma
e os resultados obtidos no processamento eram descarregados de volta
no disco aps a concluso da tarefa. Todas as operaes de transferncia
de cdigo e dados entre o disco e a memria eram coordenados por um
operador humano. Esses sistemas primitivos eram usados sobretudo para
aplicaes de clculo numrico, muitas vezes com fins militares (problemas
de trigonometria, balstica, mecnica dos fluidos, etc.). A Figura 2.2 a seguir
ilustra um sistema desse tipo.
dados
3
processador
disco
Memria
tarefa
resultados
control.
de disco
1
barramentos
Figura 2.2: Sistema mono-tarefa: 1) carga do cdigo na memria, 2) carga

dos dados na memria, 3) processamento, consumindo dados e produzindo
resultados, 4) ao trmino da execuo, a descarga dos resultados no disco.
c Carlos Maziero
39
2: Sistemas mono-tarefa
Nesse mtodo de processamento de tarefas possvel delinear um

diagrama de estados para cada tarefa executada pelo sistema, que est
representado na Figura 2.3.
nova
inicia a
execuo
executando
termina a
execuo
terminada
Figura 2.3: Diagrama de estados de uma tarefa em um sistema mono-tarefa.

Com a evoluo do hardware, as tarefas de carga e descarga de cdigo
entre memria e disco, coordenadas por um operador humano, passaram a
se tornar crticas: mais tempo era perdido nesses procedimentos manuais
que no processamento da tarefa em si. Para resolver esse problema foi
construdo um programa monitor, que era carregado na memria no incio
da operao do sistema com a funo de coordenar a execuo dos demais
programas. O programa monitor executava continuamente os seguintes
passos sobre uma fila de programas a executar, armazenada no disco:
1. carregar um programa do disco para a memria;
2. carregar os dados de entrada do disco para a memria;
3. transferir a execuo para o programa recm-carregado;
4. aguardar o trmino da execuo do programa;
5. escrever os resultados gerados pelo programa no disco.
Percebe-se claramente que a funo do monitor gerenciar uma fila de
programas a executar, mantida no disco. Na medida em que os programas
so executados pelo processador, novos programas podem ser inseridos na
fila pelo operador do sistema. Alm de coordenar a execuo dos demais
programas, o monitor tambm colocava disposio destes uma biblioteca
de funes para simplificar o acesso aos dispositivos de hardware (teclado,
leitora de cartes, disco, etc.). Assim, o monitor de sistema constitui o
precursor dos sistemas operacionais.
c Carlos Maziero
40
2.3.2
2: Sistemas multi-tarefa
Sistemas multi-tarefa
O uso do programa monitor agilizou o uso do processador, mas outros

problemas persistiam. Como a velocidade de processamento era muito
maior que a velocidade de comunicao com os dispositivos de entrada e
sada1 , o processador ficava ocioso durante os perodos de transferncia
de informao entre disco e memria. Se a operao de entrada/sada
envolvia fitas magnticas, o processador podia ficar vrios minutos parado,
esperando. O custo dos computadores era elevado demais (e sua capacidade
de processamento muito baixa) para permitir deix-los ociosos por tanto
tempo.
A soluo encontrada para resolver esse problema foi permitir ao processador suspender a execuo da tarefa que espera dados externos e passar
a executar outra tarefa. Mais tarde, quando os dados de que necessita
estiverem disponveis, a tarefa suspensa pode ser retomada no ponto onde
parou. Para tal, necessrio ter mais memria (para poder carregar mais de
um programa ao mesmo tempo) e definir procedimentos para suspender
uma tarefa e retom-la mais tarde. O ato de retirar um recurso de uma tarefa
(neste caso o recurso o processador) denominado preempo. Sistemas
que implementam esse conceito so chamados sistemas preemptivos.
A adoo da preempo levou a sistemas mais produtivos (e complexos),
nos quais vrias tarefas podiam estar em andamento simultaneamente:
uma estava ativa e as demais suspensas, esperando dados externos ou
outras condies. Sistemas que suportavam essa funcionalidade foram
denominados monitores multi-tarefas. O diagrama de estados da Figura 2.4
ilustra o comportamento de uma tarefa em um sistema desse tipo:
2.3.3
Sistemas de tempo compartilhado
Solucionado o problema de evitar a ociosidade do processador, restavam

no entanto vrios outros problemas a resolver. Por exemplo, um programa
que contm um lao infinito jamais encerra; como fazer para abortar a tarefa,
ou ao menos transferir o controle ao monitor para que ele decida o que
1
Essa diferena de velocidades permanece imensa nos sistemas atuais. Por exemplo, em
um computador atual a velocidade de acesso memria de cerca de 10 nanossegundos
(10 109 s), enquanto a velocidade de acesso a dados em um disco rgido IDE de cerca
de 10 milissegundos (10 103 s), ou seja, um milho de vezes mais lento!
c Carlos Maziero
41
nova
2: Sistemas de tempo compartilhado
terminou de
ser carregada
em memria
pronta
dado disponvel ou
evento ocorreu
inicia a
execuo
suspensa
executando
termina a
execuo
terminada
aguarda um dado externo

ou outro evento
Figura 2.4: Diagrama de estados de uma tarefa em um sistema multi-tarefas.

fazer? Situaes como essa podem ocorrer a qualquer momento, por erros
de programao ou intencionalmente, como mostra o exemplo a seguir:
void main ()
{
int i = 0, soma = 0 ;
1
2
3
4
while (i < 1000)

soma += i ; // erro: o contador i no foi incrementado
5
6
7
printf ("A soma vale %d\n", soma);
Esse tipo de programa podia inviabilizar o funcionamento do sistema,

pois a tarefa em execuo nunca termina nem solicita operaes de entrada/sada, monopolizando o processador e impedindo a execuo das demais
tarefas (pois o controle nunca volta ao monitor). Alm disso, essa soluo
no era adequada para a criao de aplicaes interativas. Por exemplo, um
terminal de comandos pode ser suspenso a cada leitura de teclado, perdendo
o processador. Se ele tiver de esperar muito para voltar ao processador, a
interatividade com o usurio fica prejudicada.
Para resolver essa questo, foi introduzido no incio dos anos 60 um novo
conceito: o compartilhamento de tempo, ou time-sharing, atravs do sistema
CTSS Compatible Time-Sharing System [Corbat, 1963]. Nessa soluo,
cada atividade que detm o processador recebe um limite de tempo de
processamento, denominado quantum2 . Esgotado seu quantum, a tarefa em
execuo perde o processador e volta para uma fila de tarefas prontas,
que esto na memria aguardando sua oportunidade de executar.
2
A durao atual do quantum depende muito do tipo de sistema operacional; no Linux

ela varia de 10 a 200 milissegundos, dependendo do tipo e prioridade da tarefa [Love, 2004].
c Carlos Maziero
42
2: Ciclo de vida das tarefas
Em um sistema operacional tpico, a implementao da preempo

por tempo tem como base as interrupes geradas pelo temporizador
programvel do hardware. Esse temporizador normalmente programado
para gerar interrupes em intervalos regulares (a cada milissegundo,
por exemplo) que so recebidas por um tratador de interrupo (interrupt
handler); as ativaes peridicas do tratador de interrupo so normalmente
chamadas de ticks do relgio. Quando uma tarefa recebe o processador,
o ncleo ajusta um contador de ticks que essa tarefa pode usar, ou seja,
seu quantum definido em nmero de ticks. A cada tick, o contador
decrementado; quando ele chegar a zero, a tarefa perde o processador e
volta fila de prontas. Essa dinmica de execuo est ilustrada na Figura
2.5.
ticks do relgio de hardware
ncleo
tarefa
c=20
tarefa
c=19
...
c=18
tarefa
c=2
tarefa
c=1
ncleo
c=0
ativaes do tratador de interrupo
Figura 2.5: Dinmica da preempo por tempo (quantum igual a 20 ticks).

O diagrama de estados das tarefas deve ser reformulado para incluir a
preempo por tempo que implementa a estratgia de tempo compartilhado.
A Figura 2.6 apresenta esse novo diagrama.
2.3.4
Ciclo de vida das tarefas
O diagrama apresentado na Figura 2.6 conhecido na literatura da rea

como diagrama de ciclo de vida das tarefas. Os estados e transies do ciclo de
vida tm o seguinte significado:
c Carlos Maziero
43

m do quantum
nova
terminou de
ser carregada
em memria
recebe o
processador
pronta
dado disponvel ou
evento ocorreu
suspensa
executando
termina a
execuo
terminada
aguarda um dado externo

ou outro evento
Figura 2.6: Diagrama de estados de uma tarefa em um sistema de tempo

compartilhado.
Nova : A tarefa est sendo criada, i.e. seu cdigo est sendo carregado
em memria, junto com as bibliotecas necessrias, e as estruturas de
dados do ncleo esto sendo atualizadas para permitir sua execuo.
Pronta : A tarefa est em memria, pronta para executar (ou para continuar
sua execuo), apenas aguardando a disponibilidade do processador.
Todas as tarefas prontas so organizadas em uma fila cuja ordem
determinada por algoritmos de escalonamento, que sero estudados
na Seo 2.5.
Executando : O processador est dedicado tarefa, executando suas instrues e fazendo avanar seu estado.
Suspensa : A tarefa no pode executar porque depende de dados externos
ainda no disponveis (do disco ou da rede, por exemplo), aguarda
algum tipo de sincronizao (o fim de outra tarefa ou a liberao de
algum recurso compartilhado) ou simplesmente espera o tempo passar
(em uma operao sleeping, por exemplo).
Terminada : O processamento da tarefa foi encerrado e ela pode ser
removida da memria do sistema.
To importantes quanto os estados das tarefas apresentados na Figura
2.6 so as transies entre esses estados, que so explicadas a seguir:
Nova : Esta transio ocorre quando uma nova tarefa admitida no
sistema e comea a ser preparada para executar.
c Carlos Maziero
44
Nova Pronta : ocorre quando a nova tarefa termina de ser carregada em

memria, juntamente com suas bibliotecas e dados, estando pronta
para executar.
Pronta Executando : esta transio ocorre quando a tarefa escolhida
pelo escalonador para ser executada, dentre as demais tarefas prontas.
Executando Pronta : esta transio ocorre quando se esgota a fatia de
tempo destinada tarefa (ou seja, o fim do quantum); como nesse momento a tarefa no precisa de outros recursos alm do processador, ela
volta fila de tarefas prontas, para esperar novamente o processador.
Executando Terminada : ocorre quando a tarefa encerra sua execuo ou
abortada em consequncia de algum erro (acesso invlido memria,
instruo ilegal, diviso por zero, etc.). Na maioria dos sistemas a
tarefa que deseja encerrar avisa o sistema operacional atravs de uma
chamada de sistema (no Linux usada a chamada exit).
Terminada : Uma tarefa terminada removida da memria e seus
registros e estruturas de controle no ncleo so apagadas.
Executando Suspensa : caso a tarefa em execuo solicite acesso a um
recurso no disponvel, como dados externos ou alguma sincronizao, ela abandona o processador e fica suspensa at o recurso ficar
disponvel.
Suspensa Pronta : quando o recurso solicitado pela tarefa se torna
disponvel, ela pode voltar a executar, portanto volta ao estado de
pronta.
A estrutura do diagrama de ciclo de vida das tarefas pode variar de
acordo com a interpretao dos autores. Por exemplo, a forma apresentada
neste texto condiz com a apresentada em [Silberschatz et al., 2001] e outros
autores. Por outro lado, o diagrama apresentado em [Tanenbaum, 2003]
divide o estado suspenso em dois subestados separados: bloqueado,
quando a tarefa aguarda a ocorrncia de algum evento (tempo, entrada/sada,
etc.) e suspenso, para tarefas bloqueadas que foram movidas da memria
RAM para a rea de troca pelo mecanismo de memria virtual (vide
Seo 5.7). Todavia, tal distino de estados no faz mais sentido nos
sistemas operacionais atuais baseados em memria paginada, pois neles os
c Carlos Maziero
45
2: Implementao de tarefas
processos podem executar mesmo estando somente parcialmente carregados

na memria.
2.4
Implementao de tarefas
Conforme apresentado, uma tarefa uma unidade bsica de atividade

dentro de um sistema. Tarefas podem ser implementadas de vrias formas,
como processos, threads, jobs e transaes. Nesta seo so descritos os problemas relacionados implementao do conceito de tarefa em um sistema
operacional tpico. So descritas as estruturas de dados necessrias para
representar uma tarefa e as operaes necessrias para que o processador
possa comutar de uma tarefa para outra de forma eficiente e transparente.
2.4.1
Contextos
Na Seo 2.2 vimos que uma tarefa possui um estado interno bem
definido, que representa sua situao atual: a posio de cdigo que ela est
executando, os valores de suas variveis e os arquivos que ela utiliza, por
exemplo. Esse estado se modifica conforme a execuo da tarefa evolui. O
estado de uma tarefa em um determinado instante denominado contexto.
Uma parte importante do contexto de uma tarefa diz respeito ao estado
interno do processador durante sua execuo, como o valor do contador de
programa (PC - Program Counter), do apontador de pilha (SP - Stack Pointer)
e demais registradores. Alm do estado interno do processador, o contexto
de uma tarefa tambm inclui informaes sobre os recursos usados por ela,
como arquivos abertos, conexes de rede e semforos.
Cada tarefa presente no sistema possui um descritor associado, ou seja,
uma estrutura de dados que a representa no ncleo. Nessa estrutura so
armazenadas as informaes relativas ao seu contexto e os demais dados
necessrios sua gerncia. Essa estrutura de dados geralmente chamada
de TCB (do ingls Task Control Block) ou PCB (Process Control Block). Um
TCB tipicamente contm as seguintes informaes:
Identificador da tarefa (pode ser um nmero inteiro, um apontador,
uma referncia de objeto ou um identificador opaco);
Estado da tarefa (nova, pronta, executando, suspensa, terminada, ...);
c Carlos Maziero
46
2: Trocas de contexto
Informaes de contexto do processador (valores contidos nos registradores);

Lista de reas de memria usadas pela tarefa;
Listas de arquivos abertos, conexes de rede e outros recursos usados
pela tarefa (exclusivos ou compartilhados com outras tarefas);
Informaes de gerncia e contabilizao (prioridade, usurio proprietrio, data de incio, tempo de processamento j decorrido, volume de
dados lidos/escritos, etc.).
Dentro do ncleo, os descritores das tarefas so organizados em listas ou
vetores de TCBs. Por exemplo, normalmente h uma lista de tarefas prontas
para executar, uma lista de tarefas aguardando acesso ao disco rgido, etc.
Para ilustrar o conceito de TCB, o Apndice A apresenta o TCB do ncleo
Linux (verso 2.6.12), representado pela estrutura task_struct definida no
arquivo include/linux/sched.h.
2.4.2
Trocas de contexto
Para que o processador possa interromper a execuo de uma tarefa e

retornar a ela mais tarde, sem corromper seu estado interno, necessrio
definir operaes para salvar e restaurar o contexto da tarefa. O ato de
salvar os valores do contexto atual em seu TCB e possivelmente restaurar o
contexto de outra tarefa, previamente salvo em outro TCB, denominado
troca de contexto. A implementao da troca de contexto uma operao
delicada, envolvendo a manipulao de registradores e flags especficos de
cada processador, sendo por essa razo geralmente codificada em linguagem
de mquina. No Linux as operaes de troca de contexto para a plataforma
Intel x86 esto definidas atravs de diretivas em Assembly no arquivo
arch/i386/kernel/process.c dos fontes do ncleo.
Durante uma troca de contexto, existem questes de ordem mecnica
e de ordem estratgica a serem resolvidas, o que traz tona a separao
entre mecanismos e polticas j discutida anteriormente (vide Seo 1.3).
Por exemplo, o armazenamento e recuperao do contexto e a atualizao
das informaes contidas no TCB de cada tarefa so aspectos mecnicos,
providos por um conjunto de rotinas denominado despachante ou executivo
(do ingls dispatcher). Por outro lado, a escolha da prxima tarefa a receber o
c Carlos Maziero
47
2: Trocas de contexto
processador a cada troca de contexto estratgica, podendo sofrer influncias

de diversos fatores, como as prioridades, os tempos de vida e os tempos
de processamento restante de cada tarefa. Essa deciso fica a cargo de um
componente de cdigo denominado escalonador (scheduler, vide Seo 2.5).
Assim, o despachante implementa os mecanismos da gerncia de tarefas,
enquanto o escalonador implementa suas polticas.
A Figura 2.7 apresenta um diagrama temporal com os principais passos
envolvidos em uma troca de contexto. A realizao de uma troca de
contexto completa, envolvendo a interrupo de uma tarefa, o salvamento
de seu contexto, o escalonamento e a reativao da tarefa escolhida, uma
operao relativamente rpida (de dezenas a centenas de micro-segundos,
dependendo do hardware e do sistema operacional). A parte potencialmente
mais demorada de uma troca de contexto a execuo do escalonador; por
esta razo, muitos sistemas operacionais executam o escalonador apenas
esporadicamente, quando h necessidade de reordenar a fila de tarefas
prontas. Nesse caso, o despachante sempre ativa a primeira tarefa da fila.
interrupo
operaes no ncleo
Tarefa t1
tratador
de
interrupo
dispatcher
scheduler
Tarefa t2
dispatcher
t
salva contexto
TCB(t1)
restaura contexto
TCB(t2)
Figura 2.7: Passos de uma troca de contexto.

importante observar que uma troca de contexto pode ser provocada
pelo fim do quantum atual (atravs de uma interrupo de tempo), por um
evento ocorrido em um perifrico (tambm atravs de uma interrupo do
hardware) ou pela execuo de uma chamada de sistema pela tarefa corrente
(ou seja, por uma interrupo de software) ou at mesmo por algum erro de
execuo que possa provocar uma exceo no processador.
c Carlos Maziero
48
2.4.3
2: Processos
Processos
Alm de seu prprio cdigo executvel, cada tarefa ativa em um sistema

de computao necessita de um conjunto de recursos para executar e cumprir
seu objetivo. Entre esses recursos esto as reas de memria usadas pela
tarefa para armazenar seu cdigo, dados e pilha, seus arquivos abertos,
conexes de rede, etc. O conjunto dos recursos alocados a uma tarefa para
sua execuo denominado processo.
Historicamente, os conceitos de tarefa e processo se confundem, sobretudo porque os sistemas operacionais mais antigos, at meados dos anos 80,
somente suportavam uma tarefa para cada processo (ou seja, uma atividade
associada a cada contexto). Essa viso vem sendo mantida por muitas referncias at os dias de hoje. Por exemplo, os livros [Silberschatz et al., 2001]
e [Tanenbaum, 2003] ainda apresentam processos como equivalentes de
tarefas. No entanto, quase todos os sistemas operacionais contemporneos suportam mais de uma tarefa por processo, como o caso do Linux,
Windows XP e os UNIX mais recentes.
Os sistemas operacionais convencionais atuais associam por default uma
tarefa a cada processo, o que corresponde execuo de um programa
sequencial (um nico fluxo de instrues dentro do processo). Caso se
deseje associar mais tarefas ao mesmo contexto (para construir o navegador
Internet da Figura 2.1, por exemplo), cabe ao desenvolvedor escrever o
cdigo necessrio para tal. Por essa razo, muitos livros ainda usam de
forma equivalente os termos tarefa e processo, o que no corresponde mais
realidade.
Assim, hoje em dia o processo deve ser visto como uma unidade de contexto,
ou seja, um continer de recursos utilizados por uma ou mais tarefas para
sua execuo. Os processos so isolados entre si pelos mecanismos de
proteo providos pelo hardware (isolamento de reas de memria, nveis
de operao e chamadas de sistema) e pela prpria gerncia de tarefas, que
atribui os recursos aos processos (e no s tarefas), impedindo que uma
tarefa em execuo no processo pa acesse um recurso atribudo ao processo
pb . A Figura 2.8 ilustra o conceito de processo, visto como um continer de
recursos.
O ncleo do sistema operacional mantm descritores de processos,
denominados PCBs (Process Control Blocks), para armazenar as informaes
referentes aos processos ativos. Cada processo possui um identificador nico
no sistema, o PID Process IDentifier. Associando-se tarefas a processos, o
c Carlos Maziero
49
2: Processos
Processo pa
tarefas
arqs abertos
Processo pb
tarefas
memria
arqs abertos
conexes
memria
conexes
ncleo
Figura 2.8: O processo visto como um continer de recursos.

descritor (TCB) de cada tarefa pode ser bastante simplificado: para cada
tarefa, basta armazenar seu identificador, os registradores do processador e
uma referncia ao processo ao qual a tarefa est vinculada. Disto observase tambm que a troca de contexto entre tarefas vinculadas ao mesmo
processo muito mais simples e rpida que entre tarefas vinculadas a
processos distintos, pois somente os registradores do processador precisam
ser salvos/restaurados (as reas de memria e demais recursos so comuns
s duas tarefas). Essas questes so aprofundadas na Seo 2.4.4.
Criao de processos
Durante a vida do sistema, processos so criados e destrudos. Essas
operaes so disponibilizadas s aplicaes atravs de chamadas de sistema;
cada sistema operacional tem suas prprias chamadas para a criao e
remoo de processos. No caso do UNIX, processos so criados atravs
da chamada de sistema fork, que cria uma rplica do processo solicitante:
todo o espao de memria do processo replicado, incluindo o cdigo
da(s) tarefa(s) associada(s) e os descritores dos arquivos e demais recursos
associados ao mesmo. A Figura 2.9 ilustra o funcionamento dessa chamada.
A chamada de sistema fork invocada por um processo (o pai), mas dois
processos recebem seu retorno: o processo pai, que a invocou, e o processo filho,
recm-criado, que possui o mesmo estado interno que o pai (ele tambm
est aguardando o retorno da chamada de sistema). Ambos os processos
c Carlos Maziero
50
Processo pai
2: Processos
Processo pai
Processo lho
tarefas
memria
tarefas
memria
tarefas
memria
arqs abertos
conexes
arqs abertos
conexes
arqs abertos
conexes
fork
ncleo
return
return
ncleo
Figura 2.9: A chamada de sistema fork: antes (esq) e depois (dir) de sua
execuo pelo ncleo do sistema UNIX.
tm os mesmos recursos associados, embora em reas de memria distintas.
Caso o processo filho deseje abandonar o fluxo de execuo herdado do
processo pai e executar outro cdigo, poder faz-lo atravs da chamada de
sistema execve. Essa chamada substitui o cdigo do processo que a invoca
pelo cdigo executvel contido em um arquivo informado como parmetro.
A listagem a seguir apresenta um exemplo de uso dessas duas chamadas de
sistema:
c Carlos Maziero
51
1
2
3
4
5
#include
#include
#include
#include
#include
2: Processos
<unistd.h>
<sys/types.h>
<sys/wait.h>
<stdio.h>
<stdlib.h>
6
7
8
9
int main (int argc, char *argv[], char *envp[])

{
int pid ;
/* identificador de processo */
10
pid = fork () ;
11
/* replicao do processo */
12
if ( pid < 0 )
/* fork no funcionou */
{
perror ("Erro: ") ;
exit (-1) ;
/* encerra o processo */
}
else if ( pid > 0 ) /* sou o processo pai */
{
wait (0) ;
/* vou esperar meu filho concluir */
}
else
/* sou o processo filho*/
{
/* carrega outro cdigo binrio para executar */
execve ("/bin/date", argv, envp) ;
perror ("Erro: ") ; /* execve no funcionou */
}
printf ("Tchau !\n") ;
exit(0) ;
/* encerra o processo */
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
A chamada de sistema exit usada no exemplo acima serve para informar

ao ncleo do sistema operacional que o processo em questo no mais
necessrio e pode ser destrudo, liberando todos os recursos a ele associados
(arquivos abertos, conexes de rede, reas de memria, etc.). Processos
podem solicitar ao ncleo o encerramento de outros processos, mas essa
operao s aplicvel a processos do mesmo usurio, ou se o processo
solicitante pertencer ao administrador do sistema.
Na operao de criao de processos do UNIX aparece de maneira
bastante clara a noo de hierarquia entre processos. medida em que
processos so criados, forma-se uma rvore de processos no sistema, que pode
ser usada para gerenciar de forma coletiva os processos ligados mesma
aplicao ou mesma sesso de trabalho de um usurio, pois iro constituir
c Carlos Maziero
52
2: Processos
uma sub-rvore de processos. Por exemplo, quando um processo encerra,

seus filhos so informados sobre isso, e podem decidir se tambm encerram
ou se continuam a executar. Por outro, nos sistemas Windows, todos os
processos tm o mesmo nvel hierrquico, no havendo distino entre
pais e filhos. O comando pstree do Linux permite visualizar a rvore de
processos do sistema, como mostra a listagem a seguir.
c Carlos Maziero
53
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
2: Processos
init-+-aacraid
|-ahc_dv_0
|-atd
|-avaliacao_horac
|-bdflush
|-crond
|-gpm
|-kdm-+-X
|
-kdm---kdm_greet
|-keventd
|-khubd
|-2*[kjournald]
|-klogd
|-ksoftirqd_CPU0
|-ksoftirqd_CPU1
|-kswapd
|-kupdated
|-lockd
|-login---bash
|-lpd---lpd---lpd
|-5*[mingetty]
|-8*[nfsd]
|-nmbd
|-nrpe
|-oafd
|-portmap
|-rhnsd
|-rpc.mountd
|-rpc.statd
|-rpciod
|-scsi_eh_0
|-scsi_eh_1
|-smbd
|-sshd-+-sshd---tcsh---top
|
|-sshd---bash
|
-sshd---tcsh---pstree
|-syslogd
|-xfs
|-xinetd
-ypbind---ypbind---2*[ypbind]
Outro aspecto importante a ser considerado em relao a processos diz

respeito comunicao. Tarefas associadas ao mesmo processo podem trocar
informaes facilmente, pois compartilham as mesmas reas de memria.
Todavia, isso no possvel entre tarefas associadas a processos distintos.
c Carlos Maziero
54
2: Threads
Para resolver esse problema, o ncleo deve prover s aplicaes chamadas

de sistema que permitam a comunicao inter-processos (IPC Inter-Process
Communication). Esse tema ser estudado em profundidade no Captulo 3.
2.4.4
Threads
Conforme visto na Seo 2.4.3, os primeiros sistemas operacionais suportavam apenas uma tarefa por processo. medida em que as aplicaes se
tornavam mais complexas, essa limitao se tornou um claro inconveniente.
Por exemplo, um editor de textos geralmente executa tarefas simultneas
de edio, formatao, paginao e verificao ortogrfica sobre a mesma
massa de dados (o texto sob edio). Da mesma forma, processos que
implementam servidores de rede (de arquivos, bancos de dados, etc.) devem gerenciar as conexes de vrios usurios simultaneamente, que muitas
vezes requisitam as mesmas informaes. Essas demandas evidenciaram a
necessidade de suportar mais de uma tarefa operando no mesmo contexto,
ou seja, dentro do mesmo processo.
De forma geral, cada fluxo de execuo do sistema, seja associado a
um processo ou no interior do ncleo, denominado thread. Threads
executando dentro de um processo so chamados de threads de usurio
(user-level threads ou simplesmente user threads). Cada thread de usurio
corresponde a uma tarefa a ser executada dentro de um processo. Por
sua vez, os fluxos de execuo reconhecidos e gerenciados pelo ncleo do
sistema operacional so chamados de threads de ncleo (kernel-level threads
ou kernel threads). Os threads de ncleo representam tarefas que o ncleo
deve realizar. Essas tarefas podem corresponder execuo dos processos
no espao de usurio, ou a atividades internas do prprio ncleo, como
drivers de dispositivos ou tarefas de gerncia.
Os sistemas operacionais mais antigos no ofereciam suporte a threads
para a construo de aplicaes. Sem poder contar com o sistema operacional,
os desenvolvedores de aplicaes contornaram o problema construindo
bibliotecas que permitiam criar e gerenciar threads dentro de cada processo,
sem o envolvimento do ncleo do sistema. Usando essas bibliotecas, uma
aplicao pode lanar vrios threads conforme sua necessidade, mas o ncleo
do sistema ir sempre perceber (e gerenciar) apenas um fluxo de execuo
dentro de cada processo. Por essa razo, esta forma de implementao
de threads nomeada Modelo de Threads N:1: N threads no processo,
mapeados em um nico thread de ncleo. A Figura 2.10 ilustra esse modelo.
c Carlos Maziero
55
2: Threads
Processo pb
Processo pa
threads
memria
memria
biblioteca
biblioteca
thread de
ncleo
threads
ncleo
thread de
ncleo
Figura 2.10: O modelo de threads N:1.

O modelo de threads N:1 muito utilizado, por ser leve e de fcil
implementao. Como o ncleo somente considera uma thread, a carga
de gerncia imposta ao ncleo pequena e no depende do nmero de
threads dentro da aplicao. Essa caracterstica torna este modelo til
na construo de aplicaes que exijam muitos threads, como jogos ou
simulaes de grandes sistemas (a simulao detalhada do trfego virio de
uma cidade grande, por exemplo, pode exigir um thread para cada veculo,
resultando em centenas de milhares ou mesmo milhes de threads). Um
exemplo de implementao desse modelo a biblioteca GNU Portable Threads
[Engeschall, 2005].
Entretanto, o modelo de threads N:1 apresenta problemas em algumas
situaes, sendo o mais grave deles relacionado s operaes de entrada/sada. Como essas operaes so intermediadas pelo ncleo, se um thread de
usurio solicitar uma operao de E/S (recepo de um pacote de rede, por
exemplo) o thread de ncleo correspondente ser suspenso at a concluso
da operao, fazendo com que todos os threads de usurio associados ao
processo parem de executar enquanto a operao no for concluda.
Outro problema desse modelo diz respeito diviso de recursos entre
as tarefas. O ncleo do sistema divide o tempo do processador entre os
fluxos de execuo que ele conhece e gerencia: as threads de ncleo. Assim,
c Carlos Maziero
56
2: Threads
uma aplicao com 100 threads de usurio ir receber o mesmo tempo de

processador que outra aplicao com apenas um thread (considerando que
ambas as aplicaes tm a mesma prioridade). Cada thread da primeira
aplicao ir portanto receber 1/100 do tempo que recebe o thread nico da
segunda aplicao, o que no pode ser considerado uma diviso justa desse
recurso.
A necessidade de suportar aplicaes com vrios threads (multithreaded)
levou os desenvolvedores de sistemas operacionais a incorporar a gerncia
dos threads de usurio ao ncleo do sistema. Para cada thread de usurio
foi ento definido um thread correspondente dentro do ncleo, suprimindo
com isso a necessidade de bibliotecas de threads. Caso um thread de usurio
solicite uma operao bloqueante (leitura de disco ou recepo de pacote de
rede, por exemplo), somente seu respectivo thread de ncleo ser suspenso,
sem afetar os demais threads. Alm disso, caso o hardware tenha mais
de um processador, mais threads da mesma aplicao podem executar ao
mesmo tempo, o que no era possvel no modelo anterior. Essa forma
de implementao, denominada Modelo de Threads 1:1 e apresentada na
Figura 2.11, a mais frequente nos sistemas operacionais atuais, incluindo
o Windows NT e seus descendentes, alm da maioria dos UNIXes.
Processo pb
Processo pa
threads
memria
threads
memria
ncleo
threads
de ncleo
Figura 2.11: O modelo de threads 1:1.
c Carlos Maziero
57
2: Threads
O modelo de threads 1:1 adequado para a maioria das situaes e atende

bem s necessidades das aplicaes interativas e servidores de rede. No
entanto, pouco escalvel: a criao de um grande nmero de threads impe
um carga significativa ao ncleo do sistema, inviabilizando aplicaes com
muitas tarefas (como grandes servidores Web e simulaes de grande porte).
Para resolver o problema da escalabilidade, alguns sistemas operacionais
implementam um modelo hbrido, que agrega caractersticas dos modelos
anteriores. Nesse novo modelo, uma biblioteca gerencia um conjunto
de threads de usurio (dentro do processo), que mapeado em um ou
mais threads do ncleo. O conjunto de threads de ncleo associados a um
processo geralmente composto de um thread para cada tarefa bloqueada
e mais um thread para cada processador disponvel, podendo ser ajustado
dinamicamente conforme a necessidade da aplicao. Essa abordagem
hbrida denominada Modelo de Threads N:M, onde N threads de usurio
so mapeados em M N threads de ncleo. A Figura 2.12 apresenta esse
modelo.
Processo pb
Processo pa
threads
memria
memria
biblioteca
biblioteca
thread de
ncleo
threads
ncleo
threads
de ncleo
Figura 2.12: O modelo de threads N:M.

O modelo N:M implementado pelo Solaris e tambm pelo projeto KSE
(Kernel-Scheduled Entities) do FreeBSD [Evans and Elischer, 2003] baseado
nas idias apresentadas em [Anderson et al., 1992]. Ele alia as vantagens de
maior interatividade do modelo 1:1 maior escalabilidade do modelo N:1.
c Carlos Maziero
58
Modelo
Resumo
Local da implementao
Complexidade
Custo de gerncia para o ncleo
Escalabilidade
Suporte a vrios
processadores
Velocidade das
trocas de contexto entre threads
Diviso de recursos entre tarefas
Exemplos
2: Threads
N:1
1:1
Todos os N threads do Cada thread do proprocesso so mapea- cesso tem um thdos em um nico thread correspondente
read de ncleo
no ncleo
bibliotecas no nvel dentro do ncleo
usurio
baixa
mdia
nulo
mdio
N:M
Os N threads do processo so mapeados
em um conjunto de
M threads de ncleo
em ambos
alta
no
baixa
sim
alta
sim
rpida
lenta
injusta
justa
rpida entre threads

no mesmo processo,
lenta entre threads de
processos distintos
varivel, pois o mapeamento thread
processador dinmico
Solaris, FreeBSD KSE
GNU Portable Thre- Windows XP, Linux

ads
alta
alto
Tabela 2.1: Quadro comparativo dos modelos de threads.

Como desvantagens desta abordagem podem ser citadas sua complexidade
de implementao e maior custo de gerncia dos threads de ncleo, quando
comparado ao modelo 1:1. A Tabela 2.1 resume os principais aspectos dos
trs modelos de implementao de threads e faz um comparativo entre eles.
c Carlos Maziero
59
2: Threads
No passado, cada sistema operacional definia sua prpria interface para

a criao de threads, o que levou a problemas de portabilidade das aplicaes.
Em 1995 foi definido o padro IEEE POSIX 1003.1c, mais conhecido como
PThreads [Nichols et al., 1996], que busca definir uma interface padronizada
para a criao e manipulao de threads na linguagem C. Esse padro
amplamente difundido e suportado hoje em dia. A listagem a seguir,
extrada de [Barney, 2005], exemplifica o uso do padro PThreads (para
compilar deve ser usada a opo de ligao -lpthread).
1
2
3
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
4
5
#define NUM_THREADS 5
6
7
8
9
10
11
12
/* cada thread vai executar esta funo */

void *PrintHello (void *threadid)
{
printf ("%d: Hello World!\n", (int) threadid);
pthread_exit (NULL);
}
13
14
15
16
17
18
/* thread "main" (vai criar as demais threads) */

int main (int argc, char *argv[])
{
pthread_t thread[NUM_THREADS];
int status, i;
19
/* cria as demais threads */

for(i = 0; i < NUM_THREADS; i++)
{
printf ("Creating thread %d\n", i);
status = pthread_create (&thread[i], NULL, PrintHello, (void *) i);
20
21
22
23
24
25
if (status) /* ocorreu um erro */

{
perror ("pthread_create");
exit (-1);
}
26
27
28
29
30
31
32
/* encerra a thread "main" */

pthread_exit (NULL);
33
34
35
c Carlos Maziero
60
2: Escalonamento de tarefas
O conceito de threads tambm pode ser utilizado em outras linguagens de

programao, como Java, Python, Perl, C++ e C#. O cdigo a seguir traz um
exemplo simples de criao de threads em Java (extrado da documentao
oficial da linguagem):
1
2
public class MyThread extends Thread {

int threadID;
MyThread (int ID) {

threadID = ID;
}
4
5
6
7
public void run () {

int i ;
8
9
10
for (i = 0; i< 100 ; i++)

System.out.println ("Hello from t" + threadID + "!") ;
11
12
13
14
public static void main (String args[]) {

MyThread t1 = new MyThread (1);
15
16
17
18
19
t1.start ();
t2.start ();
t3.start ();
20
21
22
23
24
2.5
Escalonamento de tarefas
Um dos componentes mais importantes da gerncia de tarefas o

escalonador (task scheduler), que decide a ordem de execuo das tarefas
prontas. O algoritmo utilizado no escalonador define o comportamento
do sistema operacional, permitindo obter sistemas que tratem de forma
mais eficiente e rpida as tarefas a executar, que podem ter caractersticas
diversas: aplicaes interativas, processamento de grandes volumes de
dados, programas de clculo numrico, etc.
Antes de se definir o algoritmo usado por um escalonador, necessrio
ter em mente a natureza das tarefas que o sistema ir executar. Existem
c Carlos Maziero
61
2: Escalonamento de tarefas
vrios critrios que definem o comportamento de uma tarefa; uma primeira

classificao possvel diz respeito ao seu comportamento temporal:
Tarefas de tempo real : exigem previsibilidade em seus tempos de resposta
aos eventos externos, pois geralmente esto associadas ao controle
de sistemas crticos, como processos industriais, tratamento de fluxos
multimdia, etc. O escalonamento de tarefas de tempo real um
problema complexo, fora do escopo deste livro e discutido mais
profundamente em [Burns and Wellings, 1997, Farines et al., 2000].
Tarefas interativas : so tarefas que recebem eventos externos (do usurio
ou atravs da rede) e devem respond-los rapidamente, embora sem
os requisitos de previsibilidade das tarefas de tempo real. Esta classe
de tarefas inclui a maior parte das aplicaes dos sistemas desktop
(editores de texto, navegadores Internet, jogos) e dos servidores de
rede (e-mail, web, bancos de dados).
Tarefas em lote (batch) : so tarefas sem requisitos temporais explcitos,
que normalmente executam sem interveno do usurio, como procedimentos de backup, varreduras de anti-vrus, clculos numricos
longos, renderizao de animaes, etc.
Alm dessa classificao, as tarefas tambm podem ser classificadas de
acordo com seu comportamento no uso do processador:
Tarefas orientadas a processamento (CPU-bound tasks): so tarefas que
usam intensivamente o processador na maior parte de sua existncia.
Essas tarefas passam a maior parte do tempo nos estados pronta ou
executando. A converso de arquivos de vdeo e outros processamentos numricos longos (como os feitos pelo projeto SETI@home
[Anderson et al., 2002]) so bons exemplos desta classe de tarefas.
Tarefas orientadas a entrada/sada (IO-bound tasks): so tarefas que dependem muito mais dos dispositivos de entrada/sada que do processador.
Essas tarefas despendem boa parte de suas existncias no estado
suspenso, aguardando respostas s suas solicitaes de leitura e/ou
escrita de dados nos dispositivos de entrada/sada. Exemplos desta
classe de tarefas incluem editores, compiladores e servidores de rede.
c Carlos Maziero
62
2: Objetivos e mtricas
importante observar que uma tarefa pode mudar de comportamento

ao longo de sua execuo. Por exemplo, um conversor de arquivos de
udio WAVMP3 alterna constantemente entre fases de processamento e
de entrada/sada, at concluir a converso dos arquivos desejados.
2.5.1
Objetivos e mtricas
Ao se definir um algoritmo de escalonamento, deve-se ter em mente

seu objetivo. Todavia, os objetivos do escalonador so muitas vezes contraditrios; o desenvolvedor do sistema tem de escolher o que priorizar,
em funo do perfil das aplicaes a suportar. Por exemplo, um sistema
interativo voltado execuo de jogos exige valores de quantum baixos,
para que cada tarefa pronta receba rapidamente o processador (provendo
maior interatividade). Todavia, valores pequenos de quantum implicam em
uma menor eficincia E no uso do processador, conforme visto na Seo 2.4.2.
Vrios critrios podem ser definidos para a avaliao de escalonadores; os
mais frequentemente utilizados so:
Tempo de execuo ou de vida (turnaround time, tt ): diz respeito ao tempo
total da vida de cada tarefa, ou seja, o tempo decorrido entre a
criao da tarefa e seu encerramento, computando todos os tempos
de processamento e de espera. uma medida tpica de sistemas em
lote, nos quais no h interao direta com os usurios do sistema.
No deve ser confundido com o tempo de processamento (tp ), que
o tempo total de uso de processador demandado pela tarefa.
Tempo de espera (waiting time, tw ): o tempo total perdido pela tarefa na
fila de tarefas prontas, aguardando o processador. Deve-se observar
que esse tempo no inclui os tempos de espera em operaes de
entrada/sada (que so inerentes aplicao).
Tempo de resposta (response time, tr ): o tempo decorrido entre a chegada
de um evento ao sistema e o resultado imediato de seu processamento.
Por exemplo, o tempo decorrido entre apertar uma tecla e o caractere
correspondente aparecer na tela, em um editor de textos. Essa medida
de desempenho tpica de sistemas interativos, como sistemas desktop
e de tempo-real; ela depende sobretudo da rapidez no tratamento das
interrupes de hardware pelo ncleo e do valor do quantum de tempo,
c Carlos Maziero
63
2: Escalonamento preemptivo e cooperativo
para permitir que as tarefas cheguem mais rpido ao processador

quando saem do estado suspenso.
Justia : este critrio diz respeito distribuio do processador entre
as tarefas prontas: duas tarefas de comportamento similar devem
receber tempos de processamento similares e ter duraes de execuo
similares.
Eficincia : a eficincia E, conforme definido na Seo 2.4.2, indica o grau
de utilizao do processador na execuo das tarefas do usurio.
Ela depende sobretudo da rapidez da troca de contexto e da quantidade de tarefas orientadas a entrada/sada no sistema (tarefas desse
tipo geralmente abandonam o processador antes do fim do quantum,
gerando assim mais trocas de contexto que as tarefas orientadas a
processamento).
2.5.2
Escalonamento preemptivo e cooperativo
O escalonador de um sistema operacional pode ser preemptivo ou

cooperativo (no-cooperativo):
Sistemas preemptivos : nestes sistemas uma tarefa pode perder o processador caso termine seu quantum de tempo, execute uma chamada
de sistema ou caso ocorra uma interrupo que acorde uma tarefa
mais prioritria (que estava suspensa aguardando um evento). A
cada interrupo, exceo ou chamada de sistema, o escalonador pode
reavaliar todas as tarefas da fila de prontas e decidir se mantm ou
substitui a tarefa atualmente em execuo.
Sistemas cooperativos : a tarefa em execuo permanece no processador
tanto quanto possvel, s abandonando o mesmo caso termine de executar, solicite uma operao de entrada/sada ou libere explicitamente
o processador, voltando fila de tarefas prontas (isso normalmente
feito atravs de uma chamada de sistema sched_yield() ou similar).
Esses sistemas so chamados de cooperativos por exigir a cooperao
das tarefas entre si na gesto do processador, para que todas possam
executar.
A maioria dos sistemas operacionais de uso geral atuais preemptiva.
Sistemas mais antigos, como o Windows 3.*, PalmOS 3 e MacOS 8 e 9
operavam de forma cooperativa.
c Carlos Maziero
64
2: Escalonamento FCFS (First-Come, First Served)
Em um sistema preemptivo, normalmente as tarefas s so interrompidas quando o processador est no modo usurio; a thread de ncleo
correspondente a cada tarefa no sofre interrupes. Entretanto, os sistemas
mais sofisticados implementam a preempo de tarefas tambm no modo
ncleo. Essa funcionalidade importante para sistemas de tempo real, pois
permite que uma tarefa de alta prioridade chegue mais rapidamente ao
processador quando for reativada. Ncleos de sistema que oferecem essa
possibilidade so denominados ncleos preemptivos; Solaris, Linux 2.6 e
Windows NT so exemplos de ncleos preemptivos.
2.5.3
Escalonamento FCFS (First-Come, First Served)
A forma de escalonamento mais elementar consiste em simplesmente

atender as tarefas em sequncia, medida em que elas se tornam prontas
(ou seja, conforme sua ordem de chegada na fila de tarefas prontas). Esse
algoritmo conhecido como FCFS First Come - First Served e tem como
principal vantagem sua simplicidade.
Para dar um exemplo do funcionamento do algoritmo FCFS, consideremos as tarefas na fila de tarefas prontas, com suas duraes previstas de
processamento e datas de ingresso no sistema, descritas na tabela a seguir:
tarefa
ingresso
durao
t1
0
5
t2
0
2
t3
1
4
t4
3
3
O diagrama da Figura 2.13 mostra o escalonamento do processador

usando o algoritmo FCFS cooperativo (ou seja, sem quantum ou outras
interrupes). Os quadros sombreados representam o uso do processador
(observe que em cada instante apenas uma tarefa ocupa o processador). Os
quadros brancos representam as tarefas que j ingressaram no sistema e
esto aguardando o processador (tarefas prontas).
Calculando o tempo mdio de execuo (Tt , a mdia de tt (ti )) e o tempo
mdio de espera (Tw , a mdia de tw (ti )) para o algoritmo FCFS, temos:
tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (5 0) + (7 0) + (11 1) + (14 3)
=
4
4
5 + 7 + 10 + 11 33
=
=
= 8.25s
4
4
Tt =
c Carlos Maziero
65
t4
t3
t2
t1
t
0
11
14
Figura 2.13: Escalonamento FCFS.
tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (0 0) + (5 0) + (7 1) + (11 3)

=
4
4
0 + 5 + 6 + 8 19
=
=
= 4.75s
4
4
Tw =
A adio da preempo por tempo ao escalonamento FCFS d origem

a outro algoritmo de escalonamento bastante popular, conhecido como
escalonamento por revezamento, ou Round-Robin. Considerando as tarefas
definidas na tabela anterior e um quantum tq = 2s, seria obtida a sequncia
de escalonamento apresentada na Figura 2.14.
t4
t3
t2
t1
t
0
10
11
12
13
14
Figura 2.14: Escalonamento Round-Robin.

Na Figura 2.14, importante observar que a execuo das tarefas no
obedece uma sequncia bvia como t1 t2 t3 t4 t1 t2 . . ., mas
uma sequncia bem mais complexa: t1 t2 t3 t1 t4 t3 . . ..
Isso ocorre por causa da ordem das tarefas na fila de tarefas prontas. Por
exemplo, a tarefa t1 para de executar e volta fila de tarefas prontas no
instante t = 2, antes de t4 ter entrado no sistema (em t = 3). Por isso, t1
c Carlos Maziero
66
retorna ao processador antes de t4 (em t = 6). A Figura 2.15 detalha a

evoluo da fila de tarefas prontas ao longo do tempo, para esse exemplo.
t2
t=0
t=2
t=3
t4
t=4
t=5
t=6
t=7
t2
t1
t3
t2
t1
t1
t3
t2
t1
t3
t2
t4
t1
t3
t4
t1
t3
t3
t4
t1
t=0
t=1
t1
t=8
t=9
t=10
t=11
t2
t=12
t3
t4
t1
t1
t3
t4
t1
t3
t4
t4
t1
t3
t4
t1
t3
t4
t1
t3
t4
t1
t=13
t=14
t4
Figura 2.15: Evoluo da fila de tarefas prontas no escalonamento RoundRobin.

Calculando o tempo mdio de execuo Tt e o tempo mdio de espera
Tw para o algoritmo round-robin, temos:
tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (13 0) + (4 0) + (12 1) + (14 3)
=
4
4
13 + 4 + 11 + 11 39
=
=
= 9.75s
4
4
Tt =
Tw =
tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) 8 + 2 + 7 + 8 25

=
=
= 6.25s
4
4
4
Observa-se o aumento nos tempos Tt e Tw em relao ao algoritmo FCFS

simples, o que mostra que o algoritmo round-robin menos eficiente para
a execuo de tarefas em lote. Entretanto, por distribuir melhor o uso do
c Carlos Maziero
67
2: Escalonamento SJF (Shortest Job First)
processador entre as tarefas ao longo do tempo, ele pode proporcionar

tempos de resposta bem melhores s aplicaes interativas.
O aumento da quantidade de trocas de contexto tambm tem um impacto
negativo na eficincia do sistema operacional. Quanto menor o nmero de
trocas de contexto e menor a durao de cada troca, mais tempo sobrar
para a execuo das tarefas em si. Assim, possvel definir uma medida
de eficincia E do uso do processador, em funo das duraes mdias do
quantum de tempo tq e da troca de contexto ttc :
E=
tq
tq + ttc
Por exemplo, um sistema no qual as trocas de contexto duram 1ms

20
e cujo quantum mdio de 20ms ter uma eficincia E = 20+1
= 95, 2%.
Caso a durao do quantum seja reduzida para 2ms, a eficincia cair para
2
E = 2+1
= 66, 7%. A eficincia final da gerncia de tarefas influenciada por
vrios fatores, como a carga do sistema (mais tarefas ativas implicam em
mais tempo gasto pelo escalonador, aumentando ttc ) e o perfil das aplicaes
(aplicaes que fazem muita entrada/sada saem do processador antes do
final de seu quantum, diminuindo o valor mdio de tq ).
Deve-se observar que os algoritmos de escalonamento FCFS e RR no
levam em conta a importncia das tarefas nem seu comportamento em
relao ao uso dos recursos. Por exemplo, nesses algoritmos as tarefas
orientadas a entrada/sada iro receber menos tempo de processador que
as tarefas orientadas a processamento (pois as primeiras geralmente no
usam integralmente seus quanta de tempo), o que pode ser prejudicial para
aplicaes interativas.
2.5.4
Escalonamento SJF (Shortest Job First)
O algoritmo de escalonamento que proporciona os menores tempos

mdios de execuo e de espera conhecido como menor tarefa primeiro,
ou SJF (Shortest Job First). Como o nome indica, ele consiste em atribuir o
processador menor (mais curta) tarefa da fila de tarefas prontas. Pode
ser provado matematicamente que esta estratgia sempre proporciona os
menores tempos mdios de espera. Aplicando-se este algoritmo s tarefas
da tabela anterior, obtm-se o escalonamento apresentado na Figura 2.16.
Tw para o algoritmo SJF, temos:
c Carlos Maziero
68
2: Escalonamento SJF (Shortest Job First)
t4
t3
t2
t1
t
0
14
Figura 2.16: Escalonamento SJF.
tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (14 0) + (2 0) + (6 1) + (9 3)

=
4
4
14 + 2 + 5 + 6 27
=
=
= 6.75s
4
4
Tt =
tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (9 0) + (0 0) + (2 1) + (6 3)

=
4
4
9 + 0 + 1 + 3 13
=
= 3.25s
=
4
4
Tw =
Deve-se observar que o comportamento expresso na Figura 2.16 corresponde verso cooperativa do algoritmo SJF: o escalonador aguarda a
concluso de cada tarefa para decidir quem ir receber o processador. No
caso preemptivo, o escalonador deve comparar a durao prevista de cada
nova tarefa que ingressa no sistema com o tempo restante de processamento
das demais tarefas presentes, inclusive aquela que est executando no momento. Essa abordagem denominada por alguns autores de menor tempo
restante primeiro (SRTF Short Remaining Time First) [Tanenbaum, 2003].
A maior dificuldade no uso do algoritmo SJF consiste em estimar a priori
a durao de cada tarefa, ou seja, antes de sua execuo. Com exceo
de algumas tarefas em lote ou de tempo real, essa estimativa invivel;
por exemplo, como estimar por quanto tempo um editor de textos ir ser
utilizado? Por causa desse problema, o algoritmo SJF puro pouco utilizado.
No entanto, ao associarmos o algoritmo SJF preempo por tempo, esse
algoritmo pode ser de grande valia, sobretudo para tarefas orientadas a
entrada/sada.
c Carlos Maziero
69
2: Escalonamento por prioridades
Suponha uma tarefa orientada a entrada/sada em um sistema preemptivo

com tq = 10ms. Nas ltimas 3 vezes em que recebeu o processador, essa
tarefa utilizou 3ms, 4ms e 4.5ms de cada quantum recebido. Com base nesses
dados histricos, possvel estimar qual a durao da execuo da tarefa na
prxima vez em que receber o processador. Essa estimativa pode ser feita
por mdia simples (clculo mais rpido) ou por extrapolao (clculo mais
complexo, podendo influenciar o tempo de troca de contexto ttc ).
A estimativa de uso do prximo quantum assim obtida pode ser usada
como base para a aplicao do algoritmo SJF, o que ir priorizar as tarefas
orientadas a entrada/sada, que usam menos o processador. Obviamente,
uma tarefa pode mudar de comportamento repentinamente, passando de
uma fase de entrada/sada para uma fase de processamento, ou vice-versa.
Nesse caso, a estimativa de uso do prximo quantum ser incorreta durante
alguns ciclos, mas logo voltar a refletir o comportamento atual da tarefa.
Por essa razo, apenas a histria recente da tarefa deve ser considerada (3 a
5 ltimas ativaes).
Outro problema associado ao escalonamento SJF a possibilidade de
inanio (starvation) das tarefas mais longas. Caso o fluxo de tarefas curtas
chegando ao sistema seja elevado, as tarefas mais longas nunca sero
escolhidas para receber o processador e vo literalmente morrer de fome,
esperando na fila sem poder executar. Esse problema pode ser resolvido
atravs de tcnicas de envelhecimento de tarefas, como a apresentada na
Seo 2.5.5.
2.5.5
Escalonamento por prioridades
Vrios critrios podem ser usados para ordenar a fila de tarefas prontas e
escolher a prxima tarefa a executar; a data de ingresso da tarefa (usada no
FCFS) e sua durao prevista (usada no SJF) so apenas dois deles. Inmeros
outros critrios podem ser especificados, como o comportamento da tarefa
(em lote, interativa ou de tempo-real), seu proprietrio (administrador,
gerente, estagirio), seu grau de interatividade, etc.
No escalonamento por prioridades, a cada tarefa associada uma
prioridade, geralmente na forma de um nmero inteiro. Os valores de
prioridade so ento usados para escolher a prxima tarefa a receber o
processador, a cada troca de contexto. O algoritmo de escalonamento por
prioridades define um modelo genrico de escalonamento, que permite
modelar vrias abordagens, entre as quais o FCFS e o SJF.
c Carlos Maziero
70
Para ilustrar o funcionamento do escalonamento por prioridades, sero

usadas as tarefas descritas na tabela a seguir, que usam uma escala de
prioridades positiva (ou seja, onde valores maiores indicam uma prioridade
maior):
tarefa
ingresso
durao
prioridade
t1
0
5
2
t2
0
2
3
t3
1
4
1
t4
3
3
4
O diagrama da Figura 2.17 mostra o escalonamento do processador

usando o algoritmo por prioridades em modo cooperativo (ou seja, sem
quantum ou outras interrupes).
t4
t3
t2
t1
t
0
10
14
Figura 2.17: Escalonamento por prioridades (cooperativo).

Tw para esse algoritmo, temos:
tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (7 0) + (2 0) + (14 1) + (10 3)
=
4
4
7 + 2 + 13 + 7 29
=
=
= 7.25s
4
4
Tt =
tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) (2 0) + (0 0) + (10 1) + (7 3)

=
4
4
2 + 0 + 9 + 4 15
=
=
= 3.75s
4
4
Tw =
Quando uma tarefa de maior prioridade se torna disponvel para execuo, o escalonador pode decidir entregar o processador a ela, trazendo
c Carlos Maziero
71
a tarefa atual de volta para a fila de prontas. Nesse caso, temos um escalonamento por prioridades preemptivo, cujo comportamento apresentado
na Figura 2.18 (observe que, quando t4 ingressa no sistema, ela recebe o
processador e t1 volta a esperar na fila de prontas).
t4
t3
t2
t1
t
0
10
14
Figura 2.18: Escalonamento por prioridades (preemptivo).

Tw para esse algoritmo, temos:
tt (t1 ) + tt (t2 ) + tt (t3 ) + tt (t4 ) (10 0) + (2 0) + (14 1) + (6 3)
=
4
4
10 + 2 + 13 + 3 28
=
=
= 7s
4
4
Tt =
Tw =
tw (t1 ) + tw (t2 ) + tw (t3 ) + tw (t4 ) 5 + 0 + 9 + 0 14

=
=
= 3.5s
4
4
4
Definio de prioridades
A definio da prioridade de uma tarefa influenciada por diversos
fatores, que podem ser classificados em dois grandes grupos:
Fatores externos : so informaes providas pelo usurio ou o administrador do sistema, que o escalonador no conseguiria estimar sozinho. Os
fatores externos mais comuns so a classe do usurio (administrador,
diretor, estagirio) o valor pago pelo uso do sistema (servio bsico,
servio premium) e a importncia da tarefa em si (um detector de
intruso, um script de reconfigurao emergencial, etc.).
c Carlos Maziero
72
Fatores internos : so informaes que podem ser obtidas ou estimadas

pelo escalonador, com base em dados disponveis no sistema local.
Os fatores internos mais utilizados so a idade da tarefa, sua durao
estimada, sua interatividade, seu uso de memria ou de outros recursos,
etc.
Todos esses fatores devem ser combinados para produzir um valor de
prioridade para cada tarefa. Todos os fatores externos so expressos por
valor inteiro denominado prioridade esttica (ou prioridade de base), que
resume a opinio do usurio ou administrador sobre aquela tarefa. Os
fatores internos mudam continuamente e devem ser recalculados periodicamente pelo escalonador. A combinao da prioridade esttica com os
fatores internos resulta na prioridade dinmica ou final, que usada pelo
escalonador para ordenar as tarefas prontas. A Figura 2.19 resume esse
procedimento.
classe do usurio
valor pago
importncia da tarefa
fatores externos
...
prioridade
esttica
prioridade
dinmica
idade da tarefa
durao estimada
grau de interatividade
fatores internos
uso de outros recursos

...
Figura 2.19: Composio da prioridade dinmica.

Em geral, cada famlia de sistemas operacionais define sua prpria escala
de prioridades estticas. Alguns exemplos de escalas comuns so:
Windows 2000 e sucessores : processos e threads so associados a classes
de prioridade (6 classes para processos e 7 classes para threads); a
prioridade final de uma thread depende de sua prioridade de sua
prpria classe de prioridade e da classe de prioridade do processo ao
qual est associada, assumindo valores entre 0 e 31. As prioridades
do processos, apresentadas aos usurios no Gerenciador de Tarefas,
apresentam os seguintes valores default:
c Carlos Maziero
73
4: baixa ou ociosa
6: abaixo do normal
8: normal
10: acima do normal
13: alta
24: tempo-real
Geralmente a prioridade da tarefa responsvel pela janela ativa recebe
um incremento de prioridade (+1 ou +2, conforme a configurao do
sistema).
No Linux (ncleo 2.4 e sucessores) h duas escalas de prioridades:
Tarefas interativas: a escala de prioridades negativa: a prioridade de cada tarefa vai de -20 (mais importante) a +19 (menos
importante) e pode ser ajustada atravs dos comandos nice e
renice. Esta escala padronizada em todos os sistemas UNIX.
Tarefas de tempo-real: a prioridade de cada tarefa vai de 1 (mais
importante) a 99 (menos importante). As tarefas de tempo-real
tm precedncia sobre as tarefas interativas e so escalonadas
usando polticas distintas. Somente o administrador pode criar
tarefas de tempo-real.
Inanio e envelhecimento de tarefas
No escalonamento por prioridades bsico, as tarefas de baixa prioridade
s recebem o processador na ausncia de tarefas de maior prioridade. Caso
existam tarefas de maior prioridade frequentemente ativas, as de baixa
prioridade podem sofrer de inanio (starvation), ou seja, nunca ter acesso
ao processador.
Alm disso, em sistemas de tempo compartilhado, as prioridades estticas definidas pelo usurio esto intuitivamente relacionadas proporcionalidade na diviso do tempo de processamento. Por exemplo, se um sistema
recebe duas tarefas iguais com a mesma prioridade, espera-se que cada uma
receba 50% do processador e que ambas concluam ao mesmo tempo. Caso
o sistema receba trs tarefas: t1 com prioridade 1, t2 com prioridade 2 e t3
com prioridade 3, espera-se que t3 receba mais o processador que t2 , e esta
c Carlos Maziero
74
mais que t1 (assumindo uma escala de prioridades positiva). Entretanto,

se aplicarmos o algoritmo de prioridades bsico, as tarefas iro executar
de forma sequencial, sem distribuio proporcional do processador. Esse
resultado indesejvel ocorre porque, a cada fim de quantum, sempre a
mesma tarefa escolhida para processar: a mais prioritria. Essa situao
est ilustrada na Figura 2.20.
t3
t2
t1
t
0
Figura 2.20: Escalonamento por prioridades.

Para evitar a inanio e garantir a proporcionalidade expressa atravs
das prioridades estticas, um fator interno denominado envelhecimento
(task aging) deve ser definido. O envelhecimento indica h quanto tempo
uma tarefa est aguardando o processador e aumenta sua prioridade proporcionalmente. Dessa forma, o envelhecimento evita a inanio dos processos
de baixa prioridade, permitindo a eles obter o processador periodicamente.
Uma forma simples de implementar o envelhecimento est resumida no
seguinte algoritmo (que considera uma escala de prioridades positiva):
c Carlos Maziero
75
Definies:
ti
: tarefa i
pei : prioridade esttica de ti
pdi : prioridade dinmica de ti
N : nmero de tarefas no sistema
Quando uma tarefa nova tn ingressa no sistema:
pen prioridade inicial default
pdn pen
Para escolher a prxima tarefa a executar tp :
escolher tp | pdp = maxN
(pdi )
i=1
pdp pep
i , p : pdi pdi +
Em outras palavras, a cada turno o escalonador escolhe como prxima
tarefa (tp ) aquela com a maior prioridade dinmica (pdp ). A prioridade
dinmica dessa tarefa igualada sua prioridade esttica (pdp pep ) e
ento ela recebe o processador. A prioridade dinmica das demais tarefas
aumentada de , ou seja, elas envelhecem e no prximo turno tero
mais chances de ser escolhidas. A constante conhecida como fator de
envelhecimento.
Usando o algoritmo de envelhecimento, a diviso do processador entre as
tarefas se torna proporcional s suas prioridades. A Figura 2.21 ilustra essa
proporcionalidade na execuo das trs tarefas t1 , t2 e t3 com p(t1 ) < p(t2 ) <
p(t3 ), usando a estratgia de envelhecimento. Nessa figura, percebe-se que
todas as trs tarefas recebem o processador periodicamente, mas que t3
recebe mais tempo de processador que t2 , e que t2 recebe mais que t1 .
Inverso e herana de prioridades
Outro problema relevante que pode ocorrer em sistemas baseados em
prioridades a inverso de prioridades [Sha et al., 1990]. Este tipo de problema
mais complexo que o anterior, pois envolve o conceito de excluso mtua:
alguns recursos do sistema devem ser usados por um processo de cada
vez, para evitar problemas de consistncia de seu estado interno. Isso pode
ocorrer com arquivos, portas de entrada sada e conexes de rede, por
c Carlos Maziero
76
t3
t2
t1
t
0
Figura 2.21: Escalonamento por prioridades com envelhecimento.

exemplo. Quando um processo obtm acesso a um recurso com excluso
mtua, os demais processos que desejam us-lo ficam esperando no estado
suspenso, at que o recurso esteja novamente livre. As tcnicas usadas para
implementar a excluso mtua so descritas no Captulo 4.
A inverso de prioridades consiste em processos de alta prioridade
serem impedidos de executar por causa de um processo de baixa prioridade.
Para ilustrar esse problema, pode ser considerada a seguinte situao: um
determinado sistema possui um processo de alta prioridade pa , um processo
de baixa prioridade pb e alguns processos de prioridade mdia pm . Alm
disso, h um recurso R que deve ser acessado em excluso mtua; para
simplificar, somente pa e pb esto interessados em usar esse recurso. A
seguinte sequncia de eventos, ilustrada na Figura 2.22, um exemplo de
como pode ocorrer uma inverso de prioridades:
1. Em um dado momento, o processador est livre e alocado a um
processo de baixa prioridade pb ;
2. durante seu processamento, pb obtm o acesso exclusivo a um recurso
R e comea a us-lo;
3. pb perde o processador, pois um processo com prioridade maior que a
dele (pm ) foi acordado devido a uma interrupo;
4. pb volta ao final da fila de tarefas prontas, aguardando o processador;
enquanto ele no voltar a executar, o recurso R permanecer alocado a
ele e ningum poder us-lo;
5. Um processo de alta prioridade pa recebe o processador e solicita
acesso ao recurso R; como o recurso est alocado ao processo pb , pa
suspenso at que o processo de baixa prioridade pb libere o recurso.
c Carlos Maziero
77
Neste momento, o processo de alta prioridade pa no pode continuar

sua execuo, porque o recurso de que necessita est nas mos do processo
de baixa prioridade pb . Dessa forma, pa deve esperar que pb execute e
libere R, o que justifica o nome inverso de prioridades. A espera de pa
pode ser longa, pois pb tem baixa prioridade e pode demorar a receber o
processador novamente, caso existam outros processos em execuo no
sistema (como pm ). Como tarefas de alta prioridade so geralmente crticas
para o funcionamento de um sistema, a inverso de prioridades pode ter
efeitos graves.
Pa acorda, solicita o recurso
e ca bloqueado esperando
inverso de prioridades!
Pa recebe o recurso
e o processador
Pm recebe o processador
Pa
R
Pm
Pb aloca um
recurso para si
Pb libera o recurso
bloqueado e
perde o processador
Pb
t
0
Pm libera o processador
Figura 2.22: Cenrio de uma inverso de prioridades.

Uma soluo elegante para o problema da inverso de prioridades
obtida atravs de um protocolo de herana de prioridade [Sha et al., 1990]. O
protocolo de herana de prioridade mais simples consiste em aumentar
temporariamente a prioridade do processo pb que detm o recurso de uso
exclusivo R. Caso esse recurso seja requisitado por um processo de maior
prioridade pa , o processo pb herda temporariamente a prioridade de pa ,
para que possa voltar a executar e liberar o recurso R mais rapidamente.
Assim que liberar o recurso, pb retorna sua prioridade anterior. Essa
estratgia est ilustrada na Figura 2.23.
Provavelmente o melhor exemplo real de inverso de prioridades tenha
ocorrido na sonda espacial Mars Pathfinder, enviada pela NASA em 1996 para
explorar o solo marciano (Figura 2.24) [Jones, 1997]. O software da sonda
executava sobre o sistema operacional de tempo real VxWorks e consistia de
97 threads com vrios nveis de prioridades. Essas tarefas se comunicavam
atravs de uma rea de trasferncia em memria compartilhada, com acesso
mutuamente exclusivo controlado por semforos (semforos so estruturas
de sincronizao discutidas na Seo 4.6).
c Carlos Maziero
78
Pa acorda, solicita o recurso

e ca bloqueado esperando
Pm recebe o processador
Pa
R
Pm
Pb aloca um
recurso para si
Pb libera o recurso
bloqueado e
perde o processador
Pb
t
0
Figura 2.23: Um protocolo de herana de prioridade.
Figura 2.24: Sonda Mars Pathfinder com o rob Sojourner (NASA).

A gerncia da rea de transferncia estava a cargo de uma tarefa t g ,
rpida mas de alta prioridade, que era ativada frequentemente para mover
blocos de informao para dentro e fora dessa rea. A coleta de dados
meteorolgicos era feita por uma tarefa tm de baixa prioridade, que executava
esporadicamente e escrevia seus dados na rea de transferncia, para uso
por outras tarefas. Por fim, a comunicao com a Terra estava sob a
responsabilidade de uma tarefa tc de prioridade mdia e potencialmente
demorada (Tabela 2.2 e Figura 2.25).
c Carlos Maziero
79
tarefa
funo
prioridade durao
tg
gerncia da rea de transferncia
alta
curta
coleta de dados meteorolgicos
baixa
curta
tm
tc
comunicao com a Terra
mdia
longa
Tabela 2.2: Algumas tarefas do software da sonda Mars Pathfinder.
thread tg
watchdog
thread tm
sensores
meteorolgicos
e ambientais
thread tc
rea de
transferncia
rdio e
antena
outra
threads
Figura 2.25: Principais tarefas do software embarcado da sonda Mars

Pathfinder.
Como o sistema VxWorks define prioridades preemptivas, as tarefas eram
atendidas conforme suas necessidades na maior parte do tempo. Todavia, a
excluso mtua no acesso rea de transferncia escondia uma inverso de
prioridades: caso a tarefa de coleta de dados meteorolgicos tm perdesse o
processador sem liberar a rea de transferncia, a tarefa de gerncia t g teria
de ficar esperando at que tm voltasse a executar para liberar a rea. Isso
poderia poderia demorar se, por azar, a tarefa de comunicao estivesse
executando, pois ela tinha mais prioridade que tm .
Como todos os sistemas crticos, a sonda Mars Pathfinder possui um
sistema de proteo contra erros, ativado por um temporizador (watchdog).
Caso a gerncia da rea de transferncia ficasse parada por muito tempo, um
procedimento de reincio geral do sistema era automaticamente ativado pelo
temporizador. Dessa forma, a inverso de prioridades provocava reincios
espordicos e imprevisveis no software da sonda, interrompendo suas
atividades e prejudicando seu funcionamento. A soluo foi obtida atravs
da herana de prioridades: caso a tarefa de gerncia t g fosse bloqueada pela
c Carlos Maziero
80
2: Outros algoritmos de escalonamento
tarefa de coleta de dados tm , esta ltima herdava a alta prioridade de t g para

poder liberar rapidamente a rea de transferncia, mesmo se a tarefa de
comunicao tc estivesse em execuo.
2.5.6
Outros algoritmos de escalonamento
Alm dos algoritmos de escalonamento vistos nesta seo, diversos outros podem ser encontrados na literatura e em sistemas de mercado, como os escalonadores de tempo-real [Farines et al., 2000], os escalonadores multimdia [Nieh and Lam, 1997], os escalonadores justos
[Kay and Lauder, 1988, Ford and Susarla, 1996], os escalonadores multiprocessador [Black, 1990] e multi-core [Boyd-Wickizer et al., 2009].
2.5.7
Um escalonador real
Na prtica, os sistemas operacionais de mercado implementam mais de

um algoritmo de escalonamento. A escolha do escalonador adequado feita
com base na classe de escalonamento atribuda a cada tarefa. Por exemplo, o
ncleo Linux implementa dois escalonadores (Figura 2.26): um escalonador
de tarefas de tempo-real (classes SCHED_FIFO e SCHED_RR) e um escalonador
de tarefas interativas (classe SCHED_OTHER) [Love, 2004]. Cada uma dessas
classes de escalonamento est explicada a seguir:
Classe SCHED_FIFO : as tarefas associadas a esta classe so escalonadas
usando uma poltica FCFS sem preempo (sem quantum) e usando
apenas suas prioridades estticas (no h envelhecimento). Portanto,
uma tarefa desta classe executa at bloquear por recursos ou liberar explicitamente o processador (atravs da chamada de sistema
sched_yield()).
Classe SCHED_RR : implementa uma poltica similar anterior, com a
incluso da preempo por tempo. O valor do quantum proporcional
prioridade atual de cada tarefa, variando de 10ms a 200ms.
Classe SCHED_OTHER : suporta tarefas interativas em lote, atravs de uma
poltica baseada em prioridades dinmicas com preempo por tempo
com quantum varivel. Tarefas desta classe somente so escalonadas
se no houverem tarefas prontas nas classes SCHED_FIFO e SCHED_RR.
c Carlos Maziero
81
2: Um escalonador real
sched_yield
SCHED_FIFO
SCHED_RR
sched_yield / m de quantum
executando
sched_yield / m de quantum
SCHED_OTHER
suspensa
Figura 2.26: O escalonador multi-filas do Linux.

As classes de escalonamento SCHED_FIFO e SCHED_RR so reservadas
para tarefas de tempo-real, que s podem ser lanadas pelo administrador
do sistema. Todas as demais tarefas, ou seja, a grande maioria das aplicaes
e comandos dos usurios, executa na classe de escalonamento SCHED_OTHER.
Captulo 3
Comunicao entre tarefas
Muitas implementaes de sistemas complexos so estruturadas
como vrias tarefas inter-dependentes, que cooperam entre si para
atingir os objetivos da aplicao, como por exemplo em um navegador
Web. Para que as vrias tarefas que compem uma aplicao possam
cooperar, elas precisam comunicar informaes umas s outras e
coordenar suas atividades, para garantir que os resultados obtidos
sejam coerentes. Este mdulo apresenta os principais conceitos,
problemas e solues referentes comunicao entre tarefas.
3.1
Objetivos
Nem sempre um programa sequencial a melhor soluo para um

determinado problema. Muitas vezes, as implementaes so estruturadas
na forma de vrias tarefas inter-dependentes que cooperam entre si para
atingir os objetivos da aplicao, como por exemplo em um navegador Web.
Existem vrias razes para justificar a construo de sistemas baseados em
tarefas cooperantes, entre as quais podem ser citadas:
Atender vrios usurios simultneos : um servidor de banco de dados
ou de e-mail completamente sequencial atenderia um nico cliente
por vez, gerando atrasos intolerveis para os demais clientes. Por
isso, servidores de rede so implementados com vrios processos ou
threads, para atender simultaneamente todos os usurios conectados.
Uso de computadores multi-processador : um programa sequencial executa um nico fluxo de instrues por vez, no importando o nmero
c Carlos Maziero
83
3: Escopo da comunicao
de processadores presentes no hardware. Para aumentar a velocidade

de execuo de uma aplicao, esta deve ser quebrada em vrias
tarefas cooperantes, que podero ser escalonadas simultaneamente
nos processadores disponveis.
Modularidade : um sistema muito grande e complexo pode ser melhor
organizado dividindo suas atribuies em mdulos sob a responsabilidade de tarefas inter-dependentes. Cada mdulo tem suas
prprias responsabilidades e coopera com os demais mdulos quando
necessrio. Sistemas de interface grfica, como os projetos Gnome
[Gnome, 2005] e KDE [KDE, 2005], so geralmente construdos dessa
forma.
Construo de aplicaes interativas : navegadores Web, editores de texto
e jogos so exemplos de aplicaes com alta interatividade; nelas,
tarefas associadas interface reagem a comandos do usurio, enquanto
outras tarefas comunicam atravs da rede, fazem a reviso ortogrfica
do texto, renderizam imagens na janela, etc. Construir esse tipo de
aplicao de forma totalmente sequencial seria simplesmente invivel.
Para que as tarefas presentes em um sistema possam cooperar, elas
precisam comunicar, compartilhando as informaes necessrias execuo
de cada tarefa, e coordenar suas atividades, para que os resultados obtidos
sejam consistentes (sem erros). Este mdulo visa estudar os principais
conceitos, problemas e solues empregados para permitir a comunicao
entre tarefas executando em um sistema.
3.2
Escopo da comunicao
Tarefas cooperantes precisam trocar informaes entre si. Por exemplo,

a tarefa que gerencia os botes e menus de um navegador Web precisa
informar rapidamente as demais tarefas caso o usurio clique nos botes
stop ou reload. Outra situao de comunicao frequente ocorre quando o
usurio seleciona um texto em uma pgina da Internet e o arrasta para um
editor de textos. Em ambos os casos ocorre a transferncia de informao
entre duas tarefas distintas.
Implementar a comunicao entre tarefas pode ser simples ou complexo,
dependendo da situao. Se as tarefas esto no mesmo processo, elas
c Carlos Maziero
84
3: Escopo da comunicao
compartilham a mesma rea de memria e a comunicao pode ento ser

implementada facilmente, usando variveis globais comuns. Entretanto,
caso as tarefas pertenam a processos distintos, no existem variveis
compartilhadas; neste caso, a comunicao tem de ser feita por intermdio
do ncleo do sistema operacional, usando chamadas de sistema. Caso as
tarefas estejam em computadores distintos, o ncleo deve implementar
mecanismos de comunicao especficos, fazendo uso do suporte de rede
disponvel. A Figura 3.1 ilustra essas trs situaes.
Computador 1
Computador 2
Processo pa
tarefa i
Processo pb
tarefa j
send
Processo pc
tarefa k
tarefa l
recv
rea
comum
send recv
send
recv
rea no ncleo
ncleo
ncleo
rea no ncleo
rede
Figura 3.1: Comunicao intra-processo (ti t j ), inter-processos (t j tk ) e

inter-sistemas (tk tl ).
Apesar da comunicao poder ocorrer entre threads, processos locais
ou computadores distintos, com ou sem o envolvimento do ncleo do
sistema, os mecanismos de comunicao so habitualmente denominados
de forma genrica como mecanismos de IPC (Inter-Process Communication
mechanisms).
c Carlos Maziero
85
3.3
3: Caractersticas dos mecanismos de comunicao
Caractersticas dos mecanismos de comunicao
A implementao da comunicao entre tarefas pode ocorrer de vrias

formas. Ao definir os mecanismos de comunicao oferecidos por um sistema operacional, seus projetistas devem considerar muitos aspectos, como
o formato dos dados a transferir, o sincronismo exigido nas comunicaes,
a necessidade de buffers e o nmero de emissores/receptores envolvidos em
cada ao de comunicao. As prximas sees analisam alguns dos principais aspectos que caracterizam e distinguem entre si os vrios mecanismos
de comunicao.
3.3.1
Comunicao direta ou indireta
De forma mais abstrata, a comunicao entre tarefas pode ser implementada por duas primitivas bsicas: enviar (dados, destino), que envia os dados
relacionados ao destino indicado, e receber (dados, origem), que recebe os
dados previamente enviados pela origem indicada. Essa abordagem, na
qual o emissor identifica claramente o receptor e vice-versa, denominada
comunicao direta.
Poucos sistemas empregam a comunicao direta; na prtica so utilizados mecanismos de comunicao indireta, por serem mais flexveis. Na
comunicao indireta, emissor e receptor no precisam se conhecer, pois no
interagem diretamente entre si. Eles se relacionam atravs de um canal de
comunicao, que criado pelo sistema operacional, geralmente a pedido
de uma das partes. Neste caso, as primitivas de comunicao no designam
diretamente tarefas, mas canais de comunicao aos quais as tarefas esto
associadas: enviar (dados, canal) e receber (dados, canal). A Figura 3.2 ilustra
essas duas formas de comunicao.
3.3.2
Sincronismo
Em relao aos aspectos de sincronismo do canal de comunicao, a

comunicao entre tarefas pode ser:
Sncrona : quando as operaes de envio e recepo de dados bloqueiam
(suspendem) as tarefas envolvidas at a concluso da comunicao: o
c Carlos Maziero
86
3: Sincronismo
receptor
emissor
receptor
emissor
canal
dados
enviar
receber
dados
enviar
dados
Figura 3.2: Comunicao direta (esquerda) e indireta (direita).

emissor ser bloqueado at que a informao seja recebida pelo receptor, e vice-versa. Esta modalidade de interao tambm conhecida
como comunicao bloqueante. A Figura 3.3 apresenta os diagramas
de tempo de duas situaes frequentes em sistemas com comunicao
sncrona.
receptor
emissor
receptor
emissor
enviar
receber
espera
espera
dados
receber
dados
enviar
Figura 3.3: Comunicao sncrona.

Assncrona : em um sistema com comunicao assncrona, as primitivas
de envio e recepo no so bloqueantes: caso a comunicao no
seja possvel no momento em que cada operao invocada, esta
retorna imediatamente com uma indicao de erro. Deve-se observar
que, caso o emissor e o receptor operem ambos de forma assncrona,
torna-se necessrio criar um canal ou buffer para armazenar os dados
da comunicao entre eles. Sem esse canal, a comunicao se tor-
c Carlos Maziero
87
3: Formato de envio
nar invivel, pois raramente ambos estaro prontos para comunicar

ao mesmo tempo. Esta forma de comunicao, tambm conhecida
como comunicao no-bloqueante, est representada no diagrama
de tempo da Figura 3.4.
receptor
emissor
enviar
erro !
(ningum para receber)
receber
erro !
(nada a receber)
dados
enviar
receber
Figura 3.4: Comunicao assncrona.

Semi-sncrona : primitivas de comunicao semi-sncronas (ou semibloqueantes) tm um comportamento sncrono (bloqueante) durante
um prazo pr-definido. Caso esse prazo se esgote sem que a comunicao tenha ocorrido, a primitiva se encerra com uma indicao de
erro. Para refletir esse comportamento, as primitivas de comunicao
recebem um parmetro adicional: enviar (dados, destino, prazo) e receber
(dados, origem, prazo). A Figura 3.5 ilustra duas situaes em que ocorre
esse comportamento.
3.3.3
Formato de envio
A informao enviada pelo emissor ao receptor pode ser vista basicamente de duas formas: como uma sequncia de mensagens independentes,
cada uma com seu prprio contedo, ou como um fluxo sequencial e
contnuo de dados, imitando o comportamento de um arquivo com acesso
sequencial.
c Carlos Maziero
88
3: Formato de envio
receptor
emissor
receptor
emissor
enviar
receber
prazo
prazo
erro !
(ningum para receber)
erro !
(nada a receber)
enviar
receber
dados
enviar
receber
dados
Figura 3.5: Comunicao semi-sncrona.

Na abordagem baseada em mensagens, cada mensagem consiste de um
pacote de dados que pode ser tipado ou no. Esse pacote recebido ou
descartado pelo receptor em sua ntegra; no existe a possibilidade de receber
meia mensagem (Figura 3.6). Exemplos de sistema de comunicao
orientados a mensagens incluem as message queues do UNIX e os protocolos
de rede IP e UDP, apresentados na Seo 3.4.
emissor
ab
enviar
1234
enviar
xyz
enviar
buer
receptor
ab
1234
ab
receber
ab
receber
1234
receber
xyz
xyz 1234
xyz
Figura 3.6: Comunicao baseada em mensagens.

Caso a comunicao seja definida como um fluxo contnuo de dados, o
canal de comunicao visto como o equivalente a um arquivo: o emissor
escreve dados nesse canal, que sero lidos pelo receptor respeitando a
c Carlos Maziero
89
3: Capacidade dos canais
ordem de envio dos dados. No h separao lgica entre os dados enviados

em operaes separadas: eles podem ser lidos byte a byte ou em grandes
blocos a cada operao de recepo, a critrio do receptor. A Figura 3.7
apresenta o comportamento dessa forma de comunicao.
emissor
buer
ab
enviar
ab
1234
enviar
ab1234
xyz
enviar
receptor
receber
ab12
receber
34xy
34xyz
receber
Figura 3.7: Comunicao baseada em fluxo de dados.

Exemplos de sistemas de comunicao orientados a fluxo de dados
incluem os pipes do UNIX e o protocolo de rede TCP/IP (este ltimo
normalmente classificado como orientado a conexo, com o mesmo significado).
Nestes dois exemplos a analogia com o conceito de arquivos to forte que
os canais de comunicao so identificados por descritores de arquivos e as
chamadas de sistema read e write (normalmente usadas com arquivos) so
usadas para enviar e receber os dados. Esses exemplos so apresentados
em detalhes na Seo 3.4.
3.3.4
Capacidade dos canais
O comportamento sncrono ou assncrono de um canal de comunicao pode ser afetado pela presena de buffers que permitam armazenar
temporariamente os dados em trnsito, ou seja, as informaes enviadas
pelo emissor e que ainda no foram recebidas pelo receptor. Em relao
capacidade de buffering do canal de comunicao, trs situaes devem ser
analisadas:
Capacidade nula (n = 0) : neste caso, o canal no pode armazenar dados;
a comunicao feita por transferncia direta dos dados do emissor
c Carlos Maziero
90
3: Confiabilidade dos canais
para o receptor, sem cpias intermedirias. Caso a comunicao seja

sncrona, o emissor permanece bloqueado at que o destinatrio receba
os dados, e vice-versa. Essa situao especfica (comunicao sncrona
com canais de capacidade nula) implica em uma forte sincronizao
entre as partes, sendo por isso denominada Rendez-Vous (termo francs
para encontro). A Figura 3.3 ilustra dois casos de Rendez-Vous. Por
outro lado, a comunicao assncrona torna-se invivel usando canais
de capacidade nula (conforme discutido na Seo 3.3.2).
Capacidade infinita (n = ) : o emissor sempre pode enviar dados, que
sero armazenados no buffer do canal enquanto o receptor no os
consumir. Obviamente essa situao no existe na prtica, pois
todos os sistemas de computao tm capacidade de memria e de
armazenamento finitas. No entanto, essa simplificao til no estudo
dos algoritmos de comunicao e sincronizao, pois torna menos
complexas a modelagem e anlise dos mesmos.
Capacidade finita (0 < n < ) : neste caso, uma quantidade finita (n) de
dados pode ser enviada pelo emissor sem que o receptor os consuma.
Todavia, ao tentar enviar dados em um canal j saturado, o emissor
poder ficar bloqueado at surgir espao no buffer do canal e conseguir
enviar (comportamento sncrono) ou receber um retorno indicando o
erro (comportamento assncrono). A maioria dos sistemas reais opera
com canais de capacidade finita.
Para exemplificar esse conceito, a Figura 3.8 apresenta o comportamento
de duas tarefas trocando dados atravs de um canal de comunicao com
capacidade para duas mensagens e comportamento sncrono (bloqueante).
3.3.5
Confiabilidade dos canais
Quando um canal de comunicao transporta todos os dados enviados

atravs dele para seus receptores, respeitando seus valores e a ordem em que
foram enviados, ele chamado de canal confivel. Caso contrrio, trata-se
de um canal no-confivel. H vrias possibilidades de erros envolvendo
o canal de comunicao:
Perda de dados: nem todos os dados enviados atravs do canal chegam
ao seu destino; podem ocorrer perdas de mensagens (no caso de
c Carlos Maziero
91
3: Confiabilidade dos canais

emissor
m1
enviar
m2
enviar
m3
enviar
buer
m1
m2
receptor
m1
m2 m1
no h espao
m2
m3
m1
receber
m1
m3 m2
Figura 3.8: Comunicao sncrona usando um canal com capacidade 2.

comunicao orientada a mensagens) ou de sequncias de bytes, no
caso de comunicao orientada a fluxo de dados.
Perda de integridade: os dados enviados pelo canal chegam ao seu
destino, mas podem ocorrer modificaes em seus valores devido a
interferncias externas.
Perda da ordem: todos os dados enviados chegam ntegros ao seu
destino, mas o canal no garante que eles sero entregues na ordem
em que foram enviados. Um canal em que a ordem dos dados
garantida denominado canal FIFO ou canal ordenado.
Os canais de comunicao usados no interior de um sistema operacional
para a comunicao entre processos ou threads locais so geralmente confiveis, ao menos em relao perda ou corrupo de dados. Isso ocorre porque
a comunicao local feita atravs da cpia de reas de memria, operao
em que no h risco de erros. Por outro lado, os canais de comunicao
entre computadores distintos envolvem o uso de tecnologias de rede, cujos
protocolos bsicos de comunicao so no-confiveis (como os protocolos
Ethernet, IP e UDP). Mesmo assim, protocolos de rede de nvel mais elevado,
como o TCP, permitem construir canais de comunicao confiveis.
c Carlos Maziero
92
3.3.6
3: Nmero de participantes
Nmero de participantes
Nas situaes de comunicao apresentadas at agora, cada canal de

comunicao envolve apenas um emissor e um receptor. No entanto, existem
situaes em que uma tarefa necessita comunicar com vrias outras, como
por exemplo em sistemas de chat ou mensagens instantneas (IM Instant
Messaging). Dessa forma, os mecanismos de comunicao tambm podem
ser classificados de acordo com o nmero de tarefas participantes:
1:1 : quando exatamente um emissor e um receptor interagem atravs do
canal de comunicao; a situao mais frequente, implementada por
exemplo nos pipes e no protocolo TCP.
M:N : quando um ou mais emissores enviam mensagens para um ou mais
receptores. Duas situaes distintas podem se apresentar neste caso:
Cada mensagem recebida por apenas um receptor (em geral
aquele que pedir primeiro); neste caso a comunicao continua
sendo ponto-a-ponto, atravs de um canal compartilhado. Essa
abordagem conhecida como mailbox (Figura 3.9), sendo implementada nas message queues UNIX e nos sockets do protocolo UDP.
Na prtica, o mailbox funciona como um buffer de dados, no qual
os emissores depositam mensagens e os receptores as consomem.
Cada mensagem recebida por todos os receptores (cada receptor
recebe uma cpia da mensagem). Essa abordagem conhecida
pelos nomes de difuso (multicast) ou canal de eventos (Figura 3.10),
sendo implementada por exemplo no protocolo UDP.
c Carlos Maziero
93
3: Exemplos de mecanismos de comunicao
r1
m1
e1
m3
m4
m1
m2
mailbox
r2
m2
m4
e2
m3
r3
Figura 3.9: Comunicao M:N atravs de um mailbox.

canal de
eventos
e1
e2
m3
m3
m2
m1
m3
m2
m1
m3
m2
m1
m1
r1
r2
m2
r3
Figura 3.10: Difuso atravs de um canal de eventos.
3.4
Exemplos de mecanismos de comunicao
Nesta seo sero apresentados alguns mecanismos de comunicao usados com frequncia em sistemas UNIX. Mais detalhes sobre estes e outros mecanismos podem ser obtidos em [Stevens, 1998, Robbins and Robbins, 2003].
Mecanismos de comunicao implementados nos sistemas Windows so
apresentados em [Petzold, 1998, Hart, 2004].
3.4.1
Filas de mensagens UNIX
As filas de mensagens foram definidas inicialmente na implementao

UNIX System V, sendo atualmente suportadas pela maioria dos sistemas.
Alm do padro System V, o padro POSIX tambm define uma interface para
manipulao de filas de mensagens. Esse mecanismo um bom exemplo
de implementao do conceito de mailbox (vide Seo 3.3.6), permitindo
c Carlos Maziero
94
3: Filas de mensagens UNIX
o envio e recepo ordenada de mensagens tipadas entre processos locais.

As operaes de envio e recepo podem ser sncronas ou assncronas, a
critrio do programador.
As principais chamadas para uso de filas de mensagens POSIX so:
mq_open: abre uma fila j existente ou cria uma nova fila;
mq_setattr e mq_getattr: permitem ajustar ou obter atributos da fila,
que definem seu comportamento, como o tamanho mximo da fila, o
tamanho de cada mensagem, etc.;
mq_send: envia uma mensagem para a fila; caso a fila esteja cheia, o
emissor fica bloqueado at que alguma mensagem seja retirada da fila,
abrindo espao para o envio; a variante mq_timedsend permite definir
um prazo mximo de espera: caso o envio no ocorra nesse prazo, a
chamada retorna com erro;
mq_receive: recebe uma mensagem da fila; caso a fila esteja vazia, o
receptor bloqueado at que surja uma mensagem para ser recebida;
a variante mq_timedreceive permite definir um prazo mximo de
espera;
mq_close: fecha o descritor da fila criado por mq_open;
mq_unlink: remove a fila do sistema, destruindo seu contedo.
A listagem a seguir implementa um consumidor de mensagens, ou
seja, um programa que cria uma fila para receber mensagens. O cdigo
apresentado segue o padro POSIX (exemplos de uso de filas de mensagens
no padro System V esto disponveis em [Robbins and Robbins, 2003]).
Para compil-lo em Linux necessrio efetuar a ligao com a biblioteca de
tempo-real POSIX (usando a opo -lrt).
c Carlos Maziero
95
1
2
// Arquivo mq-recv.c: recebe mensagens de uma fila de mensagens Posix.

// Em Linux, compile usando: cc -o mq-recv -lrt mq-recv.c
3
4
5
6
7
#include
#include
#include
#include
<stdio.h>
<stdlib.h>
<mqueue.h>
<sys/stat.h>
8
9
#define QUEUE "/my_queue"
10
11
12
13
14
15

{
mqd_t queue;
// descritor da fila de mensagens
struct mq_attr attr;
// atributos da fila de mensagens
int msg ;
// mensagens contendo um inteiro
16
// define os atributos da fila de mensagens

attr.mq_maxmsg = 10 ;
// capacidade para 10 mensagens
attr.mq_msgsize = sizeof(msg) ; // tamanho de cada mensagem
attr.mq_flags = 0 ;
17
18
19
20
21
umask (0) ;
22
// mascara de permissoes (umask)
23
// abre ou cria a fila com permissoes 0666

if ((queue = mq_open (QUEUE, O_RDWR|O_CREAT, 0666, &attr)) < 0)
{
perror ("mq_open");
exit (1);
}
24
25
26
27
28
29
30
// recebe cada mensagem e imprime seu conteudo

for (;;)
{
if ((mq_receive (queue, (void*) &msg, sizeof(msg), 0)) < 0)
{
perror("mq_receive:") ;
exit (1) ;
}
printf ("Received msg value %d\n", msg);
}
31
32
33
34
35
36
37
38
39
40
41
A listagem a seguir implementa o programa produtor das mensagens

consumidas pelo programa anterior:
c Carlos Maziero
96
1
2
// Arquivo mq-send.c: envia mensagens para uma fila de mensagens Posix.

// Em Linux, compile usando: cc -o mq-send -lrt mq-send.c
3
4
5
6
7
#include
#include
#include
#include
<stdio.h>
<stdlib.h>
<mqueue.h>
<unistd.h>
8
9
#define QUEUE "/my_queue"
10
11
12
13
14

{
mqd_t queue;
// descritor da fila
int
msg;
// mensagem a enviar
15
// abre a fila de mensagens, se existir

if((queue = mq_open (QUEUE, O_RDWR)) < 0)
{
perror ("mq_open");
exit (1);
}
16
17
18
19
20
21
22
for (;;)
{
msg = random() % 100 ; // valor entre 0 e 99
23
24
25
26
// envia a mensagem
if (mq_send (queue, (void*) &msg, sizeof(msg), 0) < 0)
{
perror ("mq_send");
exit (1);
}
printf ("Sent message with value %d\n", msg);
sleep (1) ;
27
28
29
30
31
32
33
34
35
36
O produtor de mensagens deve ser executado aps o consumidor, pois

este ltimo quem cria a fila de mensagens. Deve-se observar tambm
que o arquivo /fila referenciado em ambas as listagens serve unicamente
como identificador comum para a fila de mensagens; nenhum arquivo de
dados com esse nome ser criado pelo sistema. As mensagens no transitam
por arquivos, apenas pela memria do ncleo. Referncias de recursos
atravs de nomes de arquivos so frequentemente usadas para identificar
c Carlos Maziero
97
3: Pipes
vrios mecanismos de comunicao e coordenao em UNIX, como filas

de mensagens, semforos e reas de memria compartilhadas (vide Seo
3.4.3).
3.4.2
Pipes
Um dos mecanismos de comunicao entre processos mais simples de

usar no ambiente UNIX o pipe, ou tubo. Na interface de linha de comandos,
o pipe frequentemente usado para conectar a sada padro (stdout) de um
comando entrada padro (stdin) de outro comando, permitindo assim a
comunicao entre eles. A linha de comando a seguir traz um exemplo do
uso de pipes:
# who | grep marcos | sort > login-marcos.txt
A sada do comando who uma listagem de usurios conectados ao
computador. Essa sada encaminhada atravs de um pipe (indicado pelo
caractere |) ao comando grep, que a filtra e gera como sada somente as
linhas contendo a string marcos. Essa sada encaminhada atravs de
outro pipe ao comando sort, que ordena a listagem recebida e a deposita
no arquivo login-marcos.txt. Deve-se observar que todos os processos
envolvidos so lanados simultaneamente; suas aes so coordenadas pelo
comportamento sncrono dos pipes. A Figura 3.11 detalha essa sequncia de
aes.
who
stdin
stdout
pipe
grep
stdout
stdin
sort
stdout
pipe
ncleo
arquivo
Figura 3.11: Comunicao atravs de pipes.

O pipe um canal de comunicao unidirecional entre dois processos
(1:1), com capacidade finita (os pipes do Linux armazenam 4 KBytes por
c Carlos Maziero
98
3: Memria compartilhada
default), visto pelos processos como um arquivo, ou seja, a comunicao que

ele oferece baseada em fluxo. O envio e recepo de dados so feitos pelas
chamadas de sistema write e read, que podem operar em modo sncrono
(bloqueante, por default) ou assncrono.
O uso de pipes na linha de comando simples, mas seu uso na construo
de programas pode ser complexo. Vrios exemplos do uso de pipes UNIX na
construo de programas so apresentados em [Robbins and Robbins, 2003].
3.4.3
Memria compartilhada
A comunicao entre tarefas situadas em processos distintos deve ser

feita atravs do ncleo, usando chamadas de sistema, porque no existe
a possibilidade de acesso a variveis comuns a ambos. No entanto, essa
abordagem pode ser ineficiente caso a comunicao seja muito volumosa
e frequente, ou envolva muitos processos. Para essas situaes, seria
conveniente ter uma rea de memria comum que possa ser acessada direta
e rapidamente pelos processos interessados, sem o custo da intermediao
pelo ncleo.
A maioria dos sistemas operacionais atuais oferece mecanismos para
o compartilhamento de reas de memria entre processos (shared memory
areas). As reas de memria compartilhadas e os processos que as utilizam
so gerenciados pelo ncleo, mas o acesso ao contedo de cada rea feito
diretamente pelos processos, sem intermediao ou coordenao do ncleo.
Por essa razo, mecanismos de coordenao (apresentados no Captulo 4)
podem ser necessrios para garantir a consistncia dos dados armazenados
nessas reas.
A criao e uso de uma rea de memria compartilhada entre dois
processos pa e pb em um sistema UNIX pode ser resumida na seguinte
sequncia de passos, ilustrada na Figura 3.12:
1. O processo pa solicita ao ncleo a criao de uma rea de memria
compartilhada, informando o tamanho e as permisses de acesso; o
retorno dessa operao um identificador (id) da rea criada.
2. O processo pa solicita ao ncleo que a rea recm-criada seja anexada ao
seu espao de endereamento; esta operao retorna um ponteiro para
a nova rea de memria, que pode ento ser acessada pelo processo.
c Carlos Maziero
99
pa
pb
nova rea de
memria
passo 1)
criar
alocar
id
ncleo
reas alocadas
pa
pb
passos 2 e 3)
anexar
ptr
obter
id
ncleo
pa
passos 4 e 5)
pb
usar
usar
ptr
anexar
ncleo
Figura 3.12: Criao e uso de uma rea de memria compartilhada.

3. O processo pb obtm o identificador id da rea de memria criada por
pa .
4. O processo pb solicita ao ncleo que a rea de memria seja anexada
ao seu espao de endereamento e recebe um ponteiro para o acesso
mesma.
5. Os processos pa e pb acessam a rea de memria compartilhada atravs
dos ponteiros informados pelo ncleo.
c Carlos Maziero
100
Deve-se observar que, ao solicitar a criao da rea de memria compartilhada, pa define as permisses de acesso mesma; por isso, o pedido de
anexao da rea de memria feito por pb pode ser recusado pelo ncleo, se
violar as permisses definidas por pa . A Listagem 3.1 exemplifica a criao
e uso de uma rea de memria compartilhada, usando o padro POSIX
(exemplos de implementao no padro System V podem ser encontrados
em [Robbins and Robbins, 2003]). Para compil-lo em Linux necessrio
efetuar a ligao com a biblioteca de tempo-real POSIX, usando a opo
-lrt. Para melhor observar seu funcionamento, devem ser lanados dois ou
mais processos executando esse cdigo simultaneamente.
c Carlos Maziero
101
Listagem 3.1: Memria Compartilhada

1
2
// Arquivo shmem.c: cria e usa uma rea de memria compartilhada.

// Em Linux, compile usando: cc -o shmem -lrt shmem.c
3
4
5
6
7
8
#include
#include
#include
#include
#include
<stdio.h>
<stdlib.h>
<fcntl.h>
<sys/stat.h>
<sys/mman.h>
10
11
12

{
int fd, value, *ptr;
13
14
15
16
17
18
19
// Passos 1 a 3: abre/cria uma area de memoria compartilhada

fd = shm_open("/sharedmem", O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
if(fd == -1) {
perror ("shm_open");
exit (1) ;
}
20
21
22
23
24
25
// Passos 1 a 3: ajusta o tamanho da area compartilhada

if (ftruncate(fd, sizeof(value)) == -1) {
perror ("ftruncate");
exit (1) ;
}
26
27
28
29
30
31
32
// Passos 2 a 4: mapeia a area no espaco de enderecamento deste processo

ptr = mmap(NULL, sizeof(value), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
if(ptr == MAP_FAILED) {
perror ("mmap");
exit (1);
}
33
34
35
36
37
38
39
for (;;) {
// Passo 5: escreve um valor aleatorio na area compartilhada
value = random () % 1000 ;
(*ptr) = value ;
printf ("Wrote value %i\n", value) ;
sleep (1);
40
41
42
43
44
// Passo 5: le e imprime o conteudo da area compartilhada

value = (*ptr) ;
printf("Read value %i\n", value);
sleep (1) ;
Captulo 4
Coordenao entre tarefas
Muitas implementaes de sistemas complexos so estruturadas
como vrias tarefas inter-dependentes, que cooperam entre si para
atingir os objetivos da aplicao, como por exemplo em um navegador
Web. Para que as vrias tarefas que compem uma aplicao possam
cooperar, elas precisam comunicar informaes umas s outras e
coordenar suas atividades, para garantir que os resultados obtidos
sejam coerentes. Este mdulo apresenta os principais conceitos,
problemas e solues referentes coordenao entre tarefas.
4.1
Objetivos
Em um sistema multi-tarefas, vrias tarefas podem executar simultaneamente, acessando recursos compartilhados como reas de memria,
arquivos, conexes de rede, etc. Neste captulo sero estudados os problemas que podem ocorrer quando duas ou mais tarefas acessam os mesmos
recursos de forma concorrente; tambm sero apresentadas as principais
tcnicas usadas para coordenar de forma eficiente os acessos das tarefas aos
recursos compartilhados.
4.2
Condies de disputa
Quando duas ou mais tarefas acessam simultaneamente um recurso

compartilhado, podem ocorrer problemas de consistncia dos dados ou do
estado do recurso acessado. Esta seo descreve detalhadamente a origem
c Carlos Maziero
103
4: Condies de disputa
dessas inconsistncias, atravs de um exemplo simples, mas que permite

ilustrar claramente o problema.
O cdigo apresentado a seguir implementa de forma simplificada a
operao de depsito (funo depositar) de um valor em uma conta
bancria informada como parmetro. Para facilitar a compreenso do cdigo
de mquina apresentado na sequncia, todos os valores manipulados so
inteiros.
1
2
3
4
5
typedef struct conta_t

{
int saldo ;
// saldo atual da conta
...
// outras informaes da conta
} conta_t ;
6
7
8
9
10
void depositar (conta_t* conta, int valor)

{
conta->saldo += valor ;
}
Aps a compilao em uma plataforma Intel i386, a funo depositar

assume a seguinte forma em cdigo de mquina (nos comentrios ao lado
do cdigo, regi um registrador e mem(x) a posio de memria onde est
armazenada a varivel x):
00000000 <depositar>:
push %ebp
# guarda o valor do "stack frame"
mov %esp,%ebp
# ajusta o stack frame para executar a funo
mov
mov
mov
add
mov
0x8(%ebp),%ecx
0x8(%ebp),%edx
0xc(%ebp),%eax
(%edx),%eax
%eax,(%ecx)
leave
ret
#
#
#
#
#
mem(saldo)
mem(saldo)
mem(valor)
[reg1 , reg2 ]
[reg1 , reg2 ]
reg1
reg2
reg3
+ reg3 [reg1 , reg2 ]
mem(saldo)
# restaura o stack frame anterior

# retorna funo anterior
Considere que a funo depositar faz parte de um sistema mais amplo

de controle de contas bancrias, que pode ser acessado simultaneamente
por centenas ou milhares de usurios em terminais distintos. Caso dois
clientes em terminais diferentes tentem depositar valores na mesma conta
c Carlos Maziero
104
ao mesmo tempo, existiro duas tarefas acessando os dados (variveis) da

conta de forma concorrente. A Figura 4.1 ilustra esse cenrio.
aplicao
depositar
R$50
tarefa 1
tarefa 2
depositar
depositar
depositar
R$1000
conta
terminal 1
terminal 2
saldo inicial
R$0
Figura 4.1: Acessos concorrentes a variveis compartilhadas.

O comportamento dinmico da aplicao pode ser modelado atravs de
diagramas de tempo. Caso o depsito da tarefa t1 execute integralmente
antes ou depois do depsito efetuado por t2 , teremos os diagramas de
tempo da Figura 4.2. Em ambas as execues o saldo inicial da conta passou
de R$ 0,00 para R$ 1050,00, conforme esperado.
t2
t1
t2
t1
saldo: R$ 0
saldo: R$ 0
reg1 = mem(saldo)
reg1 = mem(saldo)
reg2 = mem(valor)
reg2 = mem(valor)
reg1 = reg1 + reg2
reg1 = reg1 + reg2

mem(saldo) = reg1
mem(saldo) = reg1
saldo: R$ 1000
saldo: R$ 50
reg1 = mem(saldo)
reg1 = mem(saldo)
reg2 = mem(valor)
reg2 = mem(valor)
reg1 = reg1 + reg2
reg1 = reg1 + reg2
mem(saldo) = reg1
mem(saldo) = reg1
saldo: R$ 1050
t
saldo: R$ 1050
t
Figura 4.2: Operaes de depsitos no-concorrentes.

No entanto, caso as operaes de depsito de t1 e de t2 se entrelacem,
podem ocorrer interferncias entre ambas, levando a resultados incorretos.
Em sistemas mono-processados, a sobreposio pode acontecer caso ocorram
c Carlos Maziero
105
trocas de contexto durante a execuo do depsito. Em sistemas multiprocessados a situao ainda mais complexa, pois cada tarefa poder estar
executando em um processador distinto.
Os diagramas de tempo apresentados na Figura 4.3 mostram execues
onde houve entrelaamento das operaes de depsito de t1 e de t2 . Em
ambas as execues o saldo final no corresponde ao resultado esperado,
pois um dos depsitos perdido. No caso, apenas concretizado o depsito
da tarefa que realizou a operao mem(saldo) reg1 por ltimo1 .
t2
t1
t2
t1
saldo: R$ 0
saldo: R$ 0
reg1 = mem(saldo)
reg1 = mem(saldo)
reg1 = mem(saldo)
reg1 = mem(saldo)
reg2 = mem(valor)
reg2 = mem(valor)
reg2 = mem(valor)
reg2 = mem(valor)
reg1 = reg1 + reg2
reg1 = reg1 + reg2

reg1 = reg1 + reg2
reg1 = reg1 + reg2
mem(saldo) = reg1
mem(saldo) = reg1
saldo: R$ 50
saldo: R$ 1000
mem(saldo) = reg1
mem(saldo) = reg1
saldo: R$ 1000
t
saldo: R$ 50
t
Figura 4.3: Operaes de depsito concorrentes.

Os erros e inconsistncias gerados por acessos concorrentes a dados compartilhados, como os ilustrados na Figura 4.3, so denominados condies
de disputa, ou condies de corrida (do ingls race conditions). Condies
de disputa podem ocorrer em qualquer sistema onde vrias tarefas (processos ou threads) acessam de forma concorrente recursos compartilhados
(variveis, reas de memria, arquivos abertos, etc.). Finalmente, condies
de disputa somente existem caso ao menos uma das operaes envolvidas
seja de escrita; acessos de leitura concorrentes entre si no geram condies
de disputa.
1
No h problema em ambas as tarefas usarem os mesmos registradores reg1 e reg2 ,

pois os valores de todos os registradores so salvos/restaurados a cada troca de contexto
entre tarefas.
c Carlos Maziero
106
4: Sees crticas
importante observar que condies de disputa so erros dinmicos, ou

seja, que no aparecem no cdigo fonte e que s se manifestam durante a
execuo, sendo dificilmente detectveis atravs da anlise do cdigo fonte.
Alm disso, erros dessa natureza no se manifestam a cada execuo, mas
apenas quando certos entrelaamentos ocorrerem. Assim, uma condio
de disputa poder permanecer latente no cdigo durante anos, ou mesmo
nunca se manifestar. A depurao de programas contendo condies de
disputa pode ser muito complexa, pois o problema s se manifesta com
acessos simultneos aos mesmos dados, o que pode ocorrer raramente e ser
difcil de reproduzir durante a depurao. Por isso, importante conhecer
tcnicas que previnam a ocorrncia de condies de disputa.
4.3
Sees crticas
Na seo anterior vimos que tarefas acessando dados compartilhados

de forma concorrente podem ocasionar condies de disputa. Os trechos de
cdigo de cada tarefa que acessam dados compartilhados so denominados
sees crticas (ou regies crticas). No caso da Figura 4.1, as sees crticas
das tarefas t1 e t2 so idnticas e resumidas seguinte linha de cdigo:
1
conta.saldo += valor ;
De modo geral, sees crticas so todos os trechos de cdigo que manipulam dados compartilhados onde podem ocorrer condies de disputa.
Um programa pode ter vrias sees crticas, relacionadas entre si ou no
(caso manipulem dados compartilhados distintos). Para assegurar a correo de uma implementao, deve-se impedir o entrelaamento de sees
crticas: apenas uma tarefa pode estar na seo crtica a cada instante. Essa
propriedade conhecida como excluso mtua.
Diversos mecanismos podem ser definidos para impedir o entrelaamento de sees crticas e assim prover a excluso mtua. Todos eles exigem
que o programador defina os limites (incio e o final) de cada seo crtica.
Genericamente, cada seo crtica i pode ser associada a um identificador
csi e so definidas as primitivas enter(ta , csi ), para que a tarefa ta indique que
deseja entrar na seo crtica csi , e leave(ta , csi ), para que ta informe que est
saindo da seo crtica csi . A primitiva enter(csi ) bloqueante: caso uma
tarefa j esteja ocupando a seo crtica csi , as demais tarefas que tentarem
c Carlos Maziero
107
4: Sees crticas
entrar devero aguardar at que a primeira libere a seo crtica, atravs da

primitiva leave(csi ).
Usando as primitivas enter e leave, o cdigo da operao de depsito
visto na Seo 4.2 pode ser reescrito como segue:
1
2
3
4
5
6

{
int saldo ;
int numero ;
...
} conta_t ;

// identificao da conta (seo crtica)
7
8
9
10
11
12
13
void depositar (conta_t*

{
enter (conta->numero)
conta->saldo += valor
leave (conta->numero)
}
conta, int valor)

; // tenta entrar na seo crtica
; // est na seo crtica
; // sai da seo crtica
Nas prximas sees sero estudadas vrias solues para a implementao das primitivas enter e leave, bem como abordagens alternativas.
As solues propostas devem atender a alguns critrios bsicos que so
enumerados a seguir:
Excluso mtua : somente uma tarefa pode estar dentro da seo crtica
em cada instante.
Espera limitada : uma tarefa que aguarda acesso a uma seo crtica deve
ter esse acesso garantido em um tempo finito.
Independncia de outras tarefas : a deciso sobre o uso de uma seo
crtica deve depender somente das tarefas que esto tentando entrar
na mesma. Outras tarefas do sistema, que no momento no estejam
interessadas em entrar na regio crtica, no podem ter influncia
sobre essa deciso.
Independncia de fatores fsicos : a soluo deve ser puramente lgica e
no depender da velocidade de execuo das tarefas, de temporizaes,
do nmero de processadores no sistema ou de outros fatores fsicos.
c Carlos Maziero
108
4.4
4: Inibio de interrupes
Inibio de interrupes
Uma soluo simples para a implementao das primitivas enter e leave

consiste em impedir as trocas de contexto dentro da seo crtica. Ao entrar
em uma seo crtica, a tarefa desativa (mascara) as interrupes que possam
provocar trocas de contexto, e as reativa ao sair da seo crtica. Apesar de
simples, essa soluo raramente usada para a construo de aplicaes
devido a vrios problemas:
Ao desligar as interrupes, a preempo por tempo ou por recursos
deixa de funcionar; caso a tarefa entre em um lao infinito dentro
da seo crtica, o sistema inteiro ser bloqueado. Uma tarefa malintencionada pode forar essa situao e travar o sistema.
Enquanto as interrupes esto desativadas, os dispositivos de entrada/sada deixam de ser atendidos pelo ncleo, o que pode causar
perdas de dados ou outros problemas. Por exemplo, uma placa de
rede pode perder novos pacotes se seus buffers estiverem cheios e no
forem tratados pelo ncleo em tempo hbil.
A tarefa que est na seo crtica no pode realizar operaes de
entrada/sada, pois os dispositivos no iro responder.
Esta soluo s funciona em sistemas mono-processados; em uma mquina multi-processada ou multi-core, duas tarefas concorrentes podem
executar simultaneamente em processadores separados, acessando a
seo crtica ao mesmo tempo.
Devido a esses problemas, a inibio de interrupes uma operao
privilegiada e somente utilizada em algumas sees crticas dentro do ncleo
do sistema operacional e nunca pelas aplicaes.
4.5
Solues com espera ocupada
Uma primeira classe de solues para o problema da excluso mtua

no acesso a sees crticas consiste em testar continuamente uma condio
que indica se a seo desejada est livre ou ocupada. Esta seo apresenta
algumas solues clssicas usando essa abordagem.
c Carlos Maziero
109
4.5.1
4: A soluo bvia
A soluo bvia
Uma soluo aparentemente trivial para o problema da seo crtica

consiste em usar uma varivel busy para indicar se a seo crtica desejada
est livre ou ocupada. Usando essa abordagem, a implementao das
primitivas enter e leave poderia ser escrita assim:
1
int busy = 0 ;
// a seo est inicialmente livre
2
3
4
5
6
7
void enter (int task)

{
while (busy) ;
// espera enquanto a seo estiver ocupada
busy = 1 ;
// marca a seo como ocupada
}
8
9
10
11
12
void leave (int task)

{
busy = 0 ;
// libera a seo (marca como livre)
}
Infelizmente, essa soluo bvia e simples no funciona! Seu grande

defeito que o teste da varivel busy (na linha 5) e sua atribuio (na linha 6)
so feitos em momentos distintos; caso ocorra uma troca de contexto entre as
linhas 5 e 6 do cdigo, poder ocorrer uma condio de disputa envolvendo
a varivel busy, que ter como consequncia a violao da excluso mtua:
duas ou mais tarefas podero entrar simultaneamente na seo crtica (vide
o diagrama de tempo da Figura 4.4). Em outras palavras, as linhas 5 e 6 da
implementao tambm formam uma seo crtica, que deve ser protegida.
4.5.2
Alternncia de uso
Outra soluo simples para a implementao das primitivas enter e leave

consiste em definir uma varivel turno, que indica de quem a vez de entrar
na seo crtica. Essa varivel deve ser ajustada cada vez que uma tarefa sai
da seo crtica, para indicar a prxima tarefa a us-la. A implementao
das duas primitivas fica assim:
c Carlos Maziero
110
4: Alternncia de uso
t2
t1
busy: 0
while(busy) { };
while(busy) { };
busy: 0
busy = 1
busy: 1
busy = 1
acesso
seo crtica
busy: 1
acesso
seo crtica
violao da
excluso
mtua !
t
Figura 4.4: Condio de disputa no acesso varivel busy.

1
2
int turn = 0 ;
int num_tasks ;
3
4
5
6
7

{
while (turn != task) ;
}
// task vale 0, 1, ..., num_tasks-1

// a tarefa espera seu turno
8
9
10
11
12
13
14
15

{
if (turn < num_tasks-1) // o turno da prxima tarefa
turn ++ ;
else
turn = 0 ;
// volta primeira tarefa
}
Nessa soluo, cada tarefa aguarda seu turno de usar a seo crtica, em
uma sequncia circular: t0 t1 t2 tn1 t0 . Essa abordagem
garante a excluso mtua entre as tarefas e independe de fatores externos,
mas no atende os demais critrios: caso uma tarefa ti no deseje usar a
seo crtica, todas as tarefas t j com j > i ficaro impedidas de faz-lo, pois
a varivel turno no ir evoluir.
c Carlos Maziero
111
4.5.3
4: O algoritmo de Peterson
O algoritmo de Peterson
Uma soluo correta para a excluso mtua no acesso a uma seo crtica
por duas tarefas foi proposta inicialmente por Dekker em 1965. Em 1981,
Gary Peterson props uma soluo mais simples e elegante para o mesmo
problema [Raynal, 1986]. O algoritmo de Peterson pode ser resumido no
cdigo a seguir:
int turn = 0 ;
// indica de quem a vez
int wants[2] = {0, 0} ; // indica se a tarefa i quer acessar a seo crtic
1
2
3

// task pode valer 0 ou 1
{
int other = 1 - task ; // indica a outra tarefa
wants[task] = 1 ;
// task quer acessar a seo crtica
turn = task ;
while ((turn == task) && wants[other]) ; // espera ocupada
}
4
5
6
7
8
9
10
11

{
wants[task] = 0 ;
}
12
13
14
15
// task libera a seo crtica
Os algoritmos de Dekker e de Peterson foram desenvolvidos para garantir

a excluso mtua entre duas tarefas, garantindo tambm o critrio de espera
limitada2 . Diversas generalizaes para n tarefas podem ser encontradas
na literatura [Raynal, 1986], sendo a mais conhecida delas o algoritmo da
padaria, proposto por Leslie Lamport [Lamport, 1974].
4.5.4
Instrues Test-and-Set
O uso de uma varivel busy para controlar a entrada em uma seo

crtica uma idia interessante, que infelizmente no funciona porque o
teste da varivel busy e seu ajuste so feitos em momentos distintos do
cdigo, permitindo condies de corrida.
2
Este algoritmo pode falhar quando usado em algumas mquinas multi-ncleo ou

multi-processadas, pois algumas arquiteturas permitem acesso fora de ordem memria,
ou seja, permitem que operaes de leitura na memria se antecipem a operaes de escrita
executadas posteriormente, para obter mais desempenho. Este o caso dos processadores
Pentium e AMD.
c Carlos Maziero
112
4: Instrues Test-and-Set
Para resolver esse problema, projetistas de hardware criaram instrues

em cdigo de mquina que permitem testar e atribuir um valor a uma
varivel de forma atmica ou indivisvel, sem possibilidade de troca de
contexto entre essas duas operaes. A execuo atmica das operaes de
teste e atribuio (Test & Set instructions) impede a ocorrncia de condies
de disputa. Uma implementao bsica dessa idia est na instruo
de mquina Test-and-Set Lock (TSL), cujo comportamento descrito pelo
seguinte pseudo-cdigo (que executado atomicamente pelo processador):
TSL(x) :
old x
x1
return(old)
A implementao das primitivas enter e leave usando a instruo TSL

assume a seguinte forma:
1
int lock = 0 ;
// varivel de trava
2
3
4
5
6
void enter (int *lock)

// passa o endereo da trava
{
while ( TSL (*lock) ) ; // espera ocupada
}
7
8
9
10
11
void leave (int *lock)

{
(*lock) = 0 ;
}
// libera a seo crtica
Outros processadores oferecem uma instruo que efetua a troca atmica

de contedo (swapping) entre dois registradores, ou entre um registrador
e uma posio de memria. No caso da famlia de processadores Intel
i386 (incluindo o Pentium e seus sucessores), a instruo de troca se chama
XCHG (do ingls exchange) e sua funcionalidade pode ser resumida assim:
XCHG op1 , op2 : op1 op2
A implementao das primitivas enter e leave usando a instruo XCHG
um pouco mais complexa:
c Carlos Maziero
113
1
int lock ;
4: Problemas
// varivel de trava
2
3
4
5
6
7
8
enter (int *lock)

{
int key = 1 ;
while (key)
XCHG (lock, &key) ;
}
// varivel auxiliar (local)

// espera ocupada
// alterna valores de lock e key
9
10
11
12
13
leave (int *lock)

{
(*lock) = 0 ;
}
// libera a seo crtica
Os mecanismos de excluso mtua usando instrues atmicas no

estilo TSL so amplamente usados no interior do sistema operacional, para
controlar o acesso a sees crticas internas do ncleo, como descritores de
tarefas, buffers de arquivos ou de conexes de rede, etc. Nesse contexto, eles
so muitas vezes denominados spinlocks. Todavia, mecanismos de espera
ocupada so inadequados para a construo de aplicaes de usurio, como
ser visto a seguir.
4.5.5
Problemas
Apesar das solues para o problema de acesso seo crtica usando espera ocupada garantirem a excluso mtua, elas sofrem de alguns problemas
que impedem seu uso em larga escala nas aplicaes de usurio:
Ineficincia : as tarefas que aguardam o acesso a uma seo crtica ficam
testando continuamente uma condio, consumindo tempo de processador sem necessidade. O procedimento adequado seria suspender
essas tarefas at que a seo crtica solicitada seja liberada.
Injustia : no h garantia de ordem no acesso seo crtica; dependendo
da durao de quantum e da poltica de escalonamento, uma tarefa
pode entrar e sair da seo crtica vrias vezes, antes que outras tarefas
consigam acess-la.
Por estas razes, as solues com espera ocupada so pouco usadas
na construo de aplicaes. Seu maior uso se encontra na programao
de estruturas de controle de concorrncia dentro do ncleo do sistema
c Carlos Maziero
114
4: Semforos
operacional (onde se chamam spinlocks), e na construo de sistemas de

computao dedicados, como controladores embarcados mais simples.
4.6
Semforos
Em 1965, o matemtico holands E. Dijkstra props um mecanismo

de coordenao eficiente e flexvel para o controle da excluso mtua
entre n tarefas: o semforo [Raynal, 1986]. Apesar de antigo, o semforo
continua sendo o mecanismo de sincronizao mais utilizado na construo
de aplicaes concorrentes, sendo usado de forma explcita ou implcita
(na construo de mecanismos de coordenao mais abstratos, como os
monitores).
Um semforo pode ser visto como uma varivel s, que representa uma
seo crtica e cujo contedo no diretamente acessvel ao programador.
Internamente, cada semforo contm um contador inteiro s.counter e uma
fila de tarefas s.queue, inicialmente vazia. Sobre essa varivel podem ser
aplicadas duas operaes atmicas, descritas a seguir:
Down(s) : usado para solicitar acesso seo crtica associada a s. Caso a
seo esteja livre, a operao retorna imediatamente e a tarefa pode
continuar sua execuo; caso contrrio, a tarefa solicitante suspensa
e adicionada fila do semforo; o contador associado ao semforo
decrementado3 . Dijkstra denominou essa operao P(s) (do holands
probeer, que significa tentar).
Down(s): // a executar de forma atmica
s.counter s.counter 1
if s.counter < 0 then
pe a tarefa corrente no final de s.queue
suspende a tarefa corrente
end if
Up(s) : invocado para liberar a seo crtica associada a s; o contador
associado ao semforo incrementado. Caso a fila do semforo
no esteja vazia, a primeira tarefa da fila acordada, sai da fila do
3
Alguns sistemas implementam tambm a chamada TryDown(s), cuja semntica nobloqueante: caso o semforo solicitado esteja ocupado, a chamada retorna imediatamente,
com um cdigo de erro.
c Carlos Maziero
115
4: Semforos
semforo e volta fila de tarefas prontas para retomar sua execuo.

Essa operao foi inicialmente denominada V(s) (do holands verhoog,
que significa incrementar). Deve-se observar que esta chamada no
bloqueante: a tarefa no precisa ser suspensa ao execut-la.
Up(s): // a executar de forma atmica
s.counter s.counter + 1
if s.counter 0 then
retira a primeira tarefa t de s.queue
devolve t fila de tarefas prontas (ou seja, acorda t)
end if
As operaes de acesso aos semforos so geralmente implementadas
pelo ncleo do sistema operacional, na forma de chamadas de sistema.
importante observar que a execuo das operaes Down(s) e Up(s)
deve ser atmica, ou seja, no devem ocorrer acessos concorrentes s
variveis internas do semforo, para evitar condies de disputa sobre as
mesmas. Para garantir a atomicidade dessas operaes em um sistema
monoprocessador, seria suficiente inibir as interrupes durante a execuo
das mesmas; no caso de sistemas com mais de um ncleo, torna-se necessrio
usar outros mecanismos de controle de concorrncia, como operaes TSL,
para proteger a integridade interna do semforo. Nestes casos, a espera
ocupada no constitui um problema, pois a execuo dessas operaes
muito rpida.
Usando semforos, o cdigo de depsito em conta bancria apresentado
na Seo 4.2 poderia ser reescrito da seguinte forma:
1
2
3
4
5
6

{
int saldo ;
sem_t s = 1;
...
} conta_t ;

// semforo associado conta, valor inicial 1
7
8
9
10
11
12
13
void depositar (conta_t * conta, int valor)

{
down (conta->s) ;
// solicita acesso conta
conta->saldo += valor ; // seo crtica
up (conta->s) ;
// libera o acesso conta
}
c Carlos Maziero
116
4: Semforos
A suspenso das tarefas que aguardam o acesso seo crtica elimina

a espera ocupada, o que torna esse mecanismo mais eficiente no uso do
processador que os anteriores. A fila de tarefas associada ao semforo
contm todas as tarefas que foram suspensas ao solicitar acesso seo
crtica usando a chamada Down(s). Como a fila obedece uma poltica
FIFO, garante-se a tambm a justia no acesso seo crtica, pois todos
os processos que aguardam no semforo sero atendidos em sequncia4 .
Por sua vez, o valor inteiro associado ao semforo funciona como um
contador de recursos: caso seja positivo, indica quantas instncias daquele
recurso esto disponveis. Caso seja negativo, indica quantas tarefas esto
aguardando para usar aquele recurso. Seu valor inicial permite expressar
diferentes situaes de sincronizao, como ser visto na Seo 4.9.
A listagem a seguir apresenta um exemplo hipottico de uso de um
semforo para controlar o acesso a um estacionamento. O valor inicial
do semforo vagas representa o nmero de vagas inicialmente livres no
estacionamento (500). Quando um carro deseja entrar no estacionamento ele
solicita uma vaga; enquanto o semforo for positivo no havero bloqueios,
pois h vagas livres. Caso no existam mais vagas livres, a chamada
carro_entra() ficar bloqueada at que alguma vaga seja liberada, o que
ocorre quando outro carro acionar a chamada carro_sai(). Esta soluo
simples pode ser aplicada a um estacionamento com vrias entradas e vrias
sadas simultneas.
sem_t vagas = 500 ;
1
2
void carro_entra ()
{
down (vagas) ;
...
}
3
4
5
6
7
// solicita uma vaga de estacionamento

// demais aes especficas da aplicao
void carro_sai ()
{
up (vagas) ;
...
}
9
10
11
12
13
// libera uma vaga de estacionamento

// demais aes especficas da aplicao
Algumas implementaes de semforos acordam uma tarefa aleatria da fila, no

necessariamente a primeira tarefa. Essas implementaes so chamadas de semforos fracos,
por no garantirem a justia no acesso seo crtica nem a ausncia de inanio (starvation)
de tarefas.
c Carlos Maziero
117
4: Semforos
A API POSIX define vrias chamadas para a criao e manipulao de

semforos. As chamadas mais frequentemente utilizadas esto indicadas a
seguir:
1
#include <semaphore.h>
2
3
4
// inicializa um semforo apontado por "sem", com valor inicial "value"

int sem_init(sem_t *sem, int pshared, unsigned int value);
5
6
7
// Operao Up(s)
int sem_post(sem_t *sem);
8
9
10
// Operao Down(s)
int sem_wait(sem_t *sem);
11
12
13
// Operao TryDown(s), retorna erro se o semforo estiver ocupado

int sem_trywait(sem_t *sem);
Os semforos nos quais o contador inteiro pode assumir qualquer valor

so denominados semforos genricos e constituem um mecanismo de
coordenao muito poderoso. No entanto, Muitos ambientes de programao, bibliotecas de threads e at mesmo ncleos de sistema provem
uma verso simplificada de semforos, na qual o contador s assume dois
valores possveis: livre (1) ou ocupado (0). Esses semforos simplificados so
chamados de mutexes (uma abreviao de mutual exclusion) ou semforos
binrios. Por exemplo, algumas das funes definidas pelo padro POSIX
[Gallmeister, 1994, Barney, 2005] para criar e usar mutexes so:
c Carlos Maziero
118
1
4: Variveis de condio
#include <pthread.h>
2
3
4
5
// inicializa uma varivel do tipo mutex, usando um struct de atributos

int pthread_mutex_init (pthread_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr);
6
7
8
// destri uma varivel do tipo mutex

int pthread_mutex_destroy (pthread_mutex_t *mutex);
9
10
11
12
// solicita acesso seo crtica protegida pelo mutex;

// se a seo estiver ocupada, bloqueia a tarefa
int pthread_mutex_lock (pthread_mutex_t *mutex);
13
14
15
16
// solicita acesso seo crtica protegida pelo mutex;

// se a seo estiver ocupada, retorna com status de erro
int pthread_mutex_trylock (pthread_mutex_t *mutex);
17
18
19
// libera o acesso seo crtica protegida pelo mutex

int pthread_mutex_unlock (pthread_mutex_t *mutex);
4.7
Variveis de condio
Alm dos semforos, outro mecanismo de sincronizao de uso frequente so as variveis de condio, ou variveis condicionais. Uma varivel
de condio no representa um valor, mas uma condio, que pode ser
aguardada por uma tarefa. Quando uma tarefa aguarda uma condio, ela
colocada para dormir at que a condio seja verdadeira. Assim, a tarefa
no precisa testar continuamente aquela condio, evitando uma espera
ocupada.
Uma tarefa aguardando uma condio representada pela varivel de
condio c pode ficar suspensa atravs do operador wait(c), para ser notificada mais tarde, quando a condio se tornar verdadeira. Essa notificao
ocorre quando outra tarefa chamar o operador notify(c) (tambm chamado
signal(c)). Por definio, uma varivel de condio c est sempre associada
a um semforo binrio c.mutex e a uma fila c.queue. O mutex garante a
excluso mtua sobre a condio representada pela varivel de condio,
enquanto a fila serve para armazenar em ordem as tarefas que aguardam
aquela condio.
c Carlos Maziero
119
4: Variveis de condio
Uma implementao hipottica5 para as operaes wait, notify e broadcast

(que notifica todas as tarefas na espera da condio) para uma tarefa t, seria
a seguinte:
wait (c):
c.queue t
unlock (c.mutex)
suspend (t)
lock (c.mutex)
1
2
3
4
5
//
//
//
//
coloca a tarefa t no fim de c.queue

libera o mutex
pe a tarefa atual para dormir
quando acordar, obtm o mutex imediatamente
notify (c):
awake (first (c.queue)) // acorda a primeira tarefa da fila c.queue
7
8
9
broadcast (c):
awake (c.queue)
10
11
// acorda todas as tarefas da fila c.queue
No exemplo a seguir, a tarefa A espera por uma condio que ser

sinalizada pela tarefa B. A condio de espera pode ser qualquer: um novo
dado em um buffer de entrada, a concluso de um procedimento externo, a
liberao de espao em disco, etc.
Task A ()
{
...
lock (c.mutex)
while (not condition)
wait (c) ;
...
unlock (c.mutex)
...
}
1
2
3
4
5
6
7
8
9
10
11
Task B ()
{
...
lock (c.mutex)
condition = true
notify (c)
unlock (c.mutex)
...
}
12
13
14
15
16
17
18
19
20
Assim como os operadores sobre semforos, os operadores sobre variveis de condio

tambm devem ser implementados de forma atmica.
c Carlos Maziero
120
4: Monitores
importante observar que na definio original de variveis de condio

(conhecida como semntica de Hoare), a operao notify(c) fazia com que
a tarefa notificadora perdesse imediatamente o semforo e o controle do
processador, que eram devolvidos primeira tarefa da fila de c. Como essa
semntica complexa de implementar e interfere diretamente no escalonador de processos, as implementaes modernas de variveis de condio
normalmente adotam a semntica Mesa [Lampson and Redell, 1980], proposta na linguagem de mesmo nome. Nessa semntica, a operao notify(c)
apenas acorda as tarefas que esperam pela condio, sem suspender a
execuo da tarefa corrente. Cabe ao programador garantir que a tarefa
corrente vai liberar o mutex e no vai alterar o estado associado varivel
de condio.
As variveis de condio esto presentes no padro POSIX, atravs de operadores como pthread_cond_wait, pthread_cond_signal e
pthread_cond_broadcast. O padro POSIX adota a semntica Mesa.
4.8
Monitores
Ao usar semforos, um programador define explicitamente os pontos de

sincronizao necessrios em seu programa. Essa abordagem eficaz para
programas pequenos e problemas de sincronizao simples, mas se torna
invivel e suscetvel a erros em sistemas mais complexos. Por exemplo, se
o programador esquecer de liberar um semforo previamente alocado, o
programa pode entrar em um impasse (vide Seo 4.10). Por outro lado, se
ele esquecer de requisitar um semforo, a excluso mtua sobre um recurso
pode ser violada.
Em 1972, os cientistas Per Brinch Hansen e Charles Hoare definiram
o conceito de monitor [Lampson and Redell, 1980]. Um monitor uma
estrutura de sincronizao que requisita e libera a seo crtica associada
a um recurso de forma transparente, sem que o programador tenha de se
preocupar com isso. Um monitor consiste de:
um recurso compartilhado, visto como um conjunto de variveis
internas ao monitor.
um conjunto de procedimentos que permitem o acesso a essas variveis;
c Carlos Maziero
121
4: Monitores
um mutex ou semforo para controle de excluso mtua; cada procedimento de acesso ao recurso deve obter o semforo antes de iniciar e
liberar o semforo ao concluir;
um invariante sobre o estado interno do recurso.
O pseudo-cdigo a seguir define um monitor para operaes sobre uma
conta bancria (observe sua semelhana com a definio de uma classe em
programao orientada a objetos):
1
2
3
monitor conta
{
float saldo = 0.0 ;
void depositar (float valor)

{
if (valor >= 0)
conta->saldo += valor ;
else
error ("erro: valor negativo\n") ;
}
5
6
7
8
9
10
11
12
void retirar (float saldo)

{
if (valor >= 0)
conta->saldo -= valor ;
else
error ("erro: valor negativo\n") ;
}
13
14
15
16
17
18
19
20
A definio formal de monitor prev e existncia de um invariante, ou

seja, uma condio sobre as variveis internas do monitor que deve ser
sempre verdadeira. No caso da conta bancria, esse invariante poderia
ser o seguinte: O saldo atual deve ser a soma de todos os depsitos efetuados e
todas as retiradas efetuadas (com sinal negativo). Entretanto, a maioria das
implementaes de monitor no suporta a definio de invariantes, com
exceo da linguagem Eiffel.
De certa forma, um monitor pode ser visto como um objeto que encapsula
o recurso compartilhado, com procedimentos (mtodos) para acess-lo. No
entanto, a execuo dos procedimentos feita com excluso mtua entre
eles. As operaes de obteno e liberao do semforo so inseridas automaticamente pelo compilador do programa em todos os pontos de entrada
c Carlos Maziero
122
4: Problemas clssicos de coordenao
e sada do monitor (no incio e final de cada procedimento), liberando o

programador dessa tarefa e assim evitando erros. Monitores esto presentes
em vrias linguagens, como Ada, C#, Eiffel, Java e Modula-3. O cdigo a
seguir mostra um exemplo simplificado de uso de monitor em Java:
1
2
3
class Conta
{
private float saldo = 0;
public synchronized void depositar (float valor)

{
if (valor >= 0)
saldo += valor ;
else
System.err.println("valor negativo");
}
5
6
7
8
9
10
11
12
public synchronized void retirar (float valor)

{
if (valor >= 0)
saldo -= valor ;
else
System.err.println("valor negativo");
}
13
14
15
16
17
18
19
20
Em Java, a clusula synchronized faz com que um semforo seja associado aos mtodos indicados, para cada objeto (ou para cada classe, se forem
mtodos de classe). No exemplo anterior, apenas um depsito ou retirada
de cada vez poder ser feito sobre cada objeto da classe Conta.
Variveis de condio podem ser usadas no interior de monitores (na
verdade, os dois conceitos nasceram juntos). Todavia, devido s restries
da semntica Mesa, um procedimento que executa a operao notify em
uma varivel de condio deve concluir e sair imediatamente do monitor,
para garantir que o invariante associado ao estado interno do monitor seja
respeitado [Birrell, 2004].
4.9
Problemas clssicos de coordenao
Algumas situaes de coordenao entre atividades ocorrem com muita

frequncia na programao de sistemas complexos. Os problemas clssicos de
c Carlos Maziero
123
4: O problema dos produtores/consumidores
coordenao retratam muitas dessas situaes e permitem compreender como

podem ser implementadas suas solues. Nesta seo sero estudados trs
problemas clssicos: o problema dos produtores/consumidores, o problema
dos leitores/escritores e o jantar dos filsofos. Diversos outros problemas
clssicos so frequentemente descritos na literatura, como o problema dos
fumantes e o do barbeiro dorminhoco, entre outros [Raynal, 1986, Ben-Ari, 1990].
Uma extensa coletnea de problemas de coordenao (e suas solues)
apresentada em [Downey, 2008] (disponvel online).
4.9.1
O problema dos produtores/consumidores
Este problema tambm conhecido como o problema do buffer limitado,

e consiste em coordenar o acesso de tarefas (processos ou threads) a um
buffer compartilhado com capacidade de armazenamento limitada a N itens
(que podem ser inteiros, registros, mensagens, etc.). So considerados dois
tipos de processos com comportamentos simtricos:
Produtor : periodicamente produz e deposita um item no buffer, caso o
mesmo tenha uma vaga livre. Caso contrrio, deve esperar at que
surja uma vaga no buffer. Ao depositar um item, o produtor consome
uma vaga livre.
Consumidor : continuamente retira um item do buffer e o consome; caso o
buffer esteja vazio, aguarda que novos itens sejam depositados pelos
produtores. Ao consumir um item, o consumidor produz uma vaga
livre.
Deve-se observar que o acesso ao buffer bloqueante, ou seja, cada
processo fica bloqueado at conseguir fazer seu acesso, seja para produzir
ou para consumir um item. A Figura 4.5 ilustra esse problema, envolvendo
vrios produtores e consumidores acessando um buffer com capacidade para
12 entradas. interessante observar a forte similaridade dessa figura com a
Figura 3.9; na prtica, a implementao de mailboxes e de pipes geralmente
feita usando um esquema de sincronizao produtor/consumidor.
A soluo do problema dos produtores/consumidores envolve trs
aspectos de coordenao distintos:
A excluso mtua no acesso ao buffer, para evitar condies de disputa
entre produtores e/ou consumidores que poderiam corromper seu
contedo.
c Carlos Maziero
124
4: O problema dos produtores/consumidores
c1
C
p1
buer
L
p2
c2
A
c3
Figura 4.5: O problema dos produtores/consumidores.

O bloqueio dos produtores no caso do buffer estar cheio: os produtores
devem aguardar at surjam vagas livres no buffer.
O bloqueio dos consumidores no caso do buffer estar vazio: os
consumidores devem aguardar at surjam novos itens a consumir no
buffer.
A soluo para esse problema exige trs semforos, um para atender
cada aspecto de coordenao acima descrito. O cdigo a seguir ilustra
de forma simplificada uma soluo para esse problema, considerando um
buffer com capacidade para N itens, inicialmente vazio:
c Carlos Maziero
125
1
2
3
4: O problema dos leitores/escritores
sem_t mutex ; // controla o acesso ao buffer (inicia em 1)

sem_t item ; // nmero de itens no buffer (inicia em 0)
sem_t vaga ; // nmero de vagas livres no buffer (inicia em N)
4
5
6
7
8
9
10
11
12
13
14
produtor () {
while (1) {
...
sem_down(&vaga) ;
sem_down(&mutex) ;
...
sem_up(&mutex) ;
sem_up(&item) ;
}
}
//
//
//
//
//
//
produz um item
aguarda uma vaga no buffer
aguarda acesso exclusivo ao buffer
deposita o item no buffer
libera o acesso ao buffer
indica a presena de um novo item no buffer
consumidor () {
while (1) {
sem_down(&item) ;
sem_down(&mutex) ;
...
sem_up(&mutex) ;
sem_up(&vaga) ;
...
}
}
//
//
//
//
//
//
aguarda um novo item no buffer

aguarda acesso exclusivo ao buffer
retira o item do buffer
libera o acesso ao buffer
indica a liberao de uma vaga no buffer
consome o item retirado do buffer
15
16
17
18
19
20
21
22
23
24
25
importante observar que essa soluo genrica, pois no depende do

tamanho do buffer, do nmero de produtores ou do nmero de consumidores.
4.9.2
O problema dos leitores/escritores
Outra situao que ocorre com frequncia em sistemas concorrentes

o problema dos leitores/escritores. Neste caso, um conjunto de processos
ou threads acessam de forma concorrente uma rea de memria comum
(compartilhada), na qual podem fazer leituras ou escritas de valores. As
leituras podem ser feitas simultaneamente, pois no interferem umas com
as outras, mas as escritas tm de ser feitas com acesso exclusivo rea
compartilhada, para evitar condies de disputa. No exemplo da Figura 4.6,
os leitores e escritores acessam de forma concorrente uma matriz de inteiros
M.
c Carlos Maziero
126
l1
M[3]?
e1
M[3]=2
M
3
e2
M=[2,1,0,6]
M?
1
l2
M[1]?
l3
escritores
leitores
Figura 4.6: O problema dos leitores/escritores.

Uma soluo trivial para esse problema consistiria em proteger o acesso
rea compartilhada com um semforo inicializado em 1; assim, somente
um processo por vez poderia acessar a rea, garantindo a integridade de
todas as operaes. O cdigo a seguir ilustra essa abordagem simplista:
1
sem_t mutex_area ;
// controla o acesso rea (inicia em 1)
2
3
4
5
6
7
8
9
10
leitor () {
while (1) {
sem_down (&mutex_area) ;
...
sem_up (&mutex_area) ;
...
}
}
// requer acesso exclusivo rea

// l dados da rea compartilhada
// libera o acesso rea
11
12
13
14
15
16
17
18
19
escritor () {
while (1) {
...
...
}
}

// escreve dados na rea compartilhada
c Carlos Maziero
127
Todavia, essa soluo deixa a desejar em termos de desempenho, porque

restringe desnecessariamente o acesso dos leitores rea compartilhada:
como a operao de leitura no altera os valores armazenados, no haveria
problema em permitir o acesso simultneo de vrios leitores rea compartilhada, desde que as escritas continuem sendo feitas de forma exclusiva.
Uma nova soluo para o problema, considerando a possibilidade de acesso
simultneo pelos leitores, seria a seguinte:
1
2
3
sem_t mutex_area ;
int conta_leitores = 0 ;
sem_t mutex_conta ;
// controla o acesso rea (inicia em 1)

// nmero de leitores acessando a rea
// controla o acesso ao contador (inicia em 1)
4
5
6
7
8
9
10
11
leitor () {
while (1) {
sem_down (&mutex_conta) ;
conta_leitores++ ;
if (conta_leitores == 1)
sem_up (&mutex_conta) ;
//
//
//
//
//
requer acesso exclusivo ao contador

incrementa contador de leitores
sou o primeiro leitor a entrar?
requer acesso rea
libera o contador
12
13
...
// l dados da rea compartilhada
sem_down (&mutex_conta) ;
conta_leitores-- ;
if (conta_leitores == 0)
sem_up (&mutex_conta) ;
...
//
//
//
//
//
14
15
16
17
18
19
20
21
22
requer acesso exclusivo ao contador

decrementa contador de leitores
sou o ltimo leitor a sair?
libera o acesso rea
libera o contador
23
24
25
26
27
28
29
30
31
escritor () {
while (1) {
sem_down(&mutex_area) ;
...
sem_up(&mutex_area) ;
...
}
}

// escreve dados na rea compartilhada
Essa soluo melhora o desempenho das operaes de leitura, mas

introduz um novo problema: a priorizao dos leitores. De fato, sempre
que algum leitor estiver acessando a rea compartilhada, outros leitores
c Carlos Maziero
128
4: O jantar dos filsofos
tambm podem acess-la, enquanto eventuais escritores tm de esperar at

a rea ficar livre (sem leitores). Caso existam muito leitores em atividade,
os escritores podem ficar impedidos de acessar a rea, pois ela nunca ficar
vazia. Solues com priorizao para os escritores e solues equitativas
entre ambos podem ser facilmente encontradas na literatura [Raynal, 1986,
Ben-Ari, 1990].
O relacionamento de sincronizao leitor/escritor encontrado com muita
frequncia em aplicaes com mltiplas threads. O padro POSIX define mecanismos para a criao e uso de travas com essa funcionalidade
(com priorizao de escritores), acessveis atravs de chamadas como
pthread_rwlock_init, entre outras.
4.9.3
O jantar dos filsofos
Um dos problemas clssicos de coordenao mais conhecidos o jantar dos filsofos, que foi inicialmente proposto por Dijkstra [Raynal, 1986,
Ben-Ari, 1990]. Neste problema, um grupo de cinco filsofos chineses alterna suas vidas entre meditar e comer. Na mesa h um lugar fixo para cada
filsofo, com um prato, cinco palitos (hashis ou chopsticks) compartilhados
e um grande prato de comida ao meio (na verso inicial de Dijkstra, os
filsofos compartilhavam garfos e comiam spaguetti). A Figura 4.7 ilustra
essa situao.
Para comer, um filsofo fi precisa pegar os palitos sua direita (pi ) e
sua esquerda (pi+1 ), um de cada vez. Como os palitos so compartilhados,
dois filsofos vizinhos nunca podem comer ao mesmo tempo. Os filsofos
no conversam entre si nem podem observar os estados uns dos outros.
O problema do jantar dos filsofos representativo de uma grande classe
de problemas de sincronizao entre vrios processos e vrios recursos
sem usar um coordenador central. A listagem a seguir representa uma
implementao do comportamento bsico dos filsofos, na qual cada palito
representado por um semforo:
c Carlos Maziero
129
4: O jantar dos filsofos
f4
p4
f3
p0
f0
p1
p3
f2
p2
f1
Figura 4.7: O jantar dos filsofos chineses.

1
2
#define NUMFILO 5
sem_t hashi [NUMFILO] ; // um semforo para cada palito (iniciam em 1)
3
4
5
6
7
8
9
10
11
12
13
filosofo (int i) {
while (1) {
medita () ;
sem_down (&hashi [i]) ;
sem_down (&hashi [(i+1) % NUMFILO]) ;
come () ;
sem_up (&hashi [i]) ;
sem_up (&hashi [(i+1) % NUMFILO]) ;
}
}
// obtem palito i
// obtem palito i+1
// devolve palito i
// devolve palito i+1
Resolver o problema do jantar dos filsofos consiste em encontrar uma

forma de coordenar suas atividades de maneira que todos os filsofos
consigam meditar e comer. As solues mais simples para esse problema
podem provocar impasses, nos quais todos os filsofos ficam bloqueados
(impasses sero estudados na Seo 4.10). Outras solues podem provocar
inanio (starvation), ou seja, alguns dos filsofos nunca conseguem comer. A
Figura 4.8 apresenta os filsofos em uma situao de impasse: cada filsofo
c Carlos Maziero
130
4: Impasses
obteve o palito sua direita e est aguardando o palito sua esquerda

(indicado pelas setas tracejadas). Como todos os filsofos esto aguardando,
ningum mais consegue executar.
f4
p4
p0
f3
f0
p3
p1
f2
p2
f1
Figura 4.8: Um impasse no jantar dos filsofos chineses.

Uma soluo trivial para o problema do jantar dos filsofos consiste em
colocar um saleiro hipottico sobre a mesa: quando um filsofo deseja
comer, ele deve pegar o saleiro antes de obter os palitos; assim que tiver
ambos os palitos, ele devolve o saleiro mesa e pode comer. Obviamente,
essa soluo serializa o acesso aos palitos e por isso tem baixo desempenho.
Imagine como essa soluo funcionaria em uma situao com 1000 filsofos
e 1000 palitos? Diversas outras solues podem ser encontradas na literatura
[Tanenbaum, 2003, Silberschatz et al., 2001].
4.10
Impasses
O controle de concorrncia entre tarefas acessando recursos compartilhados implica em suspender algumas tarefas enquanto outras acessam os
recursos, de forma a garantir a consistncia dos mesmos. Para isso, a cada
c Carlos Maziero
131
4: Impasses
recurso associado um semforo ou outro mecanismo equivalente. Assim,

as tarefas solicitam e aguardam a liberao de cada semforo para poder
acessar o recurso correspondente.
Em alguns casos, o uso de semforos pode levar a situaes de impasse (ou deadlock), nas quais todas as tarefas envolvidas ficam bloqueadas
aguardando a liberao de semforos, e nada mais acontece. Para ilustrar
uma situao de impasse, ser utilizado o exemplo de acesso a uma conta
bancria apresentado na Seo 4.2. O cdigo a seguir implementa uma
operao de transferncia de fundos entre duas contas bancrias. A cada
conta est associado um semforo, usado para prover acesso exclusivo aos
dados da conta e assim evitar condies de disputa:
1
2
3
4
5
6

{
int saldo ;
sem_t lock ;
...
} conta_t ;

// semforo associado conta
7
8
9
10
11
void transferir (conta_t* contaDeb, conta_t* contaCred, int valor)

{
sem_down (contaDeb->lock) ;
// obtm acesso a contaDeb
sem_down (contaCred->lock) ;
// obtm acesso a contCred
12
if (contaDeb->saldo >= valor)

{
contaDeb->saldo -= valor ;
contaCred->saldo += valor ;
}
sem_up (contaDeb->lock) ;
sem_up (contaCred->lock) ;
13
14
15
16
17
18
19
20
// debita valor de contaDeb

// credita valor em contaCred
// libera acesso a contaDeb
// libera acesso a contaCred
Caso dois clientes do banco (representados por duas tarefas t1 e t2 )

resolvam fazer simultaneamente operaes de transferncia entre suas
contas (t1 transfere um valor v1 de c1 para c2 e t2 transfere um valor v2 de c2
para c1 ), poder ocorrer uma situao de impasse, como mostra o diagrama
de tempo da Figura 4.9.
Nessa situao, a tarefa t1 detm o semforo de c1 e solicita o semforo
de c2 , enquanto t2 detm o semforo de c2 e solicita o semforo de c1 . Como
nenhuma das duas tarefas poder prosseguir sem obter o semforo desejado,
c Carlos Maziero
132
4: Caracterizao de impasses
t2
t1
sem_down (c1->lock)
(semforo obtido)
sem_down (c2->lock)
(semforo obtido)
sem_down (c2->lock)
sem_down (c1->lock)
impasse
t
Figura 4.9: Impasse entre duas transferncias.

nem poder liberar o semforo de sua conta antes de obter o outro semforo
e realizar a transferncia, se estabelece um impasse (ou deadlock).
Impasses so situaes muito frequentes em programas concorrentes,
mas tambm podem ocorrer em sistemas distribudos. Antes de conhecer
as tcnicas de tratamento de impasses, importante compreender suas
principais causas e saber caracteriz-los adequadamente, o que ser estudado
nas prximas sees.
4.10.1
Caracterizao de impasses
Em um impasse, duas ou mais tarefas se encontram bloqueadas, aguardando eventos que dependem somente delas, como a liberao de semforos.
Em outras palavras, no existe influncia de entidades externas em uma
situao de impasse. Alm disso, como as tarefas envolvidas detm alguns
recursos compartilhados (representados por semforos), outras tarefas que
vierem a requisit-los tambm ficaro bloqueadas, aumentando gradativamente o impasse, o que pode levar o sistema inteiro a parar de funcionar.
Formalmente, um conjunto de N tarefas se encontra em um impasse
se cada uma das tarefas aguarda um evento que somente outra tarefa do
conjunto poder produzir. Quatro condies fundamentais so necessrias
para que os impasses possam ocorrer [Coffman et al., 1971, Ben-Ari, 1990]:
c Carlos Maziero
133
4: Grafos de alocao de recursos
C1 Excluso mtua : o acesso aos recursos deve ser feito de forma mutuamente exclusiva, controlada por semforos ou mecanismos equivalentes. No exemplo da conta corrente, apenas uma tarefa por vez
pode acessar cada conta.
C2 Posse e espera : uma tarefa pode solicitar o acesso a outros recursos
sem ter de liberar os recursos que j detm. No exemplo da conta
corrente, cada tarefa detm o semforo de uma conta e solicita o
semforo da outra conta para poder prosseguir.
C3 No-preempo : uma tarefa somente libera os recursos que detm
quando assim o decidir, e no pode perd-los contra a sua vontade (ou
seja, o sistema operacional no retira os recursos j alocados s tarefas).
No exemplo da conta corrente, cada tarefa detm indefinidamente os
semforos que j obteve.
C4 Espera circular : existe um ciclo de esperas pela liberao de recursos
entre as tarefas envolvidas: a tarefa t1 aguarda um recurso retido pela
tarefa t2 (formalmente, t1 t2 ), que aguarda um recurso retido pela
tarefa t3 , e assim por diante, sendo que a tarefa tn aguarda um recurso
retido por t1 . Essa dependncia circular pode ser expressa formalmente
da seguinte forma: t1 t2 t3 tn t1 . No exemplo da
conta corrente, pode-se observar claramente que t1 t2 t1 .
Deve-se observar que essas quatro condies so necessrias para a
formao de impasses; se uma delas no for verificada, no existiro
impasses no sistema. Por outro lado, no so condies suficientes para a
existncia de impasses, ou seja, a verificao dessas quatro condies no
garante a presena de um impasse no sistema. Essas condies somente so
suficientes se existir apenas uma instncia de cada tipo de recurso, como
ser discutido na prxima seo.
4.10.2
Grafos de alocao de recursos
possvel representar graficamente a alocao de recursos entre as

tarefas de um sistema concorrente. A representao grfica prov uma viso
mais clara da distribuio dos recursos e permite detectar visualmente a
presena de esperas circulares que podem caracterizar impasses. Em um
grafo de alocao de recursos [Holt, 1972], as tarefas so representadas por
c Carlos Maziero
134
4: Grafos de alocao de recursos
crculos ( ) e os recursos por retngulos (). A posse de um recurso por

uma tarefa representada como , enquanto a requisio de um
recurso por uma tarefa indicada por .
A Figura 4.10 apresenta o grafo de alocao de recursos da situao
de impasse ocorrida na transferncia de valores entre contas bancrias da
Figura 4.9. Nessa figura percebe-se claramente a dependncia cclica entre
tarefas e recursos t1 c2 t2 c1 t1 , que neste caso evidencia um
impasse. Como h um s recurso de cada tipo (apenas uma conta c1 e uma
conta c2 ), as quatro condies necessrias se mostram tambm suficientes
para caracterizar um impasse.
t1 detm c1
c1
t2
t1
t1 requer c2
t2 requer c1
c2
t2 detm c2
Figura 4.10: Grafo de alocao de recursos com impasse.

Alguns recursos lgicos ou fsicos de um sistema computacional podem
ter mltiplas instncias: por exemplo, um sistema pode ter duas impressoras
idnticas instaladas, o que constituiria um recurso (impressora) com duas
instncias equivalentes, que podem ser alocadas de forma independente.
No grafo de alocao de recursos, a existncia de mltiplas instncias de
um recurso representada atravs de fichas dentro dos retngulos. Por
exemplo, as duas instncias de impressora seriam indicadas no grafo como
. A Figura 4.11 indica apresenta um grafo de alocao de recursos
considerando alguns recursos com mltiplas instncias.
importante observar que a ocorrncia de ciclos em um grafo de alocao,
envolvendo recursos com mltiplas instncias, pode indicar a presena
de um impasse, mas no garante sua existncia. Por exemplo, o ciclo
t1 r1 t2 r2 t3 r3 t1 presente no diagrama da Figura 4.11
no representa um impasse, porque a qualquer momento a tarefa t4 pode
liberar uma instncia do recurso r2 , solicitado por t2 , desfazendo assim o
c Carlos Maziero
135
4: Tcnicas de tratamento de impasses

r1
t1
r3
r4
t2
r2
t3
t4
Figura 4.11: Grafo de alocao com mltiplas instncias de recursos.

ciclo. Um algoritmo de deteco de impasses envolvendo recursos com
mltiplas instncias apresentado em [Tanenbaum, 2003].
4.10.3
Tcnicas de tratamento de impasses
Como os impasses paralisam tarefas que detm recursos, sua ocorrncia

pode incorrer em consequncias graves, como a paralisao gradativa de
todas as tarefas que dependam dos recursos envolvidos, o que pode levar
paralisao de todo o sistema. Devido a esse risco, diversas tcnicas de
tratamento de impasses foram propostas. Essas tcnicas podem definir
regras estruturais que previnam impasses, podem atuar de forma pr-ativa,
se antecipando aos impasses e impedindo sua ocorrncia, ou podem agir de
forma reativa, detectando os impasses que se formam no sistema e tomando
medidas para resolv-los.
Embora o risco de impasses seja uma questo importante, os sistemas
operacionais de mercado (Windows, Linux, Solaris, etc.) adotam a soluo mais simples: ignorar o risco, na maioria das situaes. Devido ao
custo computacional necessrio ao tratamento de impasses e sua forte
dependncia da lgica das aplicaes envolvidas, os projetistas de sistemas
operacionais normalmente preferem deixar a gesto de impasses por conta
dos desenvolvedores de aplicaes.
As principais tcnicas usadas para tratar impasses em um sistema concorrente so: prevenir impasses atravs, de regras rgidas para a programao
c Carlos Maziero
136
dos sistemas, impedir impasses, por meio do acompanhamento contnuo

da alocao dos recursos s tarefas, e detectar e resolver impasses. Essas
tcnicas sero detalhadas nas prximas sees.
Preveno de impasses
As tcnicas de preveno de impasses buscam garantir que impasses
nunca possam ocorrer no sistema. Para alcanar esse objetivo, a estrutura
do sistema e a lgica das aplicaes devem ser construdas de forma
que as quatro condies fundamentais para a ocorrncia de impasses,
apresentadas na Seo 4.10.1, nunca sejam satisfeitas. Se ao menos uma das
quatro condies for quebrada por essas regras estruturais, os impasses no
podero ocorrer. A seguir, cada uma das condies necessrias analisada
de acordo com essa premissa:
Excluso mtua : se no houver excluso mtua no acesso a recursos,
no podero ocorrer impasses. Mas, como garantir a integridade de
recursos compartilhados sem usar mecanismos de excluso mtua?
Uma soluo interessante usada na gerncia de impressoras: um
processo servidor de impresso (printer spooler) gerencia a impressora e
atende as solicitaes dos demais processos. Com isso, os processos
que desejam usar a impressora no precisam obter acesso exclusivo a
esse recurso. A tcnica de spooling previne impasses envolvendo as
impressoras, mas no facilmente aplicvel a outros tipos de recurso,
como arquivos em disco e reas de memria compartilhada.
Posse e espera : caso as tarefas usem apenas um recurso de cada vez,
solicitando-o e liberando-o logo aps o uso, impasses no podero
ocorrer. No exemplo da transferncia de fundos da Figura 4.9, seria
possvel separar a operao de transferncia em duas operaes isoladas: dbito em c1 e crdito em c2 (ou vice-versa), sem a necessidade
de acesso exclusivo simultneo s duas contas. Com isso, a condio
de posse e espera seria quebrada e o impasse evitado.
Outra possibilidade seria somente permitir a execuo de tarefas que
detenham todos os recursos necessrios antes de iniciar. Todavia,
essa abordagem poderia levar as tarefas a reter os recursos por muito
mais tempo que o necessrio para suas operaes, degradando o
desempenho do sistema. Uma terceira possibilidade seria associar um
prazo (time-out) s solicitaes de recursos: ao solicitar um recurso,
c Carlos Maziero
137
a tarefa define um tempo mximo de espera por ele; caso o prazo

expire, a tarefa pode tentar novamente ou desistir, liberando os demais
recursos que detm.
No-preempo : normalmente uma tarefa obtm e libera os recursos
de que necessita, de acordo com sua lgica interna. Se for possvel
arrancar um recurso da tarefa, sem que esta o libere explicitamente,
e devolv-lo mais tarde, impasses envolvendo aquele recurso no
podero ocorrer. Essa tcnica frequentemente usada em recursos
cujo estado interno pode ser salvo e restaurado de forma transparente
para a tarefa, como pginas de memria e o contexto do processador.
No entanto, de difcil aplicao sobre recursos como arquivos ou
reas de memria compartilhada, porque a preempo viola a excluso
mtua e pode deixar inconsistncias no estado interno do recurso.
Espera circular : um impasse uma cadeia de dependncias entre tarefas e
recursos que forma um ciclo. Ao prevenir a formao de tais ciclos,
impasses no podero ocorrer. A estratgia mais simples para prevenir
a formao de ciclos ordenar todos os recursos do sistema de acordo
com uma ordem global nica, e forar as tarefas a solicitar os recursos
obedecendo a essa ordem. No exemplo da transferncia de fundos da
Figura 4.9, o nmero de conta bancria poderia definir uma ordem
global. Assim, todas as tarefas deveriam solicitar primeiro o acesso
conta mais antiga e depois mais recente (ou vice-versa, mas sempre
na mesma ordem para todas as tarefas). Com isso, elimina-se a
possibilidade de impasses.
Impedimento de impasses
Uma outra forma de tratar os impasses preventivamente consiste em
acompanhar a alocao dos recursos s tarefas e, de acordo com algum
algoritmo, negar acessos de recursos que possam levar a impasses. Uma
noo essencial nas tcnicas de impedimento de impasses o conceito de
estado seguro. Cada estado do sistema definido pela distribuio dos
recursos entre as tarefas. O conjunto de todos os estados possveis do
sistema forma um grafo de estados, no qual as arestas indicam as alocaes
e liberaes de recursos. Um determinado estado considerado seguro se,
a partir dele, possvel concluir as tarefas pendentes. Caso o estado em
questo somente leve a impasses, ele considerado inseguro. As tcnicas
c Carlos Maziero
138
de impedimento de impasses devem portanto manter o sistema sempre em

um estado seguro, evitando entrar em estados inseguros.
A Figura 4.12 ilustra o grafo de estados do sistema de transferncia de
valores com duas tarefas discutido anteriormente. Nesse grafo, cada estado
a combinao dos estados individuais das duas tarefas. Pode-se observar
no grafo que o estado E13 corresponde a um impasse, pois a partir dele no
h mais nenhuma possibilidade de evoluo do sistema a outros estados.
Alm disso, os estados E12 , E14 e E15 so considerados estados inseguros,
pois levam invariavelmente na direo do impasse. Os demais estados so
considerados seguros, pois a partir de cada um deles possvel continuar a
execuo e retornar ao estado inicial E0 . Obviamente, transies que levem
de um estado seguro a um inseguro devem ser evitadas, como E9 E14 ou
E10 E12 .
A tcnica de impedimento de impasses mais conhecida o algoritmo do
banqueiro, criado por Dijkstra em 1965 [Tanenbaum, 2003]. Esse algoritmo
faz uma analogia entre as tarefas de um sistema e os clientes de um banco,
tratando os recursos como crditos emprestados s tarefas para a realizao
de suas atividades. O banqueiro decide que solicitaes de emprstimo
deve atender para conservar suas finanas em um estado seguro.
As tcnicas de impedimento de impasses necessitam de algum conhecimento prvio sobre o comportamento das tarefas para poderem operar.
Normalmente necessrio conhecer com antecedncia que recursos sero
acessados por cada tarefa, quantas instncias de cada um sero necessrias
e qual a ordem de acesso aos recursos. Por essa razo, so pouco utilizadas
na prtica.
Deteco e resoluo de impasses
Nesta abordagem, nenhuma medida preventiva adotada para prevenir
ou evitar impasses. As tarefas executam normalmente suas atividades,
alocando e liberando recursos conforme suas necessidades. Quando ocorrer
um impasse, o sistema o detecta, determina quais as tarefas e recursos
envolvidos e toma medidas para desfaz-lo. Para aplicar essa tcnica, duas
questes importantes devem ser respondidas: como detectar os impasses?
E como resolv-los?
A deteco de impasses pode ser feita atravs da inspeo do grafo
de alocao de recursos (Seo 4.10.2), que deve ser mantido pelo sistema
e atualizado a cada alocao ou liberao de recurso. Um algoritmo de
c Carlos Maziero
139
E0
E1
E2
E3
E4
E5
E6
E7
E20
E8
E21
E16
E22
E17
E9
E14
E10
Estados
inseguros
E23
E19
E18
E15
E12
E13
E11
impasse
Figura 4.12: Grafo de estados do sistema de transferncias com duas tarefas.

deteco de ciclos no grafo deve ser executado periodicamente, para verificar
a presena das dependncias cclicas que podem indicar impasses.
Alguns problemas decorrentes dessa estratgia so o custo de manuteno contnua do grafo de alocao e, sobretudo, o custo de sua anlise:
algoritmos de busca de ciclos em grafos tm custo computacional elevado, portanto sua ativao com muita frequncia poder prejudicar o
desempenho do sistema. Por outro lado, se a deteco for ativada apenas
c Carlos Maziero
140
esporadicamente, impasses podem demorar muito para ser detectados, o

que tambm ruim para o desempenho.
Uma vez detectado um impasse e identificadas as tarefas e recursos
envolvidos, o sistema deve proceder sua resoluo, que pode ser feita de
duas formas:
Eliminar tarefas : uma ou mais tarefas envolvidas no impasse so eliminadas, liberando seus recursos para que as demais tarefas possam
prosseguir. A escolha das tarefas a eliminar deve levar em conta vrios
fatores, como o tempo de vida de cada uma, a quantidade de recursos
que cada tarefa detm, o prejuzo para os usurios, etc.
Retroceder tarefas : uma ou mais tarefas envolvidas no impasse tm sua
execuo parcialmente desfeita, de forma a fazer o sistema retornar a
um estado seguro anterior ao impasse. Para retroceder a execuo de
uma tarefa, necessrio salvar periodicamente seu estado, de forma a
poder recuperar um estado anterior quando necessrio6 . Alm disso,
operaes envolvendo a rede ou interaes com o usurio podem ser
muito difceis ou mesmo impossveis de retroceder: como desfazer o
envio de um pacote de rede, ou a reproduo de um arquivo de udio?
A deteco e resoluo de impasses uma abordagem interessante, mas
relativamente pouco usada fora de situaes muito especficas, porque o
custo de deteco pode ser elevado e as alternativas de resoluo sempre
implicam perder tarefas ou parte das execues j realizadas.
Essa tcnica conhecida como checkpointing e os estados anteriores salvos so denominados checkpoints.
Captulo 5
Gerncia de memria
A memria principal um componente fundamental em qualquer
sistema de computao. Ela constitui o espao de trabalho do
sistema, no qual so mantidos os processos, threads, bibliotecas
compartilhadas e canais de comunicao, alm do prprio ncleo
do sistema operacional, com seu cdigo e suas estruturas de dados.
O hardware de memria pode ser bastante complexo, envolvendo
diversas estruturas, como caches, unidade de gerncia, etc, o que
exige um esforo de gerncia significativo por parte do sistema
operacional.
Uma gerncia adequada da memria essencial para o bom
desempenho de um computador. Neste captulo sero estudados
os elementos de hardware que compe a memria de um sistema
computacional e os mecanismos implementados ou controlados pelo
sistema operacional para a gerncia da memria.
5.1
Estruturas de memria
Existem diversos tipos de memria em um sistema de computao, cada

um com suas prprias caractersticas e particularidades, mas todos com um
mesmo objetivo: armazenar dados. Observando um sistema computacional
tpico, pode-se identificar vrios locais onde dados so armazenados: os
registradores e o cache interno do processador (denominado cache L1), o
cache externo da placa-me (cache L2) e a memria principal (RAM). Alm
disso, discos rgidos e unidades de armazenamento externas (pendrives, CDROMs, DVD-ROMs, fitas magnticas, etc.) tambm podem ser considerados
c Carlos Maziero
142
5: Estruturas de memria
memria em um um sentido mais amplo, pois tambm tm como funo o

armazenamento de dados.
Esses componentes de hardware so construdos usando diversas tecnologias e por isso tm caractersticas distintas, como a capacidade de
armazenamento, a velocidade de operao, o consumo de energia e o custo
por byte armazenado. Essas caractersticas permitem definir uma hierarquia
de memria, representada na forma de uma pirmide (Figura 5.1).
registradores
cache L1
velocidade,
custo e
consumo
de energia
cache L2
memria RAM
voltil
no-voltil
memria Flash
disco rgido
CD-ROM, DVD-ROM, ta magntica
capacidade
Figura 5.1: Hierarquia de memria.

Nessa pirmide, observa-se que memrias mais rpidas, como os registradores da CPU e os caches, so menores (tm menor capacidade de
armazenamento), mais caras e consomem mais energia que memrias mais
lentas, como a memria principal (RAM) e os discos rgidos. Alm disso, as
memrias mais rpidas so volteis, ou seja, perdem seu contedo ao ficarem
sem energia. Memrias que preservam seu contedo mesmo quando no
tiverem energia so denominadas no-volteis.
Outra caracterstica importante das memrias a rapidez de seu funcionamento, que pode ser detalhada em duas dimenses: tempo de acesso
(ou latncia) e taxa de transferncia. O tempo de acesso caracteriza o tempo
necessrio para iniciar uma transferncia de dados de/para um determinado
meio de armazenamento. Por sua vez, a taxa de transferncia indica quantos
bytes por segundo podem ser lidos/escritos naquele meio, uma vez iniciada
a transferncia de dados. Para ilustrar esses dois conceitos complementares,
c Carlos Maziero
143
5: Endereos, variveis e funes
a Tabela 5.1 traz valores de tempo de acesso e taxa de transferncia de alguns

meios de armazenamento usuais.
Meio
Cache L2
Memria RAM
Memria flash (NAND)
Disco rgido IDE
DVD-ROM
Tempo de acesso
1 ns
60 ns
2 ms
10 ms (tempo necessrio para o
deslocamento da cabea de leitura e rotao do disco at o setor
desejado)
de 100 ms a vrios minutos (caso
a gaveta do leitor esteja aberta ou
o disco no esteja no leitor)
Taxa de transferncia
1 GB/s (1 ns/byte)
1 GB/s (1 ns/byte)
10 MB/s (100 ns/byte)
Tabela 5.1:
Tempos de acesso e taxas de transferncia tpicas
[Patterson and Henessy, 2005].
Neste captulo sero estudados os mecanismos envolvidos na gerncia
da memria principal do computador, que geralmente constituda por
um grande espao de memria do tipo RAM (Random Access Memory ou
memria de leitura/escrita). Tambm ser estudado o uso do disco rgido
como extenso da memria principal, atravs de mecanismos de memria
virtual (Seo 5.7). A gerncia dos espaos de armazenamento em disco
rgido abordada no Captulo 6. Os mecanismos de gerncia dos caches L1
e L2 geralmente so implementados em hardware e so independentes do
sistema operacional. Detalhes sobre seu funcionamento podem ser obtidos
em [Patterson and Henessy, 2005].
5.2
Endereos, variveis e funes
Ao escrever um programa usando uma linguagem de alto nvel, como

C, C++ ou Java, o programador usa apenas referncias a entidades abstratas, como variveis, funes, parmetros e valores de retorno. No h
necessidade do programador definir ou manipular endereos de memria
explicitamente. O trecho de cdigo em C a seguir (soma.c) ilustra esse
conceito; nele, so usados smbolos para referenciar posies de dados (i e
soma) ou de trechos de cdigo (main, printf e exit):
c Carlos Maziero
144
1
2
#include <stdlib.h>
#include <stdio.h>
3
4
5
6
int main ()
{
int i, soma = 0 ;
for (i=0; i< 5; i++)

{
soma += i ;
printf ("i vale %d e soma vale %d\n", i, soma) ;
}
exit(0) ;
8
9
10
11
12
13
14
Todavia, o processador do computador acessa endereos de memria

para buscar as instrues a executar e seus operandos; acessa tambm
outros endereos de memria para escrever os resultados do processamento
das instrues. Por isso, quando programa soma.c for compilado, ligado
a bibliotecas, carregado na memria e executado pelo processador, cada
varivel ou trecho de cdigo definido pelo programador dever ocupar um
espao especfico e exclusivo na memria, com seus prprios endereos. A
listagem a seguir apresenta o cdigo assembly correspondente compilao
do programa soma.c. Nele, pode-se observar que no h mais referncias a
nomes simblicos, apenas a endereos:
c Carlos Maziero
145
00000000
0: 8d
4: 83
7: ff
a: 55
b: 89
d: 51
e: 83
11: c7
18: c7
1f: eb
21: 8b
24: 01
27: 83
2a: ff
2d: ff
30: 68
35: e8
3a: 83
3d: ff
40: 83
44: 7e
46: 83
49: 6a
4b: e8
<main>:
4c 24 04
e4 f0
71 fc
e5
ec
45
45
1f
45
45
ec
75
75
00
fc
c4
45
7d
db
ec
00
fc
14
f4 00 00 00 00
f8 00 00 00 00
f8
f4
04
f4
f8
00 00 00
ff ff ff
10
f8
f8 04
0c
ff ff ff
lea
and
pushl
push
mov
push
sub
movl
movl
jmp
mov
add
sub
pushl
pushl
push
call
add
incl
cmpl
jle
sub
push
call
0x4(%esp),%ecx
$0xfffffff0,%esp
-0x4(%ecx)
%ebp
%esp,%ebp
%ecx
$0x14,%esp
$0x0,-0xc(%ebp)
$0x0,-0x8(%ebp)
40 <main+0x40>
-0x8(%ebp),%eax
%eax,-0xc(%ebp)
$0x4,%esp
-0xc(%ebp)
-0x8(%ebp)
$0x0
36 <main+0x36>
$0x10,%esp
-0x8(%ebp)
$0x4,-0x8(%ebp)
21 <main+0x21>
$0xc,%esp
$0x0
4c <main+0x4c>
Dessa forma, os endereos das variveis e trechos de cdigo usados por

um programa devem ser definidos em algum momento entre a escrita do
cdigo e sua execuo pelo processador, que pode ser:
Durante a edio : o programador escolhe a posio de cada uma das
variveis e do cdigo do programa na memria. Esta abordagem
normalmente s usada na programao de sistemas embarcados
simples, programados diretamente em linguagem de mquina.
Durante a compilao : o compilador escolhe as posies das variveis
na memria. Para isso, todos os cdigos-fonte que fazem parte do
programa devem ser conhecidos no momento da compilao, para
evitar conflitos de endereos entre variveis. Uma outra tcnica
bastante usada a gerao de cdigo independente de posio (PIC Position-Independent Code), no qual todas as referncias a variveis so
c Carlos Maziero
146
feitas usando endereos relativos (como 3.471 bytes aps o incio do

mdulo, ou 15 bytes aps o program counter, por exemplo).
Durante a ligao : o compilador gera smbolos que representam as variveis mas no define seus endereos finais, gerando um arquivo
que contm as instrues em linguagem de mquina e as definies
das variveis utilizadas, denominado arquivo objeto1 . Os arquivos
com extenso .o em UNIX ou .obj em Windows so exemplos de
arquivos-objeto obtidos da compilao de arquivos em C ou outra
linguagem de alto nvel. O ligador (ou link-editor) ento l todos os
arquivos-objeto e as bibliotecas e gera um arquivo-objeto executvel, no qual os endereos de todas as variveis esto corretamente
definidos.
Durante a carga : tambm possvel definir os endereos de variveis e de
funes durante a carga do cdigo em memria para o lanamento de
um novo processo. Nesse caso, um carregador (loader) responsvel
por carregar o cdigo do processo na memria e definir os endereos
de memria que devem ser utilizados. O carregador pode ser parte do
ncleo do sistema operacional ou uma biblioteca ligada ao executvel,
ou ambos. Esse mecanismo normalmente usado na carga das
bibliotecas dinmicas (DLL - Dynamic Linking Libraries).
Durante a execuo : os endereos emitidos pelo processador durante a
execuo do processo so analisados e convertidos nos endereos
efetivos a serem acessados na memria real. Por exigir a anlise e a
converso de cada endereo gerado pelo processador, este mtodo s
vivel com o uso de hardware dedicado para esse tratamento. Esta
a abordagem usada na maioria dos sistemas computacionais atuais
(como os computadores pessoais), e ser descrita nas prximas sees.
A Figura 5.2 ilustra os diferentes momentos da vida de um processo em
que pode ocorrer a resoluo dos endereos de variveis e de cdigo.
1
Arquivos-objeto so formatos de arquivo projetados para conter cdigo binrio e dados

provenientes de uma compilao de cdigo-fonte. Existem diversos formatos de arquivosobjeto; os mais simples, como os arquivos .com do DOS, apenas definem uma sequncia de
bytes a carregar em uma posio fixa da memria; os mais complexos, como os formatos
UNIX ELF (Executable and Library Format) e Microsoft PE (Portable Executable Format),
permitem definir sees internas, tabelas de relocao, informao de depurao, etc.
[Levine, 2000].
c Carlos Maziero
147
5: Endereos lgicos e fsicos

edio/
programao
cdigo
fonte
arq.c
lib.c
biblioteca
fonte
compilao
cdigo
objeto
arq.o
lib.a
biblioteca
esttica
ligao
cdigo
executvel
lib.so
lib.dll
arq.exe
biblioteca
dinmica
carga
execuo
processo
Figura 5.2: Momentos de atribuio de endereos.
5.2.1
Endereos lgicos e fsicos
Ao executar uma sequncia de instrues, o processador escreve endereos no barramento de endereos do computador, que servem para buscar
instrues e operandos, mas tambm para ler e escrever valores em posies
de memria e portas de entrada/sada. Os endereos de memria gerados
pelo processador medida em que executa algum cdigo so chamados de
endereos lgicos, porque correspondem lgica do programa, mas no so
necessariamente iguais aos endereos reais das instrues e variveis na
memria real do computador, que so chamados de endereos fsicos.
Os endereos lgicos emitidos pelo processador so interceptados por
um hardware especial denominado Unidade de Gerncia de Memria (MMU
- Memory Management Unit), que pode fazer parte do prprio processador
(como ocorre nos sistemas atuais) ou constituir um dispositivo separado
(como ocorria na mquinas mais antigas). A MMU faz a anlise dos
endereos lgicos emitidos pelo processador e determina os endereos fsicos
correspondentes na memria da mquina, permitindo ento seu acesso
c Carlos Maziero
148
5: Modelo de memria dos processos
pelo processador. Caso o acesso a um determinado endereo solicitado

pelo processador no seja possvel, a MMU gera uma interrupo de
hardware para notificar o processador sobre a tentativa de acesso indevido.
O funcionamento bsico da MMU est ilustrado na Figura 5.3.
memria
processador
endereo
lgico
interrupo
MMU
endereo
fsico
endereo
fsico
dados
barramentos
endereos
Figura 5.3: Funcionamento bsico de uma MMU.

A proteo de memria entre processos essencial para a segurana e
estabilidade dos sistemas mais complexos, nos quais centenas ou milhares
de processos podem estar na memria simultaneamente. A MMU pode ser
rapidamente ajustada para mudar a forma de converso entre endereos
lgicos e fsicos, o que permite implementar uma rea de memria exclusiva
para cada processo do sistema. Assim, a cada troca de contexto entre
processos, as regras de converso da MMU devem ser ajustadas para
somente permitir o acesso rea de memria definida para cada novo
processo corrente.
5.2.2
Modelo de memria dos processos
Cada processo visto pelo sistema operacional como uma cpsula

isolada, ou seja, uma rea de memria exclusiva que s ele e o ncleo do
sistema podem acessar. Essa rea de memria contm todas as informaes
necessrias execuo do processo, divididas nas seguintes sees:
TEXT : contm o cdigo a ser executado pelo processo, gerado durante
a compilao e a ligao com as bibliotecas. Esta rea tem tamanho
c Carlos Maziero
149
5: Modelo de memria dos processos
fixo, calculado durante a compilao, e normalmente s deve estar

acessvel para leitura e execuo.
DATA : esta rea contm os dados estticos usados pelo programa, ou seja,
suas variveis globais e as variveis locais estticas (na linguagem C,
so as variveis definidas como static dentro das funes). Como o
tamanho dessas variveis pode ser determinado durante a compilao,
esta rea tem tamanho fixo; deve estar acessvel para leituras e escritas,
mas no para execuo.
HEAP : rea usada para armazenar dados atravs de alocao dinmica,
usando operadores como malloc e free ou similares. Esta rea
tem tamanho varivel, podendo aumentar/diminuir conforme as
alocaes/liberaes de memria feitas pelo processo. Ao longo do
uso, esta rea pode se tornar fragmentada, ou seja, pode conter lacunas
entre os blocos de memria alocados. So necessrios ento algoritmos
de alocao que minimizem sua fragmentao.
STACK : rea usada para manter a pilha de execuo do processo, ou seja, a
estrutura responsvel por gerenciar o fluxo de execuo nas chamadas
de funo e tambm para armazenar os parmetros, variveis locais e
o valor de retorno das funes. Geralmente a pilha cresce para baixo,
ou seja, inicia em endereos elevados e cresce em direo aos endereos
menores da memria. No caso de programas com mltiplas threads,
esta rea contm somente a pilha do programa principal. Como threads
podem ser criadas e destrudas dinamicamente, a pilha de cada thread
mantida em uma rea prpria, geralmente alocada no heap.
A Figura 5.4 apresenta a organizao da memria de um processo.
Nela, observa-se que as duas reas de tamanho varivel (stack e heap) esto
dispostas em posies opostas e vizinhas memria livre (no alocada).
Dessa forma, a memria livre disponvel ao processo pode ser aproveitada
da melhor forma possvel, tanto pelo heap quanto pelo stack, ou por ambos.
c Carlos Maziero
150
5: Estratgias de alocao
rea no alocada
max
TEXT
DATA
STACK
HEAP
variveis dinmicas
(malloc/free)
programa principal
funes
bibliotecas estticas
variveis globais
variveis locais estticas
buers internos
endereos de retorno de chamadas

parmetros de funes
variveis locais das funes
Figura 5.4: Organizao da memria de um processo.
5.3
Estratgias de alocao
Em um sistema mono-processo, em que apenas um processo por vez

carregado em memria para execuo, a alocao da memria principal
um problema simples de resolver: basta reservar uma rea de memria para
o ncleo do sistema operacional e alocar o processo na memria restante,
respeitando a disposio de suas reas internas, conforme apresentado na
Figura 5.4.
A memria reservada para o ncleo do sistema operacional pode estar
no incio ou no final da rea de memria fsica disponvel. Como a maioria
das arquiteturas de hardware define o vetor de interrupes (vide Seo
1.5.1) nos endereos iniciais da memria (tambm chamados endereos
baixos), geralmente o ncleo tambm colocado na parte inicial da memria.
Assim, toda a memria disponvel aps o ncleo do sistema destinada
aos processos no nvel do usurio (user-level). A Figura 5.5 ilustra essa
organizao da memria.
ncleo
rea para processo(s) no nvel usurio
max
vetor de interrupes
Figura 5.5: Organizao da memria do sistema.

Nos sistemas multi-processos, vrios processos podem ser carregados
na memria para execuo simultnea. Nesse caso, o espao de memria
destinado aos processos deve ser dividido entre eles usando uma estratgia
c Carlos Maziero
151
5: Parties fixas
que permita eficincia e flexibilidade de uso. As principais estratgias de

alocao da memria fsica sero estudadas nas prximas sees.
5.3.1
Parties fixas
A forma mais simples de alocao de memria consiste em dividir a

memria destinada aos processos em N parties fixas, de tamanhos iguais
ou distintos. Em cada partio pode ser carregado um processo. Nesse
esquema, a traduo entre os endereos lgicos vistos pelos processos e os
endereos fsicos feita atravs de um simples registrador de relocao, cujo
valor somado ao endereo lgico gerado pelo processador, a fim de obter o
endereo fsico correspondente. Endereos lgicos maiores que o tamanho
da partio em uso so simplesmente rejeitados pela MMU. O exemplo da
Figura 5.6 ilustra essa estratgia. No exemplo, o processo da partio 3
est executando e deseja acessar o endereo lgico 14.257. A MMU recebe
esse endereo e o soma ao valor do registrador de relocao (110.000) para
obter o endereo fsico 124.257, que ento acessado. Deve-se observar
que o valor contido no registrador de relocao o endereo de incio da
partio ativa (partio 3); esse registrador deve ser atualizado a cada troca
de processo ativo.
processo na particao 3
tabela de incio das

parties de memria
0
20.000
30.000
60.000
110.000
200.000
partio
ativa
14.257 (endereo lgico)
registrador
de relocao
110.000
MMU
124.257 (endereo fsico)
ncleo
0
part 0
part 1
part 2
part 3
Figura 5.6: Alocao em parties fixas.
part 4
max
c Carlos Maziero
152
5: Alocao contgua
Essa abordagem extremamente simples, todavia sua simplicidade no

compensa suas vrias desvantagens:
Os processos podem ter tamanhos distintos dos tamanhos das parties, o que implica em reas de memria sem uso no final de cada
partio.
O nmero mximo de processos na memria limitado ao nmero de
parties, mesmo que os processos sejam pequenos.
Processos maiores que o tamanho da maior partio no podero ser
carregados na memria, mesmo se todas as parties estiverem livres.
Por essas razes, esta estratgia de alocao pouco usada atualmente;
ela foi muito usada no OS/360, um sistema operacional da IBM usado nas
dcadas de 1960-70 [Tanenbaum, 2003].
5.3.2
Alocao contgua
A estratgia anterior, com parties fixas, pode ser tornar bem mais
flexvel caso o tamanho de cada partio possa ser ajustado para se adequar
demanda especfica de cada processo. Nesse caso, a MMU deve ser
projetada para trabalhar com dois registradores prprios: um registrador
base, que define o endereo inicial da partio ativa, e um registrador limite,
que define o tamanho em bytes dessa partio. O algoritmo de traduo de
endereos lgicos em fsicos bem simples: cada endereo lgico gerado
pelo processo em execuo comparado ao valor do registrador limite; caso
seja maior ou igual a este, uma interrupo gerada pela MMU de volta
para o processador, indicando um endereo invlido. Caso contrrio, o
endereo lgico somado ao valor do registrador base, para a obteno do
endereo fsico correspondente. A Figura 5.7 apresenta uma viso geral
dessa estratgia. Na Figura, o processo p3 tenta acessar o endereo lgico
14.257.
Os valores dos registradores base e limite da MMU devem ser ajustados
pelo despachante (dispatcher) a cada troca de contexto, ou seja, cada vez que
o processo ativo substitudo. Os valores de base e limite para cada processo
do sistema devem estar armazenados no respectivo TCB (Task Control Block,
vide Seo 2.4.1). Obviamente, quando o ncleo estiver executando, os
c Carlos Maziero
153
5: Alocao contgua
TCB(P3)
processo P3
base
limite
14.257 (endereo lgico)
limite
45.000
registradores
atualizados na
troca de contexto
que ativou P3
el<lim
no
Erro: endereo
invlido (IRQ)
sim
base
110.000
MMU
Memria RAM
ncleo
P1
P2
P3
P4
P5
rea acessvel a P3
110.000
(base)
max
154.999
(base+limite-1)
Figura 5.7: Alocao contgua de memria.

valores de base e limite devem ser ajustados respectivamente para 0 e ,
para permitir o acesso direto a toda a memria fsica.
Alm de traduzir endereos lgicos nos endereos fsicos correspondentes, a ao da MMU propicia a proteo de memria entre os processos:
quando um processo pi estiver executando, ele s pode acessar endereos
lgicos no intervalo [0, limite(pi ) 1], que correspondem a endereos fsicos
no intervalo [base(pi ), base(pi ) + limite(pi ) 1]. Ao detectar uma tentativa de
acesso a um endereo fora desse intervalo, a MMU ir gerar uma solicitao
de interrupo (IRQ - Interrupt ReQuest, vide Seo 1.5.1) para o processador,
indicando o endereo invlido. Ao receber a interrupo, o processador
interrompe o fluxo de execuo do processo pi , retorna ao ncleo e ativa
a rotina de tratamento da interrupo, que poder abortar o processo ou
tomar outras providncias.
A maior vantagem da estratgia de alocao contgua sua simplicidade:
por depender apenas de dois registradores e de uma lgica simples para
a traduo de endereos, pode ser implementada em hardware de baixo
custo, ou mesmo incorporada a processadores mais simples. Todavia,
uma estratgia pouco flexvel e est muito sujeita fragmentao externa,
conforme ser discutido na Seo 5.5.
c Carlos Maziero
154
5.3.3
5: Alocao por segmentos
Alocao por segmentos
A alocao por segmentos, ou alocao segmentada, uma extenso da

alocao contgua, na qual o espao de memria de um processo fracionado
em reas, ou segmentos, que podem ser alocados separadamente na memria
fsica. Alm das quatro reas funcionais bsicas da memria do processo
discutidas na Seo 5.2.2 (text, data, stack e heap), tambm podem ser definidos
segmentos para tens especficos, como bibliotecas compartilhadas, vetores,
matrizes, pilhas de threads, buffers de entrada/sada, etc.
Ao estruturar a memria em segmentos, o espao de memria de cada
processo no mais visto como uma sequncia linear de endereos lgicos,
mas como uma coleo de segmentos de tamanhos diversos e polticas de
acesso distintas. A Figura 5.8 apresenta a viso lgica da memria de um
processo e a sua forma de mapeamento para a memria fsica.
P1
S1
S5
S1
S4
S2
S6
S4
S3
S3
S2
P2
Memria RAM
ncleo
0
P1.S5
P2.S4
P2.S2
P1.S6
P1.S1
P2.S1
P1.S3
P1.S2
P1.S4
P2.S3
max
Figura 5.8: Alocao de memria por segmentos.

No modelo de memria alocada por segmentos, os endereos gerados
pelos processos devem indicar as posies de memria e os segmentos onde
elas se encontram. Em outras palavras, este modelo usa endereos lgicos
bidimensionais, compostos por pares [segmento:offset], onde segmento indica o
nmero do segmento desejado e offset indica a posio desejada dentro do
segmento. Os valores de offset variam de 0 (zero) ao tamanho do segmento.
A Figura 5.9 mostra alguns exemplos de endereos lgicos usando alocao
por segmentos.
c Carlos Maziero
155

P1
S1
S3
[3:1204]
[1:5317]
[2:5799]
6000 0
4000
S2
10000
Figura 5.9: Endereos lgicos em segmentos.

Na alocao de memria por segmentos, a forma de traduo de endereos lgicos em fsicos similar da alocao contgua. Contudo, como
os segmentos podem ter tamanhos distintos e ser alocados separadamente
na memria fsica, cada segmento ter seus prprios valores de base e
limite, o que leva necessidade de definir uma tabela de segmentos para cada
processo do sistema. Essa tabela contm os valores de base e limite para
cada segmento usado pelo processo, alm de flags com informaes sobre
cada segmento, como permisses de acesso, etc. (vide Seo 5.3.4). A Figura
5.10 apresenta os principais elementos envolvidos na traduo de endereos
lgicos em fsicos usando memria alocada por segmentos. Nessa figura,
ST reg indica o registrador que aponta para a tabela de segmentos ativa.
Cabe ao compilador colocar os diversos trecho do cdigo-fonte de cada
programa em segmentos separados. Ele pode, por exemplo, colocar cada
vetor ou matriz em um segmento prprio. Dessa forma, erros frequentes
como acessos a ndices alm do tamanho de um vetor iro gerar endereos
fora do respectivo segmento, que sero detectados pelo hardware de gerncia
de memria e notificados ao sistema operacional.
A implementao da tabela de segmentos varia conforme a arquitetura
de hardware considerada. Caso o nmero de segmentos usados por cada
processo seja pequeno, a tabela pode residir em registradores especializados
do processador. Por outro lado, caso o nmero de segmentos por processo
seja elevado, ser necessrio alocar as tabelas na memria RAM. O processador 80.386 usa duas tabelas em RAM: a LDT (Local Descriptor Table), que
define os segmentos locais (exclusivos) de cada processo, e a GDT (Global
Descriptor Table), usada para descrever segmentos globais que podem ser
compartilhados entre processos distintos (vide Seo 5.6). Cada uma dessas
duas tabelas comporta at 8.192 segmentos. As tabelas em uso pelo processo
em execuo so indicadas por registradores especficos do processador. A
c Carlos Maziero
156
TCB(P3)
processo P3
Segment
Table
address
S4
registrador atualizado
na troca de contexto
que ativou P3
[4:6.914] (endereo lgico)
ST reg
Tabela de segmentos
(em memria RAM)
base
limite
1.200
5.500
8.000
4.200
15.000
10.500
27.500
1.500
32.300
8.750
45.000
12.000
87.000
7.600
...
...
segmento
offset
6.914
no
o<lim
8.750
Erro: violao de
segmento (IRQ)
sim
32.300
MMU
Memria RAM
ncleo
P3.S4
max
32.300
(base)
41.049
(base+limite-1)
Figura 5.10: Traduo de endereos em memria alocada por segmentos.

cada troca de contexto, os registradores que indicam a tabela de segmentos
ativa devem ser atualizados para refletir as reas de memria usadas pelo
processo que ser ativado.
Para cada endereo de memria acessado pelo processo em execuo,
necessrio acessar a tabela de segmentos para obter os valores de base
e limite correspondentes ao endereo lgico acessado. Todavia, como as
tabelas de segmentos normalmente se encontram na memria principal,
esses acessos tm um custo significativo: considerando um sistema de
32 bits, para cada acesso memria seriam necessrias pelo menos duas
leituras adicionais na memria, para ler os valores de base e limite, o que
tornaria cada acesso memria trs vezes mais lento. Para contornar esse
problema, os processadores definem alguns registradores de segmentos, que
permitem armazenar os valores de base e limite dos segmentos mais usados
pelo processo ativo. Assim, caso o nmero de segmentos em uso simultneo
seja pequeno, no h necessidade de consultar a tabela de segmentos com
c Carlos Maziero
157
5: Alocao paginada
excessiva frequncia, o que mantm o desempenho de acesso memria em

um nvel satisfatrio. O processador 80.386 define os seguintes registradores
de segmentos:
CS: Code Segment, indica o segmento onde se encontra o cdigo
atualmente em execuo; este valor automaticamente ajustado no
caso de chamadas de funes de bibliotecas, chamadas de sistema,
interrupes ou operaes similares.
SS: Stack Segment, indica o segmento onde se encontra a pilha em
uso pelo processo atual; caso o processo tenha vrias threads, este
registrador deve ser ajustado a cada troca de contexto entre threads.
DS, ES, FS e GS: Data Segments, indicam quatro segmentos com
dados usados pelo processo atual, que podem conter variveis globais,
vetores ou reas alocadas dinamicamente. Esses registradores podem
ser ajustados em caso de necessidade, para acessar outros segmentos
de dados.
O contedo desses registradores preservado no TCB (Task Control Block)
de cada processo a cada troca de contexto, tornando o acesso memria
bastante eficiente caso poucos segmentos sejam usados simultaneamente.
Portanto, o compilador tem uma grande responsabilidade na gerao
de cdigo executvel: minimizar o nmero de segmentos necessrios
execuo do processo a cada instante, para no prejudicar o desempenho
de acesso memria.
Exemplos de processadores que utilizam a alocao por segmentos
incluem o 80.386 e seus sucessores (486, Pentium, Athlon e processadores
correlatos).
5.3.4
Alocao paginada
Conforme visto na Seo anterior, a alocao de memria por segmentos

exige o uso de endereos bidimensionais na forma [segmento:offset], o que
pouco intuitivo para o programador e torna mais complexa a construo
de compiladores. Alm disso, uma forma de alocao bastante suscetvel
fragmentao externa, conforme ser discutido na Seo 5.5. Essas
deficincias levaram os projetistas de hardware a desenvolver outras tcnicas
para a alocao da memria principal.
c Carlos Maziero
158
5: Alocao paginada
Na alocao de memria por pginas, ou alocao paginada, o espao de

endereamento lgico dos processos mantido linear e unidimensional (ao
contrrio da alocao por segmentos, que usa endereos bidimensionais).
Internamente, e de forma transparente para os processos, o espao de
endereos lgicos dividido em pequenos blocos de mesmo tamanho,
denominados pginas. Nas arquiteturas atuais, as pginas geralmente
tm 4 Kbytes (4.096 bytes), mas podem ser encontradas arquiteturas com
pginas de outros tamanhos2 . O espao de memria fsica destinado aos
processos tambm dividido em blocos de mesmo tamanho que as pginas,
denominados quadros (do ingls frames). A alocao dos processos na
memria fsica ento feita simplesmente indicando em que quadro da
memria fsica se encontra cada pgina de cada processo, conforme ilustra
a Figura 5.11. importante observar que as pginas de um processo podem
estar em qualquer posio da memria fsica disponvel aos processos,
ou seja, podem estar associadas a quaisquer quadros, o que permite uma
grande flexibilidade de alocao. Alm disso, as pginas no usadas pelo
processo no precisam estar mapeadas na memria fsica, o que proporciona
maior eficincia no uso da mesma.
O mapeamento entre as pginas de um processo e os quadros correspondentes na memria fsica feita atravs de uma tabela de pginas (page
table), na qual cada entrada corresponde a uma pgina e contm o nmero
do quadro onde ela se encontra. Cada processo possui sua prpria tabela
de pginas; a tabela de pginas ativa, que corresponde ao processo em
execuo no momento, referenciada por um registrador do processador
denominado PTBR Page Table Base Register. A cada troca de contexto, esse
registrador deve ser atualizado com o endereo da tabela de pginas do
novo processo ativo.
A diviso do espao de endereamento lgico de um processo em pginas
pode ser feita de forma muito simples: como as pginas sempre tm 2n
bytes de tamanho (por exemplo, 212 bytes para pginas de 4 Kbytes) os
n bits menos significativos de cada endereo lgico definem a posio
daquele endereo dentro da pgina (deslocamento ou offset), enquanto os
2
As arquiteturas de processador mais recentes suportam diversos tamanhos de pginas,

inclusive pginas muito grandes, as chamadas super-pginas (hugepages, superpages ou
largepages). Uma super-pgina tem geralmente entre 1 e 16 MBytes, ou mesmo acima disso;
seu uso em conjunto com as pginas normais permite obter mais desempenho no acesso
memria, mas torna os mecanismos de gerncia de memria bem mais complexos. O
artigo [Navarro et al., 2002] traz uma discusso mais detalhada sobre esse tema.
c Carlos Maziero
159
5: Alocao paginada
pginas
processo P1
processo P2
Memria RAM
ncleo
rea no-paginada
quadros
Figura 5.11: Alocao de memria por pginas.

bits restantes (mais significativos) so usados para definir o nmero da
pgina. Por exemplo, o processador Intel 80.386 usa endereos lgicos de 32
bits e pginas com 4 Kbytes; um endereo lgico de 32 bits decomposto
em um offset de 12 bits, que representa uma posio entre 0 e 4.095 dentro
da pgina, e um nmero de pgina com 20 bits. Dessa forma, podem ser
endereadas 220 pginas com 212 bytes cada (1.048.576 pginas com 4.096
bytes cada). Eis um exemplo de decomposio de um endereo lgico nesse
sistema:
01805E9AH 0000 0001 1000 0000 0101 1110 1001 10102
0000 0001 1000 0000 01012 e 1110 1001 10102
|
{z
} |
{z
}
20 bits
12 bits
01805H e E9AH
| {z } |{z}
pgina offset
pgina 01805H e offset E9AH
Para traduzir um endereo lgico no endereo fsico correspondente, a
MMU precisa efetuar os seguintes passos:
c Carlos Maziero
160
5: Alocao paginada
1. decompor o endereo lgico em nmero de pgina e offset;

2. obter o nmero do quadro onde se encontra a pgina desejada;
3. construir o endereo fsico, compondo o nmero do quadro com o
offset; como pginas e quadros tm o mesmo tamanho, o valor do offset
preservado na converso;
4. caso a pgina solicitada no esteja mapeada em um quadro da memria
fsica, a MMU deve gerar uma interrupo de falta de pgina (page fault)
para o processador;
5. essa interrupo provoca o desvio da execuo para o ncleo do
sistema operacional, que deve ento tratar a falta de pgina.
A Figura 5.12 apresenta os principais elementos que proporcionam a
traduo de endereos em um sistema paginado com pginas de 4.096 bytes.
processo P3
TCB(P3)
que ativou P3
PTBR
0000 5E9A (endereo lgico)
PTBR
pgina
Pginas no-mapeadas
Tabela de pginas
(em memria RAM)
13
A7
2F
4B
offset
0000 5
E9A
Erro: falta de
pgina (IRQ)
0002 F
quadro
offset
...
7 1A
MMU
0002 FE9A (endereo fsico)
Memria RAM
ncleo
rea no-paginada
47
Figura 5.12: Traduo de endereos usando paginao.
c Carlos Maziero
161
5: Alocao paginada
Flags de controle
Como o espao de endereamento lgico de um processo pode ser
extremamente grande (por exemplo, o espao de endereos lgicos de
cada processo em uma arquitetura de 32 bits pode ir at 232 bytes), uma
parte significativa das pginas de um processo pode no estar mapeada em
quadros de memria fsica. reas de memria no usadas por um processo
no precisam estar mapeadas na memria fsica, o que permite um uso
mais eficiente da memria. Assim, a tabela de pginas de cada processo
indica as reas no mapeadas com um flag adequado (vlido/invlido). Cada
entrada da tabela de pginas de um processo contm o nmero do quadro
correspondente e um conjunto de flags (bits) de controle, com diversas
finalidades:
Presena: indica se a pgina est presente (mapeada) no espao de
endereamento daquele processo;
Proteo: bits indicando os direitos de acesso do processo pgina
(basicamente leitura, escrita e/ou execuo);
Referncia: indica se a pgina foi referenciada (acessada) recentemente,
sendo ajustado para 1 pelo prprio hardware a cada acesso pgina.
Este bit usado pelos algoritmos de memria virtual (apresentados
na Seo 5.7);
Modificao: tambm chamado de dirty bit, ajustado para 1 pelo
hardware a cada escrita na pgina, indicando se a pgina foi modificada
aps ser carregada na memria; usado pelos algoritmos de memria
virtual.
Alm destes, podem ser definidos outros bits, indicando a poltica de
caching da pgina, se uma pgina de usurio ou de sistema, se a pgina
pode ser movida para disco, o tamanho da pgina (no caso de sistemas
que permitam mais de um tamanho de pgina), etc. O contedo exato de
cada entrada da tabela de pginas depende da arquitetura do hardware
considerado.
Tabelas multi-nveis
Em uma arquitetura de 32 bits com pginas de 4 Kbytes, cada entrada na
tabela de pginas ocupa cerca de 32 bits, ou 4 bytes (20 bits para o nmero de
c Carlos Maziero
162
5: Alocao paginada
quadro e os 12 bits restantes para flags). Considerando que cada tabela de

pginas tem 220 pginas, cada tabela ocupar 4 Mbytes de memria (4 220
bytes) se for armazenada de forma linear na memria. No caso de processos
pequenos, com muitas pginas no mapeadas, uma tabela de pginas linear
ocupar mais espao na memria que o prprio processo, como mostra a
Figura 5.13, o que torna seu uso pouco interessante.
TCB(P3)
1.048.576 pginas
(espao de endereamento lgico)
PTBR
100 pginas mapeadas
(CODE, DATA, HEAP)
1.048.456 pginas
no-mapeadas
20 pginas mapeadas
(STACK)
1.048.576 ponteiros de 32 bits = 4 MBytes
Figura 5.13: Inviabilidade de tabelas de pgina lineares.

Para resolver esse problema, so usadas tabelas de pginas multi-nveis,
estruturadas na forma de rvores: uma tabela de pginas de primeiro nvel (ou
diretrio de pginas) contm ponteiros para tabelas de pginas de segundo nvel,
e assim por diante, at chegar tabela que contm os nmeros dos quadros
desejados. Para percorrer essa rvore, o nmero de pgina dividido em
duas ou mais partes, que so usadas de forma sequencial, um para cada
nvel de tabela, at encontrar o nmero de quadro desejado. O nmero
de nveis da tabela depende da arquitetura considerada: os processadores
Intel 80.386 usam tabelas com dois nveis, os processadores Sun Sparc e DEC
Alpha usam tabelas com 3 nveis; processadores mais recentes, como Intel
Itanium, podem usar tabelas com 3 ou 4 nveis.
Um exemplo permite explicar melhor esse conceito: considerando uma
arquitetura de 32 bits com pginas de 4 Kbytes, 20 bits so usados para
acessar a tabela de pginas. Esses 20 bits podem ser divididos em dois
grupos de 10 bits que so usados como ndices em uma tabela de pginas
com dois nveis:
c Carlos Maziero
163
5: Alocao paginada
01805E9AH 0000 0001 1000 0000 0101 1110 1001 10102

0000 0001 102 e 00 0000 01012 e 1110 1001 10102
|
{z
} |
{z
} |
{z
}
10 bits
10 bits
12 bits
0006H e 0005H e E9AH
p1 0006H , p2 0005H e offset E9AH
A traduo de endereos lgicos em fsicos usando uma tabela de pginas
estruturada em dois nveis efetuada atravs dos seguintes passos, que so
ilustrados na Figura 5.14:
1. o endereo lgico el (0180 5E9AH ) decomposto em um offset de 12
bits o (E9AH ) e dois nmeros de pgina de 10 bits cada: o nmero de
pgina de primeiro nvel p1 (006H ) e o nmero de pgina de segundo
nvel p2 (005H );
2. o nmero de pgina p1 usado como ndice na tabela de pgina de
primeiro nvel, para encontrar o endereo de uma tabela de pgina de
segundo nvel;
3. o nmero de pgina p2 usado como ndice na tabela de pgina
de segundo nvel, para encontrar o nmero de quadro q (2FH ) que
corresponde a [p1 p2 ];
4. o nmero de quadro q combinado ao offset o para obter o endereo
fsico e f (0002 FE9AH ) correspondente ao endereo lgico solicitado el.
Com a estruturao da tabela de pginas em nveis, a quantidade de
memria necessria para armazen-la diminui significativamente, sobretudo
no caso de processos pequenos. Considerando o processo apresentado
como exemplo na Figura 5.13, ele faria uso de uma tabela de primeiro
nvel e somente duas tabelas de segundo nvel (uma para mapear suas
primeiras pginas e outra para mapear suas ltimas pginas); todas as
demais entradas da tabela de primeiro nvel estariam vazias. Assumindo
que cada entrada de tabela ocupa 4 bytes, sero necessrios somente 12
Kbytes para armazenar essas trs tabelas (4 3 210 bytes). Na situao
limite onde um processo ocupa toda a memria possvel, seriam necessrias
c Carlos Maziero
164
5: Alocao paginada
processo P3
TCB(P3)
que ativou P3
PTBR
pg2
offset
2B
22
31
3 1A 3B
E9A
...
1 14
005
6C 21
4 17 13
4E
5 8E A4
2F
6 10
19
71 9A
7F
12
16
2C
0002F
quadro
offset
MMU
...
...
...
...
006
0 5C
0000000110 0000000101 111010011010
pg 1
Tabela de pginas
(em memria RAM)
1
PTBR
Memria RAM
ncleo
rea no-paginada
47
Figura 5.14: Tabela de pgina multi-nvel.

uma tabela de primeiro nvel e 1.024 tabelas de segundo nvel. Essas tabelas
ocupariam de 4 (210 210 + 210 ) bytes, ou seja, 0,098% a mais que se a tabela
de pginas fosse estruturada em um s nvel (4 220 bytes). Essas duas
situaes extremas de alocao esto ilustradas na Figura 5.15.
Cache da tabela de pginas
A estruturao das tabelas de pginas em vrios nveis resolve o problema
do espao ocupado pelas tabelas de forma muito eficiente, mas tem um
efeito colateral muito nocivo: aumenta drasticamente o tempo de acesso
memria. Como as tabelas de pginas so armazenadas na memria, cada
acesso a um endereo de memria implica em mais acessos para percorrer
a rvore de tabelas e encontrar o nmero de quadro desejado. Em um
sistema com tabelas de dois nveis, cada acesso memria solicitado pelo
c Carlos Maziero
165
5: Alocao paginada
Nvel 1
...
Nvel 2
RAM (quadros)
Nvel 1
...
Nvel 2
...
...
...
RAM (quadros)
Figura 5.15: Tabela de pginas multi-nvel vazia (alto) e cheia (baixo).

processador implica em mais dois acessos, para percorrer os dois nveis de
tabelas. Com isso, o tempo efetivo de acesso memria se torna trs vezes
maior.
Quando um processo executa, ele acessa endereos de memria para
buscar instrues e operandos e ler/escrever dados. Em cada instante, os
acessos tendem a se concentrar em poucas pginas, que contm o cdigo e
as variveis usadas naquele instante3 . Dessa forma, a MMU ter de fazer
muitas tradues consecutivas de endereos nas mesmas pginas, que iro
3
Esse fenmeno conhecido como localidade de referncias e ser detalhado na Seo 5.4.
c Carlos Maziero
166
5: Alocao paginada
resultar nos mesmos quadros de memria fsica. Por isso, consultas recentes
tabela de pginas so armazenadas em um cache dentro da prpria MMU,
evitando ter de repeti-las constantemente e assim diminuindo o tempo de
acesso memria fsica.
O cache de tabela de pginas na MMU, denominado TLB (Translation
Lookaside Buffer) ou cache associativo, armazena pares [pgina, quadro] obtidos
em consultas recentes s tabelas de pginas do processo ativo. Esse cache
funciona como uma tabela de hash: dado um nmero de pgina p em sua
entrada, ele apresenta em sua sada o nmero de quadro q correspondente,
ou um flag de erro chamado erro de cache (cache miss). Por ser implementado
em um hardware especial rpido e caro, geralmente esse cache pequeno:
TLBs de processadores tpicos tm entre 16 e 256 entradas. Seu tempo
de acesso pequeno: um acerto custa cerca de 1 ciclo de relgio da CPU,
enquanto um erro pode custar entre 10 e 30 ciclos.
A traduo de endereos lgicos em fsicos usando TLBs se torna mais
rpida, mas tambm mais complexa. Ao receber um endereo lgico, a
MMU consulta o TLB; caso o nmero do quadro correspondente esteja em
cache, ele usado para compor o endereo fsico e o acesso memria
efetuado. Caso contrrio, uma busca normal (completa) na tabela de pginas
deve ser realizada. O quadro obtido nessa busca usado para compor o
endereo fsico e tambm adicionado ao TLB para agilizar as consultas
futuras. A Figura 5.16 apresenta os detalhes desse procedimento.
fcil perceber que, quanto maior a taxa de acertos do TLB (cache hit
ratio), melhor o desempenho dos acessos memria fsica. O tempo mdio
de acesso memria pode ento ser determinado pela mdia ponderada
entre o tempo de acesso com acerto de cache e o tempo de acesso no caso de
erro. Por exemplo, considerando um sistema operando a 2 GHz (relgio
de 0,5 ns) com tempo de acesso RAM de 50 ns, tabelas de pginas com 3
nveis e um TLB com custo de acerto de 0,5 ns (um ciclo de relgio), custo de
erro de 10 ns (20 ciclos de relgio) e taxa de acerto de 95%, o tempo mdio
de acesso memria pode ser estimado como segue:
tmdio = 95% 0, 5ns
+ 5% (10ns + 3 50ns)
+ 50ns
tmdio = 58, 475ns
// em caso de acerto
// em caso de erro, consultar as tabel
// acesso ao quadro desejado
c Carlos Maziero
167
5: Alocao paginada
processo P3
TCB(P3)
0000000110 0000000101 111010011010
pg 1
Tabela de pginas
(em memria RAM)
2
PTBR
que ativou P3
PTBR
pg2
offset
006
E9A
...
01805
TLB
p1,p2
0 5C
2B
1 14
22
31
3 1A 3B
2F
6 10
0002F
4E
5 8E A4
19
71 9A
7F
12
16
2C
0002F
quadro
offset
MMU
...
...
...
...
update
6C 21
4 17 13
005
Memria RAM
ncleo
rea no-paginada
47
Figura 5.16: Uso da TLB.

Este resultado indica que o sistema de paginao multi-nvel aumenta em
8,475 ns (16,9%) o tempo de acesso memria, o que razovel considerandose os benefcios e flexibilidade que esse sistema traz. Todavia, esse custo
muito dependente da taxa de acerto do TLB: no clculo anterior, caso a taxa
de acerto fosse de 90%, o custo adicional seria de 32,9%; caso a taxa subisse
a 99%, o custo adicional cairia para 4,2%.
Obviamente, quanto mais entradas houverem no TLB, melhor ser sua
taxa de acerto. Contudo, trata-se de um hardware caro e volumoso, por
isso os processadores atuais geralmente tm TLBs com poucas entradas
(geralmente entre 16 e 256 entradas). Por exemplo, o Intel i386 tem um
TLB com 64 entradas para pginas de dados e 32 entradas para pginas de
cdigo; por sua vez, o Intel Itanium tem 128 entradas para pginas de dados
e 96 entradas para pginas de cdigo.
c Carlos Maziero
168
5: Alocao segmentada paginada
O tamanho do TLB um fator que influencia a sua taxa de acertos, mas

h outros fatores importantes a considerar, como a poltica de substituio
das entradas do TLB. Essa poltica define o que ocorre quando h um erro de
cache e no h entradas livres no TLB: em alguns processadores, a associao
[pgina, quadro] que gerou o erro adicionada ao cache, substituindo a entrada mais antiga; todavia, na maioria dos processadores mais recentes, cada
erro de cache provoca uma interrupo, que transfere ao sistema operacional
a tarefa de gerenciar o contedo do TLB [Patterson and Henessy, 2005].
Outro aspecto que influencia significativamente a taxa de acerto do TLB
a forma como cada processo acessa a memria. Processos que concentram
seus acessos em poucas pginas de cada vez faro um uso eficiente desse
cache, enquanto processos que acessam muitas pginas distintas em um
curto perodo iro gerar frequentes erros de cache, prejudicando seu desempenho no acesso memria. Essa propriedade conhecida como localidade
de referncia (Seo 5.4).
Finalmente, importante observar que o contedo do TLB reflete a
tabela de pginas ativa, que indica as pginas de memria pertencentes ao
processo em execuo naquele momento. A cada troca de contexto, a tabela
de pginas substituda e portanto o cache TLB deve ser esvaziado, pois seu
contedo no mais vlido. Isso permite concluir que trocas de contexto
muito frequentes prejudicam a eficincia de acesso memria, tornando o
sistema mais lento.
5.3.5
Alocao segmentada paginada
Cada uma das principais formas de alocao de memria vistas at agora

tem suas vantagens: a alocao contgua prima pela simplicidade e rapidez;
a alocao por segmentos oferece mltiplos espaos de endereamento
para cada processo, oferecendo flexibilidade ao programador; a alocao
por pginas oferece um grande espao de endereamento linear, enquanto
elimina a fragmentao externa. Alguns processadores oferecem mais de
uma forma de alocao, deixando aos projetistas do sistema operacional a
escolha da forma mais adequada de organizar a memria usada por seus
processos.
Vrios processadores permitem combinar mais de uma forma de alocao.
Por exemplo, os processadores Intel i386 permitem combinar a alocao com
segmentos com a alocao por pginas, visando oferecer a flexibilidade da
alocao por segmentos com a baixa fragmentao da alocao por pginas.
c Carlos Maziero
169
5: Localidade de referncias
Nessa abordagem, os processos vem a memria estruturada em segmentos, conforme indicado na Figura 5.9. O hardware da MMU converte os
endereos lgicos na forma [segmento:offset] para endereos lgicos lineares
(unidimensionais), usando as tabelas de descritores de segmentos (Seo
5.3.3). Em seguida, esse endereos lgicos lineares so convertidos nos endereos fsicos correspondentes atravs do hardware de paginao (tabelas
de pginas e TLB), visando obter o endereo fsico correspondente.
Apesar do processador Intel i386 oferece as duas formas de alocao de
memria, a maioria dos sistemas operacionais que o suportam no fazem
uso de todas as suas possibilidades: os sistemas da famlia Windows NT
(2000, XP, Vista) e tambm os da famlia UNIX (Linux, FreeBSD) usam
somente a alocao por pginas. O antigo DOS e o Windows 3.* usavam
somente a alocao por segmentos. O OS/2 da IBM foi um dos poucos
sistemas operacionais comerciais a fazer uso pleno das possibilidades de
alocao de memria nessa arquitetura, combinando segmentos e pginas.
5.4
Localidade de referncias
A forma como os processos acessam a memria tem um impacto direto

na eficincia dos mecanismos de gerncia de memria, sobretudo o cache
de pginas (TLB, Seo 5.3.4) e o mecanismo de memria virtual (Seo
5.7). Processos que concentram seus acessos em poucas pginas de cada vez
faro um uso eficiente desses mecanismos, enquanto processos que acessam
muitas pginas distintas em um curto perodo iro gerar frequentes erros
de cache (TLB) e faltas de pgina, prejudicando seu desempenho no acesso
memria.
A propriedade de um processo ou sistema concentrar seus acessos em
poucas reas da memria a cada instante chamada localidade de referncias
[Denning, 2006]. Existem ao menos trs formas de localidade de referncias:
Localidade temporal : um recurso usado h pouco tempo ser provavelmente usado novamente em um futuro prximo (esta propriedade
usada pelos algoritmos de gerncia de memria virtual);
Localidade espacial : um recurso ser mais provavelmente acessado se
outro recurso prximo a ele j foi acessado ( a propriedade verificada
na primeira execuo);
c Carlos Maziero
170
Localidade sequencial : um caso particular da localidade espacial, no

qual h uma predominncia de acesso sequencial aos recursos (esta
propriedade til na otimizao de sistemas de arquivos).
Como exemplo prtico da importncia da localidade de referncias, considere um programa para o preenchimento de uma matriz de 4.096 4.096
bytes, onde cada linha da matriz est alocada em uma pgina distinta (considerando pginas de 4.096 bytes). O trecho de cdigo a seguir implementa
essa operao, percorrendo a matriz linha por linha:
1
unsigned char buffer[4096][4096] ;
2
3
4
5
int main ()
{
int i, j ;
for (i=0; i<4096; i++) // percorre as linhas do buffer

for (j=0; j<4096; j++) // percorre as colunas do buffer
buffer[i][j]= (i+j) % 256 ;
7
8
9
10
Outra implementao possvel seria percorrer a matriz coluna por coluna,

conforme o cdigo a seguir:
1
unsigned char buffer[4096][4096] ;
2
3
4
5
int main ()
{
int i, j ;
for (j=0; j<4096; j++) // percorre as colunas do buffer

for (i=0; i<4096; i++) // percorre as linhas do buffer
buffer[i][j]= (i+j) % 256 ;
7
8
9
10
Embora percorram a matriz de forma distinta, os dois programas geram

o mesmo resultado e so conceitualmente equivalentes (a Figura 5.17 mostra
o padro de acesso memria dos dois programas). Entretanto, eles no
tm o mesmo desempenho. A primeira implementao (percurso linha
por linha) usa de forma eficiente o cache da tabela de pginas, porque
s gera um erro de cache a cada nova linha acessada. Por outro lado, a
implementao com percurso por colunas gera um erro de cache TLB a
c Carlos Maziero
171
cada clula acessada, pois o cache TLB no tem tamanho suficiente para
armazenar as 4.096 entradas referentes s pginas usadas pela matriz.
A diferena de desempenho entre as duas implementaes pode ser
grande: em processadores Intel e AMD, verses 32 e 64 bits, o primeiro
cdigo executa cerca de 10 vezes mais rapidamente que o segundo! Alm
disso, caso o sistema no tenha memria suficiente para manter as 4.096
pginas em memria, o mecanismo de memria virtual ser ativado, fazendo
com que a diferena de desempenho seja muito maior.
i
pginas
4095
1
2
3
4
4095
Figura 5.17: Comportamento dos programas no acesso memria.

A diferenca de comportamento das duas execues pode ser observada na
Figura 5.18, que mostra a distribuio dos endereos de memria acessados
pelos dois cdigos4 . Nos grficos, percebe-se claramente que a primeira
implementao tem uma localidade de referncias muito mais forte que a
segunda: enquanto a primeira execuo usa em mdia 5 pginas distintas
em cada 100.000 acessos memria, na segunda execuo essa mdia sobe
para 3.031 pginas distintas.
A Figura 5.19 traz outro exemplo de boa localidade de referncias. Ela
mostra as pginas acessadas durante uma execuo do visualizador grfico
gThumb, ao abrir um arquivo de imagem. O grfico da esquerda d uma
viso geral da distribuio dos acessos na memria, enquanto o grfico da
4
Como a execuo total de cada cdigo gera mais de 500 milhes de referncias
memria, foi feita uma amostragem da execuo para construir os grficos.
c Carlos Maziero
172
Figura 5.18: Localidade de referncias nas duas execues.

direita detalha os acessos da parte inferior, que corresponde s reas de
cdigo, dados e heap do processo.
Figura 5.19: Distribuio dos acessos memria do programa gThumb: viso

geral ( esquerda) e detalhe da parte inferior ( direita).
A localidade de referncia de uma implementao depende de um
conjunto de fatores, que incluem:
As estruturas de dados usadas pelo programa: estruturas como vetores
e matrizes tm seus elementos alocados de forma contgua na memria,
o que leva a uma localidade de referncias maior que estruturas mais
dispersas, como listas encadeadas e rvores;
Os algoritmos usados pelo programa: o comportamento do programa
no acesso memria definido pelos algoritmos que ele implementa;
c Carlos Maziero
173
5: Fragmentao
A qualidade do compilador: cabe ao compilador analisar quais variveis e trechos de cdigo so usadas com frequncia juntos e coloc-los
nas mesmas pginas de memria, para aumentar a localidade de
referncias do cdigo gerado.
A localidade de referncias uma propriedade importante para a construo de programas eficientes. Ela tambm til em outras reas da
computao, como a gerncia das pginas armazenadas nos caches de
navegadores web e servidores proxy, nos mecanismos de otimizao de
leituras/escritas em sistemas de arquivos, na construo da lista arquivos
recentes dos menus de muitas aplicaes interativas, etc.
5.5
Fragmentao
Ao longo da vida de um sistema, reas de memria so liberadas por

processos que concluem sua execuo e outras reas so alocadas por novos
processos, de forma contnua. Com isso, podem surgir reas livres (vazios
ou buracos na memria) entre os processos, o que constitui um problema
conhecido como fragmentao externa. Esse problema somente afeta as
estratgias de alocao que trabalham com blocos de tamanho varivel,
como a alocao contgua e a alocao segmentada. Por outro lado, a
alocao paginada sempre trabalha com blocos de mesmo tamanho (os
quadros e pginas), sendo por isso imune fragmentao externa.
A fragmentao externa prejudicial porque limita a capacidade de
alocao de memria no sistema. A Figura 5.20 apresenta um sistema com
alocao contgua de memria no qual ocorre fragmentao externa. Nessa
Figura, observa-se que existem 68 MBytes de memria livre em quatro
reas separadas (A1 . . . A4 ), mas somente processos com at 28 MBytes
podem ser alocados (usando a maior rea livre, A4 ). Alm disso, quanto
mais fragmentada estiver a memria livre, maior o esforo necessrio para
gerenci-la: as reas livres so mantidas em uma lista encadeada de rea
de memria, que manipulada a cada pedido de alocao ou liberao de
memria.
Pode-se enfrentar o problema da fragmentao externa de duas formas:
minimizando sua ocorrncia, atravs de critrios de escolha das reas a alocar,
ou desfragmentando periodicamente a memria do sistema. Para minimizar
a ocorrncia de fragmentao externa, cada pedido de alocao deve ser
c Carlos Maziero
174
5: Fragmentao
A1: 20M
ncleo
A2: 8M
P1
24M
P3
P2
40M
60M
A3: 12M
72M
80M
88M
A4: 28M
P4
100M
116M
144M
Figura 5.20: Memria com fragmentao externa.

analisado para encontrar a rea de memria livre que melhor o atenda. Essa
anlise pode ser feita usando um dos seguintes critrios:
Melhor encaixe (best-fit) : consiste em escolher a menor rea possvel que
possa atender solicitao de alocao. Dessa forma, as reas livres so
usadas de forma otimizada, mas eventuais resduos (sobras) podem
ser pequenos demais para ter alguma utilidade.
Pior encaixe (worst-fit) : consiste em escolher sempre a maior rea livre
possvel, de forma que os resduos sejam grandes e possam ser usados
em outras alocaes.
Primeiro encaixe (first-fit) : consiste em escolher a primeira rea livre
que satisfaa o pedido de alocao; tem como vantagem a rapidez,
sobretudo se a lista de reas livres for muito longa.
Prximo encaixe (next-fit) : variante da anterior (first-fit) que consiste em
percorrer a lista a partir da ltima rea alocada ou liberada, para que
o uso das reas livres seja distribudo de forma mais homognea no
espao de memria.
Diversas pesquisas [Johnstone and Wilson, 1999] demonstraram que as
abordagens mais eficientes so a de melhor encaixe e a de primeiro encaixe,
sendo esta ltima bem mais rpida. A Figura 5.21 ilustra essas estratgias.
Outra forma de tratar a fragmentao externa consiste em desfragmentar
a memria periodicamente. Para tal, as reas de memria usadas pelos
processos devem ser movidas na memria de forma a concatenar as reas
livres e assim diminuir a fragmentao. Ao mover um processo na memria,
suas informaes de alocao (registrador base ou tabela de segmentos)
devem ser ajustadas para refletir a nova posio do processo.
Obviamente, nenhum processo pode executar durante a desfragmentao. Portanto, importante que esse procedimento seja executado rapidamente e com pouca frequncia, para no interferir nas atividades normais
c Carlos Maziero
175
5: Fragmentao
alocao de 10M
rst-t
best-t
A1: 20M
ncleo
A2: 8M
P1
24M
40M
60M
A3: 12M
P3
P2
72M
worst-t
80M
88M
A4: 28M
P4
100M
116M
144M
Figura 5.21: Estratgias para minimizar a fragmentao externa.

do sistema. Como as possibilidades de movimentao de processos podem
ser muitas, a desfragmentao deve ser tratada como um problema de otimizao combinatria, cuja soluo tima pode ser difcil de calcular. A Figura
5.22 ilustra trs possibilidades de desfragmentao de uma determinada
situao de memria; as trs alternativas produzem o mesmo resultado,
mas apresentam custos distintos.
Situao inicial
ncleo
P1
P3
P2
30M
40M
20M
30M
40M
20M
Soluo 1: deslocar P2 e P3 (custo: mover 60M)
ncleo
P1
P3
P2
Soluo 2: deslocar P3 (custo: mover 40M)
ncleo
P1
P3
P2
Soluo 3: deslocar P3 (custo: mover 20M)
ncleo
P1
P3
P2
Figura 5.22: Possibilidades de desfragmentao.

Alm da fragmentao externa, que afeta as reas livres entre os processos, as estratgias de alocao de memria tambm podem apresentar a
fragmentao interna, que pode ocorrer dentro das reas alocadas aos proces-
c Carlos Maziero
176
5: Fragmentao
sos. A Figura 5.23 apresenta uma situao onde ocorre esse problema: um
novo processo requisita uma rea de memria com 4.900 Kbytes. Todavia, a
rea livre disponvel tem 5.000 Kbytes. Se for alocada exatamente a rea
solicitada pelo processo (situao A), sobrar um fragmento residual com
100 Kbytes, que praticamente intil para o sistema, pois muito pequeno
para acomodar novos processos. Alm disso, essa rea residual de 100
Kbytes deve ser includa na lista de reas livres, o que representa um custo
de gerncia desnecessrio. Outra possibilidade consiste em arredondar
o tamanho da rea solicitada pelo processo para 5.000 Kbytes, ocupando
totalmente aquela rea livre (situao B). Assim, haver uma pequena rea
de 100 Kbytes no final da memria do processo, que provavelmente no
ser usada por ele.
situao inicial
5.000 Kbytes
Pedido de alocao de 4.900 Kbytes
Soluo 1:
aloca 4.900 Kbytes
4.900 Kbytes
fragmentao externa
Soluo 2:
aloca 5.000 Kbytes
5.000 Kbytes
fragmentao interna
Figura 5.23: Fragmentao interna.

A fragmentao interna afeta todas as formas de alocao; as alocaes
contgua e segmentada sofrem menos com esse problema, pois o nvel de
arredondamento das alocaes pode ser decidido caso a caso. No caso
da alocao paginada, essa deciso no possvel, pois as alocaes so
feitas em pginas inteiras. Assim, em um sistema com pginas de 4 Kbytes
(4.096 bytes), um processo que solicite a alocao de 550.000 bytes (134,284
pginas) receber 552.960 bytes (135 pginas), ou seja, 2.960 bytes a mais
que o solicitado.
c Carlos Maziero
177
5: Compartilhamento de memria
Em mdia, para cada processo haver uma perda de 1/2 pgina de

memria por fragmentao interna. Assim, uma forma de minimizar a
perda por fragmentao interna seria usar pginas de menor tamanho (2K,
1K, 512 bytes ou ainda menos). Todavia, essa abordagem implica em ter
mais pginas por processo, o que geraria tabelas de pginas maiores e com
maior custo de gerncia.
5.6
Compartilhamento de memria
A memria RAM um recurso escasso, que deve ser usado de forma

eficiente. Nos sistemas atuais, comum ter vrias instncias do mesmo
programa em execuo, como vrias instncias de editores de texto, de
navegadores, etc. Em servidores, essa situao pode ser ainda mais frequente,
com centenas ou milhares de instncias do mesmo programa carregadas
na memria. Por exemplo, em um servidor de e-mail UNIX, cada cliente
que se conecta atravs dos protocolos POP3 ou IMAP ter um processo
correspondente no servidor, para atender suas consultas de e-mail (Figura
5.24). Todos esses processos operam com dados distintos (pois atendem
a usurios distintos), mas executam o mesmo cdigo. Assim, centenas
ou milhares de cpias do mesmo cdigo executvel podero coexistir na
memria do sistema.
cliente 1
code
data1 heap1 stack1
code
data2 heap2 stack2
code
data3 heap3 stack3
code
data4 heap4 stack4
cliente 3
cliente 5
cliente 2
cliente 4
code
data5 heap5 stack5
code
datan heapn stackn
...
servidor de e-mail
cliente n
Figura 5.24: Vrias instncias do mesmo processo.

Conforme visto na Seo 5.2.2, a estrutura tpica da memria de um
processo contm reas separadas para cdigo, dados, pilha e heap. Normal-
c Carlos Maziero
178
mente, a rea de cdigo no precisa ter seu contedo modificado durante a

execuo, portanto geralmente essa rea protegida contra escritas (readonly). Assim, seria possvel compartilhar essa rea entre todos os processos
que executam o mesmo cdigo, economizando memria fsica.
O compartilhamento de cdigo entre processos pode ser implementado
de forma muito simples e transparente para os processos envolvidos, atravs
dos mecanismos de traduo de endereos oferecidos pela MMU, como
segmentao e paginao. No caso da segmentao, bastaria fazer com
que todos os segmentos de cdigo dos processos apontem para o mesmo
segmento da memria fsica, como indica a Figura 5.25. importante
observar que o compartilhamento transparente para os processos: cada
processo continua a acessar endereos lgicos em seu prprio segmento de
cdigo, buscando suas instrues a executar.
S4
S4
S3
S2
S4
S3
S2
S1
S3
S2
P2
S1
S1
P1
P3
Memria RAM
ncleo
0
P1.S2
P2.S4
P1.S3
P3.S4
P*.S1
P3.S3
P1.S3
P3.S2
P2.S3
P1.S4
max
Figura 5.25: Compartilhamento de segmentos.

No caso da paginao, a unidade bsica de compartilhamento a
pgina. Assim, as entradas das tabelas de pginas dos processos envolvidos
so ajustadas para referenciar os mesmos quadros de memria fsica.
importante observar que, embora referenciem os mesmos endereos fsicos,
as pginas compartilhadas podem ter endereos lgicos distintos. A Figura
5.26 ilustra o compartilhamento de pginas entre processos.
O compartilhamento das reas de cdigo permite proporcionar uma
grande economia no uso da memria fsica, sobretudo em servidores e
sistemas multi-usurios. Por exemplo: consideremos um processador de
textos que necessite de 100 MB de memria para executar, dos quais 60 MB
c Carlos Maziero
179
processo P1
processo P2
Memria RAM
ncleo
rea no-paginada
Figura 5.26: Compartilhamento de pginas.

so ocupados por cdigo executvel. Sem o compartilhamento de reas de
cdigo, 10 instncias do editor consumiriam 1.000 MB de memria; com o
compartilhamento, esse consumo cairia para 460 MB (60MB + 10 40MB).
O mecanismo de compartilhamento de memria no usado apenas com
reas de cdigo; em princpio, toda rea de memria protegida contra escrita
pode ser compartilhada, o que poderia incluir reas de dados constantes,
como tabelas de constantes, textos de ajuda, etc., proporcionando ainda
mais economia de memria.
Uma forma mais agressiva de compartilhamento de memria proporcionada pelo mecanismo denominado copiar-ao-escrever (COW - Copy-On-Write).
Nele, todas as reas de memria de um processo (segmentos ou pginas)
so passveis de compartilhamento por outros processos, condio que ele
ainda no tenha modificado seu contedo. A idia central do mecanismo
simples:
1. ao carregar um novo processo em memria, o ncleo protege todas as
reas de memria do processo contra escrita (inclusive dados, pilha e
heap), usando os flags da tabela de pginas (ou de segmentos);
2. quando o processo tentar escrever na memria, a MMU gera uma
interrupo (negao de escrita) para o ncleo do sistema operacional;
3. o sistema operacional ajusta ento os flags daquela rea para permitir
a escrita e devolve a execuo ao processo, para ele poder continuar;
4. processos subsequentes idnticos ao primeiro, ao serem carregados em
memria, sero mapeados sobre as mesmas reas de memria fsica
c Carlos Maziero
180
5: Memria virtual
do primeiro processo que ainda estiverem protegidas contra escrita,

ou seja, que ainda no foram modificadas por ele;
5. se um dos processos envolvidos tentar escrever em uma dessas reas
compartilhadas, a MMU gera uma interrupo para o ncleo;
6. o ncleo ento faz uma cpia separada daquela rea fsica para o
processo que deseja escrever nela e desfaz seu compartilhamento,
ajustando as tabelas do processo que provocou a interrupo. Os
demais processos continuam compartilhando a rea inicial.
Todo esse procedimento feito de forma transparente para os processos
envolvidos, visando compartilhar ao mximo as reas de memria dos
processos e assim otimizar o uso da RAM. Esse mecanismo mais efetivo
em sistemas baseados em pginas, porque normalmente as pginas so
menores que os segmentos. A maioria dos sistemas operacionais atuais
(Linux, Windows, Solaris, FreeBSD, etc.) usa esse mecanismo.
reas de memria compartilhada tambm podem ser usadas para
permitir a comunicao entre processos. Para tal, dois ou mais processos
solicitam ao ncleo o mapeamento de uma rea de memria comum, sobre
a qual podem ler e escrever. Como os endereos lgicos acessados nessa
rea sero mapeados sobre a mesma rea de memria fsica, o que cada
processo escrever nessa rea poder ser lido pelos demais, imediatamente.
importante observar que os endereos lgicos em cada processo podero
ser distintos, pois isso depende do mapeamento feito pela tabela de pginas
(ou de segmentos) de cada processo; apenas os endereos fsicos sero iguais.
Portanto, ponteiros (variveis que contm endereos lgicos) armazenados
na rea compartilhada tero significado para o processo que os escreveu,
mas no necessariamente para os demais processos que acessam aquela
rea. A Seo 3.4.3 traz informaes mais detalhadas sobre a comunicao
entre processos atravs de memria compartilhada.
5.7
Memria virtual
Um problema constante nos computadores a disponibilidade de memria fsica: os programas se tornam cada vez maiores e cada vez mais
processos executam simultaneamente, ocupando a memria disponvel.
Alm disso, a crescente manipulao de informaes multimdia (imagens,
c Carlos Maziero
181
5: Mecanismo bsico
udio, vdeo) contribui para esse problema, uma vez que essas informaes
so geralmente volumosas e seu tratamento exige grandes quantidades
de memria livre. Como a memria RAM um recurso caro (cerca de
U$50/GByte no mercado americano, em 2007) e que consome uma quantidade significativa de energia, aumentar sua capacidade nem sempre uma
opo factvel.
Observando o comportamento de um sistema computacional, constata-se
que nem todos os processos esto constantemente ativos, e que nem todas as
reas de memria esto constantemente sendo usadas. Por isso, as reas de
memria pouco acessadas poderiam ser transferidas para um meio de armazenamento mais barato e abundante, como um disco rgido (U$0,50/GByte)
ou um banco de memria flash (U$10/GByte)5 , liberando a memria RAM
para outros usos. Quando um processo proprietrio de uma dessas reas
precisar acess-la, ela deve ser transferida de volta para a memria RAM.
O uso de um armazenamento externo como extenso da memria RAM
se chama memria virtual; essa estratgia pode ser implementada de forma
eficiente e transparente para processos, usurios e programadores.
5.7.1
Mecanismo bsico
Nos primeiros sistemas a implementar estratgias de memria virtual,

processos inteiros eram transferidos da memria para o disco rgido e
vice-versa. Esse procedimento, denominado troca (swapping) permite liberar
grandes reas de memria a cada transferncia, e se justifica no caso de
um armazenamento com tempo de acesso muito elevado, como os antigos
discos rgidos. Os sistemas atuais raramente transferem processos inteiros
para o disco; geralmente as transferncias so feitas por pginas ou grupos
de pginas, em um procedimento denominado paginao (paging), detalhado
a seguir.
Normalmente, o mecanismo de memria virtual se baseia em pginas ao
invs de segmentos. As pginas tm um tamanho nico e fixo, o que permite
simplificar os algoritmos de escolha de pginas a remover, os mecanismos
de transferncia para o disco e tambm a formatao da rea de troca no
disco. A otimizao desses fatores seria bem mais complexa e menos efetiva
caso as operaes de troca fossem baseadas em segmentos, que tm tamanho
varivel.
5
Estes valores so apenas indicativos, variando de acordo com o fabricante e a tecnologia
envolvida.
c Carlos Maziero
182
5: Mecanismo bsico
A idia central do mecanismo de memria virtual em sistemas com

memria paginada consiste em retirar da memria principal as pginas
menos usadas, salvando-as em uma rea do disco rgido reservada para
esse fim. Essa operao feita periodicamente, de modo reativo (quando a
quantidade de memria fsica disponvel cai abaixo de um certo limite) ou
pr-ativo (aproveitando os perodos de baixo uso do sistema para retirar
da memria as pginas pouco usadas). As pginas a retirar so escolhidas
de acordo com algoritmos de substituio de pginas, discutidos na Seo
5.7.3. As entradas das tabelas de pginas relativas s pginas transferidas
para o disco devem ento ser ajustadas de forma a referenciar os contedos
correspondentes no disco rgido. Essa situao est ilustrada de forma
simplificada na Figura 5.27.
processo P2
processo P1
0
rea de troca
Memria RAM
ncleo
rea no-paginada
Figura 5.27: Memria virtual paginada.

O armazenamento externo das pginas pode ser feito em em um disco
exclusivo para esse fim (usual em servidores de maior porte), em uma
partio do disco principal (usual no Linux e outros UNIX) ou em um
arquivo reservado dentro do sistema de arquivos do disco principal da
mquina, geralmente oculto (como no Windows NT e sucessores). Em
alguns sistemas, possvel usar uma rea de troca remota, em um servidor
de arquivos de rede; todavia, essa soluo apresenta baixo desempenho. Por
razes histricas, essa rea de disco geralmente denominada rea de troca
(swap area), embora armazene pginas. No caso de um disco exclusivo ou
partio de disco, essa rea geralmente formatada usando uma estrutura
de sistema de arquivos otimizada para o armazenamento e recuperao
rpida das pginas.
c Carlos Maziero
183
5: Mecanismo bsico
As pginas que foram transferidas da memria para o disco provavelmente sero necessrias no futuro, pois seus processos proprietrios
provavelmente continuam vivos. Quando um processo tentar acessar uma
pgina ausente, esta deve ser transferida de volta para a memria para
permitir seu acesso, de forma transparente ao processo. Conforme exposto
na Seo 5.3.4, quando um processo acessa uma pgina, a MMU verifica
se a mesma est mapeada na memria RAM e, em caso positivo, faz o
acesso ao endereo fsico correspondente. Caso contrrio, a MMU gera uma
interrupo de falta de pgina (page fault) que fora o desvio da execuo
para o sistema operacional. Nesse instante, o sistema deve verificar se
a pgina solicitada no existe ou se foi transferida para o disco, usando
os flags de controle da respectiva entrada da tabela de pginas. Caso a
pgina no exista, o processo tentou acessar um endereo invlido e deve
ser abortado. Por outro lado, caso a pgina solicitada tenha sido transferida
para o disco, o processo deve ser suspenso enquanto o sistema transfere
a pgina de volta para a memria RAM e faz os ajustes necessrios na
tabela de pginas. Uma vez a pgina carregada em memria, o processo
pode continuar sua execuo. O fluxograma da Figura 5.28 apresenta as
principais aes desenvolvidas pelo mecanismo de memria virtual.
Nesse procedimento aparentemente simples h duas questes importantes. Primeiro, caso a memria principal j esteja cheia, uma ou mais pginas
devero ser removidas para o disco antes de trazer de volta a pgina faltante.
Isso implica em mais operaes de leitura e escrita no disco e portanto em
mais demora para atender o pedido do processo. Muitos sistemas, como o
Linux e o Solaris, mantm um processo daemon com a finalidade de escolher
e transferir pginas para o disco, ativado sempre que a quantidade de
memria livre estiver abaixo de um limite mnimo.
Segundo, retomar a execuo do processo que gerou a falta de pgina
pode ser uma tarefa complexa. Como a instruo que gerou a falta de
pgina no foi completada, ela deve ser re-executada. No caso de instrues
simples, envolvendo apenas um endereo de memria sua re-execuo
trivial. Todavia, no caso de instrues que envolvam vrias aes e vrios
endereos de memria, deve-se descobrir qual dos endereos gerou a falta de
pgina, que aes da instruo foram executadas e ento executar somente o
que estiver faltando. A maioria dos processadores atuais prov registradores
especiais que auxiliam nessa tarefa.
c Carlos Maziero
184
5: Eficincia de uso
processo P tenta acessar uma pgina X
sim
a pgina X
est presente?
no
MMU gera interrupo (falta de pgina)
a pgina X
existe?
no
endereo invlido: aborta o processo P
sim
suspende o processo P
h espao
na memria?
no
escolhe uma pgina "vtima",

transfere essa pgina para o disco,
ajusta a tabela de pginas
sim
carrega a pgina X na memria,
ajusta a tabela de pginas de P,
acorda o processo P
P acessa a pgina X
Figura 5.28: Aes do mecanismo de memria virtual.
5.7.2
Eficincia de uso
O mecanismo de memria virtual permite usar o disco como uma

extenso de memria RAM, de forma transparente para os processos. Seria
a soluo ideal para as limitaes da memria principal, se no houvesse um
problema importante: o tempo de acesso dos discos utilizados. Conforme
os valores indicados na Tabela 5.1, um disco rgido tpico tem um tempo
de acesso cerca de 100.000 vezes maior que a memria RAM. Cada falta de
pgina provocada por um processo implica em um acesso ao disco, para
buscar a pgina faltante (ou dois acessos, caso a memria RAM esteja cheia
e outra pgina tenha de ser removida antes). Assim, faltas de pgina muito
c Carlos Maziero
185
5: Eficincia de uso
frequentes iro gerar muitos acessos ao disco, aumentando o tempo mdio

de acesso memria e, em consequncia, diminuindo o desempenho geral
do sistema.
Para demonstrar o impacto das faltas de pgina no desempenho, consideremos um sistema cuja memria RAM tem um tempo de acesso de 60 ns
(60 109 s) e cujo disco de troca tem um tempo de acesso de 6 ms (6 103 s),
no qual ocorre uma falta de pgina a cada milho de acessos (106 acessos).
Caso a memria no esteja saturada, o tempo mdio de acesso ser:
(999.999 60ns) + 6ms + 60ns
1.000.000
106 60 109 + 6 103
=
106
tmdio =
tmdio = 66ns
Caso a memria esteja saturada, o tempo mdio ser maior:
(999.999 60ns) + 2 6ms + 60ns
1.000.000
6
10 60 109 + 2 6 103
=
106
tmdio =
tmdio = 72ns
Caso a frequncia de falta de pginas aumente para uma falta a cada
100.000 acessos (105 acessos), o tempo mdio de acesso memria subir
para 180 ns, ou seja, trs vezes mais lento. A frequncia de faltas de pgina
depende de vrios fatores, como:
O tamanho da memria RAM, em relao demanda dos processos em
execuo: sistemas com memria insuficiente, ou muito carregados,
podem gerar muitas faltas de pgina, prejudicando o seu desempenho
e podendo ocasionar o fenmeno conhecido como thrashing (Seo
5.7.6).
c Carlos Maziero
186
5: Algoritmos de substituio de pginas
o comportamento dos processos em relao ao uso da memria: processos que agrupem seus acessos a poucas pginas em cada momento,
respeitando a localidade de referncias (Seo 5.4), necessitam usar
menos pginas simultaneamente e geram menos faltas de pgina.
A escolha das pginas a remover da memria: caso sejam removidas
pginas usadas com muita frequncia, estas sero provavelmente
acessadas pouco tempo aps sua remoo, gerando mais faltas de
pgina. A escolha das pginas a remover tarefa dos algoritmos
apresentados na Seo 5.7.3.
5.7.3
Algoritmos de substituio de pginas
A escolha correta das pginas a remover da memria fsica um fator

essencial para a eficincia do mecanismo de memria virtual. Ms escolhas
podero remover da memria pginas muito usadas, aumentando a taxa de
faltas de pgina e e diminuindo o desempenho do sistema. Vrios critrios
podem ser usados para escolher vtimas, ou seja, pginas a transferir da
memria para a rea de troca no disco:
Idade da pgina : h quanto tempo a pgina est na memria; pginas
muito antigas talvez sejam pouco usadas.
Frequncia de acessos pgina : pginas muito acessadas em um passado
recente possivelmente ainda o sero em um futuro prximo.
Data do ltimo acesso : pginas h mais tempo sem acessar possivelmente
sero pouco acessadas em um futuro prximo (sobretudo se os processos respeitarem o princpio da localidade de referncias).
Prioridade do processo proprietrio : processos de alta prioridade, ou de
tempo-real, podem precisar de suas pginas de memria rapidamente;
se elas estiverem no disco, seu desempenho ou tempo de resposta
podero ser prejudicados.
Contedo da pgina : pginas cujo contedo seja cdigo executvel exigem
menos esforo do mecanismo de memria virtual, porque seu contedo
j est mapeado no disco (dentro do arquivo executvel correspondente
ao processo). Por outro lado, pginas de dados que tenham sido
alteradas precisam ser salvas na rea de troca.
c Carlos Maziero
187
Pginas especiais : pginas contendo buffers de operaes de entrada/sada

podem ocasionar dificuldades ao ncleo caso no estejam na memria
no momento em que ocorrer a transferncia de dados entre o processo
e o dispositivo fsico. O processo tambm pode solicitar que certas
pginas contendo informaes sensveis (como senhas ou chaves
criptogrficas) no sejam copiadas na rea de troca, por segurana.
Existem vrios algoritmos para a escolha de pginas a substituir na
memria, visando reduzir a frequncia de falta de pginas, que levam
em conta alguns dos fatores acima enumerados. Os principais sero
apresentados na sequncia.
Uma ferramenta importante para o estudo desses algoritmos a cadeia
de referncias (reference string), que indica a sequncia de pginas acessadas
por um processo durante sua execuo. Ao submeter a cadeia de referncias
de uma execuo aos vrios algoritmos, podemos calcular quantas faltas de
pgina cada um geraria naquela execuo em particular e assim comparar
sua eficincia.
Cadeias de referncias de execues reais podem ser muito longas:
considerando um tempo de acesso memria de 50 ns, em apenas um
segundo de execuo ocorrem por volta de 20 milhes de acessos memria.
Alm disso, a obteno de cadeias de referncias confiveis uma rea de
pesquisa importante, por envolver tcnicas complexas de coleta, filtragem
e compresso de dados de execuo de sistemas [Uhlig and Mudge, 1997].
Para possibilitar a comparao dos algoritmos de substituio de pginas
apresentados na sequncia, ser usada a seguinte cadeia de referncias
fictcia, extrada de [Tanenbaum, 2003]:
0, 2, 1, 3, 5, 4, 6, 3, 7, 4, 7, 3, 3, 5, 5, 3, 1, 1, 1, 7, 1, 3, 4, 1
Deve-se observar que acessos consecutivos a uma mesma pgina no
so relevantes para a anlise dos algoritmos, porque somente o primeiro
acesso em cada grupo de acessos consecutivos provoca uma falta de pgina.
Algoritmo FIFO
Um critrio bsico a considerar para a escolha das pginas a substituir
poderia ser sua idade, ou seja, o tempo em que esto na memria. Assim,
pginas mais antigas podem ser removidas para dar lugar a novas pginas.
Esse algoritmo muito simples de implementar: basta organizar as pginas
c Carlos Maziero
188
em uma fila de nmeros de pginas com poltica FIFO (First In, First Out).
Os nmeros das pginas recm carregadas na memria so registrados no
final da lista, enquanto os nmeros das prximas pginas a substituir na
memria so obtidos no incio da lista.
A aplicao do algoritmo FIFO cadeia de referncias apresentada
na Seo anterior, considerando uma memria fsica com 3 quadros,
apresentada na Tabela 5.2. Nesse caso, o algoritmo gera no total 15 faltas de
pgina.
t
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
qo
0
0
0
3
3
3
6
6
6
4
4
4
4
4
4
4
1
1
1
1
1
1
1
antes
q1
2
2
2
5
5
5
3
3
3
3
3
3
5
5
5
5
5
5
7
7
7
7
q2
1
1
1
4
4
4
7
7
7
7
7
7
7
3
3
3
3
3
3
3
4
pgina
0
2
1
3
5
4
6
3
7
4
7
3
3
5
5
3
1
1
1
7
1
3
4
1
qo
0
0
0
3
3
3
6
6
6
4
4
4
4
4
4
4
1
1
1
1
1
1
1
1
depois
q1
2
2
2
5
5
5
3
3
3
3
3
3
5
5
5
5
5
5
7
7
7
7
7
q2
1
1
1
4
4
4
7
7
7
7
7
7
7
3
3
3
3
3
3
3
4
4
faltas
?
?
?
?
?
?
?
?
?
?
?
?
?
ao realizada
p0 carregada no quadro vazio q0
p2 carregada em q1
p1 carregada em q2
p3 substitui p0 (a mais antiga na mem
p5 substitui p2 (idem)
p4 substitui p1
p6 substitui p3
p3 substitui p5
p7 substitui p4
p4 substitui p6
p7 est na memria
p3 est na memria
p3 est na memria
p5 substitui p3
p5 est na memria
p3 substitui p7
p1 substitui p4
p1 est na memria
p1 est na memria
p7 substitui p5
p1 est na memria
p3 est na memria
p4 substitui p3
p1 est na memria
Tabela 5.2: Aplicao do algoritmo de substituio FIFO.

Apesar de ter uma implementao simples, na prtica este algoritmo
no oferece bons resultados. Seu principal defeito considerar somente a
c Carlos Maziero
189
idade da pgina, sem levar em conta sua importncia. Pginas carregadas

na memria h muito tempo podem estar sendo frequentemente acessadas,
como o caso de pginas contendo bibliotecas dinmicas compartilhadas
por muitos processos, ou pginas de processos servidores lanados durante
a inicializao (boot) da mquina.
Algoritmo timo
Idealmente, a melhor pgina a remover da memria em um dado instante
aquela que ficar mais tempo sem ser usada pelos processos. Esta idia
simples define o algoritmo timo (OPT). Entretanto, como o comportamento
futuro dos processos no pode ser previsto com preciso, este algoritmo no
implementvel. Mesmo assim ele importante, porque define um limite
mnimo conceitual: se para uma dada cadeia de referncias, o algoritmo
timo gera 17 faltas de pgina, nenhum outro algoritmo ir gerar menos de
17 faltas de pgina ao tratar a mesma cadeia. Assim, seu resultado serve
como parmetro para a avaliao dos demais algoritmos.
A aplicao do algoritmo timo cadeia de referncias apresentada
apresentada na Tabela 5.3. Nesse caso, o algoritmo gera 11 faltas de pgina,
ou seja, 4 a menos que o algoritmo FIFO.
Algoritmo LRU
Uma aproximao implementvel do algoritmo timo proporcionada
pelo algoritmo LRU (Least Recently Used, menos recentemente usado). Neste
algoritmo, a escolha recai sobre as pginas que esto na memria h mais
tempo sem ser acessadas. Assim, pginas antigas e menos usadas so
as escolhas preferenciais. Pginas antigas mas de uso frequente no so
penalizadas por este algoritmo, ao contrrio do que ocorre no algoritmo
FIFO.
Pode-se observar facilmente que este algoritmo simtrico do algoritmo
OPT em relao ao tempo: enquanto o OPT busca as pginas que sero
acessadas mais longe no futuro do processo, o algoritmo LRU busca as
pginas que foram acessadas mais longe no seu passado.
A aplicao do algoritmo LRU cadeia de referncias apresentada
c Carlos Maziero
190
t
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
qo
0
0
0
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
4
antes
q1
2
2
2
5
5
6
6
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
q2
1
1
1
4
4
4
4
4
4
4
4
5
5
5
1
1
1
1
1
1
1
pgina
0
2
1
3
5
4
6
3
7
4
7
3
3
5
5
3
1
1
1
7
1
3
4
1
qo
0
0
0
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
4
4
depois
q1
2
2
2
5
5
6
6
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
7
q2
1
1
1
4
4
4
4
4
4
4
4
5
5
5
1
1
1
1
1
1
1
1
faltas
?
?
?
?
?
?
?
?
ao realizada
p2 carregada em q1
p1 carregada em q2
p3 substitui p0 (no ser mais acessada
p4 substitui p1 (s ser acessada em t =
p3 est na memria
p4 est na memria
p7 est na memria
p3 est na memria
p3 est na memria
p5 est na memria
p3 est na memria
p1 est na memria
p1 est na memria
p7 est na memria
p1 est na memria
p3 est na memria
p1 est na memria
Tabela 5.3: Aplicao do algoritmo de substituio timo.

apresentada na Tabela 5.4. Nesse caso, o algoritmo gera 14 faltas de pgina
(trs faltas a mais que o algoritmo timo).
O grfico da Figura 5.29 permite a comparao dos algoritmos OPT,
FIFO e LRU sobre a cadeia de referncias em estudo, em funo do nmero de quadros existentes na memria fsica. Pode-se observar que o
melhor desempenho do algoritmo OPT, enquanto o pior desempenho
proporcionado pelo algoritmo FIFO.
O algoritmo LRU parte do pressuposto que pginas recentemente acessadas no passado provavelmente sero acessadas em um futuro prximo,
e ento evita remov-las da memria. Esta hiptese se verifica na prtica,
c Carlos Maziero
191
t
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
qo
0
0
0
3
3
3
6
6
6
4
4
4
4
5
5
5
5
5
5
7
7
7
4
antes
q1
2
2
2
5
5
5
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
q2
1
1
1
4
4
4
7
7
7
7
7
7
7
7
1
1
1
1
1
1
1
pgina
0
2
1
3
5
4
6
3
7
4
7
3
3
5
5
3
1
1
1
7
1
3
4
1
qo
0
0
0
3
3
3
6
6
6
4
4
4
4
5
5
5
5
5
5
7
7
7
4
4
depois
q1
2
2
2
5
5
5
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
q2
1
1
1
4
4
4
7
7
7
7
7
7
7
7
1
1
1
1
1
1
1
1
faltas
?
?
?
?
?
?
?
?
?
?
ao realizada
p2 carregada em q1
p1 carregada em q2
p3 substitui p0 (h mais tempo sem ace
p5 substitui p2 (idem)
p4 substitui p1 (...)
p6 substitui p3
p3 substitui p5
p7 substitui p4
p4 substitui p6
p7 est na memria
p3 est na memria
p3 est na memria
p5 substitui p4
p5 est na memria
p3 est na memria
p1 substitui p7
p1 est na memria
p1 est na memria
p7 substitui p5
p1 est na memria
p3 est na memria
p4 substitui p7
p1 est na memria
Tabela 5.4: Aplicao do algoritmo de substituio LRU.

sobretudo se os processos respeitam o princpio da localidade de referncia
(Seo 5.4).
Embora possa ser implementado, o algoritmo LRU bsico pouco usado
na prtica, porque sua implementao exigiria registrar as datas de acesso s
pginas a cada leitura ou escrita na memria, o que difcil de implementar
de forma eficiente em software e com custo proibitivo para implementar
em hardware. Alm disso, sua implementao exigiria varrer as datas de
acesso de todas as pginas para buscar a pgina com acesso mais antigo (ou
manter uma lista de pginas ordenadas por data de acesso), o que exigiria
c Carlos Maziero
192
20
OPT
FIFO
LRU
Faltas de pgina
15
10
0
1
4
Nmero de quadros de RAM
Figura 5.29: Comparao dos algoritmos de substituio de pginas.

muito processamento. Portanto, a maioria dos sistemas operacionais reais
implementa algoritmos baseados em aproximaes do LRU.
As prximas sees apresentam alguns algoritmos simples que permitem
se aproximar do comportamento LRU. Por sua simplicidade, esses algoritmos tm desempenho limitado e por isso somente so usados em sistemas
operacionais mais simples. Como exemplos de algoritmos de substituio
de pginas mais sofisticados e com maior desempenho podem ser citados o
LIRS [Jiang and Zhang, 2002] e o ARC [Bansal and Modha, 2004].
Algoritmo da segunda chance
O algoritmo FIFO move para a rea de troca as pginas h mais tempo
na memria, sem levar em conta seu histrico de acessos. Uma melhoria
simples desse algoritmo consiste em analisar o bit de referncia (Seo 5.3.4)
de cada pgina candidata, para saber se ela foi acessada recentemente. Caso
tenha sido, essa pgina recebe uma segunda chance, voltando para o fim
da fila com seu bit de referncia ajustado para zero. Dessa forma, evita-se
substituir pginas antigas mas muito acessadas. Todavia, caso todas as
pginas sejam muito acessadas, o algoritmo vai varrer todas as pginas,
ajustar todos os bits de referncia para zero e acabar por escolher a primeira
pgina da fila, como faria o algoritmo FIFO.
c Carlos Maziero
193
Uma forma eficiente de implementar este algoritmo atravs de uma

fila circular de nmeros de pgina, ordenados de acordo com seu ingresso
na memria. Um ponteiro percorre a fila sequencialmente, analisando os
bits de referncia das pginas e ajustando-os para zero medida em que
avana. Quando uma pgina vtima encontrada, ela movida para o disco
e a pgina desejada carregada na memria no lugar da vtima, com seu bit
de referncia ajustado para zero. Essa implementao conhecida como
algoritmo do relgio e pode ser vista na Figura 5.30.
21
12
2
11
26
prxima
vtima
42
18
14
33
nmeros
de pgina
17
0
26
nova
pgina
23
11
bits de
referncia
12
ajustados
para zero
2
0
21
17
18
14
33
Figura 5.30: Algoritmo da segunda chance (ou do relgio).
Algoritmo NRU
O algoritmo da segunda chance leva em conta somente o bit de referncia
de cada pgina ao escolher as vtimas para substituio. O algoritmo NRU
(Not Recently Used, ou no usada recentemente) melhora essa escolha, ao
considerar tambm o bit de modificao (dirty bit, vide Seo 5.3.4), que
indica se o contedo de uma pgina foi modificado aps ela ter sido
carregada na memria.
Usando os bits R (referncia) e M (modificao), possvel classificar as
pginas em memria em quatro nveis de importncia:
00 (R = 0, M = 0): pginas que no foram referenciadas recentemente
e cujo contedo no foi modificado. So as melhores candidatas
substituio, pois podem ser simplesmente retiradas da memria.
c Carlos Maziero
194
01 (R = 0, M = 1): pginas que no foram referenciadas recentemente,

mas cujo contedo j foi modificado. No so escolhas to boas, porque
tero de ser gravadas na rea de troca antes de serem substitudas.
10 (R = 1, M = 0): pginas referenciadas recentemente, cujo contedo
permanece inalterado. So provavelmente pginas de cdigo que
esto sendo usadas ativamente e sero referenciadas novamente em
breve.
11 (R = 1, M = 1): pginas referenciadas recentemente e cujo contedo
foi modificado. So a pior escolha, porque tero de ser gravadas na
rea de troca e provavelmente sero necessrias em breve.
O algoritmo NRU consiste simplesmente em tentar substituir primeiro
pginas do nvel 0; caso no encontre, procura candidatas no nvel 1 e assim
sucessivamente. Pode ser necessrio percorrer vrias vezes a lista circular
at encontrar uma pgina adequada para substituio.
Algoritmo do envelhecimento
Outra possibilidade de melhoria do algoritmo da segunda chance consiste
em usar os bits de referncia das pginas para construir contadores de acesso
s mesmas. A cada pgina associado um contador inteiro com N bits
(geralmente 8 bits so suficientes). Periodicamente, o algoritmo varre
as tabelas de pginas, l os bits de referncia e agrega seus valores aos
contadores de acessos das respectivas pginas. Uma vez lidos, os bits de
referncia so ajustados para zero, para registrar as referncias de pginas
que ocorrero durante prximo perodo.
O valor lido de cada bit de referncia no deve ser simplesmente
somado ao contador, por duas razes: o contador chegaria rapidamente
ao seu valor mximo (overflow) e a simples soma no permitiria diferenciar
acessos recentes dos mais antigos. Por isso, outra soluo foi encontrada:
cada contador deslocado para a direita 1 bit, descartando o bit menos
significativo (LSB - Least Significant Bit). Em seguida, o valor do bit de
referncia colocado na primeira posio esquerda do contador, ou seja,
em seu bit mais significativo (MSB - Most Significant Bit). Dessa forma,
acessos mais recentes tm um peso maior que acessos mais antigos, e o
contador nunca ultrapassa seu valor mximo.
c Carlos Maziero
195
5: Conjunto de trabalho
O exemplo a seguir mostra a evoluo dos contadores para quatro

pginas distintas, usando os valores dos respectivos bits de referncia R.
Os valores decimais dos contadores esto indicados entre parnteses, para
facilitar a comparao. Observe que as pginas acessadas no ltimo perodo
(p2 e p4 ) tm seus contadores aumentados, enquanto aquelas no acessadas
(p1 e p3 ) tm seus contadores diminudos.
p1
p2
p3
p4
R
0
1
0
1
contadores
0000 0011
com 0011 1101
1010 1000
1110 0011
(3)
(61) =
(168)
(227)
R
0
0
0
0
contadores
0000 0001
e 1001 1110
0101 0100
1111 0001
(1)
(158)
(84)
(241)
O contador construdo por este algoritmo constitui uma aproximao razovel do algoritmo LRU: pginas menos acessadas envelhecero, ficando
com contadores menores, enquanto pginas mais acessadas permanecero
jovens, com contadores maiores. Por essa razo, esta estratgia conhecida
como algoritmo do envelhecimento [Tanenbaum, 2003], ou algoritmo dos bits de
referncia adicionais [Silberschatz et al., 2001].
5.7.4
Conjunto de trabalho
A localidade de referncias (estudada na Seo 5.4) mostra que os

processos normalmente acessam apenas uma pequena frao de suas pginas a cada instante. O conjunto de pginas acessadas na histria recente de um processo chamado Conjunto de Trabalho (Working Set, ou ws)
[Denning, 1980, Denning, 2006]. A composio do conjunto de trabalho
dinmica, variando medida em que o processo executa e evolui seu
comportamento, acessando novas pginas e deixando de acessar outras.
Para ilustrar esse conceito, consideremos a cadeia de referncias apresentada
na Seo 5.7.3. Considerando como histria recente as ltimas n pginas
acessadas pelo processo, a evoluo do conjunto de trabalho ws do processo
que gerou aquela cadeia apresentada na Tabela 5.5.
O tamanho e a composio do conjunto de trabalho dependem do
nmero de pginas consideradas em sua histria recente (o valor n na Tabela
5.5). Em sistemas reais, essa dependncia no linear, mas segue uma
proporo exponencial inversa, devido localidade de referncias. Por essa
c Carlos Maziero
196
t
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
pgina
0
2
1
3
5
4
6
3
7
4
7
3
3
5
5
3
1
1
1
7
1
3
4
1
ws(n = 3)
{0}
{0, 2}
{0, 2, 1}
{2, 1, 3}
{1, 3, 5}
{3, 5, 4}
{5, 4, 6}
{4, 6, 3}
{6, 3, 7}
{3, 7, 4}
{4, 7}
{4, 7, 3}
{7, 3}
{3, 5}
{3, 5}
{5, 3}
{5, 3, 1}
{3, 1}
{1}
{1, 7}
{7, 1}
{7, 1, 3}
{1, 3, 4}
{3, 4, 1}
ws(n = 4)
{0}
{0, 2}
{0, 2, 1}
{0, 2, 1, 3}
{2, 1, 3, 5}
{1, 3, 5, 4}
{3, 5, 4, 6}
{5, 4, 6, 3}
{4, 6, 3, 7}
{6, 3, 7, 4}
{3, 4, 7}
{4, 7, 3}
{4, 7, 3}
{7, 3, 5}
{3, 5}
{5, 3}
{5, 3, 1}
{5, 3, 1}
{3, 1}
{1, 7}
{7, 1}
{7, 1, 3}
{7, 1, 3, 4}
{3, 4, 1}
ws(n = 5)
{0}
{0, 2}
{0, 2, 1}
{0, 2, 1, 3}
{0, 2, 1, 3, 5}
{2, 1, 3, 5, 4}
{1, 3, 5, 4, 6}
{5, 4, 6, 3}
{5, 4, 6, 3, 7}
{6, 3, 7, 4}
{6, 3, 4, 7}
{4, 7, 3}
{4, 7, 3}
{4, 7, 3, 5}
{7, 3, 5}
{5, 3}
{5, 3, 1}
{5, 3, 1}
{5, 3, 1}
{3, 1, 7}
{3, 7, 1}
{7, 1, 3}
{7, 1, 3, 4}
{7, 3, 4, 1}
Tabela 5.5: Conjuntos de trabalho ws para n = 3, n = 4 e n = 5.

razo, a escolha precisa do tamanho da histria recente a considerar no
crtica. Esse fenmeno pode ser observado na Tabela 5.5: assim que a
localidade de referncias se torna mais forte (a partir de t = 12), os trs
conjuntos de trabalho ficam muito similares. Outro exemplo apresentado
na Figura 5.31, que mostra o tamanho mdio dos conjuntos de trabalhos
observados na execuo do programa gThumb (analisado na Seo 5.4), em
funo do tamanho da histria recente considerada (em nmero de pginas
referenciadas).
Se um processo tiver todas as pginas de seu conjunto de trabalho
carregadas na memria, ele sofrer poucas faltas de pgina, pois somente
acessos a novas pginas podero gerar faltas. Essa constatao permite
delinear um algoritmo simples para substituio de pginas: s substituir
pginas que no pertenam ao conjunto de trabalho de nenhum processo
c Carlos Maziero
197
Tamanho mdio do conjunto de trabalho (pginas)
350
300
250
200
150
100
50
0
0
1000
2000
3000
4000
5000
6000
Tamanho da histria recente (pginas)
7000
8000
9000
Figura 5.31: Tamanho do conjunto de trabalho do programa gThumb.

ativo. Contudo, esse algoritmo difcil de implementar, pois exigiria manter
atualizado o conjunto de trabalho de cada processo a cada acesso memria,
o que teria um custo computacional proibitivo.
Uma alternativa mais simples e eficiente de implementar seria verificar
que pginas cada processo acessou recentemente, usando a informao dos
respectivos bits de referncia. Essa a base do algoritmo WSClock (Working
Set Clock) [Carr and Hennessy, 1981], que modifica o algoritmo do relgio
(Seo 5.7.3) da seguinte forma:
1. Uma data de ltimo acesso ta (p) associada a cada pgina p da fila
circular; essa data pode ser atualizada quando o ponteiro do relgio
visita a pgina.
2. Define-se um prazo de validade para as pginas, geralmente entre
dezenas e centenas de mili-segundos; a idade i(p) de uma pgina p
definida como a diferena entre sua data de ltimo acesso ta (p) e o
instante corrente tc (i(p) = tc ta (p)).
3. Quando h necessidade de substituir pginas, o ponteiro percorre a
fila buscando pginas candidatas:
c Carlos Maziero
198
5: A anomalia de Belady
(a) Ao encontrar uma pgina referenciada (com R = 1), sua data

de ltimo acesso atualizada com o valor corrente do tempo
(ta (p) = tc ), seu bit de referncia limpo (R = 0) e o ponteiro do
relgio avana, ignorando aquela pgina.
(b) Ao encontrar uma pgina no referenciada (com R = 0), se sua
idade for menor que , a pgina est no conjunto de trabalho;
caso contrrio, ela considerada fora do conjunto de trabalho e
pode ser substituda.
4. Caso o ponteiro d uma volta completa na fila e no encontre pginas
com idade maior que , a pgina mais antiga (que tiver o menor ta (p))
encontrada na volta anterior substituda.
5. Em todas as escolhas, d-se preferncia a pginas no-modificadas
(M = 0), pois seu contedo j est salvo no disco.
O algoritmo WSClock pode ser implementado de forma eficiente, porque
a data ltimo acesso de cada pgina no precisa ser atualizada a cada acesso
memria, mas somente quando a referncia da pgina na fila circular
visitada pelo ponteiro do relgio (caso R = 1). Todavia, esse algoritmo no
uma implementao pura do conceito de conjunto de trabalho, mas
uma composio de conceitos de vrios algoritmos: FIFO e segunda-chance
(estrutura e percurso do relgio), Conjuntos de trabalho (diviso das pginas
em dois grupos conforme sua idade), LRU (escolha das pginas com datas
de acesso mais antigas) e NRU (preferncia s pginas no-modificadas).
5.7.5
A anomalia de Belady
Espera-se que, quanto mais memria fsica um sistema possua, menos

faltas de pgina ocorram. Todavia, esse comportamento intuitivo no
se verifica em todos os algoritmos de substituio de pginas. Alguns
algoritmos, como o FIFO, podem apresentar um comportamento estranho:
ao aumentar o nmero de quadros de memria, o nmero de faltas de pgina
geradas pelo algoritmo aumenta, ao invs de diminuir. Esse comportamento
atpico de alguns algoritmos foi estudado pelo matemtico hngaro Laslo
Belady nos anos 60, sendo por isso denominado anomalia de Belady.
A seguinte cadeia de referncias permite observar esse fenmeno; o
comportamento dos algoritmos OPT, FIFO e LRU ao processar essa cadeia
c Carlos Maziero
199
5: Thrashing
pode ser visto na Figura 5.32, que exibe o nmero de faltas de pgina
em funo do nmero de quadros de memria disponveis no sistema. A
anomalia pode ser observada no algoritmo FIFO: ao aumentar a memria
de 4 para 5 quadros, esse algoritmo passa de 22 para 24 faltas de pgina.
0, 1, 2, 3, 4, 0, 1, 2, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 0, 1, 2, 5, 0, 1, 2, 3, 4, 5
30
OPT
FIFO
LRU
25
Faltas de pgina
20
15
10
0
1
4
Nmero de quadros de RAM
Figura 5.32: A anomalia de Belady.

Estudos demonstraram que uma famlia de algoritmos denominada
algoritmos de pilha ( qual pertencem os algoritmos OPT e LRU, entre outros)
no apresenta a anomalia de Belady [Tanenbaum, 2003].
5.7.6
Thrashing
Na Seo 5.7.2, foi demonstrado que o tempo mdio de acesso memria

RAM aumenta significativamente medida em que aumenta a frequncia de
faltas de pgina. Caso a frequncia de faltas de pginas seja muito elevada,
o desempenho do sistema como um todo pode ser severamente prejudicado.
Conforme discutido na Seo 5.7.4, cada processo tem um conjunto de
trabalho, ou seja, um conjunto de pginas que devem estar na memria para
sua execuo naquele momento. Se o processo tiver uma boa localidade de
c Carlos Maziero
200
5: Thrashing
referncia, esse conjunto pequeno e varia lentamente. Caso a localidade

de referncia seja ruim, o conjunto de trabalho geralmente grande e muda
rapidamente. Enquanto houver espao na memria RAM para os conjuntos
de trabalho dos processos ativos, no havero problemas. Contudo, caso a
soma de todos os conjuntos de trabalho dos processos prontos para execuo
seja maior que a memria RAM disponvel no sistema, poder ocorrer um
fenmeno conhecido como thrashing [Denning, 1980, Denning, 2006].
No thrashing, a memria RAM no suficiente para todos os processos
ativos, portanto muitos processos no conseguem ter seus conjuntos de
trabalho totalmente carregados na memria. Cada vez que um processo
recebe o processador, executa algumas instrues, gera uma falta de pgina
e volta ao estado suspenso, at que a pgina faltante seja trazida de volta
RAM. Todavia, para trazer essa pgina RAM ser necessrio abrir
espao na memria, transferindo algumas pginas (de outros processos)
para o disco. Quanto mais processos estiverem nessa situao, maior ser a
atividade de paginao e maior o nmero de processos no estado suspenso,
aguardando pginas.
A Figura 5.33 ilustra o conceito de thrashing: ela mostra a taxa de uso
do processador (quantidade de processos na fila de prontos) em funo
do nmero de processos ativos no sistema. Na zona esquerda no h
thrashing, portanto a taxa de uso do processador aumenta com o aumento do
nmero de processos. Caso esse nmero aumente muito, a memria RAM
no ser suficiente para todos os conjuntos de trabalho e o sistema entra
em uma regio de thrashing: muitos processos passaro a ficar suspensos
aguardando a paginao, diminuindo a taxa de uso do processador. Quanto
mais processos ativos, menos o processador ser usado e mais lento ficar o
sistema. Pode-se observar que um sistema ideal com memria infinita no
teria esse problema, pois sempre haveria memria suficiente para todos os
processos ativos.
Um sistema operacional sob thrashing tem seu desempenho muito prejudicado, a ponto de parar de responder ao usurio e se tornar inutilizvel.
Por isso, esse fenmeno deve ser evitado. Para tal, pode-se aumentar a
quantidade de memria RAM do sistema, limitar a quantidade mxima de
processos ativos, ou mudar a poltica de escalonamento dos processos durante o thrashing, para evitar a competio pela memria disponvel. Vrios
sistemas operacionais adotam medidas especiais para situaes de thrashing,
como suspender em massa os processos ativos, adotar uma poltica de
escalonamento de processador que considere o uso da memria, aumentar o
c Carlos Maziero
201
5: Thrashing
taxa de uso do processador

zona de
saturao
da RAM
sistema ideal
sistema real
situao normal
thrashing
nmero de processos ativos
Figura 5.33: Thrashing no uso da memria RAM.

quantum de processador para cada processo ativo, ou simplesmente abortar
os processos com maior alocao de memria ou com maior atividade de
paginao.
Captulo 6
Gerncia de arquivos
Um sistema operacional tem por finalidade permitir que o usurios do computador executem aplicaes, como editores de texto,
jogos, reprodutores de udio e vdeo, etc. Essas aplicaes processam
informaes como textos, msicas e filmes, armazenados sob a forma
de arquivos em um disco rgido ou outro meio. Este mdulo apresenta
a noo de arquivo, suas principais caractersticas e formas de acesso,
a organizao de arquivos em diretrios e as tcnicas usadas para
criar e gerenciar arquivos nos dispositivos de armazenamento.
6.1
Arquivos
Desde os primrdios da computao, percebeu-se a necessidade de

armazenar informaes para uso posterior, como programas e dados. Hoje,
parte importante do uso de um computador consiste em recuperar e apresentar informaes previamente armazenadas, como documentos, fotografias,
msicas e vdeos. O prprio sistema operacional tambm precisa manter
informaes armazenadas para uso posterior, como programas, bibliotecas
e configuraes. Geralmente essas informaes devem ser armazenadas em
um dispositivo no-voltil, que preserve seu contedo mesmo quando o
computador estiver desligado. Para simplificar o armazenamento e busca
de informaes, surgiu o conceito de arquivo, que ser discutido a seguir.
c Carlos Maziero
203
6.1.1
6: O conceito de arquivo
O conceito de arquivo
Um arquivo basicamente um conjunto de dados armazenados em

um dispositivo fsico no-voltil, com um nome ou outra referncia que
permita sua localizao posterior. Do ponto de vista do usurio e das
aplicaes, o arquivo a unidade bsica de armazenamento de informao
em um dispositivo no-voltil, pois para eles no h forma mais simples de
armazenamento persistente de dados. Arquivos so extremamente versteis
em contedo e capacidade: podem conter desde um texto ASCII com alguns
bytes at sequncias de vdeo com dezenas de gigabytes, ou mesmo mais.
Como um dispositivo de armazenamento pode conter milhes de arquivos, estes so organizados em estruturas hierrquicas denominadas
diretrios (conforme ilustrado na Figura 6.1 e discutido mais detalhadamente
na Seo 6.3.1). A organizao fsica e lgica dos arquivos e diretrios
dentro de um dispositivo denominada sistema de arquivos. Um sistema de
arquivos pode ser visto como uma imensa estrutura de dados armazenada
de forma persistente em um dispositivo fsico. Existe um grande nmero
de sistemas de arquivos, dentre os quais podem ser citados o NTFS (nos
sistemas Windows), Ext2/Ext3/Ext4 (Linux), HPFS (MacOS), FFS (Solaris)
e FAT (usado em pendrives USB, mquinas fotogrficas digitais e leitores
MP3). A organizao dos sistemas de arquivos ser discutida na Seo 6.4.
/
bin
home
ls
usr
bin
daniel
henrique
gcc
cp
arq1.txt
relat.pdf
firefox
mv
play.mp3
foto.jpg
perl
diretrios
ooffice
arquivos
Figura 6.1: Arquivos organizados em diretrios dentro de um dispositivo.
c Carlos Maziero
204
6.1.2
6: Atributos
Atributos
Conforme apresentado, um arquivo uma unidade de armazenamento

de informaes que podem ser dados, cdigo executvel, etc. Cada arquivo
caracterizado por um conjunto de atributos, que podem variar de acordo
com o sistema de arquivos utilizado. Os atributos mais usuais so:
Nome: string de caracteres que identifica o arquivo para o usurio, como
foto1.jpg, relatrio.pdf, hello.c, etc.;
Tipo: indicao do formato dos dados contidos no arquivo, como udio,
vdeo, imagem, texto, etc. Muitos sistemas operacionais usam parte
do nome do arquivo para identificar o tipo de seu contedo, na forma
de uma extenso: .doc, .jpg, .mp3, etc.;
Tamanho: indicao do tamanho do contedo do arquivo, em bytes ou
registros;
Datas: para fins de gerncia, importante manter as datas mais importantes
relacionadas ao arquivo, como suas datas de criao, de ltimo acesso
e de ltima modificao do contedo;
Proprietrio: em sistemas multi-usurios, cada arquivo tem um proprietrio, que deve estar corretamente identificado;
Permisses de acesso: indicam que usurios tm acesso quele arquivo e
que formas de acesso so permitidas (leitura, escrita, remoo, etc.);
Localizao: indicao do dispositivo fsico onde o arquivo se encontra e
da posio do arquivo dentro do mesmo;
Outros atributos: vrios outros atributos podem ser associados a um arquivo, por exemplo para indicar se um arquivo de sistema, se
est visvel aos usurios, se tem contedo binrio ou textual, etc.
Cada sistema de arquivos normalmente define seus prprios atributos
especficos, alm dos atributos usuais.
Nem sempre os atributos oferecidos por um sistema de arquivos so
suficientes para exprimir todas as informaes a respeito de um arquivo.
Nesse caso, a soluo encontrada pelos usurios usar o nome do arquivo
para exprimir a informao desejada. Por exemplo, em muitos sistemas
c Carlos Maziero
205
6: Operaes
a parte final do nome do arquivo (sua extenso) usada para identificar

o formato de seu contedo. Outra situao frequente usar parte do
nome do arquivo para identificar diferentes verses do mesmo contedo1 :
relat-v1.txt, relat-v2.txt, etc.
6.1.3
Operaes
As aplicaes e o sistema operacional usam arquivos para armazenar

e recuperar dados. O uso dos arquivos feito atravs de um conjunto de
operaes, geralmente implementadas sob a forma de chamadas de sistema
e funes de bibliotecas. As operaes bsicas envolvendo arquivos so:
Criar: a criao de um novo arquivo implica em alocar espao para ele
no dispositivo de armazenamento e definir seus atributos (nome,
localizao, proprietrio, permisses de acesso, etc.);
Abrir: antes que uma aplicao possa ler ou escrever dados em um arquivo,
ela deve solicitar ao sistema operacional a abertura desse arquivo. O
sistema ir ento verificar se o arquivo existe, verificar se as permisses
associadas ao arquivo permitem aquele acesso, localizar seu contedo
no dispositivo de armazenamento e criar uma referncia para ele na
memria da aplicao;
Ler: permite transferir dados presentes no arquivo para uma rea de
memria da aplicao;
Escrever: permite transferir dados na memria da aplicao para o arquivo
no dispositivo fsico; os novos dados podem ser adicionados no final
do arquivo ou sobrescrever dados j existentes;
Mudar atributos: para modificar outras caractersticas do arquivo, como
nome, localizao, proprietrio, permisses, etc.
Fechar: ao concluir o uso do arquivo, a aplicao deve informar ao sistema
operacional que o mesmo no mais necessrio, a fim de liberar as
estruturas de gerncia do arquivo na memria do ncleo;
1
Alguns sistemas operacionais, como o TOPS-20 e o OpenVMS, possuem sistemas de

arquivos com suporte automtico a mltiplas verses do mesmo arquivo.
c Carlos Maziero
206
6: Formatos
Remover: para eliminar o arquivo do dispositivo, descartando seus dados

e liberando o espao ocupado por ele.
Alm dessas operaes bsicas, outras operaes podem ser definidas,
como truncar, copiar, mover ou renomear arquivos. Todavia, essas operaes
geralmente podem ser construdas usando as operaes bsicas.
6.1.4
Formatos
Em sua forma mais simples, um arquivo contm basicamente uma

sequncia de bytes, que pode estar estruturada de diversas formas para
representar diferentes tipos de informao. O formato ou estrutura interna
de um arquivo pode ser definido e reconhecido pelo ncleo do sistema
operacional ou somente pelas aplicaes. O ncleo do sistema geralmente
reconhece apenas alguns poucos formatos de arquivos, como binrios
executveis e bibliotecas. Os demais formatos de arquivos so vistos pelo
ncleo apenas como sequncias de bytes sem um significado especfico,
cabendo s aplicaes interpret-los.
Os arquivos de dados convencionais so estruturados pelas aplicaes
para armazenar os mais diversos tipos de informaes, como imagens,
sons e documentos. Uma aplicao pode definir um formato prprio de
armazenamento ou seguir formatos padronizados. Por exemplo, h um
grande nmero de formatos pblicos padronizados para o armazenamento
de imagens, como JPEG, GIF, PNG e TIFF, mas tambm existem formatos
de arquivos proprietrios, definidos por algumas aplicaes especficas,
como o formato PSD (do editor Adobe Photoshop) e o formato XCF (do editor
grfico GIMP). A adoo de um formato proprietrio ou exclusivo dificulta
a ampla utilizao das informaes armazenadas, pois somente aplicaes
que reconheam aquele formato conseguem ler corretamente as informaes
contidas no arquivo.
Arquivos de registros
Alguns ncleos de sistemas operacionais oferecem arquivos com estruturas internas que vo alm da simples sequncia de bytes. Por exemplo,
o sistema OpenVMS [Rice, 2000] proporciona arquivos baseados em registros,
cujo contedo visto pelas aplicaes como uma sequncia linear de registros de tamanho fixo ou varivel, e tambm arquivos indexados, nos quais
c Carlos Maziero
207
6: Formatos
podem ser armazenados pares {chave/valor}, de forma similar a um banco de

dados relacional. A Figura 6.2 ilustra a estrutura interna desses dois tipos
de arquivos.
reg1
reg2
reg3
reg4
reg5
reg6
reg7
struct
char
char
int
int
int
}
{
nome[40];
CPF[10];
idade;
peso;
altura;
nome (chave)
telefone (valor)
daniel
marina
henrique
gabriel
renata
andressa
guilherme
9977-1173
9876-5432
8781-9750
8858-8286
9663-9293
8779-5538
9979-4166
Figura 6.2: Arquivos estruturados: registros em sequncia e registros

indexados.
Nos sistemas operacionais cujo ncleo no suporta arquivos estruturados
como registros, essa funcionalidade pode ser facilmente obtida atravs de
bibliotecas especficas ou do suporte de execuo de algumas linguagens
de programao. Por exemplo, a biblioteca Berkeley DB disponvel em
plataformas UNIX oferece suporte indexao de registros sobre arquivos
UNIX convencionais.
Arquivos de texto
Um tipo de arquivo de uso muito frequente o arquivo de texto puro
(ou plain text). Esse tipo de arquivo muito usado para armazenar informaes textuais simples, como cdigos-fonte de programas, arquivos de
configurao, pginas HTML, dados em XML, etc. Um arquivo de texto
formado por linhas de caracteres ASCII de tamanho varivel, separadas por
caracteres de controle. Nos sistemas UNIX, as linhas so separadas por um
caractere New Line (ASCII 10 ou \n). J nos sistemas DOS/Windows, as
linhas de um arquivo de texto so separadas por dois caracteres: o caractere
Carriage Return (ASCII 13 ou \r) seguido do caractere New Line. Por
exemplo, considere o seguinte programa em C armazenado em um arquivo
hello.c (os caracteres indicam espaos em branco):
1
2
3
4
int main()
{
printf("Hello, world\n");
exit(0);
c Carlos Maziero
208
6: Formatos
O arquivo de texto hello.c seria armazenado da seguinte forma2 em

um ambiente UNIX:
1
0000
2
3
0010
4
5
0020
6
7
0030
69
i
72
r
72
r
30
0
6e
n
69
i
6c
l
29
)
74
t
6e
n
64
d
3b
;
20 6d
m
74 66
t f
5c 6e
\ n
0a 7d
\n }
61 69 6e 28 29 0a 7b 0a 20 20 70
a i n ( ) \n { \n
p
28 22 48 65 6c 6c 6f 2c 20 77 6f
( " H e l l o ,
w o
22 29 3b 0a 20 20 65 78 69 74 28
" ) ; \n
e x i t (
0a
\n
Por outro lado, o mesmo arquivo hello.c seria armazenado da seguinte

forma em um sistema DOS/Windows:
1
0000
2
3
0010
4
5
0020
6
7
0030
69 6e 74
i n t
20 70 72
p r
77 6f 72
w o r
69 74 28
i t (
20 6d
m
69 6e
i n
6c 64
l d
30 29
0 )
61
a
74
t
5c
\
3b
;
69
i
66
f
6e
n
0d
\r
6e
n
28
(
22
"
0a
\n
28
(
22
"
29
)
7d
}
29
)
48
H
3b
;
0d
\r
0d
\r
65
e
0d
\r
0a
\n
0a 7b 0d 0a 20
\n { \r \n
6c 6c 6f 2c 20
l l o ,
0a 20 20 65 78
\n
e x
Essa diferena na forma de representao da separao entre linhas

pode provocar problemas em arquivos de texto transferidos entre sistemas
Windows e UNIX, caso no seja feita a devida converso.
Arquivos executveis
Um arquivo executvel dividido internamente em vrias sees, para
conter cdigo, tabelas de smbolos (variveis e funes), listas de dependncias (bibliotecas necessrias) e outras informaes de configurao. A
organizao interna de um arquivo executvel ou biblioteca depende do
sistema operacional para o qual foi definido. Os formatos de executveis
mais populares atualmente so [Levine, 2000]:
2
Listagem obtida atravs do comando hd do Linux, que apresenta o contedo de um

arquivo em hexadecimal e seus caracteres ASCII correspondentes, byte por byte.
c Carlos Maziero
209
6: Formatos
ELF (Executable and Linking Format): formato de de arquivo usado para

programas executveis e bibliotecas na maior parte das plataformas
UNIX modernas. composto por um cabealho e vrias sees de
dados, contendo cdigo executvel, tabelas de smbolos e informaes
de relocao de cdigo.
PE (Portable Executable): o formato usado para executveis e bibliotecas na plataforma Windows. Consiste basicamente em uma adaptao
do antigo formato COFF usado em plataformas UNIX.
A Figura 6.3 ilustra a estrutura interna de um arquivo executvel no
formato ELF, usado tipicamente em sistemas UNIX (Linux, Solaris, etc.).
Esse arquivo dividido em sees, que representam trechos de cdigo e
dados sujeitos a ligao dinmica e relocao; as sees so agrupadas
em segmentos, de forma a facilitar a carga em memria do cdigo e o
lanamento do processo.
ELF header
Sections
Program
header table
Segments
Section
header table
Figura 6.3: Estrutura interna de um arquivo executvel em formato ELF

[Levine, 2000].
Alm de executveis e bibliotecas, o ncleo de um sistema operacional
costuma reconhecer alguns tipos de arquivos no convencionais, como
diretrios, atalhos (links), dispositivos fsicos e estruturas de comunicao
do ncleo, como sockets, pipes e filas de mensagens (vide Seo 6.1.5).
c Carlos Maziero
210
6: Formatos
Identificao de contedo
Um problema importante relacionado aos formatos de arquivos a
correta identificao de seu contedo pelos usurios e aplicaes. J
que um arquivo de dados pode ser visto como uma simples sequncia
de bytes, como possvel saber que tipo de informao essa sequncia
representa? Uma soluo simples para esse problema consiste em indicar o
tipo do contedo como parte do nome do arquivo: um arquivo praia.jpg
provavelmente contm uma imagem em formato JPEG, enquanto um
arquivo entrevista.mp3 contm udio em formato MP3. Essa estratgia,
amplamente utilizada em muitos sistemas operacionais, foi introduzida
nos anos 1980 pelo sistema operacional DOS. Naquele sistema, os arquivos
eram nomeados segundo uma abordagem denominada 8.3, ou seja, 8
caracteres seguidos de um ponto (.) e mais 3 caracteres de extenso, para
definir o tipo do arquivo.
Outra abordagem, frequentemente usada em sistemas UNIX, o uso de
alguns bytes no incio de cada arquivo para a definio de seu tipo. Esses
bytes iniciais so denominados nmeros mgicos (magic numbers), e so
usados em muitos tipos de arquivos, como exemplificado na Tabela 6.1:
Tabela 6.1: Nmeros mgicos de alguns tipos de arquivos
Tipo de arquivo
Documento PostScript
Imagem GIF
Msica MIDI
bytes iniciais
%!
GIF89a
MThd
Tipo de arquivo
Documento PDF
Imagem JPEG
Classes Java (JAR)
bytes iniciais
%PDF
0xFFD8
0xCAFEBABE
Nos sistema UNIX, o utilitrio file permite identificar o tipo de arquivo

atravs da anlise de seus bytes iniciais e do restante de sua estrutura interna,
sem levar em conta o nome do arquivo. Por isso, constitui uma ferramenta
importante para identificar arquivos desconhecidos ou com extenso errada.
Alm do uso de extenses no nome do arquivo e de nmeros mgicos,
alguns sistemas operacionais definem atributos adicionais no sistema de
arquivos para indicar o contedo de cada arquivo. Por exemplo, o sistema
operacional MacOS 9 definia um atributo com 4 bytes para identificar o
tipo de cada arquivo (file type), e outro atributo com 4 bytes para indicar a
aplicao que o criou (creator application). Os tipos de arquivos e aplicaes
so definidos em uma tabela mantida pelo fabricante do sistema. Assim,
quando o usurio solicitar a abertura de um determinado arquivo, o sistema
c Carlos Maziero
211
6: Arquivos especiais
ir escolher a aplicao que o criou, se ela estiver presente. Caso contrrio,

pode indicar ao usurio uma relao de aplicaes aptas a abrir aquele tipo
de arquivo.
Recentemente, a necessidade de transferir arquivos atravs de e-mail e
de pginas Web levou definio de um padro de tipagem de arquivos
conhecido como Tipos MIME (da sigla Multipurpose Internet Mail Extensions)
[Freed and Borenstein, 1996]. O padro MIME define tipos de arquivos
atravs de uma notao uniformizada na forma tipo/subtipo. Alguns
exemplos de tipos de arquivos definidos segundo o padro MIME so
apresentados na Tabela 6.2.
Tabela 6.2: Tipos MIME correspondentes a alguns formatos de arquivos
Tipo MIME
application/java-archive
application/msword
application/vnd.oasis.opendocument.text
audio/midi
audio/mpeg
image/jpeg
image/png
text/csv
text/html
text/plain
text/rtf
text/x-csrc
video/quicktime
Significado
Arquivo de classes Java (JAR)
Documento do Microsoft Word
Documento do OpenOffice
udio em formato MIDI
udio em formato MP3
Imagem em formato JPEG
Imagem em formato PNG
Texto em formato CSV (Comma-separated V
Texto HTML
Texto puro
Texto em formato RTF (Rich Text Format)
Cdigo-fonte em C
Vdeo no formato Quicktime
O padro MIME usado para identificar arquivos transferidos como

anexos de e-mail e contedos recuperados de pginas Web. Alguns sistemas
operacionais, como o BeOS e o MacOS X, definem atributos de acordo com
esse padro para identificar o contedo de cada arquivo dentro do sistema
de arquivos.
6.1.5
Arquivos especiais
O conceito de arquivo ao mesmo tempo simples e poderoso, o que

motivou sua utilizao de forma quase universal. Alm do armazenamento
de cdigo e dados, arquivos tambm podem ser usados como:
c Carlos Maziero
212
6: Arquivos especiais
Abstrao de dispositivos de baixo nvel: os sistemas UNIX costumam

mapear as interfaces de acesso de vrios dispositivos fsicos em arquivos dentro do diretrio /dev (de devices), como por exemplo:
/dev/ttyS0: porta de comunicao serial COM1;
/dev/audio: placa de som;
/dev/sda1: primeira partio do primeiro disco SCSI (ou SATA).
Abstrao de interfaces do ncleo: em sistemas UNIX, os diretrios /proc
e /sys permitem consultar e/ou modificar informaes internas do
ncleo do sistema operacional, dos processos em execuo e dos drivers
de dispositivos. Por exemplo, alguns arquivos oferecidos pelo Linux:
/proc/cpuinfo: informaes sobre os processadores disponveis
no sistema;
/proc/3754/maps: disposio das reas de memria alocadas
para o processo cujo identificador (PID) 3754;
/sys/block/sda/queue/scheduler: definio da poltica de escalonamento de disco (vide Seo 7.4.3) a ser usada no acesso ao
disco /dev/sda.
Canais de comunicao: na famlia de protocolos de rede TCP/IP, a metfora de arquivo usada como interface para os canais de comunicao:
uma conexo TCP apresentada aos dois processos envolvidos como
um arquivo, sobre o qual eles podem escrever (enviar) e ler (receber)
dados entre si. Vrios mecanismos de comunicao local entre processos de um sistema tambm usam a metfora do arquivo, como o
caso dos pipes em UNIX.
Em alguns sistemas operacionais experimentais, como o Plan 9
[Pike et al., 1993, Pike et al., 1995] e o Inferno [Dorward et al., 1997], todos
os recursos e entidades fsicas e lgicas do sistema so mapeadas sob a forma
de arquivos: processos, threads, conexes de rede, usurios, sesses de usurios, janelas grficas, reas de memria alocadas, etc. Assim, para finalizar
um determinado processo, encerrar uma conexo de rede ou desconectar
um usurio, basta remover o arquivo correspondente.
Embora o foco deste texto esteja concentrado em arquivos convencionais,
que visam o armazenamento de informaes (bytes ou registros), muitos
c Carlos Maziero
213
6: Uso de arquivos
dos conceitos aqui expostos so igualmente aplicveis aos arquivos noconvencionais descritos nesta seo.
6.2
Uso de arquivos
Arquivos so usados por processos para ler e escrever dados de forma novoltil. Para usar arquivos, um processo tem sua disposio uma interface
de acesso, que depende da linguagem utilizada e do sistema operacional
subjacente. Essa interface normalmente composta por uma representao
lgica de cada arquivo usado pelo processo (uma referncia ao arquivo) e por
um conjunto de funes (ou mtodos) para realizar operaes sobre esses
arquivos. Atravs dessa interface, os processos podem localizar arquivos
no disco, ler e modificar seu contedo, entre outras operaes.
Na sequncia desta seo sero discutidos aspectos relativos ao uso de
arquivos, como a abertura do arquivo, as formas de acesso aos seus dados, o
controle de acesso e problemas associados ao compartilhamento de arquivos
entre vrios processos.
6.2.1
Abertura de um arquivo
Para poder ler ou escrever dados em um arquivo, cada aplicao precisa

antes abr-lo. A abertura de um arquivo consiste basicamente em preparar
as estruturas de memria necessrias para acessar os dados do arquivo em
questo. Assim, para abrir um arquivo, o ncleo do sistema operacional
deve realizar as seguintes operaes:
1. Localizar o arquivo no dispositivo fsico, usando seu nome e caminho
de acesso (vide Seo 6.3.2);
2. Verificar se a aplicao tem permisso para usar aquele arquivo da
forma desejada (leitura e/ou escrita);
3. Criar uma estrutura na memria do ncleo para representar o arquivo
aberto;
4. Inserir uma referncia a essa estrutura na lista de arquivos abertos
mantida pelo sistema, para fins de gerncia;
c Carlos Maziero
214
6: Abertura de um arquivo
5. Devolver aplicao uma referncia a essa estrutura, para ser usada

nos acessos subsequentes ao arquivo recm-aberto.
Concluda a abertura do arquivo, o processo solicitante recebe do ncleo
uma referncia para o arquivo recm-aberto, que deve ser informada pelo
processo em suas operaes subsequentes envolvendo aquele arquivo.
Assim que o processo tiver terminado de usar um arquivo, ele deve solicitar
ao ncleo o fechamento do arquivo, que implica em concluir as operaes
de escrita eventualmente pendentes e remover da memria do ncleo as
estruturas de gerncia criadas durante sua abertura. Normalmente, os
arquivos abertos so automaticamente fechados quando do encerramento
do processo, mas pode ser necessrio fech-los antes disso, caso seja um
processo com vida longa, como um daemon servidor de pginas Web, ou que
abra muitos arquivos, como um compilador.
As referncias a arquivos abertos usadas pelas aplicaes dependem da
linguagem de programao utilizada para constru-las. Por exemplo, em
um programa escrito na linguagem C, cada arquivo aberto representado
por uma varivel dinmica do tipo FILE*, que denominada um ponteiro
de arquivo (file pointer). Essa varivel dinmica alocada no momento da
abertura do arquivo e serve como uma referncia ao mesmo nas operaes
de acesso subsequentes. J em Java, as referncias a arquivos abertos so
objetos instanciados a partir da classe File. Na linguagem Python existem
os file objects, criados a partir da chamada open.
Por outro lado, cada sistema operacional tem sua prpria conveno para
a representao de arquivos abertos. Por exemplo, em sistemas Windows
os arquivos abertos por um processo so representados pelo ncleo por
referncias de arquivos (file handles), que so estruturas de dados criadas
pelo ncleo para representar cada arquivo aberto. Por outro lado, em
sistemas UNIX os arquivos abertos por um processo so representados por
descritores de arquivos (file descriptors). Um descritor de arquivo aberto
um nmero inteiro no-negativo, usado como ndice em uma tabela que
relaciona os arquivos abertos por aquele processo, mantida pelo ncleo.
Dessa forma, cabe s bibliotecas e ao suporte de execuo de cada linguagem
de programao mapear a representao de arquivo aberto fornecida pelo
ncleo do sistema operacional subjacente na referncia de arquivo aberto
usada por aquela linguagem. Esse mapeamento necessrio para garantir
que as aplicaes que usam arquivos (ou seja, quase todas elas) sejam
portveis entre sistemas operacionais distintos.
c Carlos Maziero
215
6.2.2
6: Formas de acesso
Formas de acesso
Uma vez aberto um arquivo, a aplicao pode ler os dados contidos

nele, modific-los ou escrever novos dados. H vrias formas de se ler
ou escrever dados em um arquivo, que dependem da estrutura interna do
mesmo. Considerando apenas arquivos simples, vistos como uma sequncia
de bytes, duas formas de acesso so usuais: o acesso sequencial e o acesso
direto (ou acesso aleatrio).
No acesso sequencial, os dados so sempre lidos e/ou escritos em
sequncia, do incio ao final do arquivo. Para cada arquivo aberto por uma
aplicao definido um ponteiro de acesso, que inicialmente aponta para
a primeira posio do arquivo. A cada leitura ou escrita, esse ponteiro
incrementado e passa a indicar a posio da prxima leitura ou escrita.
Quando esse ponteiro atinge o final do arquivo, as leituras no so mais
permitidas, mas as escritas ainda o so, permitindo acrescentar dados ao
final do mesmo. A chegada do ponteiro ao final do arquivo normalmente
sinalizada ao processo atravs de um flag de fim de arquivo (EoF - End-of-File).
A Figura 6.4 traz um exemplo de acesso sequencial em leitura a um arquivo, mostrando a evoluo do ponteiro do arquivo durante uma sequncia
de leituras. A primeira leitura no arquivo traz a string Qui scribit bis,
a segunda leitura traz legit. , e assim sucessivamente. O acesso sequencial implementado em praticamente todos os sistemas operacionais
de mercado e constitui a forma mais usual de acesso a arquivos, usada pela
maioria das aplicaes.
0
15
23
35
45
60
leituras
Qui scribit bis legit. Non nova, sed nove. Felix qui potuit rerum...
Figura 6.4: Leituras sequenciais em um arquivo de texto.

Por outro lado, no mtodo de acesso direto (ou aleatrio), pode-se
indicar a posio no arquivo onde cada leitura ou escrita deve ocorrer,
sem a necessidade de um ponteiro. Assim, caso se conhea previamente
a posio de um determinado dado no arquivo, no h necessidade de
percorr-lo sequencialmente at encontrar o dado desejado. Essa forma
de acesso muito importante em gerenciadores de bancos de dados e
aplicaes congneres, que precisam acessar rapidamente as posies do
arquivo correspondentes ao registros desejados em uma operao.
c Carlos Maziero
216
6: Formas de acesso
Na prtica, a maioria dos sistemas operacionais usa o acesso sequencial

como modo bsico de operao, mas oferece operaes para mudar a posio
do ponteiro do arquivo caso necessrio, o que permite ento o acesso direto
a qualquer registro do arquivo. Nos sistemas POSIX, o reposicionamento
do ponteiro do arquivo efetuado atravs das chamadas lseek e fseek.
Uma forma particular de acesso direto ao contedo de um arquivo
o mapeamento em memria do mesmo, que faz uso dos mecanismos de
memria virtual (paginao). Nessa modalidade de acesso, um arquivo
associado a um vetor de bytes (ou de registros) de mesmo tamanho na
memria principal, de forma que cada posio do vetor corresponda sua
posio equivalente no arquivo. Quando uma posio especfica do vetor
ainda no acessada lida, gerada uma falta de pgina. Nesse momento, o
mecanismo de paginao da memria virtual intercepta o acesso memria,
l o contedo correspondente no arquivo e o deposita no vetor, de forma
transparente aplicao. Escritas no vetor so transferidas para o arquivo
por um procedimento similar. Caso o arquivo seja muito grande, pode-se
mapear em memria apenas partes dele. A Figura 6.5 ilustra essa forma de
acesso.
processo
acessos
vetor de bytes
pginas
lidas
pginas
escritas
arquivo em disco
Figura 6.5: Arquivo mapeado em memria.
c Carlos Maziero
217
6: Controle de acesso
Finalmente, alguns sistemas operacionais oferecem tambm a possibilidade de acesso indexado aos dados de um arquivo, como o caso do
OpenVMS [Rice, 2000]. Esse sistema implementa arquivos cuja estrutura
interna pode ser vista como um conjunto de pares chave/valor. Os dados do
arquivo so armazenados e recuperados de acordo com suas chaves correspondentes, como em um banco de dados relacional. Como o prprio ncleo
do sistema implementa os mecanismos de acesso e indexao do arquivo, o
armazenamento e busca de dados nesse tipo de arquivo costuma ser muito
rpido, dispensando bancos de dados para a construo de aplicaes mais
simples.
6.2.3
Controle de acesso
Como arquivos so entidades que sobrevivem existncia do processo

que as criou, importante definir claramente o proprietrio de cada arquivo
e que operaes ele e outros usurios do sistema podem efetuar sobre o
mesmo. A forma mais usual de controle de acesso a arquivos consiste em
associar os seguintes atributos a cada arquivo e diretrio do sistema de
arquivos:
Proprietrio: identifica o usurio dono do arquivo, geralmente aquele
que o criou; muitos sistemas permitem definir tambm um grupo
proprietrio do arquivo, ou seja, um grupo de usurios com acesso
diferenciado sobre o mesmo;
Permisses de acesso: define que operaes cada usurio do sistema
pode efetuar sobre o arquivo.
Existem muitas formas de se definir permisses de acesso a recursos em
um sistema computacional; no caso de arquivos, a mais difundida emprega
listas de controle de acesso (ACL - Access Control Lists) associadas a cada
arquivo. Uma lista de controle de acesso basicamente uma lista indicando
que usurios esto autorizados a acessar o arquivo, e como cada um pode
acess-lo. Um exemplo conceitual de listas de controle de acesso a arquivos
seria:
1
2
3
arq1.txt : (Joo: ler), (Jos: ler, escrever), (Maria: ler, remover)

video.avi : (Jos: ler), (Maria: ler)
musica.mp3: (Daniel: ler, escrever, apagar)
c Carlos Maziero
218
No entanto, essa abordagem se mostra pouco prtica caso o sistema tenha

muitos usurios e/ou arquivos, pois as listas podem ficar muito extensas e
difceis de gerenciar. O UNIX usa uma abordagem bem mais simplificada
para controle de acesso, que considera basicamente trs tipos de usurios e
trs tipos de permisses:
Usurios: o proprietrio do arquivo (User), um grupo de usurios
associado ao arquivo (Group) e os demais usurios (Others).
Permisses: ler (Read), escrever (Write) e executar (eXecute).
Dessa forma, no UNIX so necessrios apenas 9 bits para definir as permisses de acesso a cada arquivo ou diretrio. Por exemplo, considerando
a seguinte listagem de diretrio em um sistema UNIX (editada para facilitar
sua leitura):
1
2
3
4
5
6
7
host:~> ls -l
d rwx --- --- rwx r-x --- rw- r-- r-- rw- --- --- rw- r-- r-- rw- --- ---
2
1
1
1
1
1
maziero
maziero
maziero
maziero
maziero
maziero
prof
prof
prof
prof
prof
prof
4096
7248
54
59
195780
40494
2008-09-27
2008-08-23
2008-08-23
2008-08-23
2008-09-26
2008-09-27
08:43
09:54
09:54
09:49
22:08
08:44
figuras
hello-unix
hello-unix.c
hello-windows.c
main.pdf
main.tex
Nessa listagem, o arquivo hello-unix.c (linha 4) pode ser acessado em

leitura e escrita por seu proprietrio (o usurio maziero, com permisses
rw-), em leitura pelos usurios do grupo prof (permisses r--) e em leitura
pelos demais usurios do sistema (permisses r--). J o arquivo hello-unix
(linha 3) pode ser acessado em leitura, escrita e execuo por seu proprietrio
(permisses rwx), em leitura e execuo pelos usurios do grupo prof
(permisses r-x) e no pode ser acessado pelos demais usurios (permisses
---). No caso de diretrios, a permisso de leitura autoriza a listagem do
diretrio, a permisso de escrita autoriza sua modificao (criao, remoo
ou renomeao de arquivos ou sub-diretrios) e a permisso de execuo
autoriza usar aquele diretrio como diretrio de trabalho ou parte de um
caminho.
No mundo Windows, o sistema de arquivos NTFS implementa um
controle de acesso bem mais flexvel que o do UNIX, que define permisses
aos proprietrios de forma similar, mas no qual permisses complementares
c Carlos Maziero
219
6: Compartilhamento de arquivos
a usurios individuais podem ser associadas a qualquer arquivo. Mais

detalhes sobre os modelos de controle de acesso usados nos sistemas UNIX
e Windows podem ser encontrados no Captulo 8.
importante destacar que o controle de acesso normalmente realizado
somente durante a abertura do arquivo, para a criao de sua referncia em
memria. Isso significa que, uma vez aberto um arquivo por um processo,
este ter acesso ao arquivo enquanto o mantiver aberto, mesmo que as
permisses do arquivo sejam alteradas para impedir esse acesso. O controle
contnuo de acesso aos arquivos pouco frequentemente implementado
em sistemas operacionais, porque verificar as permisses de acesso a cada
operao de leitura ou escrita em um arquivo teria um impacto negativo
significativo sobre o desempenho do sistema.
6.2.4
Compartilhamento de arquivos
Em um sistema multi-tarefas, frequente ter arquivos acessados por

mais de um processo, ou mesmo mais de um usurio, caso as permisses de
acesso ao mesmo o permitam. Conforme estudado no Captulo 4, o acesso
simultneo a recursos compartilhados pode gerar condies de disputa
(race conditions), que levam inconsistncia de dados e outros problemas. O
acesso concorrente em leitura a um arquivo no acarreta problemas, mas a
possibilidade de escritas e leituras simultneas tem de ser prevista e tratada
de forma adequada.
Travas em arquivos
A soluo mais simples e mais frequentemente utilizada para gerenciar
o acesso compartilhado a arquivos o uso de travas de excluso mtua
(mutex locks), estudadas no Captulo 4. A maioria dos sistemas operacionais
oferece algum mecanismo de sincronizao para o acesso a arquivos, na
forma de uma ou mais travas (locks) associadas a cada arquivo aberto. A
sincronizao pode ser feita sobre o arquivo inteiro ou sobre algum trecho
especfico dele, permitindo que dois ou mais processos possam trabalhar
em partes distintas de um arquivo sem necessidade de sincronizao entre
eles.
As travas oferecidas pelo sistema operacional podem ser obrigatrias
(mandatory locks) ou recomendadas (advisory locks). As travas obrigatrias
so impostas pelo ncleo de forma incontornvel: se um processo obtiver a
c Carlos Maziero
220
trava do arquivo para si, outros processos que solicitarem acesso ao arquivo
sero suspensos at que a respectiva trava seja liberada. Por outro lado, as
travas recomendadas no so impostas pelo ncleo do sistema operacional.
Neste caso, um processo pode acessar um arquivo mesmo sem ter sua trava.
Caso sejam usadas travas recomendadas, cabe ao programador implementar
os controles de trava necessrios em suas aplicaes, para impedir acessos
conflitantes aos arquivos.
As travas sobre arquivos tambm podem ser exclusivas ou compartilhadas. Uma trava exclusiva, tambm chamada trava de escrita, garante acesso
exclusivo ao arquivo: enquanto uma trava exclusiva estiver ativa, nenhum
outro processo poder obter uma trava sobre aquele arquivo. J uma trava
compartilhada (ou trava de leitura) impede outros processos de criar travas
exclusivas sobre aquele arquivo, mas permite a existncia de outras travas
compartilhadas. Em conjunto, as travas exclusivas e compartilhadas implementam um modelo de sincronizao leitores/escritores (descrito na Seo
4.9.2), no qual os leitores acessam o arquivo usando travas compartilhadas
e os escritores o fazem usando travas exclusivas.
importante observar que normalmente as travas de arquivos so atribudas a processos, portanto um processo s pode ter um tipo de trava sobre
um mesmo arquivo. Alm disso, todas as suas travas so liberadas quando o
processo fecha o arquivo ou encerra sua execuo. No UNIX, a manipulao
de travas em arquivos feita atravs das chamadas de sistema flock e
fcntl. Esse sistema oferece por default travas recomendadas exclusivas ou
compartilhadas sobre arquivos ou trechos de arquivos. Sistemas Windows
oferecem por default travas obrigatrias sobre arquivos, que podem ser
exclusivas ou compartilhadas, ou travas recomendadas sobre trechos de
arquivos.
Semntica de acesso
Quando um arquivo aberto e usado por um nico processo, o funcionamento das operaes de leitura e escrita simples e inequvoco: quando um
dado escrito no arquivo, ele est prontamente disponvel para leitura se o
processo desejar l-lo novamente. No entanto, arquivos podem ser abertos
por vrios processos simultaneamente, e os dados escritos por um processo
podem no estar prontamente disponveis aos demais processos que lem
aquele arquivo. Isso ocorre porque os discos rgidos so normalmente
lentos, o que leva os sistemas operacionais a usar buffers intermedirios
c Carlos Maziero
221
para acumular os dados a escrever e assim otimizar o acesso aos discos.

A forma como os dados escritos por um processo so percebidos pelos
demais processos que abriram aquele arquivo chamada de semntica de
compartilhamento. Existem vrias semnticas possveis, mas as mais usuais
so [Silberschatz et al., 2001]:
Semntica UNIX: toda modificao em um arquivo imediatamente visvel
a todos os processos que mantm aquele arquivo aberto; existe tambm
a possibilidade de vrios processos compartilharem o mesmo ponteiro
de posicionamento do arquivo. Essa semntica a mais comum
em sistemas de arquivos locais, ou seja, para acesso a arquivos nos
dispositivos locais;
Semntica de sesso: considera que cada processo usa um arquivo em
uma sesso, que inicia com a abertura do arquivo e que termina com
seu fechamento. Modificaes em um arquivo feitas em uma sesso
somente so visveis na mesma seo e pelas sesses que iniciarem
depois do encerramento da mesma, ou seja, depois que o processo
fechar o arquivo; assim, sesses concorrentes de acesso a um arquivo
compartilhado podem ver contedos distintos para o mesmo arquivo.
Esta semntica normalmente aplicada a sistemas de arquivos de
rede, usados para acesso a arquivos em outros computadores;
Semntica imutvel: de acordo com esta semntica, se um arquivo pode ser
compartilhado por vrios processos, ele marcado como imutvel, ou
seja, seu contedo no pode ser modificado. a forma mais simples de
garantir a consistncia do contedo do arquivo entre os processos que
compartilham seu acesso, sendo por isso usada em alguns sistemas de
arquivos distribudos.
A Figura 6.6 traz um exemplo de funcionamento da semntica de sesso:
os processos p1 a p4 compartilham o acesso ao mesmo arquivo, que contm
apenas um nmero inteiro, com valor inicial 23. Pode-se perceber que o
valor 39 escrito por p1 visto por ele na mesma sesso, mas no visto por
p2 , que abriu o arquivo antes do fim da sesso de p1 . O processo p3 v o
valor 39, pois abriu o arquivo depois que p1 o fechou, mas no v o valor
escrito por p2 . Da mesma forma, o valor 71 escrito por p2 no percebido
por p3 , mas somente por p4 .
c Carlos Maziero
222
6: Exemplo de interface
71
p4
close
read
39
close
read
23
23
open
p2
39
write
71
close
read
23
write
open
p3
p1
12
open
read
write
39
open
close
read
write
read
Figura 6.6: Compartilhamento de arquivo usando a semntica de sesso.
6.2.5
Exemplo de interface
Como visto na Seo 6.2.1, cada linguagem de programao define sua

prpria forma de representar arquivos abertos e as funes ou mtodos
usados para manipul-los. A ttulo de exemplo, ser apresentada uma
viso geral da interface para arquivos oferecida pela linguagem C no
padro ANSI [Kernighan and Ritchie, 1989]. Em C, cada arquivo aberto
representado por uma varivel dinmica do tipo FILE*, criada pela funo
fopen. As funes de acesso a arquivos so definidas na Biblioteca Padro
de Entrada/Sada (Standard I/O Library, definida no arquivo de cabealho
stdio.h). As funes mais usuais dessa biblioteca so apresentadas a seguir:
Abertura e fechamento de arquivos:
FILE * fopen (const char *filename, const char *opentype

abre o arquivo cujo nome indicado por filename; a forma
de abertura (leitura, escrita, etc.) indicada pelo parmetro
opentype; em caso de sucesso, devolve uma referncia ao
arquivo;
int fclose (FILE *f): fecha o arquivo referenciado por f;
Leitura e escrita de caracteres e strings:
c Carlos Maziero
223
6: Exemplo de interface
int fputc (int c, FILE *f): escreve um caractere no arquivo;

int fgetc (FILE *f): l um caractere do arquivo ;
Reposicionamento do ponteiro do arquivo:
long int ftell (FILE *f): indica a posio corrente do ponteiro do arquivo referenciado por f;
int fseek (FILE *f, long int offset, int whence):
move o ponteiro do arquivo para a posio indicada por
offset;
void rewind (FILE *f): retorna o ponteiro do arquivo sua
posio inicial;
int feof (FILE *f): indica se o ponteiro chegou ao final do
arquivo;
Tratamento de travas:
void flockfile (FILE *f): solicita acesso exclusivo ao arquivo, podendo bloquear o processo solicitante caso o arquivo j
tenha sido reservado por outro processo;
void funlockfile (FILE *f): libera o acesso ao arquivo.
O exemplo a seguir ilustra o uso de algumas dessas funes. Esse
programa abre um arquivo chamado numeros.dat para operaes de leitura
(linha 9), verifica se a abertura do arquivo foi realizada corretamente (linhas
11 a 15), l seus caracteres e os imprime na tela at encontrar o fim do
arquivo (linhas 17 a 23) e finalmente o fecha (linha 25).
c Carlos Maziero
224
1
2
6: Organizao de volumes
#include <stdio.h>
#include <stdlib.h>
3
4
5
6
7
int main (int argc, char *argv[], char* envp[])

{
FILE *arq ;
char c ;
arq = fopen ("infos.dat", "r") ; /* abertura do arquivo em leitura */
9
10
if (! arq) /* referencia de arquivo invalida */

{
perror ("Erro ao abrir arquivo") ;
exit (1) ;
}
11
12
13
14
15
16
while (1)
{
c = getc (arq) ; /* le um caractere do arquivo */
if (feof (arq)) /* chegou ao final do arquivo? */
break ;
putchar(c) ;
/* imprime o caractere na tela */
}
17
18
19
20
21
22
23
24
fclose (arq) ;
exit (0) ;
25
26
27
/* fecha o arquivo */
6.3
Organizao de volumes
Um computador normalmente possui um ou mais dispositivos para

armazenar arquivos, que podem ser discos rgidos, discos ticos (CDROM, DVD-ROM), discos de estado slido (baseados em memria flash,
como pendrives USB), etc. A estrutura fsica dos discos rgidos e demais
dispositivos ser discutida em detalhes no Captulo 7; por enquanto, um
disco rgido pode ser visto basicamente como um grande vetor de blocos de
bytes. Esses blocos de dados, tambm denominados setores, tm tamanho
fixo geralmente entre 512 e 4.096 bytes e so numerados sequencialmente.
As operaes de leitura e escrita de dados nesses dispositivos so feitas
bloco a bloco, por essa razo esses dispositivos so chamados dispositivos de
blocos (block devices).
c Carlos Maziero
225
6: Diretrios
Em um computador no padro PC, o espao de armazenamento de cada

dispositivo dividido em uma pequena rea inicial de configurao e uma
ou mais parties, que podem ser vistas como espaos independentes. A rea
de configurao denominada MBR - Master Boot Record, e contm uma tabela
de parties com informaes sobre o particionamento do dispositivo. Alm
disso, contm tambm um pequeno cdigo executvel, usado no processo de
inicializao do sistema operacional. No incio de cada partio geralmente
h um bloco reservado, utilizado para a descrio do contedo daquela
partio e para armazenar o cdigo de lanamento do sistema operacional,
se for uma partio inicializvel (bootable partition). Esse bloco reservado
denominado bloco de inicializao ou VBR - Volume Boot Record. O restante
dos blocos da partio est disponvel para o armazenamento de arquivos.
A Figura 6.7 ilustra a organizao bsica do espao de armazenamento em
um dispositivo de blocos tpico: um disco rgido.
reas de armazenamento de dados
partio 1
Master Boot Record
partio 2
partio 3
Volume Boot Records
Figura 6.7: Organizao em parties de um disco rgido tpico.

Cada partio deve ser formatada, ou seja, estruturada para conter um
sistema de arquivos, que pode conter arquivos, diretrio, atalhos e outras
entradas. Cada dispositivo ou partio devidamente preparado e formatado
para receber um sistema de arquivos designado como um volume.
6.3.1
Diretrios
A quantidade de arquivos em um sistema atual pode ser muito grande,

chegando facilmente a milhes deles em um computador desktop tpico,
e muito mais em servidores. Embora o sistema operacional possa tratar
facilmente essa imensa quantidade de arquivos, essa tarefa no to simples
para os usurios: identificar e localizar de forma inequvoca um arquivo
especfico em meio a milhes de outros arquivos pode ser impraticvel.
c Carlos Maziero
226
6: Diretrios
Para permitir a organizao de arquivos dentro de uma partio, so

usados diretrios. Um diretrio, tambm chamado de pasta (folder), representa
um continer de informaes, que pode conter arquivos ou mesmo outros
diretrios. Da mesma forma que os arquivos, diretrios tm nome e atributos,
que so usados na localizao e acesso aos arquivos neles contidos.
Cada espao de armazenamento possui ao menos um diretrio principal,
denominado diretrio raiz (root directory). Em sistemas de arquivos mais
antigos e simples, o diretrio raiz de um volume estava definido em
seus blocos de inicializao, normalmente reservados para informaes de
gerncia. Todavia, como o nmero de blocos reservados era pequeno e fixo,
o nmero de entradas no diretrio raiz era limitado. Nos sistemas mais
recentes, um registro especfico dentro dos blocos de inicializao aponta
para a posio do diretrio raiz dentro do sistema de arquivos, permitindo
que este tenha um nmero muito maior de entradas.
O uso de diretrios permite construir uma estrutura hierrquica (em
rvore) de armazenamento dentro de um volume, sobre a qual os arquivos
so distribudos. A Figura 6.8 representa uma pequena parte da rvore de
diretrios tpica de um sistema Linux, cuja estrutura definida nas normas
Filesystem Hierarchy Standard [Russell et al., 2004].
Os primeiros sistemas de arquivos implementavam apenas o diretrio
raiz, que continha todos os arquivos do volume. Posteriormente, ofereceram
sub-diretrios, ou seja, um nvel de diretrios abaixo do diretrio raiz. Os
sistemas atuais oferecem uma estrutura muito mais flexvel, com um nmero
de nveis de diretrios muito mais elevado, ou mesmo ilimitado (como no
NTFS e no Ext3).
A implementao de diretrios relativamente simples: um diretrio
implementado como um arquivo estruturado, cujo contedo uma relao
de entradas. Os tipos de entradas normalmente considerados nessa relao
so arquivos normais, diretrios, atalhos (vide Seo 6.3.3) e entradas
associadas a arquivos especiais, como os discutidos na Seo 6.1.1. Cada
entrada contm ao menos o nome do arquivo (ou do diretrio), seu tipo e a
localizao fsica do mesmo no volume. Deve ficar claro que um diretrio
no contm fisicamente os arquivos e sub-diretrios, ele apenas os relaciona.
Duas entradas padronizadas so usualmente definidas em cada diretrio:
a entrada . (ponto), que representa o prprio diretrio, e a entrada ..
(ponto-ponto), que representa seu diretrio pai (o diretrio imediatamente
acima dele na hierarquia de diretrios). No caso do diretrio raiz, ambas as
entradas apontam para ele prprio.
c Carlos Maziero
227
bin
etc
home
lib
proc
root
tmp
usr
var
6: Caminhos de acesso
bin
lib
include
opt
sgml
skel
X11
X11
X11
asm
linux
g++
X11R6
bin
include
lib
local
man
share
src
tmp
adm
cache
cron
lib
local
log
mail
run
spool
X11
gcc-lib
groff
uucp
bin
doc
etc
include
lib
man
share
at
cron
lpd
mail
news
smail
doc
games
info
locale
man
zoneinfo
Figura 6.8: Estrutura de diretrios tpica de um sistema Linux.

A Figura 6.9 apresenta uma possibilidade de implementao de parte da
estrutura de diretrios apresentada na Figura 6.8. Os tipos das entradas em
cada diretrio so: A para arquivos normais e D para diretrios.
A relao de entradas em um diretrio, tambm chamada de ndice do
diretrio, pode ser implementada como uma lista linear, como no caso do
MS-DOS e do Ext2 (Linux) ou como algum tipo de tabela hash ou rvore, o
que feito no NTFS e no Ext3, entre outros. A implementao em lista linear
mais simples, mas tem baixo desempenho. A implementao em tabela
hash ou rvore prov um melhor desempenho quando necessrio percorrer
a estrutura de diretrios em busca de arquivos, o que ocorre frequentemente.
6.3.2
Caminhos de acesso
Em um sistema de arquivos, os arquivos esto dispersos ao longo da

hierarquia de diretrios. Para poder abrir e acessar um arquivo, torna-se
c Carlos Maziero
228
VBR
/
.
..
bin
etc
home
lib
usr
var
0101011
110000110
001101011
101110100
110000010
100011111
010110100
Volume (disco ou partio)
D
D
D
D
D
D
D
D
0101011
110000110
001101011
101110100
110000010
100011111
010110100
bin
.
..
cp
ls
mv
D
D
A
A
A
home
.
..
daniel
ike
D
D
D
D
lib
.
..
X11
lib.a
lib.so
D
D
D
A
A
0101011
110000110
001101011
101110100
110000010
100011111
010110100
daniel
.
..
arq1
arq2
1111010
101010101
011010101
111110100
000100111
010101010
111100000
D
D
A
A
1100110
110011001
100110011
111110011
111110011
111111111
000000000
0000000
000000000
111100000
111111111
111111111
111000011
000010101
1100110
110011001
100110011
111110011
111110011
111111111
000000000
X11
.
D
..
D
libX.a A
0101011
110000110
001101011
101110100
110000010
100011111
010110100
Figura 6.9: Implementao de uma estrutura de diretrios.

ento necessrio conhecer sua localizao completa, ao invs de somente seu
nome. A posio de um arquivo dentro do sistema de arquivos chamada
de caminho de acesso ao arquivo. Normalmente, o caminho de acesso a um
arquivo composto pela sequncia de nomes de diretrios que levam at ele,
separadas por um caractere especfico. Por exemplo, o sistema Windows usa
como separador o caractere \, enquanto sistemas UNIX usam o caractere
/; outros sistemas podem usar caracteres como : e !. Exemplos de
caminhos de acesso a arquivos seriam \Windows\system32\ole32.dll (no
Windows) e /usr/bin/bash (em sistemas UNIX).
A maioria dos sistemas implementa o conceito de diretrio de trabalho
ou diretrio corrente de um processo (working directory). Ao ser criado,
cada novo processo recebe um diretrio de trabalho, que ser usado por ele
como local default para criar novos arquivos ou abrir arquivos existentes,
c Carlos Maziero
229
quando no informar os respectivos caminhos de acesso. Cada processo

geralmente herda o diretrio de trabalho de seu pai, mas pode mudar de
diretrio atravs de chamadas de sistema (como chdir nos sistemas UNIX).
Existem basicamente trs formas de se referenciar arquivos em um
sistema de arquivos:
Referncia direta: somente o nome do arquivo informado; neste caso,
considera-se que o arquivo est (ou ser criado) no diretrio de trabalho
do processo. Exemplos:
1
2
3
prova1.doc
materiais.pdf
uma-bela-foto.jpg
Referncia absoluta: o caminho de acesso ao arquivo indicado a partir do

diretrio raiz do sistema de arquivos, e no depende do diretrio de
trabalho do processo; uma referncia absoluta a um arquivo sempre
inicia com o caractere separador, indicando que o nome do arquivo
est referenciado a partir do diretrio raiz do sistema de arquivos. O
caminho de acesso mais curto a um arquivo a partir do diretrio raiz
denominado caminho cannico do arquivo. Nos exemplos de referncias
absolutas a seguir, os dois primeiros so caminhos cannicos, enquanto
os dois ltimos no o so:
1
2
3
4
\Windows\system32\drivers\etc\hosts.lm
/usr/local/share/fortunes/brasil.dat
\Documents and Settings\Carlos Maziero\..\All Users\notas.xls
/home/maziero/bin/scripts/../../docs/proj1.pdf
Referncia relativa: o caminho de acesso ao arquivo tem como incio o

diretrio de trabalho do processo, e indica sub-diretrios ou diretrios
anteriores, atravs de referncias ..; eis alguns exemplos:
1
2
3
4
imagens\satelite\brasil\geral.jpg
..\users\maziero\documentos\prova-2.doc
public_html/static/fotografias/rennes.jpg
../../../share/icons/128x128/calculator.svg
c Carlos Maziero
230
Durante a abertura de um arquivo, o sistema operacional deve encontrar

a localizao do mesmo no dispositivo de armazenamento, a partir do nome
e caminho informados pelo processo. Para isso, necessrio percorrer as
estruturas definidas pelo caminho do arquivo at encontrar sua localizao,
em um procedimento denominado localizao de arquivo (file lookup). Por
exemplo, para abrir o arquivo /usr/lib/X11/libX.a da Figura 6.9 seria
necessrio executar os seguintes passos3 :
1. Acessar o disco para ler o VBR (Volume Boot Record) do volume;
2. Nos dados lidos, descobrir onde se encontra o diretrio raiz (/) daquele
sistema de arquivos;
3. Acessar o disco para ler o diretrio raiz;
4. Nos dados lidos, descobrir onde se encontra o diretrio usr;
5. Acessar o disco para ler o diretrio usr;
6. Nos dados lidos, descobrir onde se encontra o diretrio lib;
7. Acessar o disco para ler o diretrio lib;
8. Nos dados lidos, descobrir onde se encontra o diretrio X11;
9. Acessar o disco para ler o diretrio X11;
10. Nos dados lidos, descobrir onde se encontra o arquivo libX11.a;
11. Acessar o disco para ler o bloco de controle do arquivo libX11.a, que
contm seus atributos;
12. Criar as estruturas em memria que representam o arquivo aberto;
13. Retornar uma referncia ao arquivo para o processo solicitante.
Pode-se perceber que a localizao de arquivo um procedimento
trabalhoso. Neste exemplo, foram necessrias 5 leituras no disco (passos 1,
3, 5, 7 e 9) apenas para localizar a posio do bloco de controle do arquivo
desejado no disco. Assim, o tempo necessrio para localizar um arquivo
3
Para simplificar, foram omitidas as verificaes de existncia de entradas, de permisses

de acesso e os tratamentos de erro.
c Carlos Maziero
231
6: Atalhos
pode ser muito elevado, pois discos rgidos so dispositivos lentos. Para
evitar esse custo e melhorar o desempenho do mecanismo de localizao
de arquivos, mantido em memria um cache de entradas de diretrio
localizadas recentemente, gerenciado de acordo com uma poltica LRU
(Least Recently Used). Cada entrada desse cache contm um nome de arquivo
ou diretrio e sua localizao no dispositivo fsico. Esse cache geralmente
organizado na forma de uma tabela hash, o que permite localizar rapidamente
os arquivos ou diretrios recentemente utilizados.
6.3.3
Atalhos
Em algumas ocasies, pode ser necessrio ter um mesmo arquivo ou

diretrio replicado em vrias posies dentro do sistema de arquivos.
Isso ocorre frequentemente com arquivos de configurao de programas e
arquivos de bibliotecas, por exemplo. Nestes casos, seria mais econmico
armazenar apenas uma instncia dos dados do arquivo no sistema de
arquivos e criar referncias indiretas (ponteiros) para essa instncia, para
representar as demais cpias do arquivo. O mesmo raciocnio pode ser
aplicado a diretrios duplicados. Essas referncias indiretas a arquivos ou
diretrios so denominadas atalhos (links).
Existem basicamente duas abordagens para a construo de atalhos:
Atalhos simblicos (soft links): cada cpia do arquivo original na verdade um pequeno arquivo de texto contendo uma string com o caminho
at o arquivo original (pode ser usado um caminho simples, absoluto
ou relativo posio do atalho). Como o caminho ao arquivo original
indicado de forma simblica, este pode estar localizado em outro
dispositivo fsico (outro disco ou uma unidade de rede). O arquivo
original e seus atalhos simblicos so totalmente independentes: caso
o arquivo original seja movido, renomeado ou removido, os atalhos
simblicos apontaro para um arquivo inexistente; neste caso, diz-se
que aqueles atalhos esto quebrados (broken links).
Atalhos fsicos (hard links): vrias referncias do arquivo no sistema de
arquivos apontam para a mesma localizao do dispositivo fsico
onde o contedo do arquivo est de fato armazenado. Normalmente
mantido um contador de referncias a esse contedo, indicando
quantos atalhos fsicos apontam para o mesmo: somente quando o
nmero de referncias ao arquivo for zero, aquele contedo poder
c Carlos Maziero
232
6: Atalhos
ser removido do dispositivo. Como so usadas referncias posio

do arquivo no dispositivo, atalhos fsicos s podem ser feitos para
arquivos dentro do mesmo sistema de arquivos (o mesmo volume).
A Figura 6.10 traz exemplos de implementao de atalhos simblicos
e fsicos a arquivos em um sistema de arquivos UNIX. As entradas de
diretrios indicadas como L correspondem a atalhos simblicos (de links).
Nessa figura, pode-se constatar que as entradas /bin/ls e /usr/bin/dir
so atalhos fsicos para o mesmo contedo no disco, enquanto a entrada
/bin/shell um atalho simblico para o arquivo /usr/bin/sh e /lib
um atalho simblico para o diretrio /usr/lib.
VBR
/
.
..
bin
etc
home
lib
usr
D
D
D
D
D
L
D
bin
.
..
cp
ls
rm
shell
D
D
A
A
A
L
link to:
/usr/lib
usr
.
..
bin
lib
Volume (disco ou partio)
D
D
D
D
0101011
110000110
001101011
101110100
110000010
100011111
010110100
link to:
/usr/bin/sh
bin
.
..
copy
cut
dir
sh
D
D
L
A
A
A
lib
.
..
X11
lib.a
lib.so
D
D
D
A
A
0101011
110000110
001101011
101110100
110000010
100011111
010110100
link to:
/bin/cp
0101011
110000110
001101011
101110100
110000010
100011111
010110100
Figura 6.10: Atalhos simblicos e fsicos a arquivos em UNIX.

Sistemas UNIX suportam atalhos fsicos e simblicos, com algumas
limitaes: atalhos fsicos geralmente s podem ser feitos para arquivos
dentro do mesmo sistema de arquivos (mesmo volume) e no so permitidos
c Carlos Maziero
233
6: Montagem de volumes
atalhos fsicos para diretrios4 . Em ambientes Windows, o sistema de

arquivos NTFS suporta ambos os tipos de atalhos (embora atalhos simblicos
s tenham sido introduzidos no Windows Vista), com limitaes similares.
6.3.4
Montagem de volumes
Para que o sistema operacional possa acessar o sistema de arquivos

presente em um determinado volume, ele deve ler os dados presentes em
seu bloco de inicializao, que descrevem o tipo de sistema de arquivos
presente, e criar as estruturas em memria que representam esse volume
dentro do ncleo. Alm disso, ele deve definir um identificador para o
volume, de forma que os processos possam acessar seus arquivos. Esse
procedimento denominado montagem do volume, e seu nome vem do
tempo em que era necessrio montar fisicamente os discos rgidos ou fitas
magnticas nos leitores, antes de poder acessar seus dados. O procedimento
oposto, a desmontagem, consiste em fechar todos os arquivos abertos no
volume e remover as estruturas de memria usadas para gerenci-lo.
A montagem um procedimento frequente no caso de mdias mveis,
como CD-ROMs, DVD-ROMs e pendrives USB. Neste caso, a desmontagem
do volume inclui tambm ejetar a mdia (CD, DVD) ou avisar o usurio que
ela pode ser removida (discos USB).
Ao montar um volume, deve-se fornecer aos processos e usurios uma
referncia para seu acesso, denominada ponto de montagem (mounting point).
Sistemas UNIX normalmente definem os pontos de montagem de volumes
como posies dentro da rvore principal do sistema de arquivos. Dessa
forma, h um volume principal, montado durante a inicializao do sistema
operacional, onde normalmente reside o prprio sistema operacional e que
define a estrutura bsica da rvore de diretrios. Os volumes secundrios
so montados como sub-diretrios na rvore do volume principal, atravs
do comando mount. A Figura 6.11 apresenta um exemplo de montagem
de volumes em plataformas UNIX. Nessa figura, o disco rgido 1 contm o
sistema operacional e foi montado como raiz da rvore de diretrios durante
a inicializao do sistema. O disco rgido 2 contm os diretrios de usurios
e seu ponto de montagem o diretrio /home. J o diretrio /media/cdrom
4
Atalhos fsicos para diretrios geralmente so proibidos porque permitiriam diretrios

recursivos, tornando muito complexa a implementao de rotinas de verificao e gerncia
do sistema de arquivos.
c Carlos Maziero
234
6: Sistemas de arquivos
o ponto de montagem de uma mdia removvel (CD-ROM), com sua rvore

de diretrios prpria.
bin
etc
home
dout
Disco rgido 2
espec
grad
alcides
mest
maziero
prof
santin
/
apagar
lib
media
usr
Disco rgido 1
var
backup
fotos
Pendrive USB
livro
cdrom
CD-ROM
bin
html
docs
pdf
extras
txt
install
Figura 6.11: Montagem de volumes em UNIX.

Em sistemas de arquivos de outras plataformas, como DOS e Windows,
comum definir cada volume montado como um disco lgico distinto,
chamado simplesmente de disco ou drive e identificado por uma letra (A:,
C:, D:, etc.). Todavia, o sistema de arquivos NTFS do Windows tambm
permite a montagem de volumes como sub-diretrios, da mesma forma que
o UNIX.
6.4
Sistemas de arquivos
Vrios problemas importantes devem ser resolvidos na construo de

um sistema de arquivos, que vo do acesso de baixo nvel aos dispositivos
fsicos de armazenamento implementao da interface de acesso a arquivos
para os programadores. Na implementao de um sistema de arquivos,
considera-se que cada arquivo possui dados e meta-dados. Os dados de
um arquivo so o seu contedo em si (uma msica, uma fotografia, um
documento ou uma planilha); por outro lado, os meta-dados do arquivo
so seus atributos (nome, datas, permisses de acesso, etc.) e todas as
c Carlos Maziero
235
6: Arquitetura geral
informaes de controle necessrias para localizar e manter seu contedo

no disco.
Nesta seo sero discutidos os principais elementos que compem a
gerncia de arquivos em um sistema operacional tpico.
6.4.1
Arquitetura geral
Os principais elementos que constituem a gerncia de arquivos esto

organizados em camadas, conforme apresentado na Figura 6.12. No nvel
mais baixo dessa arquitetura esto os dispositivos de armazenamento,
como discos rgidos ou bancos de memria flash, responsveis pelo armazenamento dos dados e meta-dados dos arquivos. Esses dispositivos so
acessados atravs de controladores, que so circuitos eletrnicos dedicados
ao controle e interface dos dispositivos. A interface entre controladores e
dispositivos de armazenamento segue padres como SATA, ATAPI, SCSI,
USB e outros.
Os controladores de dispositivos so configurados e acessados pelo
ncleo do sistema operacional atravs de drivers de dispositivos, que so
componentes de software capazes de interagir com os controladores. Os
drivers usam portas de entrada/sada, interrupes e canais de acesso direto
memria (DMA) para interagir com os controladores e realizar as operaes
de controle e de entrada/sada de dados. Como cada controlador define sua
prpria interface, tambm possui um driver especfico. Os drivers ocultam
essas interfaces e fornecem s camadas superiores do ncleo uma interface
padronizada para acesso aos dispositivos de armazenamento. Desta forma,
os detalhes tecnolgicos e particularidades de cada dispositivo so isolados,
tornando o restante do sistema operacional independente da tecnologia
subjacente.
Acima dos drivers est a camada de gerncia de blocos, que gerencia o
fluxo de blocos de dados entre a memria e os dispositivos de armazenamento. importante lembrar que os discos so dispositivos orientados a
blocos, ou seja, as operaes de leitura e escrita de dados so sempre feitas
com blocos de dados, e nunca com bytes individuais. As funes mais
importantes desta camada so efetuar o mapeamento de blocos lgicos nos
blocos fsicos do dispositivo, oferecer s camadas superiores a abstrao
de cada dispositivo fsico como sendo um imenso vetor de blocos lgicos,
independente de sua configurao real, e tambm efetuar o caching/buffering
de blocos (Seo 7.4.4).
c Carlos Maziero
236
6: Arquitetura geral
processo
biblioteca de E/S
espao de usurio
chamadas de sistema
ncleo
sistema de arquivos virtual
alocao de arquivos
alocao de arquivos
gerncia de blocos
driver de dispositivo
driver de dispositivo
controlador
controlador
dispositivo
dispositivo
software
hardware
Figura 6.12: Camadas da implementao da gerncia de arquivos.

A seguir est a camada de alocao de arquivos, que tem como funo
principal alocar os arquivos sobre os blocos lgicos oferecidos pela gerncia
de blocos. Cada arquivo visto como uma sequncia de blocos lgicos que
deve ser armazenada nos blocos dos dispositivos de forma eficiente, robusta
e flexvel. As principais tcnicas de alocao de arquivos so discutidas na
Seo 6.4.3.
Acima da alocao de arquivos est o sistema de arquivos virtual
(VFS - Virtual File System), que prov uma interface de acesso a arquivos
independente dos dispositivos fsicos e das estratgias de alocao de
c Carlos Maziero
237
6: Blocos fsicos e lgicos
arquivos empregadas pelas camadas inferiores. O sistema de arquivos

virtual normalmente gerencia as permisses associadas aos arquivos e
as travas de acesso compartilhado, alm de construir as abstraes de
diretrios e atalhos. Outra responsabilidade importante desta camada
manter informaes sobre cada arquivo aberto pelos processos, como a
posio da ltima operao no arquivo, o modo de abertura usado e o
nmero de processos que esto usando o arquivo. A interface de acesso
ao sistema de arquivos virtual oferecida aos processos atravs de um
conjunto de chamadas de sistema.
Finalmente, as bibliotecas de entrada/sada usam as chamadas de sistema oferecidas pelo sistema operacional para construir funes padronizadas de acesso a arquivos para cada linguagem de programao, como
aquelas apresentadas na Seo 6.2.5 para a linguagem C ANSI.
6.4.2
Blocos fsicos e lgicos
Um dos aspectos mais importantes dos sistemas de arquivos a forma

como o contedo dos arquivos disposto dentro do disco rgido ou outro
dispositivo de armazenamento secundrio. Conforme visto na Seo 6.3,
um disco rgido pode ser visto como um conjunto de blocos de tamanho
fixo (geralmente de 512 bytes). Os blocos do disco rgido so normalmente
denominados blocos fsicos. Como esses blocos so pequenos, o nmero de
blocos fsicos em um disco rgido recente pode ser imenso: um disco rgido
de 250 GBytes contm mais de 500 milhes de blocos fsicos! Para simplificar
a gerncia dessa quantidade de blocos fsicos e melhorar o desempenho das
operaes de leitura/escrita, os sistemas operacionais costumam trabalhar
com blocos lgicos ou clusters, que so grupos de 2n blocos fsicos consecutivos.
Blocos lgicos com 4K, 8K, 16K e 32K bytes so frequentemente usados. A
maior parte das operaes e estruturas de dados definidas nos discos pelos
sistemas operacionais so baseadas em blocos lgicos, que tambm definem
a unidade mnima de alocao de arquivos e diretrios: cada arquivo ou
diretrio ocupa um ou mais blocos lgicos para seu armazenamento.
O nmero de blocos fsicos em cada bloco lgico de uma partio
definido pelo sistema operacional ao formatar a partio, em funo de
vrios parmetros, como o tamanho da partio, o sistema de arquivos usado
e o tamanho das pginas de memria RAM. Blocos lgicos muito pequenos
implicam em ter mais blocos a gerenciar e menos bytes transferidos em cada
operao de leitura/escrita, o que tem impacto negativo sobre o desempenho
c Carlos Maziero
238
6: Alocao fsica de arquivos
do sistema. Por outro lado, blocos lgicos muito grandes podem levar
fragmentao interna: um arquivo com 200 bytes armazenado em um sistema
de arquivos com blocos lgicos de 32.768 bytes (32K) ocupar um bloco
lgico, do qual 32.568 bytes sero desperdiados, pois ficaro alocados ao
arquivo sem serem usados. A fragmentao interna diminui o espao til
do disco rgido, por isso deve ser evitada. Uma forma de evit-la escolher
um tamanho de bloco lgico adequado ao tamanho mdio dos arquivos a
armazenar no disco, ao format-lo. Alm disso, alguns sistemas de arquivos
(como o UFS do Solaris e o ReiserFS do Linux) permitem a alocao de
partes de blocos lgicos, atravs de tcnicas denominadas fragmentos de
blocos ou alocao de sub-blocos [Vahalia, 1996].
6.4.3
Alocao fsica de arquivos
Um dispositivo de armazenamento visto pelas camadas superiores

como um grande vetor de blocos lgicos de tamanho fixo. O problema da
alocao de arquivos consiste em dispor (alocar) o contedo e os meta-dados
dos arquivos dentro desses blocos lgicos. Como os blocos lgicos so
pequenos, cada arquivo poder precisar de muitos blocos lgicos para
ser armazenado no disco (Figura 6.13). Os dados e meta-dados de um
arquivo devem estar dispostos nesses blocos de forma a permitir um acesso
rpido e confivel. Como um arquivo pode ocupar milhares ou mesmo
milhes de blocos, a forma de alocao dos arquivos nos blocos do disco
tem um impacto importante sobre o desempenho e a robustez do sistema
de arquivos.
A alocao de um arquivo no disco tem como ponto de partida a definio
de um bloco de controle de arquivo (FCB - File Control Block), que nada mais
que uma estrutura contendo os meta-dados do arquivo e a localizao de
seu contedo no disco. Em alguns sistemas de arquivos mais simples, como
o sistema FAT (File Alocation Table) usado em plataformas MS-DOS, o FCB
bastante pequeno e cabe na entrada correspondente ao arquivo, na tabela
de diretrio onde ele se encontra definido. Em sistemas de arquivos mais
complexos, os blocos de controle de arquivos so definidos em estruturas
separadas, como a Master File Table do sistema NTFS e os i-nodes dos sistemas
UNIX.
H trs estratgias usuais de alocao de arquivos nos blocos lgicos do
disco, que sero apresentadas a seguir: as alocaes contgua, encadeada
e indexada. Como diretrios so usualmente implementados na forma de
c Carlos Maziero
239
foto1.jpg
0
relat.pdf
blocos do dispositivo
instruc.txt
6
sinfonia.mp3
0
7 ...
Figura 6.13: O problema da alocao de arquivos.

arquivos, as estratgias de alocao discutidas aqui so vlidas tambm
para a alocao de diretrios. Essas estratgias sero descritas e analisadas
luz de trs critrios: a rapidez oferecida por cada estratgia no acesso
aos dados do arquivo, tanto para acessos sequenciais quanto para acessos
diretos; a robustez de cada estratgia frente a erros, como blocos de disco
defeituosos (bad blocks) e dados corrompidos; e a flexibilidade oferecida
por cada estratgia para a criao, modificao e excluso de arquivos e
diretrios.
Alocao contgua
Na alocao contgua, os dados do arquivo so dispostos de forma
ordenada sobre um conjunto de blocos consecutivos no disco, sem buracos
entre os blocos. Assim, a localizao do contedo do arquivo no disco
definida pelo endereo de seu primeiro bloco. A Figura 6.14 apresenta um
exemplo dessa estratgia de alocao (para simplificar o exemplo, considerase que a tabela de diretrios contm os meta-dados de cada arquivo, como
nome, tamanho em bytes e nmero do bloco inicial).
Como os blocos de cada arquivo se encontram em sequncia no disco,
o acesso sequencial aos dados do arquivo rpido, por exigir pouca
movimentao da cabea de leitura do disco. O acesso direto a posies
especficas do arquivo tambm rpido, pois a posio de cada byte do
arquivo pode ser facilmente calculada a partir da posio do bloco inicial,
c Carlos Maziero
240

00
Tabela de diretrio
01
bytes blocos incio
nome
02
03
foto1.jpg
10417
relat.pdf
28211
13
6214
20
06
19116
24
07
instruc.txt
sinfonia.mp3
blocos lgicos com 4096 bytes
04
05
08
09
10
11
12
13
14
15
bloco em uso
16
17
bloco livre
18
19
20
21
22
23
24
25
26
27
28
29
Figura 6.14: Estratgia de alocao contgua.

conforme indica o algoritmo 1. De acordo com esse algoritmo, o byte de
nmero 14.372 do arquivo relat.pdf da Figura 6.14 estar na posio 2.084
do bloco 16 do disco rgido.
Esta estratgia apresenta uma boa robustez a falhas de disco: caso um
bloco do disco apresente defeito e no permita a leitura de seus dados, apenas
o contedo daquele bloco perdido: o contedo do arquivo nos blocos
anteriores e posteriores ao bloco defeituoso ainda podero ser acessados
sem dificuldades. Por outro lado, o ponto fraco desta estratgia sua baixa
flexibilidade, pois o tamanho final de cada arquivo precisa ser conhecido
no momento de sua criao. Alm disso, esta estratgia est sujeita
fragmentao externa, de forma similar tcnica de alocao contgua
estudada nos mecanismos de alocao de memria (vide Seo 5.3.2):
c Carlos Maziero
241
Algoritmo 1 Localizar a posio do i-simo byte do arquivo no disco

i: nmero do byte a localizar
B: tamanho dos blocos lgicos, em bytes
b0 : nmero do bloco do disco onde o arquivo inicia
bi : nmero do bloco do disco onde se encontra o byte i
oi : posio do byte i dentro do bloco bi (offset)
: diviso inteira
mod: mdulo (resto da diviso inteira)
bi = b0 + i B
oi = i mod B
return (bi , oi )
medida em que arquivos so criados e destrudos, as reas livres do disco
vo sendo fracionadas em pequenas reas isoladas (os fragmentos) que
diminuem a capacidade de alocao de arquivos maiores. Por exemplo, na
situao da Figura 6.14 h 13 blocos livres no disco, mas somente podem
ser criados arquivos com at 7 blocos de tamanho. As tcnicas de alocao
first/best/worst-fit utilizadas em gerncia de memria tambm podem ser
aplicadas para atenuar este problema. Contudo, a desfragmentao de um
disco problemtica, pois pode ser uma operao muito lenta e os arquivos
no devem ser usados durante sua realizao.
A baixa flexibilidade desta estratgia e a possibilidade de fragmentao
externa limitam muito seu uso em sistemas operacionais de propsito geral,
nos quais os arquivos so constantemente criados, modificados e destrudos.
Todavia, ela pode encontrar uso em situaes especficas, nas quais os
arquivos no sejam modificados constantemente e seja necessrio rapidez
nos acessos sequenciais e diretos aos dados. Um exemplo dessa situao
so sistemas dedicados para reproduo de dados multimdia, como udio
e vdeo.
Alocao encadeada
Esta forma de alocao foi proposta para contornar a pouca flexibilidade
da alocao contgua e eliminar a fragmentao externa. Nela, cada bloco
do arquivo no disco contm dados do arquivo e tambm um ponteiro para o
prximo bloco, ou seja, um campo indicando o nmero do prximo bloco do
c Carlos Maziero
242
arquivo no disco. Desta forma construda uma lista encadeada de blocos

para cada arquivo, no sendo mais necessrio manter os blocos do arquivo
lado a lado no disco. Esta estratgia elimina a fragmentao externa, pois
todos os blocos livres do disco so utilizveis sem restries, e permite que
arquivos sejam criados sem a necessidade de definir seu tamanho final. A
Figura 6.15 ilustra um exemplo dessa abordagem.
00
Tabela de diretrio
01
bytes blocos incio
02
foto1.jpg
10417
03
relat.pdf
28211
13
6214
20
06
19116
24
07
nome
instruc.txt
sinfonia.mp3
04
05
08
09
10
11
12
13
14
15
bloco em uso
16
17
bloco livre
18
19
20
21
22
23
24
25
26
27
28
29
Figura 6.15: Estratgia de alocao encadeada.

Nesta abordagem, o acesso sequencial aos dados do arquivo simples e
rpido, pois cada bloco contm o ponteiro do prximo bloco do arquivo.
Todavia, caso os blocos estejam muito espalhados no disco, a cabea de
leitura ter de fazer muitos deslocamentos, diminuindo o desempenho de
acesso ao disco. J o acesso direto a posies especficas do arquivo fica
muito prejudicado com esta abordagem: caso se deseje acessar um bloco no
meio do arquivo, todos os blocos anteriores tero de ser lidos em sequncia,
para poder seguir os ponteiros que levam ao bloco desejado. O algoritmo
c Carlos Maziero
243

i: nmero do byte a localizar
B: tamanho dos blocos lgicos, em bytes
P: tamanho dos ponteiros de blocos, em bytes
b0 : nmero do primeiro bloco do arquivo no disco
bi : nmero do bloco do disco onde se encontra o byte i
oi : posio do byte i dentro do bloco bi (offset)
// define bloco inicial do percurso
baux = b0
// calcula nmero de blocos a percorrer
b = i (B P)
while b > 0 do
block = read_block (baux )
baux = ponteiro extrado de block
b=b1
end while
bi = baux
oi = i mod (B P)
return (bi , oi )
c Carlos Maziero
244
2 mostra claramente esse problema, indicado atravs do lao while. Essa

dependncia dos blocos anteriores tambm acarreta problemas de robustez:
caso um bloco do arquivo seja corrompido ou se torne defeituoso, todos
os blocos posteriores a este tambm ficaro inacessveis. Por outro lado,
esta abordagem muito flexvel, pois no h necessidade de se definir o
tamanho mximo do arquivo durante sua criao, e arquivos podem ser
expandidos ou reduzidos sem maiores dificuldades. Alm disso, qualquer
bloco livre do disco pode ser usados por qualquer arquivo, eliminando a
fragmentao externa.
Os principais problemas da alocao encadeada so o baixo desempenho
nos acessos diretos e a relativa fragilidade em relao a erros nos blocos do
disco. Ambos os problemas provm do fato de que os ponteiros dos blocos
so armazenados nos prprios blocos, junto dos dados do arquivo. Para
resolver esse problema, os ponteiros podem ser retirados dos blocos de dados
e armazenados em uma tabela separada. Essa tabela denominada Tabela de
Alocao de Arquivos (FAT - File Allocation Table), sendo a base dos sistemas
de arquivos FAT12, FAT16 e FAT32 usados nos sistemas operacionais MSDOS, Windows e em muitos dispositivos de armazenamento portteis, como
pen-drives, reprodutores MP3 e cmeras fotogrficas digitais.
Na abordagem da FAT, os ponteiros dos blocos de cada arquivo so
mantidos em uma tabela nica, armazenada em blocos reservados no incio
da partio. Cada entrada dessa tabela corresponde a um bloco lgico do
disco e contm um ponteiro indicando o prximo bloco do mesmo arquivo.
As entradas da tabela tambm podem conter valores especiais para indicar
o ltimo bloco de cada arquivo, blocos livres, blocos defeituosos e blocos
reservados. Uma cpia dessa tabela mantida em cache na memria durante
o uso do sistema, para melhorar o desempenho na localizao dos blocos
dos arquivos. A Figura 6.16 apresenta o contedo da tabela de alocao de
arquivos para o exemplo apresentado anteriormente na Figura 6.15.
Alocao indexada
Nesta abordagem, a estrutura em lista encadeada da estratgia anterior
substituda por um vetor contendo um ndice de blocos do arquivo. Cada
entrada desse ndice corresponde a um bloco do arquivo e aponta para
a posio desse bloco no disco. O ndice de blocos de cada arquivo
mantido no disco em uma estrutura denominada n de ndice (index node)
ou simplesmente n-i (i-node). O i-node de cada arquivo contm, alm de
c Carlos Maziero
245

Tabela de alocao
de arquivos
00
01
bytes blocos incio
02
foto1.jpg
10417
03
relat.pdf
28211
13
04
02
05
6214
20
06
19116
24
07
04
08
Tabela de diretrio
nome
instruc.txt
sinfonia.mp3
bloco em uso
bloco livre
Entradas da tabela de alocao
17 : nmero do prximo bloco

L : ltimo bloco do arquivo (Last)
F : bloco livre (Free)
R : bloco reservado (Reserved)
B : bloco defeituoso (Bad)
09
10
12
11
12
13
16
14
15
16
17
17
19
18
19
22
20
21
21
22
10
23
24
26
25
26
27
27
28
28
29
Figura 6.16: Uma tabela de alocao de arquivos.

seu ndice de blocos, os principais atributos do mesmo, como tamanho,
permisses, datas de acesso, etc. Os i-nodes de todos os arquivos so
agrupados em uma tabela de i-nodes, mantida em uma rea reservada do
disco, separada dos blocos de dados dos arquivos. A Figura 6.17 apresenta
um exemplo de alocao indexada.
Como os i-nodes tambm tm tamanho fixo, o nmero de entradas no
ndice de blocos de um arquivo limitado. Por isso, esta estratgia de
alocao impe um tamanho mximo para os arquivos. Por exemplo, se o
sistema usar blocos de 4 Kbytes e o ndice de blocos suportar 64 entradas,
s podero ser armazenados arquivos com at 256 Kbytes. Alm disso,
a tabela de i-nodes tambm tem um tamanho fixo, determinado durante
c Carlos Maziero
246

Tabela de i-nodes
Tabela de diretrio
nome
i-node
foto1.jpg
relat.pdf
instruc.txt
10
sinfonia.mp3
31
10417
...
i-node 5

meta-dados
13
16
17
bloco em uso
bloco livre
19
ponteiros
de dados
22
10
12
null
null
null
Figura 6.17: Estratgia de alocao indexada simples.

a formatao do sistema de arquivos, o que limita o nmero mximo de
arquivos ou diretrios que podem ser criados na partio.
Para aumentar o tamanho mximo dos arquivos armazenados, algumas
das entradas do ndice de blocos podem ser transformadas em ponteiros
indiretos. Essas entradas apontam para blocos do disco que contm outros
ponteiros, criando assim uma estrutura em rvore. Considerando um
sistema com blocos lgicos de 4K bytes e ponteiros de 32 bits (4 bytes),
cada bloco lgico pode conter 1024 ponteiros, o que aumenta muito a
capacidade do ndice de blocos. Alm de ponteiros indiretos, podem ser
usados ponteiros dupla e triplamente indiretos. Por exemplo, os sistemas
de arquivos Ext2/Ext3 do Linux (apresentado na Figura 6.18) usam i-nodes
com 12 ponteiros diretos (que apontam para blocos de dados), um ponteiro
c Carlos Maziero
247
indireto, um ponteiro duplamente indireto e um ponteiro triplamente

indireto. Considerando blocos lgicos de 4K bytes e ponteiros de 4 bytes,
cada bloco de ponteiros contm 1024 ponteiros. Dessa forma, o clculo do
tamanho mximo de um arquivo nesse sistema simples:
max =
+
+
+
=
max
4096 12
4096 1024
4096 1024 1024
4096 1024 1024 1024
4.402.345.721.856 bytes
4T bytes
(ponteiros diretos)
(ponteiro indireto)
(ponteiro indireto duplo)
(ponteiro indireto triplo)
c Carlos Maziero
248
i-node
12
meta-dados
do arquivo
13
blocos de dados
0
1
1035
2
12 ponteiros
diretos
1036
1037
10
2059
11
ponteiro 1-indireto
ponteiro 2-indireto
ponteiro 3-indireto
blocos com
1024 ponteiros
de 4 bytes
Figura 6.18: Estratgia de alocao indexada multi-nvel.

Apesar dessa estrutura aparentemente complexa, a localizao e acesso
de um bloco do arquivo no disco permanece relativamente simples, pois a
estrutura homognea de ponteiros permite calcular a localizao dos blocos
com exatido. A localizao do bloco lgico de disco correspondente ao
i-simo bloco lgico de um arquivo segue o algoritmo 3.
Em relao ao desempenho, pode-se afirmar que esta estratgia bastante
rpida, tanto para acessos sequenciais quanto para acessos diretos a blocos,
devido aos ndices de ponteiros dos blocos presentes nos i-nodes. Contudo,
c Carlos Maziero
249

1. B: tamanho dos blocos lgicos, em bytes
2. bi : nmero do bloco do disco onde se encontra o byte i
3. oi : posio do byte i dentro do bloco bi (offset)
4. ptr[0...14]: vetor de ponteiros do i-node
5. block[0...1023]: bloco de ponteiros para outros blocos
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
oi = i mod B
baux = i B
if baux < 12 then // ponteiros diretos
// o endereo do bloco bi o prprio valor do ponteiro
bi = ptr[baux ]
else
baux = baux 12
if baux < 1024 then // ponteiro indireto simples
// ler bloco de ponteiros de nvel 1
block1 = read_block (ptr[12])
// encontrar o endereo do bloco bi
bi = block1 [baux ]
else
baux = baux 1024
if baux < 1024 1024 then // ponteiro indireto duplo
block2 = read_block (block1 [baux 1024])
bi = block2 [baux mod 1024]
else // ponteiro indireto triplo
baux = baux (1024 1024)
block2 = read_block (block1 [baux (1024 1024)])
block3 = read_block (block2 [(baux 1024) mod 1024])
bi = block3 [baux mod 1024]
c Carlos Maziero
250
no caso de blocos no final de arquivos muito grandes, podem ser necessrios

trs ou quatro acessos a disco adicionais para localizar o bloco desejado,
devido aos ponteiros indiretos. Defeitos em blocos de dados no afetam
os demais blocos de dados, o que torna esta estratgia robusta. Todavia,
defeitos nos meta-dados (o i-node ou os blocos de ponteiros) podem danificar
grandes extenses do arquivo; por isso, muitos sistemas que usam esta
estratgia implementam tcnicas de redundncia de i-nodes e meta-dados
para melhorar a robustez. Em relao flexibilidade, pode-se afirmar que
esta forma de alocao to flexvel quanto a alocao encadeada, no
apresentando fragmentao externa e permitindo o uso de todas as reas
do disco para armazenar dados. Todavia, o tamanho mximo dos arquivos
criados limitado, bem como o nmero mximo de arquivos na partio.
Uma caracterstica interessante da alocao indexada a possibilidade
de criar arquivos esparsos. Um arquivo esparso contm reas mapeadas no
disco (contendo dados) e reas no-mapeadas (sem dados). Somente as
reas mapeadas esto fisicamente alocadas no disco rgido, pois os ponteiros
correspondentes a essas reas no i-node apontam para blocos do disco
contendo dados do arquivo. Os ponteiros relativos s reas no-mapeadas
tm valor nulo, servindo apenas para indicar que aquela rea do arquivo
ainda no est mapeada no disco (conforme indicado na Figura 6.19). Caso
um processo leia uma rea no-mapeada, receber somente zeros. As reas
no-mapeadas sero alocadas em disco somente quando algum processo
escrever nelas. Arquivos esparsos so muito usados por gerenciadores de
bancos de dados e outras aplicaes que precisem manter arquivos com
ndices ou tabelas hash que possam conter grandes intervalos sem uso.
meta-dados
viso lgica do arquivo
i-node
disco
blocos de disco
efetivamente alocados
Figura 6.19: Alocao de um arquivo esparso.
c Carlos Maziero
251
Anlise comparativa
A Tabela 6.3 traz um comparativo entre as principais formas de alocao
estudadas aqui, sob a tica de suas caractersticas de rapidez, robustez e
flexibilidade de uso.
Estratgia
Contgua
Rapidez
Robustez
Alta, pois acessos se- Alta, pois blocos defeiquencial e direto r- tuosos no impedem o
pidos, pois os blocos acesso aos demais blodo arquivo esto pr- cos do arquivo.
ximos no disco.
Encadeada
Acesso sequencial rpido, se os blocos estiverem prximos; o

acesso direto lento,
pois necessrio ler todos os blocos a partir
do incio do arquivo at
encontrar o bloco desejado.
Alta, pois acessos se- Mais robusta que a Alta, pois arquivos poquencial e direto so r- alocao encadeada, dem ser criados em
pidos, se os blocos do desde que no ocor- qualquer local do disco,
arquivo estiverem pr- ram erros na tabela de sem risco de fragmenximos no disco.
alocao.
tao externa.
Alta, pois os acessos se- Alta, desde que no Alta, pois arquivos poquencial e direto so r- ocorram erros no i-node dem ser criados em
pidos, se os blocos do nem nos blocos de pon- qualquer local do disco,
arquivo estiverem pr- teiros.
sem risco de fragmenximos no disco.
tao externa. No entanto, o tamanho mximo dos arquivos limitado pelo nmero de
ponteiros definidos nos
i-nodes.
FAT
Indexada
Flexibilidade
Baixa, pois o tamanho
mximo dos arquivos
deve ser conhecido a
priori; nem sempre
possvel aumentar o tamanho de um arquivo
existente.
Baixa, pois um bloco Alta, pois arquivos podefeituoso leva perda dem ser criados em
dos dados daquele qualquer local do disco,
bloco e de todos os blo- sem risco de fragmencos subsequentes, at o tao externa.
fim do arquivo.
Tabela 6.3: Quadro comparativo das estratgias de alocao de arquivos
c Carlos Maziero
252
6: O sistema de arquivos virtual
Gerncia de espao livre

Alm de manter informaes sobre que blocos so usados por cada
arquivo no disco, a camada de alocao de arquivos deve manter um
registro atualizado de quais blocos esto livres, ou seja no esto ocupados
por nenhum arquivo ou meta-dado. Duas tcnicas de gerncia de blocos
livres so frequentemente utilizadas: o mapa de bits e a lista de blocos livres
[Silberschatz et al., 2001, Tanenbaum, 2003].
Na abordagem de mapa de bits, um pequeno conjunto de blocos no
incio da partio reservado para manter um mapa de bits. Cada bit nesse
mapa de bits representa um bloco lgico da partio, que pode estar livre (o
bit vale 1) ou ocupado (o bit vale 0). Essa abordagem como vantagem ser
bastante compacta e simples de implementar: em um disco de 80 GBytes
com blocos lgicos de 4.096 bytes, seriam necessrios 20.971.520 bits no
mapa de bits, o que representa 2.621.440 bytes ou 640 blocos (ou seja, 0,003%
do total de blocos lgicos do disco).
A abordagem de lista de blocos livres pode ser implementada de vrias
formas. Na forma mais simples, cada bloco livre contm um ponteiro para
o prximo bloco livre do disco, de forma similar alocao encadeada de
arquivos vista na Seo 6.4.3. Apesar de simples, essa abordagem pouco
eficiente, por exigir um acesso a disco para cada bloco livre requisitado.
A abordagem FAT (Seo 6.4.3) uma melhoria desta tcnica, na qual os
blocos livres so indicados por flags especficos na tabela de alocao de
arquivos. Outra melhoria simples consiste em armazenar em cada bloco
livre um vetor de ponteiros para outros blocos livres; o ltimo ponteiro
desse vetor apontaria para um novo bloco livre contendo mais um vetor
de ponteiros, e assim sucessivamente. Essa abordagem permite obter um
grande nmero de blocos livre a cada acesso a disco. Outra melhoria similar
consiste em armazenar uma tabela de extenses de blocos livres, ou seja, a
localizao e o tamanho de um conjunto de blocos livres consecutivos no
disco, de forma similar alocao contgua (Seo 6.4.3).
6.4.4
O sistema de arquivos virtual
O sistema de arquivos virtual gerencia os aspectos do sistema de arquivos

mais prximos do usurio, como a verificao de permisses de acesso, o
controle de concorrncia (atribuio e liberao travas) e a manuteno de
informaes sobre os arquivos abertos pelos processos.
c Carlos Maziero
253
6: O sistema de arquivos virtual
Conforme apresentado na Seo 6.2.1, quando um processo abre um

arquivo, ele recebe do ncleo uma referncia ao arquivo aberto, a ser usada
nas operaes subsequentes envolvendo aquele arquivo. Em sistemas UNIX,
as referncias a arquivos abertos so denominadas descritores de arquivos, e
correspondem a ndices de entradas em uma tabela de arquivos abertos pelo
processo (process file table), mantida pelo ncleo. Cada entrada dessa tabela
contm informaes relativas ao uso do arquivo por aquele processo, como
o ponteiro de posio corrente e o modo de acesso ao arquivo solicitado
pelo processo (leitura, escrita, etc.).
Adicionalmente, cada entrada da tabela de arquivos do processo contm
uma referncia para uma entrada correspondente na tabela global de
arquivos abertos (system file table) do sistema. Nessa tabela global, cada
entrada contm um contador de processos que mantm aquele arquivo
aberto, uma trava para controle de compartilhamento e uma referncia s
estruturas de dados que representam o arquivo no sistema de arquivos
onde ele se encontra, alm de outras informaes [Bach, 1986, Vahalia, 1996,
Love, 2004].
A Figura 6.20 apresenta a organizao geral das estruturas de controle
de arquivos abertos presentes no sistema de arquivos virtual de um ncleo
UNIX tpico. Essa estrutura similar em outros sistemas, mas pode ser
simplificada em sistemas mais antigos e simples, como no caso do DOS.
Deve-se observar que toda essa estrutura independente do dispositivo
fsico onde os dados esto armazenados e da estratgia de alocao de
arquivos utilizada; por essa razo, esta camada denominada sistema de
arquivos virtual. Essa transparncia permite que os processos acessem de
maneira uniforme, usando a mesma interface, arquivos em qualquer meio
de armazenamento e armazenados sob qualquer estratgia de alocao.
c Carlos Maziero
254
6: Tpicos avanados
referncias de arquivos abertos
P1
P2
P3
nvel usurio
ncleo
tabelas locais de
arquivos abertos
tabela global de
arquivos abertos
sistemas
de arquivos
especcos
Sistema de
Arquivos Virtual
alocao
de arquivos
alocao
de arquivos
driver
driver
dispositivo
dispositivo
Figura 6.20: Estruturas de controle de arquivos abertos em um ncleo UNIX.
6.5
Tpicos avanados
Journaling FS
Extents
Log-structured Fyle Systems
Captulo 7
Gerncia de entrada/sada
Este contedo est em elaborao. Ainda h muito o que escrever aqui...
7.1
Introduo
Um computador constitudo basicamente de um ou mais processadores,

memria RAM e dispositivos de entrada e sada, tambm chamados de
perifricos. Os dispositivos de entrada/sada permitem a interao do
computador com o mundo exterior de vrias formas, como por exemplo:
interao com os usurios atravs de mouse, teclado, tela grfica, tela
de toque e joystick;
escrita e leitura de dados em discos rgidos, SSDs, CD-ROMs, DVDROMs e pen-drives;
impresso de informaes atravs de impressoras e plotadoras;
captura e reproduo de udio e vdeo, como cmeras, microfones e
alto-falantes;
comunicao com outros computadores, atravs de redes LAN, WLAN,
Bluetooth e de telefonia celular.
Esses exemplos so tpicos de computadores pessoais e de computadores
menores, como os smartphones. J em ambientes industriais, comum
encontrar dispositivos de entrada/sada especficos para a monitorao e
c Carlos Maziero
256
7: Introduo
controle de mquinas e processos de produo, como tornos de comando

numrico, braos robotizados e processos qumicos. Por sua vez, o computador embarcado em um carro conta com dispositivos de entrada para coletar
dados do combustvel e do funcionamento do motor e dispositivos de sada
para controlar a injeo eletrnica e a trao dos pneus, por exemplo. bastante bvio que um computador no tem muita utilidade sem dispositivos
perifricos, pois o objetivo bsico da imensa maioria dos computadores
receber dados, process-los e devolver resultados aos seus usurios, sejam
eles seres humanos, outros computadores ou processos fsicos/qumicos
externos.
Figura 7.1: Dispositivos de entrada/sada.

Os primeiros sistemas de computao, construdos nos anos 1940, eram
destinados a clculos matemticos e por isso possuam dispositivos de
entrada/sada rudimentares, que apenas permitiam carregar/descarregar
programas e dados diretamente na memria principal. Em seguida surgiram
os terminais compostos de teclado e monitor de texto, para facilitar a leitura
e escrita de dados, e os discos rgidos, como meio de armazenamento
persistente de dados e programas. Hoje, dispositivos de entrada/sada dos
mais diversos tipos podem estar conectados a um computador. A grande
diversidade de dispositivos perifricos um dos maiores desafios presentes
c Carlos Maziero
257
7: Dispositivos de entrada/sada
na construo e manuteno de um sistema operacional, pois cada um deles

tem especificidades e exige mecanismos de acesso especficos.
Este captulo apresenta uma viso geral da operao dos dispositivos
de entrada/sada sob a tica do sistema operacional. Inicialmente sero
discutidas as principais caractersticas dos dispositivos de entrada/sada
usualmente presentes nos computadores convencionais para a interao
com o usurio, armazenamento de dados e comunicao via rede. A seguir, a arquitetura de hardware e software responsvel pela operao dos
dispositivos de entrada/sada ser detalhada. Na sequncia, as principais
estratgias de interao entre o software e o hardware sero apresentadas.
Os drivers, componentes de software responsveis pela interao do sistema operacional com o hardware de entrada/sada, tero sua estrutura
e princpio de funcionamento abordados em seguida. Por fim, alguns
sub-sistemas de entrada/sada especficos, considerados os mais relevantes
nos computadores de uso geral atualmente em uso, sero estudados com
maior profundidade.
7.2
Dispositivos de entrada/sada
Um dispositivo de entrada/sada realiza a interao entre os sistemas

internos de um computador (processadores e memria) e o mundo exterior.
7.2.1
Componentes de um dispositivo
Conceitualmente, a entrada de dados em um computador inicia com um

sensor capaz de converter uma informao externa (fsica ou qumica) em
um sinal eltrico analgico. Como exemplos de sensores temos o microfone,
as chaves internas das teclas de um teclado ou o foto-diodo de um leitor de
DVDs. O sinal eltrico analgico fornecido pelo sensor ento aplicado a
um conversor analgico-digital (CAD), que o transforma em informao
digital (sequncias de bits). Essa informao digital armazenada em um
buffer que pode ser acessado pelo processador atravs de um controlador
de entrada.
Uma sada de dados inicia com o envio de dados do processador a
um controlador de sada, atravs do barramento. Os dados enviados pelo
processador so armazenados em um buffer interno do controlador e a
c Carlos Maziero
258
7: Barramentos
seguir convertidos em um sinal eltrico analgico, atravs de um conversor

digital-analgico (CDA). Esse sinal ser aplicado a um atuador1 que ir
convert-lo em efeitos fsicos perceptveis ao usurio. Exemplos simples de
atuadores so a cabea de impresso e os motores de uma impressora, um
alto-falante, uma tela grfica, etc.
Vrios dispositivos combinam funcionalidades tanto de entrada quanto
de sada, como os discos rgidos: o processador pode ler dados gravados no
disco rgido (entrada), mas para isso precisa ativar o motor que faz girar o
disco e posicionar adequadamente a cabea de leitura (sada). O mesmo
ocorre com uma placa de udio de um PC convencional, que pode tanto
capturar quanto reproduzir sons. A Figura 7.2 mostra a estrutura bsica de
captura e reproduo de udio em um computador pessoal, que um bom
exemplo de dispositivo de entrada/sada.
Como existem muitas possibilidades de interao do computador com o
mundo exterior, tambm existem muitos tipos de dispositivos de entrada/sada, com caractersticas diversas de velocidade de transferncia, forma
de transferncia dos dados e mtodo de acesso. A velocidade de transferncia de dados de um dispositivo pode ir de alguns bytes por segundo,
no caso de dispositivos simples como teclados e mouses, a gigabytes por
segundo, para algumas placas de interface grfica ou de acesso a discos de
alto desempenho. A Tabela 7.1 traz alguns exemplos de dispositivos de
entrada/sada com suas velocidades tpicas de transferncia de dados.
7.2.2
Barramentos
Historicamente, o acoplamento dos dispositivos de entrada/sada ao

computador feito atravs de barramentos, seguindo o padro estabelecido
pela arquitetura de Von Neumann. Enquanto o barramento dos primeiros
sistemas era um simples agrupamento de fios, os barramentos dos sistemas
atuais so estruturas de hardware bastante complexas, com circuitos especficos para seu controle. Alm disso, a diversidade de velocidades e volumes
de dados suportados pelos dispositivos fez com que o barramento nico dos
primeiros sistemas fosse gradativamente estruturado em um conjunto de
barramentos com caractersticas distintas de velocidade e largura de dados.
1
Sensores e atuadores so denominados genericamente dispositivos transdutores, pois

transformam energia externa (como luz, calor, som ou movimento) em sinais eltricos, ou
vice-versa.
c Carlos Maziero
259
7: Barramentos
CPU
dados
controlador de barramento
01001010
11011001
01101010
dados
buer
01001010
11011001
01101010
buer
sinal
digital
conversor
digitalanalgico
conversor
analgicodigital
sinal
analgico
sensor
amplicador
atuador
amplicador
Figura 7.2: Estrutura bsica da entrada e sada de udio.

O controle dos barramentos em um sistema destktop moderno est a cargo
de dois controladores de hardware que fazem parte do chipset2 da placa-me:
a north bridge e a south bridge. A north bridge, diretamente conectada ao
processador, responsvel pelo acesso memria RAM e aos dispositivos de
alta velocidade, atravs de barramentos dedicados como AGP (Accelerated
Graphics Port) e PCI-Express (Peripheral Component Interconnect).
Por outro lado, a south bridge o controlador responsvel pelos barramentos e portas de baixa ou mdia velocidade do computador, como
as portas seriais e paralelas, e pelos barramentos dedicados como o PCI
2
O chipset de um computador um conjunto de controladores e circuitos auxiliares de

hardware integrados placa-me, que provem servios fundamentais ao funcionamento
do computador, como o controle dos barramentos, acesso BIOS, controle de interrupes,
temporizadores programveis e controladores on-board para alguns perifricos, como discos
rgidos, portas paralelas e seriais e entrada/sada de udio.
c Carlos Maziero
260
7: Interface de acesso
Tabela 7.1: Velocidades tpicas de alguns dispositivos de entrada/sada.

Dispositivo
velocidade
Teclado
10 B/s
Mouse tico
100 B/s
Interface infravermelho (IrDA-SIR)
14 KB/s
Interface paralela padro
125 KB/s
Interface de udio digital S/PDIF
384 KB/s
11.6 MB/s
Interface de rede Fast Ethernet
60 MB/s
Chave ou disco USB 2.0
Interface de rede Gigabit Ethernet
116 MB/s
Disco rgido SATA 2
300 MB/s
4.2 GB/s
Interface grfica high-end
padro, o USB e o SATA. Alm disso, a south bridge costuma integrar outros
componentes importantes do computador, como controladores de udio e
rede on-board, controlador de interrupes, controlador DMA (Direct Memory
Access), relgio de tempo real (responsvel pelas interrupes de tempo
usadas pelo escalonador de processos), controle de energia e o acesso
memria BIOS. O processador se comunica com a south bridge indiretamente,
atravs da north bridge.
A Figura 7.3 traz uma viso da arquitetura tpica de um computador pessoal moderno. A estrutura detalhada e o funcionamento dos barramentos e
seus respectivos controladores esto fora do escopo deste texto; informaes
mais detalhadas podem ser encontradas em [Patterson and Henessy, 2005].
7.2.3
Interface de acesso
Para o sistema operacional, o aspecto mais relevante de um dispositivo

de entrada/sada sua interface de acesso, ou seja, a abordagem a ser usada
para acessar o dispositivo, configur-lo e enviar dados para ele (ou receber
dados dele). Normalmente, cada dispositivo oferece um conjunto de registradores acessveis atravs do barramento, tambm denominados portas de
entrada/sada, que so usados para a comunicao entre o dispositivo e o
processador. As portas oferecidas para acesso a cada dispositivo de entra-
c Carlos Maziero
261
processor
PCI Express bus
North bridge
(memory
controller hub)
AGP port
LPC bus
mouse keyboard serial parallel oppy

standard PC ports
RAM
onboard ethernet
BIOS
Super I/O controller
RAM
South bridge
(I/O controller
hub)
onboard audio
power management
real-time clock
SATA
PCI
USB
standard buses
Figura 7.3: Arquitetura tpica de um PC atual.

da/sada podem ser divididas nos seguintes grupos (conforme ilustrado na
Figura 7.4):
Portas de entrada (data-in ports): usadas pelo processador para receber
dados provindos do dispositivo; so escritas pelo dispositivo e lidas
pelo processador;
Portas de sada (data-out ports): usadas pelo processador para enviar
dados ao dispositivo; essas portas so escritas pelo processador e lidas
pelo dispositivo;
Portas de status (status ports): usadas pelo processador para consultar
o estado interno do dispositivo ou verificar se uma operao solicitada
ocorreu sem erro; essas portas so escritas pelo dispositivo e lidas pelo
processador;
Portas de controle (control ports): usadas pelo processador para enviar
comandos ao dispositivo ou modificar parmetros de sua configurao;
essas portas so escritas pelo processador e lidas pelo dispositivo.
c Carlos Maziero
262
CPU
data-in
data-out
status
control
device controller
s demais partes do hardware do dispositivo
Figura 7.4: Portas de interface de um dispositivo de entrada/sada.

O nmero exato de portas e o significado especfico de cada uma
dependem do tipo de dispositivo considerado. Um exemplo simples de
interface de acesso a dispositivo a interface paralela, geralmente usada
para acessar impressoras. As portas de uma interface paralela operando
no modo padro (SPP - Standard Parallel Port) esto descritas a seguir
[Patterson and Henessy, 2005]:
P0 (data port): porta de sada, usada para enviar bytes impressora;
pode ser usada tambm como porta de entrada, se a interface estiver
operando em modo bidirecional;
P1 (status port): porta de status, permite ao processador consultar
vrios indicadores de status da interface paralela ou do dispositivo
ligado a ela. O significado de cada um de seus 8 bits :
0. reservado;
1. reservado;
2. nIRQ: se 0, indica que o controlador gerou uma interrupo
(Seo 7.2.5);
3. error: h um erro interno na impressora;
4. select: a impressora est pronta (online);
c Carlos Maziero
263
5. paper_out: falta papel na impressora;

6. ack: se 0, indica que um dado foi recebido (gera um pulso em 0
com durao de ao menos 1s);
7. busy: indica que o controlador est ocupado processando um
comando.
P2 (control port): porta de controle, usada para configurar a interface
paralela e para solicitar operaes de sada (ou entrada) de dados
atravs da mesma. Seus 8 bits tm o seguinte significado:
0. strobe: informa a interface que h um dado em P0 (deve ser gerado
um pulso em 0, com durao de ao menos 1s);
1. auto_lf : a impressora deve inserir um line feed a cada carriage
return recebido;
2. reset: a impressora deve ser reiniciada;
3. select: a impressora est selecionada para uso;
4. enable_IRQ: permite ao controlador gerar interrupes (Seo
7.2.5);
5. bidirectional: informa que a interface ser usada para entrada e
para sada de dados;
6. reservado;
7. reservado.
P3 a P7 : estas portas so usadas nos modos estendidos de operao da
interface paralela, como EPP (Enhanced Paralel Port) e ECP (Extended
Capabilities Port).
O algoritmo bsico implementado pelo hardware interno do controlador
da interface paralela para coordenar suas interaes com o processador
est ilustrado no fluxograma da Figura 7.5. Considera-se que os valores
iniciais dos flags de status da porta P1 so nIRQ = 1, error = 0, select = 1,
paper_out = 0, ack = 1 e busy = 0.
c Carlos Maziero
264
aguarda um
novo dado
7: Endereamento
P2.strobe?
informa que
o controlador
est ocupado
P1.busy = 1
l e trata o
dado recebido
l P0
informa que
o dado foi
processado
gera pulso
em P1.ack
gera
interrupo?
P2.nIRQ?
ack
gera IRQ
1
informa que
o controlador
est livre
P1.busy = 0
Figura 7.5: Comportamento bsico do controlador da porta paralela.
7.2.4
Endereamento
A forma de acesso aos registradores que compem a interface de um

dispositivo varia de acordo com a arquitetura do computador. Alguns
sistemas utilizam entrada/sada mapeada em portas (port-mapped I/O), onde
as portas que compem a interface so acessadas pelo processador atravs
de instrues especficas para operaes de entrada/sada. Por exemplo, os
processadores da famlia Intel usam a instruo IN reg port para ler o valor
presente na porta port do dispositivo e deposit-lo no registrador reg do
c Carlos Maziero
265
7: Endereamento
processador, enquanto a instruo OUT port reg usada para escrever na

porta port o valor contido no registrador reg.
Na entrada/sada mapeada em portas, definido um espao de endereos de entrada/sada (I/O address space) separado da memria principal e
normalmente compreendido entre 0 e 64K. Para distinguir entre endereos
de memria e de portas de entrada/sada, o barramento de controle do
processador possui uma linha IO/M, que indica se o endereo presente no
barramento de endereos se refere a uma posio de memria (se IO/M = 0)
ou a uma porta de entrada/sada (se IO/M = 1). A Tabela 7.2 apresenta os
endereos tpicos de algumas portas de entrada/sada de dispositivos em
computadores pessoais que seguem o padro IBM-PC.
Dispositivo
Endereos das portas
teclado e mouse PS/2
0060h e 0064h
0170h a 0177h
01F0h a 01F7h
relgio de tempo real
0070h e 0071h
porta serial COM1
02F8h a 02FFh
porta serial COM2
03F8h a 03FFh
porta paralela LPT1
0378h a 037F
Tabela 7.2: Endereos de portas de E/S de alguns dispositivos.
Uma outra forma de acesso aos dispositivos de entrada/sada, usada frequentemente em interfaces grficas e de rede, a entrada/sada mapeada em
memria (memory-mapped I/O). Nesta abordagem, uma parte no-ocupada
do espao de endereos de memria reservado para mapear as portas de
acesso aos dispositivos. Dessa forma, as portas so vistas como se fossem
parte da memria principal e podem ser lidas e escritas atravs das mesmas
instrues usadas para acessar o restante da memria, sem a necessidade de
instrues especiais como IN e OUT. Algumas arquiteturas de computadores,
como caso do IBM-PC padro, usam uma abordagem hbrida para certos
dispositivos como interfaces de rede e de udio: as portas de controle
e status so mapeadas no espao de endereos de entrada/sada, sendo
acessadas atravs de instrues especficas, enquanto as portas de entrada
e sada de dados so mapeadas em memria (normalmente na faixa de
endereos entre 640 KB e 1MB) [Patterson and Henessy, 2005].
c Carlos Maziero
266
7: Interrupes
Finalmente, uma abordagem mais sofisticada para o controle de dispositivos de entrada/sada o uso de um hardware independente, com
processador dedicado, que comunica com o processador principal atravs
de algum tipo de barramento. Em sistemas de grande porte (mainframes)
essa abordagem denominada canais de entrada/sada (IO channels); em
computadores pessoais, essa abordagem costuma ser usada em interfaces
para vdeo ou udio de alto desempenho, como o caso das placas grficas
com acelerao, nas quais um processador grfico (GPU Graphics Processing Unit) realiza a parte mais pesada do processamento da sada de vdeo,
como a renderizao de imagens em 3 dimenses e texturas, deixando o
processador principal livre para outras tarefas.
7.2.5
Interrupes
O acesso aos controladores de dispositivos atravs de seus registradores

conveniente para a comunicao no sentido processador controlador, ou
seja, para as interaes iniciadas pelo processador. Entretanto, pode ser
problemtica no sentido controlador processador, caso o controlador precise
informar algo ao processador de forma assncrona, sem que o processador
esteja esperando. Nesse caso, o controlador pode utilizar uma requisio
de interrupo (IRQ - Interrupt Request) para notificar o processador sobre
algum evento importante, como a concluso de uma operao solicitada, a
disponibilidade de um novo dado ou a ocorrncia de algum problema no
dispositivo.
As requisies de interrupo so sinais eltricos veiculados atravs do
barramento de controle do computador. Cada interrupo est associada
a um nmero inteiro, geralmente na faixa 031 ou 063, o que permite
identificar o dispositivo que a solicitou. A Tabela 7.3 informa os nmeros
de interrupo associados a alguns dispositivos perifricos tpicos.
Ao receber uma requisio de interrupo, o processador suspende
seu fluxo de instrues corrente e desvia a execuo para um endereo
pr-definido, onde se encontra uma rotina de tratamento de interrupo
(interrupt handler). Essa rotina responsvel por tratar a interrupo, ou seja,
executar as aes necessrias para identificar e atender o dispositivo que
gerou a requisio. Ao final da rotina de tratamento da interrupo, o processador retoma o cdigo que estava executando quando foi interrompido.
A Figura 7.6 representa os principais passos associados ao tratamento de
uma interrupo envolvendo o controlador de teclado, detalhados a seguir:
c Carlos Maziero
267
7: Interrupes
Dispositivo
Interrupo
teclado
1
mouse PS/2
12
14
15
relgio de tempo real
8
porta serial COM1
4
porta serial COM2
3
porta paralela LPT1
7
Tabela 7.3: Interrupes geradas por alguns dispositivos.
1: processamento normal
4: a execuo desviada
rotina de
tratamento de
interrupo
6: retorno ao
fluxo anterior
programa
em
execuo
buer
CPU
3: o controlador gera
uma interrupo
5: dados do controlador
transferidos para a memria
registers
keyboard controller
buer
2: uma tecla pressionada
Figura 7.6: Roteiro tpico de um tratamento de interrupo

1. O processador est executando um programa qualquer;
2. O usurio pressiona uma tecla no teclado;
c Carlos Maziero
268
7: Interrupes
3. O controlador do teclado identifica a tecla pressionada, armazena seu

cdigo em um buffer interno e envia uma solicitao de interrupo
(IRQ) ao processador;
4. O processador recebe a interrupo, salva na pilha seu estado atual
(o contedo de seus registradores) e desvia sua execuo para uma
rotina de tratamento da interrupo;
5. Ao executar, essa rotina acessa os registradores do controlador de
teclado para transferir o contedo de seu buffer para uma rea de
memria do ncleo. Depois disso, ela pode executar outras aes,
como acordar algum processo ou thread que esteja esperando por
entradas do teclado;
6. Ao concluir a execuo da rotina de tratamento da interrupo, o
processador retorna execuo do fluxo de instrues que havia sido
interrompido, usando a informao de estado salva no passo 4.
Essa sequncia de aes ocorre a cada requisio de interrupo recebida
pelo processador. Como cada interrupo corresponde a um evento ocorrido
em um dispositivo perifrico (chegada de um pacote de rede, movimento
do mouse, concluso de operao do disco, etc.), podem ocorrer centenas
ou milhares de interrupes por segundo, dependendo da carga de trabalho
e da configurao do sistema (nmero e natureza dos perifricos). Por
isso, as rotinas de tratamento de interrupo devem realizar suas tarefas
rapidamente, para no prejudicar o funcionamento do restante do sistema.
Como cada tipo de interrupo pode exigir um tipo de tratamento diferente (pois os dispositivos so diferentes), cada requisio de interrupo
deve disparar uma rotina de tratamento especfica. A maioria das arquiteturas atuais define um vetor de endereos de funes denominado Vetor
de Interrupes (IV - Interrupt Vector); cada entrada desse vetor aponta para
a rotina de tratamento da interrupo correspondente. Por exemplo, se
a entrada 5 do vetor contm o valor 3C20h, ento a rotina de tratamento
da IRQ 5 iniciar na posio 3C20h da memria RAM. Dependendo do
hardware, o vetor de interrupes pode residir em uma posio fixa da
memria RAM, definida pelo fabricante do processador, ou ter sua posio
indicada pelo contedo de um registrador da CPU especfico para esse fim.
As interrupes recebidas pelo processador tm como origem eventos
externos a ele, ocorridos nos dispositivos perifricos e reportados por
c Carlos Maziero
269
7: Interrupes
seus controladores. Entretanto, eventos gerados pelo prprio processador

podem ocasionar o desvio da execuo usando o mesmo mecanismo de
interrupo: so as excees. Eventos como instrues ilegais (inexistentes
ou com operandos invlidos), diviso por zero ou outros erros de software
disparam excees internas no processador, que resultam na ativao de
rotinas de tratamento de exceo registradas no vetor de interrupes. A
Tabela 7.4 apresenta algumas excees previstas pelo processador Intel
Pentium (extrada de [Patterson and Henessy, 2005]).
Tabela 7.4: Algumas excees do processador Pentium.
Exceo
0
3
5
6
9
11
12
13
14
16
Descrio
divide error
breakpoint
bound range exception
invalid opcode
coprocessor segment overrun
segment not present
stack fault
general protection
page fault
floating point error
Nas arquiteturas de hardware atuais, as interrupes geradas pelos dispositivos de entrada/sada no so transmitidas diretamente ao processador,
mas a um controlador de interrupes programvel (PIC - Programmable
Interrupt Controller, ou APIC - Advanced Programmable Interrupt Controller), que faz parte do chipset do computador. As linhas de interrupo
dos controladores de perifricos so conectadas aos pinos desse controlador de interrupes, enquanto suas sadas so conectadas s entradas de
interrupo do processador.
O controlador de interrupes recebe as interrupes dos dispositivos e
as encaminha ao processador em sequncia, uma a uma. Ao receber uma
interrupo, o processador deve acessar a interface do PIC para identificar
a origem da interrupo e depois reconhec-la, ou seja, indicar ao PIC
que aquela interrupo foi tratada e pode ser descartada pelo controlador.
c Carlos Maziero
270
7: Interrupes
Interrupes j ocorridas mas ainda no reconhecidas pelo processador so

chamadas de interrupes pendentes.
O PIC pode ser programado para bloquear ou ignorar algumas das
interrupes recebidas, impedindo que cheguem ao processador. Alm disso,
ele permite definir prioridades entre as interrupes. A Figura 7.7 mostra a
operao bsica de um controlador de interrupes; essa representao
simplificada, pois as arquiteturas de computadores mais recentes podem
contar com vrios controladores de interrupes interligados.
CPU
IRQ
registers
registers
interrupt
controller
IRQ
disk
controller
control
status
data
registers
IRQ
...
network
controller
registers
IRQ
USB
controller
registers
IRQ
touchscreen
controller
Figura 7.7: Uso de um controlador de interrupes.

O mecanismo de interrupo torna eficiente a interao do processador
com os dispositivos perifricos. Se no existissem interrupes, o processador perderia muito tempo consultando todos os dispositivos do sistema
para verificar se h eventos a serem tratados. Alm disso, as interrupes
permitem construir funes de entrada/sada assncronas: o processador no
precisa esperar a concluso de cada operao solicitada, pois o dispositivo
emitir uma interrupo para avisar o processador quando a operao
for concluda.
c Carlos Maziero
271
7.3
7: Software de entrada/sada
Software de entrada/sada
O sistema operacional responsvel por oferecer acesso aos dispositivos

de entrada/sada s aplicaes e, em ltima instncia, aos usurios do
sistema. Prover acesso eficiente, rpido e confivel a um conjunto de
perifricos com caractersticas diversas de comportamento, velocidade
de transferncia, volume de dados produzidos/consumidos e diferentes
interfaces de hardware um imenso desafio. Alm disso, como cada
dispositivo define sua prpria interface e modo de operao, o ncleo do
sistema operacional deve implementar cdigo de baixo nvel para interagir
com milhares de tipos de dispositivos distintos. Como exemplo, cerca de
60% das 12 milhes de linhas de cdigo do ncleo Linux 2.6.31 pertencem a
cdigo de drivers de dispositivos de entrada/sada.
Para simplificar o acesso e a gerncia dos dispositivos de entrada/sada,
o cdigo do sistema operacional estruturado em camadas, que levam das
portas de entrada/sada, interrupes de operaes de DMA a interfaces
de acesso abstratas, como arquivos e sockets de rede. Uma viso conceitual
dessa estrutura em camadas pode ser vista na Figura 7.8. Nessa figura, a
camada inferior corresponde aos dispositivos perifricos propriamente ditos,
como discos rgidos, teclados, etc. A camada logo acima, implementada
em hardware, corresponde ao controlador especfico de cada dispositivo
(controlador IDE, SCSI, SATA, etc.) e aos controladores de DMA e de
interrupes, pertencentes ao chipset do computador.
A primeira camada de software corresponde s rotinas de tratamento de
interrupes (interrupt handles)e aos drivers de entrada/sada. As rotinas de
tratamento de interrupo so acionadas pelo mecanismo de interrupo
do processador a cada interrupo provinda do controlador de interrupes
e servem basicamente para registrar sua ocorrncia. A execuo dessas
rotinas deve ser muito breve, pois durante o tratamento de uma interrupo
o processador desabilita a ocorrncia de novas interrupes, conforme
discutido na Seo 7.2.5. Assim, quando uma rotina acionada, ela apenas
reconhece a interrupo ocorrida junto ao controlador, cria um descritor
de evento (event handler) contendo os dados da interrupo, o insere em
uma fila de eventos pendentes mantida pelo driver do dispositivo, notifica o
driver e conclui.
Os eventos da fila de eventos pendentes mantida por cada driver so
tratados posterior, quando o processador estiver livre. A separao do
tratamento de interrupes em dois nveis de urgncia levar a estruturar o
c Carlos Maziero
272
7: Classes de dispositivos
processos de aplicao
nvel de usurio
data
control
nvel de ncleo
Input/output API
data
control
device-independent I/O functions

data
control
IRQ
interrupt
handler
device driver
software
hardware
control
IRQ
interrupt
controller
data/control
IRQ
device
controller
DMA
controller
IRQ
data/control
I/O device
Figura 7.8: Estrutura em camadas do software de entrada/sada.

cdigo de tratamento de cada interrupo tambm em dois nveis: o bottomhalf, que compreende as aes imediatas a executar quando a interrupo
ocorre, e o o top-half, que compreende o restante das aes de tratamento
da interrupo.
7.3.1
Classes de dispositivos
Para simplificar a construo de aplicaes (e do prprio sistema operacional), os dispositivos de entrada/sada so agrupados em classes ...
Os dispositivos orientados a blocos so aqueles em que as operaes
de entrada ou sada de dados so feitas usando blocos de bytes e nunca
bytes isolados. Discos rgidos, fitas magnticas e outros dispositivos de
armazenamento so exemplos tpicos desta categoria.
c Carlos Maziero
273
7: Classes de dispositivos
Os dispositivos orientados a caracteres so aqueles cujas transferncias

de dados so sempre feitas byte por byte, ou usando blocos de bytes de
tamanho varivel, cujo tamanho mnimo seja um byte. Dispositivos ligados
s interfaces paralelas e seriais do computador, como mouse e teclado, so
os exemplos mais clssicos deste tipo de dispositivo. Os terminais de
texto e modems de transmisso de dados por linhas seriais (como as linhas
telefnicas) tambm so vistos como dispositivos orientados a caracteres.
As interfaces de rede so colocadas em uma classe particular, pois so
vistos como dispositivos orientados a blocos (os pacotes de rede so blocos),
esses blocos so endereveis (os endereos dos destinos dos pacotes), mas
a sada feita de forma sequencial, bloco aps bloco, e normalmente no
possvel resgatar ou apagar um bloco enviado ao dispositivo.
sentido dos fluxos:
granularidade
exemplos:
acesso
exemplos:
persistncia:
exemplos:
entrada
sada
caractere: os dados so envia- bloco: os dados so enviados/dos ou recebidos byte por byte recebidos em blocos de tamanho fixo
terminais, portas paralelas e discos rgidos, interfaces de
seriais, mouses, teclados
rede (pacotes), fitas magnticas
sequencial: os dados so envi- direto: a cada dado enviado
ados ou recebidos em sequn- ou recebido associado um
cia, um aps o outro
endereo (respectivamente de
destino ou de origem)
porta paralela/serial, mouse, disco rgido, interface de rede
teclado, fita magntica
persistente, se o dado envi- voltil, se o dado enviado
ado pode ser resgatado dire- consumido pelo dispositivo,
tamente (ou, em outras pala- ou se o dado recebido do disvras, se os dados lidos do dispositivo foi produzido por
positivo foram anteriormente ele e no anteriormente depoescritos nele por aquele com- sitado nele.
putador ou algum outro)
fita magntica, disco rgido
interface de rede, porta serial/paralela
granularidade da informao: byte, bloco, stream

tipos de dispositivos: a blocos, a caracteres, de rede, blocos sequenciais?
(fita, rede)
c Carlos Maziero
274
7: Estratgias de interao
tipos de interface: bloqueante, no bloqueante, assncrona

arquitetura de E/S do kernel
estrutura de E/S do kernel: de devices genricos a drivers especficos
interfaces, drivers, irq handlers, controllers
Drivers
arquitetura geral
a estrutura de um driver
fluxograma de execuo
top e bottom half
rotinas oferecidas aos processos
acesso via /dev
acesso ao hardware
integrao ao kernel (recompilao ou mdulos dinmicos)
7.3.2
Estratgias de interao
O sistema operacional deve interagir com cada dispositivo de entrada/sada para realizar as operaes desejadas, atravs das portas de seu
controlador. Esta seo aborda as trs estratgias de interao mais frequentemente usadas pelo sistema operacional, que so a entrada/sada
controlada por programa, a controlada por eventos e o acesso direto
memria, detalhados a seguir.
Interao controlada por programa
A estratgia de entrada/sada mais simples, usada com alguns tipos
de dispositivos, a interao controlada por programa, tambm chamada
varredura ou polling. Nesta abordagem, o sistema operacional solicita
uma operao ao controlador do dispositivo, usando as portas control e
data-out (ou data-in) de sua interface, e aguarda a concluso da operao
solicitada, monitorando continuamente os bits da respectiva porta de status.
c Carlos Maziero
275
Considerando as portas da interface paralela descrita na Seo 7.2.3, o

comportamento do processador em uma operao de sada na porta paralela
usando essa abordagem seria descrito pelo seguinte pseudo-cdigo, no qual
as leituras e escritas nas portas so representadas respectivamente pelas
funes in(port) e out(port,value)3 :
// portas da
#define P0
#define P1
#define P2
1
2
3
4
interface paralela LPT1 (endereo inicial em 0378h)

0x0378
# porta de dados
0x0379
# porta de status
0x037A
# porta de controle
// mscaras para alguns bits de controle e status

#define BUSY 0x80
# 1000 0000 (bit 7)
#define ACK 0x40
# 0100 0000 (bit 6)
#define STROBE 0x01
# 0000 0001 (bit 0)
6
7
8
9
10
// buffer de bytes a enviar

unsigned char buffer[BUFSIZE] ;
11
12
13
polling_output ()
{
for (i = 0 ; i < BUFSIZE ; i++)
{
// espera o controlador ficar livre (bit BUSY deve ser zero).
while (in (P1) & BUSY) ;
14
15
16
17
18
19
20
// escreve o byte a enviar na porta P0.

out (P0, buffer[i]) ;
21
22
23
// gera pulso de 1
// para indicar ao
out (P2, in (P2) |
usleep (1) ;
out (P2, in (P2) &
24
25
26
27
28
microssegundo no bit STROBE de P2,

controlador que h um novo dado.
STROBE) ;
! STROBE) ;
29
// espera o byte terminar de ser tratado (pulso "zero" em ACK).

while (in (P1) & ACK) ;
30
31
32
33
Como o bit BUSY da porta P1 deve retornar ao valor zero (0) aps o pulso no bit ACK, o
pseudo-cdigo poderia ser simplificado, eliminando o lao de espera sobre ACK; contudo,
esse lao foi mantido para maior clareza didtica.
c Carlos Maziero
276
Em conjunto, processador e controlador executam aes coordenadas e

complementares: o processador espera que o controlador esteja livre antes de
enviar um novo dado; por sua vez, o controlador espera que o processador
lhe envie um novo dado para processar. Essa interao ilustrada na Figura
7.9. O controlador pode ficar esperando por novos dados, pois s precisa
trabalhar quando h dados a processar, ou seja, quando o bit strobe de sua
porta P2 indicar que h um novo dado em sua porta P0 . Entretanto, manter
o processador esperando at que a operao seja concluda indesejvel,
sobretudo se a operao solicitada for demorada. Alm de constituir uma
situao clssica de desperdcio de recursos por espera ocupada, manter
o processador esperando pela resposta do controlador pode prejudicar o
andamento de outras atividades importantes do sistema, como a interao
com o usurio.
processador
espera
controlador
ficar livre
controlador
wait (!busy)
busy=0
wait (!strobe)
prepara e
envia byte
interface
data=byte
espera
novo byte
strobe=0
busy=1
espera
byte ser
recebido
wait (!ack)
recebe e
processa
novo byte
ack=0
busy=0
Figura 7.9: Entrada/sada controlada por programa.

O problema da espera ocupada torna a estratgia de entrada/sada por
programa pouco eficiente, sobretudo se o tempo de resposta do dispositivo
for longo, sendo por isso pouco usada em sistemas operacionais de propsito
geral. Seu uso se concentra sobretudo em sistemas embarcados dedicados,
nos quais o processador s tem uma atividade (ou poucas) a realizar. A
estratgia bsica de varredura pode ser modificada, substituindo o teste
contnuo do status do dispositivo por um teste peridico (por exemplo, a
c Carlos Maziero
277
cada 10ms), e permitindo ao processador executar outras tarefas enquanto

o dispositivo estiver ocupado. Todavia, essa abordagem implica em uma
menor taxa de transferncia de dados para o dispositivo e, por essa razo,
s usada em dispositivos com baixa vazo de dados.
Interao controlada por eventos
Uma forma mais eficiente de interagir com dispositivos de entrada/sada
consiste em efetuar a requisio da operao desejada e suspender o fluxo
de execuo corrente, desviando o processador para tratar outro processo ou
thread. Quando o dispositivo tiver terminado de processar a requisio, seu
controlador ir gerar uma interrupo (IRQ) para notificar o processador,
que poder ento retomar a execuo daquele fluxo quando for conveniente.
Essa estratgia de ao denominada interao controlada por eventos ou
por interrupes, pois as interrupes tm um papel fundamental em sua
implementao.
Na estratgia de entrada/sada por eventos, uma operao de entrada
ou sada dividida em dois blocos de instrues: um bloco que inicia
a operao, ativado pelo sistema operacional a pedido de um processo
ou thread, e uma rotina de tratamento de interrupo (interrupt handler),
ativado a cada interrupo, para prosseguir a transferncia de dados ou
para informar sobre sua concluso. Considerando novamente a sada de
um buffer de N bytes em uma interface paralela (descrita na Seo 7.2.3), o
pseudo-cdigo a seguir representa o lanamento da operao de E/S pelo
processador e a rotina de tratamento de interrupo (subentende-se as
constantes e variveis definidas na listagem anterior):
c Carlos Maziero
278
1
2
3
4
// lanamento da operao de sada de dados

interrupt_driven_output ()
{
i = 0 ;
// espera o controlador ficar livre (bit BUSY de P1 deve ser zero).

while (in (P1) & BUSY) ;
6
7
8

9
10
11
// gera pulso de 1 microssegundo no bit STROBE de P2.

out (P2, in (P2) | STROBE) ;
usleep (1) ;
out (P2, in (P2) & ! STROBE) ;
12
13
14
15
16
// suspende o processo solicitante, liberando o processador.

schedule () ;
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// rotina de tratamento de interrupes da interface paralela

interrupt_handle ()
{
i++ ;
if (i >= BUFSIZE)
// a sada terminou, acordar o processo solicitante.
awake_process () ;
else
{
32
// gera pulso de 1 microssegundo no bit STROBE de P2.

out (P2, in (P2) | STROBE) ;
usleep (1) ;
out (P2, in (P2) & ! STROBE) ;
33
34
35
36
37
38
// informa o controlador de interrupes que a IRQ foi tratada.

acknowledge_irq () ;
39
40
41
Nesse pseudo-cdigo, percebe-se que o processador inicia a transferncia de dados para a interface paralela e suspende o processo solicitante
(chamada schedule), liberando o processador para outras atividades. A cada
c Carlos Maziero
279
interrupo, a rotina de tratamento ativada para enviar um novo byte

interface paralela, at que todos os bytes do buffer tenham sido enviados, quando ento sinaliza ao escalonador que o processo solicitante pode
retomar sua execuo (chamada resume). Conforme visto anteriormente,
o controlador da interface paralela pode ser configurado para gerar uma
interrupo atravs do flag Enable_IRQ de sua porta de controle (porta P2 ,
Seo 7.2.3). O diagrama da Figura 7.10 ilustra de forma simplificada a
estratgia de entrada/sada usando interrupes.
Durante a execuo da rotina de tratamento de uma interrupo, usual
inibir novas interrupes, para evitar a execuo aninhada de tratadores de
interrupo, o que tornaria o cdigo dos drivers (e do ncleo) mais complexo
e suscetvel a erros. Entretanto, manter interrupes inibidas durante muito
tempo pode ocasionar perdas de dados ou outros problemas. Por exemplo,
uma interface de rede gera uma interrupo quando recebe um pacote vindo
da rede; esse pacote fica em seu buffer interno e deve ser transferido dali
para a memria principal antes que outros pacotes cheguem, pois esse buffer
tem uma capacidade limitada. Por essa razo, o tratamento das interrupes
deve ser feito de forma muito rpida.
A maioria dos sistemas operacionais implementa o tratamento de interrupes em dois nveis distintos: um tratador primrio (FLIH - First-Level
Interrupt Handler) e um tratador secundrio (SLIH - Second-Level Interrupt
Handler). O tratador primrio, tambm chamado hard/fast interrupt handler
ou ainda top-half handler, lanado quando a interrupo ocorre e deve
executar rapidamente, pois as demais interrupes esto inibidas. Sua
atividade se restringe a aes essenciais, como reconhecer a ocorrncia da
interrupo junto ao controlador e registrar dados sobre a mesma em uma
fila de eventos pendentes, para tratamento posterior.
Por sua vez, o tratador secundrio, tambm conhecido como soft/slow
interrupt handler ou ainda bottom-half handler, tem por objetivo tratar a fila de
eventos pendentes registrados pelo tratador primrio, quando o processador
estiver disponvel. Ele pode ser escalonado e suspenso da mesma forma que
um processo ou thread, embora normalmente execute com maior prioridade.
Embora mais complexa, esta estrutura em dois nvel traz algumas vantagens:
ao permitir um tratamento mais rpido de cada interrupo, minimiza o
risco de perder interrupes concomitantes; alm disso, a fila de eventos
pendentes pode ser analisada para remover eventos redundantes (como
atualizaes consecutivas de posio do mouse).
c Carlos Maziero
280
processador
espera
controlador
ficar livre
controlador
wait (!busy)
busy=0
wait (!strobe)
prepara e
envia byte
interface
data=byte
strobe=0
schedule()
tratador de
interrupo
raise IRQ
wait (!strobe)
data=byte
espera
novo
byte
recebe e
processa
byte
espera
novo
byte
strobe=0
processo
suspenso
raise IRQ
wait (!strobe)
data=byte
recebe e
processa
byte
espera
novo
byte
strobe=0
raise IRQ
recebe e
processa
byte
resume()
t
Figura 7.10: Entrada/sada controlada por eventos (interrupes).

No Linux, cada interrupo possui sua prpria fila de eventos pendentes
e seus prprios top-half e bottom-half. Os tratadores secundrios so lanados
pelos respectivos tratadores primrios, sob a forma de threads de ncleo
especiais (denominadas tasklets ou workqueues) [Bovet and Cesati, 2005]. O
ncleo Windows NT e seus sucessores implementam o tratamento primrio
atravs de rotinas de servio de interrupo (ISR - Interrupt Service Routine).
Ao final de sua execuo, cada ISR agenda o tratamento secundrio da
c Carlos Maziero
281
interrupo atravs de um procedimento postergado (DPC - Deferred Procedure Call) [Russinovich and Solomon, 2004]. O sistema Symbian usa uma
abordagem similar a esta.
Por outro lado, os sistemas Solaris, FreeBSD e MacOS X usam uma
abordagem denominada interrupt threads [Mauro and McDougall, 2006].
Cada interrupo provoca o lanamento de uma thread de ncleo, que
escalonada e compete pelo uso do processador de acordo com sua prioridade.
As interrupes tm prioridades que podem estar acima da prioridade do
escalonador ou abaixo dela. Como o prprio escalonador tambm uma
thread, interrupes de baixa prioridade podem ser interrompidas pelo
escalonador ou por outras interrupes. Por outro lado, interrupes de
alta prioridade no so interrompidas pelo escalonador, por isso devem
executar rapidamente.
Acesso direto memria
Na maioria das vezes, o tratamento de operaes de entrada/sada uma
operao lenta, pois os dispositivos so mais lentos que o processador. Alm
disso, o uso do processador principal para intermediar essas operaes
ineficiente, pois implica em transferncias adicionais (e desnecessrias) de
dados: por exemplo, para transportar um byte de um buffer da memria
para a interface paralela, esse byte precisa antes ser carregado em um
registrador do processador, para em seguida ser enviado ao controlador
da interface. Para resolver esse problema, a maioria dos computadores
atuais, com exceo de pequenos sistemas embarcados dedicados, oferece
mecanismos de acesso direto memria (DMA - Direct Memory Access), que
permitem transferncias diretas entre a memria principal e os controladores
de entrada/sada.
O funcionamento do mecanismo de acesso direto memria em si
relativamente simples. Como exemplo, a seguinte sequncia de passos seria
executada para a escrita de dados de um buffer em memria RAM para o
controlador de um disco rgido:
1. o processador acessa os registradores do canal DMA associado ao
dispositivo desejado, para informar o endereo inicial e o tamanho da
rea de memria RAM contendo os dados a serem escritos no disco.
O tamanho da rea de memria deve ser um mltiplo de 512 bytes,
que o tamanho padro dos setores do disco rgido;
c Carlos Maziero
282
2. o controlador de DMA solicita ao controlador do disco a transferncia

de dados da RAM para o disco e aguarda a concluso da operao;
3. o controlador do disco recebe os dados da memria;
4. a operao anterior pode ser repetida mais de uma vez, caso a quantidade de dados a transferir seja maior que o tamanho mximo de cada
transferncia feita pelo controlador de disco;
5. a final da transferncia de dados, o controlador de DMA notifica o
processador sobre a concluso da operao, atravs de uma interrupo
(IRQ).
processador
memria RAM
5: interrupt request
barramento
1: DMA request
2: transfer request
controlador
de DMA
3: data transfer
controlador
de disco rgido
hardware do dispositivo
Figura 7.11: Funcionamento do acesso direto memria.

A dinmica dessas operaes ilustrada de forma simplificada na Figura
7.11. Uma vez efetuado o passo 1, o processador fica livre para outras
c Carlos Maziero
283
atividades4 , enquanto o controlador de DMA e o controlador do disco se

encarregam da transferncia de dados propriamente dita. O cdigo a seguir
representa uma implementao hipottica de rotinas para executar uma
operao de entrada/sada atravs de DMA.
// requisio da operao de sada atravs de DMA
dma_driven_output ()
{
// solicita uma operao DMA, informando os dados da transferncia
// atravs da estrutura "dma_data".
request_dma (dma_data) ;
1
2
3
4
5
6
7
// suspende o processo solicitante, liberando o processador.

schedule () ;
8
9
10
11
// rotina de tratamento da interrupo do controlador de DMA

interrupt_handle ()
{
// informa o controlador de interrupes que a IRQ foi tratada.
acknowledge_irq () ;
12
13
14
15
16
17
// sada terminou, acordar o processo solicitante.

resume (...) ;
18
19
20
A implementao dos mecanismos de DMA depende da arquitetura e do

barramento considerado. Computadores mais antigos dispunham de um
controlador de DMA central, que oferecia vrios canais de DMA distintos,
permitindo a realizao de transferncias de dados por DMA simultneas.
J os computadores pessoais usando barramento PCI no possuem um
controlador DMA central; ao invs disso, cada controlador de dispositivo
conectado ao barramento pode assumir o controle do mesmo para efetuar
transferncias de dados de/para a memria sem depender do processador
principal [Corbet et al., 2005], gerenciando assim seu prprio canal DMA.
4
Obviamente pode existir uma conteno (disputa) entre o processador e os controladores

no acesso aos barramentos e memria principal, mas esse problema atenuado pelo fato
do processador poder acessar o contedo das memrias cache enquanto a transferncia
DMA executada. Alm disso, circuitos de arbitragem intermedeiam o acesso memoria
para evitar conflitos. Mais detalhes sobre conteno de acesso memria durante operaes
de DMA podem ser obtidos em [Patterson and Henessy, 2005].
c Carlos Maziero
284
7: Discos rgidos
No exemplo anterior, a ativao do mecanismo de DMA dita sncrona,

pois feita explicitamente pelo processador, provavelmente em decorrncia
de uma chamada de sistema. Contudo, a ativao tambm pode ser
assncrona, quando ativada por um dispositivo de entrada/sada que dispe
de dados a serem transferidos para a memria, como ocorre com uma
interface de rede ao receber dados provindos de outro computador atravs
da rede.
O mecanismo de DMA utilizado para transferir grandes blocos de
dados diretamente entre a memria RAM e as portas dos dispositivos de
entrada/sada, liberando o processador para outras atividades. Todavia,
como a configurao de cada operao de DMA complexa, para pequenas
transferncias de dados acaba sendo mais rpido e simples usar o processador principal [Bovet and Cesati, 2005]. Por essa razo, o mecanismo
de DMA usado preponderantemente nas operaes de entrada/sada
envolvendo dispositivos que produzem ou consomem grandes volumes
de dados, como interfaces de rede, entradas e sadas de udio, interfaces
grficas e discos.
Nas prximas sees sero discutidos alguns aspectos relevantes dos
dispositivos de entrada/sada mais usados e da forma como estes so
acessados e gerenciados nos sistemas de computao pessoal. Sempre
que possvel, buscar-se- adotar uma abordagem independente de sistema
operacional, concentrando a ateno sobre os aspectos comuns que devem
ser considerados por todos os sistemas.
7.4
Discos rgidos
Discos rgidos esto presentes na grande maioria dos computadores

pessoais e servidores. Um disco rgido permite o armazenamento persistente
(no-voltil) de grandes volumes de dados com baixo custo e tempos de
acesso razoveis. Alm disso, a leitura e escrita de dados em um disco
rgido mais simples e flexvel que em outros meios, como fitas magnticas
ou discos ticos (CDs, DVDs). Por essas razes, eles so intensivamente
utilizados em computadores para o armazenamento de arquivos do sistema
operacional, das aplicaes e dos dados dos usurios. Os discos rgidos
tambm so frequentemente usados como rea de armazenamento de
pginas em sistemas de memria virtual (Seo 5.7).
c Carlos Maziero
285
7: Estrutura fsica
Esta seo inicialmente discute alguns aspectos de hardware relacionados

aos discos rgidos, como sua estrutura fsica e os principais padres de
interface entre o disco e sua controladora no computador. Em seguida,
apresenta aspectos de software que esto sob a responsabilidade direta
do sistema operacional, como o caching de blocos e o escalonamento de
operaes de leitura/escrita no disco. Por fim, apresenta as tcnicas RAID
para a composio de discos rgidos, que visam melhorar seu desempenho
e/ou confiabilidade.
7.4.1
Estrutura fsica
Um disco rgido composto por um ou mais discos metlicos que giram

juntos em alta velocidade (entre 4.200 e 15.000 RPM), acionados por um
motor eltrico. Para cada face de cada disco h uma cabea de leitura,
responsvel por ler e escrever dados atravs da magnetizao de pequenas
reas da superfcie metlica. Cada face dividida logicamente em trilhas e
setores; a interseo de uma trilha e um setor em uma face define um bloco
fsico, que a unidade bsica de armazenamento e transferncia de dados
no disco. Os discos rgidos atuais (at 2010) usam blocos de 512 bytes, mas
o padro da industria est migrando para blocos fsicos de 4.096 bytes. A
Figura 7.12 apresenta os principais elementos que compem a estrutura de
um disco rgido. Um disco tpico comporta milhares de trilhas e centenas
de setores por face de disco [Patterson and Henessy, 2005].
setores
trilhas
blocos
faces
cabeas
Figura 7.12: Elementos da estrutura de um disco rgido.

Por serem dispositivos eletromecnicos, os discos rgidos so extremamente lentos, se comparados velocidade da memria ou do processador.
c Carlos Maziero
286
7: Interface de hardware
Para cada bloco a ser lido/escrito, a cabea de leitura deve se posicionar na

trilha desejada e aguardar o disco girar at encontrar o setor desejado. Esses
dois passos definem o tempo de busca (ts seek time), que o tempo necessrio
para a cabea de leitura se posicionar sobre uma determinada trilha, e a
latncia rotacional (tr rotation latency), que o tempo necessrio para o disco
girar at que o setor desejado esteja sob a cabea de leitura. Valores mdios
tpicos desses atrasos para discos de uso domstico so ts 10ms e tr 5ms.
Juntos, esses dois atrasos podem ter um forte impacto no desempenho do
acesso a disco.
7.4.2
Interface de hardware
Conforme estudado anteriormente (Sees 6.4.1 e 7.2), o acesso do

processador ao discos feito atravs de uma controladora em hardware,
ligada ao barramento do computador. Por sua vez, o disco ligado
controladora de disco atravs de um barramento de interconexo, que pode
usar diversas tecnologias. As mais comuns esto descritas a seguir:
IDE: Integrated Drive Electronics, padro tambm conhecido como PATA
(Parallell ATA - Advanced Technology Attachment); surgiu nos anos 1980
e durante muito tempo foi o padro de interface de discos mais usado
em computadores pessoais. Suporta velocidades de at 133 MB/s,
atravs de cabos paralelos de 40 ou 80 vias. Cada barramento IDE
suporta at dois dispositivos, em uma configurao mestre/escravo.
SATA: Serial ATA, o padro de interface de discos em desktops e
notebooks atuais. A transmisso dos dados entre o disco e a controladora
serial, atingindo taxas entre 150 MB/s e 300 MB/s atravs de cabos
com 7 vias.
SCSI: Small Computer System Interface, padro de interface desenvolvida nos anos 1980, foi muito usada em servidores e estaes de
trabalho de alto desempenho. Um barramento SCSI suporta at 16
dispositivos e atinge taxas de transferncia de at 640 MB/s (divididos
entre os dispositivos conectados no mesmo barramento).
SAS: Serial Attached SCSI, uma evoluo do padro SCSI, permitindo
atingir taxas de transferncia de at 600 MB/s em cada dispositivo
conectado controladora. usado em equipamentos de alto desempenho.
c Carlos Maziero
287
7: Escalonamento de acessos
importante observar que esses padres de interface no so de uso

exclusivo em discos rgidos, muito pelo contrrio. H vrios tipos de
dispositivos que se conectam ao computador atravs dessas interfaces,
como discos de estado slido (SSD), leitores ticos (CD, DVD), unidades de
fita magntica, scanners, etc.
7.4.3
Escalonamento de acessos
Em um sistema multi-tarefas, vrias aplicaes e processos do sistema

podem solicitar acessos concorrentes ao disco, para escrita e leitura de
dados. Por sua estrutura fsica, um disco rgido s pode atender a uma
requisio de acesso por vez, o que torna necessrio criar uma fila de acessos
pendentes. Cada nova requisio de acesso ao disco colocada nessa fila e
o processo solicitante suspenso at seu pedido ser atendido. Sempre que
o disco concluir um acesso, ele informa o sistema operacional, que deve
buscar nessa fila a prxima requisio de acesso a ser atendida. A ordem de
atendimento das requisies pendentes denominada escalonamento de
disco e pode ter um grande impacto no desempenho do sistema operacional.
Na sequncia do texto sero apresentados alguns algoritmos de escalonamento de disco clssicos. Para exemplificar seu funcionamento, ser
considerado um disco hipottico com 1.024 blocos, cuja cabea de leitura
se encontra inicialmente sobre o bloco 500. A fila de pedidos de acesso
pendentes contm pedidos de acesso aos seguintes blocos do disco, em
sequncia: {278, 914, 71, 447, 161, 659, 335, 524}. Para simplificar, considerase que nenhum novo pedido de acesso chegar fila durante a execuo
dos algoritmos.
FCFS (First Come, First Served): esta abordagem consiste em atender as
requisies de acesso na ordem em que elas foram pedidas pelos
processos. a estratgia mais simples de implementar, mas raramente
oferece um bom desempenho. Se os pedidos de acesso estiverem
espalhados ao longo do disco, este ir perder muito tempo movendo
a cabea de leitura de um lado para o outro. A Figura 7.13 mostra os
deslocamentos da cabea de leitura para atender os pedidos de acesso
da fila de exemplo. Pode-se perceber que a cabea de leitura teve de
percorrer 3374 blocos do disco para atender todos pedidos da fila.
SSTF (Shortest Seek Time First Menor Tempo de Busca Primeiro): esta estratgia de escalonamento de disco consiste em sempre atender o
c Carlos Maziero
288
524
189
335
324
659
498
161
286
447
Percurso total = 3374 blocos
376
71
843
914
636
278
bloco
222
500
200
400
600
800
Figura 7.13: Escalonamento de disco FCFS.

pedido que est mais prximo da posio atual da cabea de leitura
(que geralmente a posio do pedido que acabou de ser atendido).
Dessa forma, ela busca reduzir os movimentos da cabea de leitura,
e com isso o tempo perdido entre os acessos atendidos. A estratgia
SSTF est ilustrada na fura 7.14. Pode-se observar uma forte reduo
da movimentao da cabea de leitura em relao estratgia FCFS,
que passou de 3374 para 1320 blocos percorridos. Contudo, essa
estratgia no garante um percurso mnimo. Por exemplo, o percurso
500 524 659 914 447 335 278 161 71 percorreria
apenas 1257 blocos.
Apesar de oferecer um bom desempenho, esta estratgia pode levar
inanio (starvation) de requisies de acesso: caso existam muitas
requisies em uma determinada regio do disco, pedidos de acesso
a blocos longe dessa regio podem ficar muito tempo esperando.
Para resolver esse problema, torna-se necessrio implementar uma
estratgia de envelhecimento dos pedidos pendentes.
c Carlos Maziero
289
914
255
659
588

71
90
117
161
57
278
335
200
112
bloco
77
447
524
500
24
400
600
800
Figura 7.14: Escalonamento de disco SSTF.

Elevador : este algoritmo reproduz o comportamento dos elevadores em
edifcios: a cabea de leitura se move em uma direo e atende os
pedidos que encontra pela frente; aps o ltimo pedido, ela inverte seu
sentido de movimento e atende os prximos pedidos. Esse movimento
tambm anlogo ao dos limpadores de para-brisas de um automvel.
A Figura 7.15 apresenta o comportamento deste algoritmo para a
sequncia de requisies de exemplo, considerando que a cabea
de leitura estava inicialmente se movendo para o comeo do disco.
Pode-se observar que o desempenho deste algoritmo foi melhor que os
algoritmos anteriores, mas isso no ocorre sempre. A grande vantagem
do algoritmo do elevador atender os pedidos de forma mais uniforme
ao longo do disco, eliminando a possibilidade de inanio de pedidos
e mantendo um bom desempenho. Ele adequado para sistemas
com muitos pedidos concorrentes de acesso a disco em paralelo,
como servidores de arquivos. Este algoritmo tambm conhecido la
literatura como SCAN ou LOOK [Silberschatz et al., 2001].
t
914
255
135
659
524
453
71
90
161
117
278
57
335
112
200
400
bloco
53
447
500
600
800
Figura 7.15: Escalonamento de disco com o algoritmo do elevador.
c Carlos Maziero
290
Elevador Circular : esta uma variante do algoritmo do elevador, na qual a

cabea de leitura varre o disco em uma direo, atendendo os pedidos
que encontrar. Ao atender o ltimo pedido em um extremo do disco,
ela retorna diretamente ao primeiro pedido no outro extremo, sem
atender os pedidos intermedirios, e recomea. O nome circular
devido ao disco ser visto como uma lista circular de blocos. A
Figura 7.16 apresenta um exemplo deste algoritmo. Apesar de seu
desempenho ser pior que o do algoritmo do elevador clssico, sua
maior vantagem prover um tempo de espera mais homogneo aos
pedidos pendentes, o que importante em servidores. Este algoritmo
tambm conhecido como C-SCAN ou C-LOOK.
t
524
135
659
255
914
843

71
90
161
117
278
57
335
112
200
400
bloco
53
447
500
600
800
Figura 7.16: Escalonamento de disco com o algoritmo do elevador circular.

Sistemas reais mais complexos, como Solaris, Windows e Linux, utilizam
escalonadores de disco geralmente mais sofisticados. No caso do Linux, os seguintes escalonadores de disco esto presentes no ncleo, podendo ser selecionados pelo administrador do sistema [Love, 2004, Bovet and Cesati, 2005]:
Noop (No-Operation): o escalonador mais simples, baseado em FCFS,
que no reordena os pedidos de acesso, apenas agrupa os pedidos
direcionados ao mesmo bloco ou a blocos adjacentes. Este escalonador
voltado para discos de estado slido (baseados em memria flash) ou
sistemas de armazenamento que faam seu prprio escalonamento,
como sistemas RAID (vide Seo 7.4.5).
Deadline : este escalonador baseado no algoritmo do elevador circular,
mas associa um prazo (deadline) a cada requisio, para evitar problemas de inanio. Como os pedidos de leitura implicam no bloqueio
c Carlos Maziero
291
7: Caching de blocos
dos processos solicitantes, eles recebem um prazo de 500 ms; pedidos

de escrita podem ser executados de forma assncrona, por isso recebem
um prazo maior, de 5 segundos. O escalonador processa os pedidos
usando o algoritmo do elevador, mas prioriza os pedidos cujo prazo
esteja esgotando.
Anticipatory : este algoritmo baseado no anterior (deadline), mas busca se
antecipar s operaes de leitura de dados feitas pelos processos. Como
as operaes de leitura so geralmente feitas de forma sequencial (em
blocos contguos ou prximos), a cada operao de leitura realizada o
escalonador aguarda um certo tempo (por default 6 ms) por um novo
pedido de leitura naquela mesma regio do disco, que imediatamente
atendido. Caso no surja nenhum pedido, o escalonador volta a tratar
a fila de pedidos pendentes normalmente. Essa espera por pedidos
adjacentes melhora o desempenho das operaes de leitura.
CFQ (Completely Fair Queuing): os pedidos dos processos so divididos
em vrias filas (64 filas por default); cada fila recebe uma fatia de
tempo para acesso ao disco, que varia de acordo com a prioridade de
entrada/sada dos processos contidos na mesma. Este o escalonador
default do Linux na maioria das distribuies atuais.
7.4.4
Caching de blocos
Como o disco rgido pode apresentar latncias elevadas, a funcionalidade

de caching muito importante para o bom desempenho dos acessos ao disco.
possvel fazer caching de leitura e de escrita. No caching de leitura (read
caching), blocos de dados lidos do disco so mantidos em memria, para
acelerar leituras posteriores dos mesmos. No caching de escrita (write
caching, tambm chamado buffering), dados a escrever no disco so mantidos
em memria para leituras posteriores, ou para concentrar vrias escritas
pequenas em poucas escritas maiores (e mais eficientes). Quatro estratgias
de caching so usuais:
Read-behind: esta a poltica mais simples, na qual somente os dados j
lidos em requisies anteriores so mantidos em cache; outros acessos
aos mesmos dados sero beneficiados pelo cache;
Read-ahead: nesta poltica, ao atender uma requisio de leitura, so
trazidos para o cache mais dados que os solicitados pela requisio;
c Carlos Maziero
292
7: Sistemas RAID
alm disso, leituras de dados ainda no solicitados podem ser agendadas em momentos de ociosidade dos discos. Dessa forma, futuras
requisies podem ser beneficiadas pela leitura antecipada dos dados.
Essa poltica pode melhorar muito o desempenho de acesso sequencial
a arquivos;
Write-through: nesta poltica, ao atender uma requisio de escrita,
uma cpia dos dados a escrever no disco mantida em cache, para
beneficiar possveis leituras futuras desses dados;
Write-back: nesta poltica, alm de copiar os dados em cache, sua
escrita efetiva no disco adiada; esta estratgia melhora o desempenho
de escrita de duas formas: por liberar mais cedo os processos que
solicitam escritas (eles no precisam esperar pela escrita real no disco)
e por concentrar as operaes de escrita, gerando menos acessos a
disco. Todavia, pode ocasionar perda de dados, caso ocorram erros de
hardware ou falta de energia antes que os dados sejam efetivamente
escritos no disco.
7.4.5
Sistemas RAID
Apesar dos avanos dos sistemas de armazenamento em estado slido

(como os dispositivos baseados em memrias flash), os discos rgidos
continuam a ser o principal meio de armazenamento no-voltil de grandes
volumes de dados. Os discos atuais tm capacidades de armazenamento
impressionantes: encontram-se facilmente no mercado discos rgidos com
capacidade da ordem de terabytes para computadores domsticos.
Entretanto, o desempenho dos discos rgidos evolui a uma velocidade
muito menor que que a observada nos demais componentes dos computadores, como processadores, memrias e barramentos. Com isso, o acesso
aos discos constitui um dos maiores gargalos de desempenhos nos sistemas
de computao. Boa parte do baixo desempenho no acesso aos discos
devida aos aspectos mecnicos do disco, como a latncia rotacional e o
tempo de posicionamento da cabea de leitura do disco (vide Seo 7.4.3)
[Chen et al., 1994].
Outro problema relevante associado aos discos rgidos diz respeito sua
confiabilidade. Os componentes internos do disco podem falhar, levando
perda de dados. Essas falhas podem estar localizadas no meio magntico,
c Carlos Maziero
293
7: Sistemas RAID
read-behind
t1
read-ahead
t2
cache
cache
t2
cache
cache
t1
dispositivo
dispositivo
write-through
t1
write-back
t2
cache
cache
t1
cache
cache
t2
dispositivo
dispositivo
Figura 7.17: Estratgias de caching de blocos (t1 e t2 indicam dois instantes

de tempo).
ficando restritas a alguns setores, ou podem estar nos componentes mecnicos/eletrnicos do disco, levando corrupo ou mesmo perda total dos
dados armazenados.
Buscando solues eficientes para os problemas de desempenho e confiabilidade dos discos rgidos, pesquisadores da Universidade de Berkeley, na
Califrnia, propuseram em 1988 a construo de discos virtuais compostos
por conjuntos de discos fsicos, que eles denominaram RAID Redundant
Array of Inexpensive Disks5 [Patterson et al., 1988], que em portugus pode
ser traduzido como Conjunto Redundante de Discos Econmicos.
Um sistema RAID constitudo de dois ou mais discos rgidos que so
vistos pelo sistema operacional e pelas aplicaes como um nico disco
lgico, ou seja, um grande espao contguo de armazenamento de dados. O
5
Mais recentemente alguns autores adotaram a expresso Redundant Array of Independent

Disks para a sigla RAID, buscando evitar a subjetividade da palavra Inexpensive (econmico).
c Carlos Maziero
294
7: Sistemas RAID
objetivo central de um sistema RAID proporcionar mais desempenho nas

operaes de transferncia de dados, atravs do paralelismo no acesso aos
vrios discos, e tambm mais confiabilidade no armazenamento, usando
mecanismos de redundncia dos dados armazenados nos discos, como
cpias de dados ou cdigos corretores de erros.
Um sistema RAID pode ser construdo por hardware, usando uma
placa controladora dedicada a esse fim, qual esto conectados os discos
rgidos. Essa placa controladora oferece a viso de um disco lgico nico
ao restante do computador. Tambm pode ser usada uma abordagem
por software, na qual so usados drivers apropriados dentro do sistema
operacional para combinar os discos rgidos conectados ao computador em
um nico disco lgico. Obviamente, a soluo por software mais flexvel
e econmica, por no exigir uma placa controladora dedicada, enquanto
a soluo por hardware mais robusta e tem um desempenho melhor.
importante observar que os sistemas RAID operam abaixo dos sistemas
de arquivos, ou seja, eles se preocupam apenas com o armazenamento e
recuperao de blocos de dados.
H vrias formas de se organizar um conjunto de discos rgidos em RAID,
cada uma com suas prprias caractersticas de desempenho e confiabilidade.
Essas formas de organizao so usualmente chamadas Nveis RAID. Os
nveis RAID padronizados pela Storage Networking Industry Association so
[SNIA, 2009]:
RAID 0 (stripping) : neste nvel os discos fsicos so divididos em reas
de tamanhos fixo chamadas fatias ou faixas (stripes). Cada fatia de
disco fsico armazena um ou mais blocos do disco lgico. As fatias so
preenchidas com os blocos usando uma estratgia round-robin, como
mostra a Figura 7.18. O disco lgico ter como tamanho a soma dos
tamanhos dos discos fsicos.
Esta abordagem oferece um grande ganho de desempenho em operaes de leitura e escrita: usando N discos fsicos, at N operaes
podem ser efetuadas em paralelo. Entretanto, no h nenhuma estratgia de redundncia de dados, o que torna este nvel mais suscetvel
a erros de disco: caso um disco falhe, todos os blocos armazenados
nele sero perdidos. Como a probabilidade de falhas aumenta com o
nmero de discos, esta abordagem acaba por reduzir a confiabilidade
do sistema de discos.
c Carlos Maziero
295
7: Sistemas RAID
Suas caractersticas de grande volume de dados e alto desempenho em

leitura/escrita tornam esta abordagem adequada para ambientes que
geram e precisam processar grandes volumes de dados temporrios,
como os sistemas de computao cientfica [Chen et al., 1994].
bloco 0
bloco 1
bloco 2
bloco 3
bloco 4
bloco 5
bloco 6
bloco 7
bloco 8
bloco 9
bloco 10
bloco 11
bloco 12
bloco 13
bloco 14
bloco 15
bloco 16
bloco 17
Controladora RAID
faixa
bloco 0
bloco 1
bloco 4
bloco 5
bloco 8
bloco 9
bloco 2
bloco 3
bloco 6
bloco 7
bloco 10
bloco 11
bloco 18
bloco 19
bloco 20
bloco 21
bloco 12
bloco 13
bloco 16
bloco 17
bloco 20
bloco 21
bloco 22
bloco 23
bloco 14
bloco 15
bloco 18
bloco 19
bloco 22
bloco 23
disco lgico
disco fsico 0 (dados)
Figura 7.18: RAID nvel 0 (striping).

RAID 0 (linear) : Alguns sistemas RAID no dividem os discos fsicos
em fatias, mas apenas concatenam os espaos dos vrios discos em
sequncia para construir o disco lgico. Essa abordagem, ilustrada
na Figura 7.19, denominada por alguns autores de RAID 0 linear,
enquanto outros a denominam JBoD (Just a Bunch of Disks apenas
um punhado de discos). Como os blocos do disco lgico esto
menos uniformemente espalhados sobre os discos fsicos, os acessos
se concentram em um disco a cada instante, levando a um menor
desempenho em leituras e escritas.
RAID 1 : neste nvel, cada disco fsico possui um espelho, ou seja, outro disco com a cpia de seu contedo, sendo por isso comumente
chamado de espelhamento de discos. A Figura 7.20 mostra uma configurao simples deste nvel, com dois discos fsicos. Caso hajam mais
de dois discos, devem ser incorporadas tcnicas de RAID 0 para organizar a distribuio dos dados sobre eles (o que leva a configuraes
denominadas RAID 0+1, RAID 1+0 ou RAID 1E).
Esta abordagem oferece uma excelente confiabilidade, pois cada bloco
lgico est escrito em dois discos distintos; caso um deles falhe, o outro
continua acessvel. O desempenho em leituras tambm beneficiado,
c Carlos Maziero
296
bloco 0
7: Sistemas RAID
bloco 1
bloco 2
bloco 3
bloco 4
bloco 5
bloco 6
bloco 7
bloco 8
bloco 9
bloco 10
bloco 11
bloco 12
bloco 13
Controladora RAID
bloco 14
bloco 15
bloco 0
bloco 1
bloco 10
bloco 11
bloco 20
bloco 21
bloco 16
bloco 17
bloco 2
bloco 3
bloco 12
bloco 13
bloco 22
bloco 23
bloco 18
bloco 19
bloco 4
bloco 5
bloco 14
bloco 15
bloco 20
bloco 21
bloco 6
bloco 7
bloco 16
bloco 17
bloco 22
bloco 23
bloco 8
bloco 9
bloco 18
bloco 19
disco lgico
Figura 7.19: RAID nvel 0 (linear).

pois a controladora pode distribuir as leituras entre as cpias. Contudo,
no h ganho de desempenho em escrita, pois cada operao de escrita
deve ser replicada em todos os discos. Alm disso, seu custo de
implantao elevado, pois so necessrios dois discos fsicos para
cada disco lgico.
bloco 0
bloco 1
bloco 2
bloco 3
bloco 4
bloco 5
bloco 6
bloco 7
bloco 8
bloco 9
Controladora RAID
disco lgico
bloco 0
bloco 1
bloco 0
bloco 1
bloco 2
bloco 3
bloco 2
bloco 3
bloco 4
bloco 5
bloco 4
bloco 5
bloco 6
bloco 7
bloco 6
bloco 7
bloco 8
bloco 9
bloco 8
bloco 9
Figura 7.20: RAID nvel 1 (mirroring).

RAID 2 : este nvel fatia os dados em bits individuais que so escritos
nos discos fsicos em sequncia; discos adicionais so usados para
armazenar cdigos corretores de erros (Hamming Codes), em um arranjo
similar ao usado nas memrias RAM. Este nvel no usado na prtica.
RAID 3 : este nvel fatia os dados em bytes, que so escritos nos discos em
sequncia. Um disco separado contm dados de paridade, usados
c Carlos Maziero
297
7: Sistemas RAID
para a recuperao de erros. A cada leitura ou escrita, os dados do

disco de paridade devem ser atualizados, o que implica na serializao
dos acessos e a consequente queda de desempenho. Por esta razo,
esta abordagem raramente usada.
bloco 0
bloco 1
bloco 2
bloco 3
bloco 4
bloco 5
bloco 6
bloco 7
bloco 8
bloco 9
bloco 10
bloco 11
bloco 12
bloco 13
bloco 14
bloco 15
bloco 16
bloco 17
bloco 18
bloco 19
bloco 20
bloco 21
bloco 22
bloco 23
disco lgico
Controladora RAID
byte 0
byte 3
byte 1
byte 4
byte 2
byte 5
par 0-2
par 3-5
byte 6
byte 9
byte 7
byte 10
byte 8
byte 11
par 6-8
par 9-11
byte 12
byte 15
byte 13
byte 16
byte 14
byte 17
par 12-14 par 15-17
byte 18
byte 21
byte 19
byte 22
byte 20
byte 23
par 18-20 par 21-23
byte 24
byte 27
byte 25
byte 28
byte 26
byte 29
par 24-26 par 27-29
disco fsico 3 (paridade)
Figura 7.21: RAID nvel 3.

RAID 4 : esta abordagem similar ao RAID 3, com a diferena de que o
fatiamento feito por blocos ao invs de bytes (Figura 7.22). Ela sofre
dos mesmos problemas de desempenho que o RAID 3, sendo por isso
pouco usada. Todavia, ela serve como base conceitual para o RAID 5.
bloco 0
bloco 1
bloco 2
bloco 3
bloco 4
bloco 5
bloco 6
bloco 7
bloco 8
bloco 9
bloco 10
bloco 11
bloco 12
bloco 13
bloco 14
bloco 15
bloco 16
bloco 17
bloco 18
bloco 19
bloco 20
bloco 21
bloco 22
bloco 23
disco lgico
Controladora RAID
bloco 0
bloco 3
bloco 1
bloco 4
bloco 2
bloco 5
par 0-2
par 3-5
bloco 6
bloco 9
bloco 7
bloco 10
bloco 8
bloco 11
par 6-8
par 9-11
bloco 12
bloco 15
bloco 13
bloco 16
bloco 14
bloco 17
par 12-14 par 15-17
bloco 18
bloco 21
bloco 19
bloco 22
bloco 20
bloco 23
par 18-20 par 21-23
disco fsico 3 (paridade)

RAID 5 : assim como a anterior, esta abordagem tambm armazena informaes de paridade para tolerar falhas em discos. Todavia, essas
c Carlos Maziero
298
7: Sistemas RAID
informaes no ficam concentradas em um nico disco fsico, mas

so distribudas uniformemente entre todos eles. A Figura 7.23 ilustra
uma possibilidade de distribuio das informaes de paridade. Essa
estratgia elimina o gargalo de desempenho no acesso aos dados de
paridade. Esta sem dvida a abordagem de RAID mais popular, por
oferecer um bom desempenho e redundncia de dados com um custo
menor que o espelhamento (RAID 1).
bloco 0
bloco 1
bloco 2
bloco 3
bloco 4
bloco 5
bloco 6
bloco 7
bloco 8
bloco 9
bloco 10
bloco 11
bloco 12
bloco 13
bloco 14
bloco 15
bloco 16
bloco 17
bloco 18
bloco 19
Controladora RAID
faixa
bloco 0
bloco 1
bloco 4
bloco 5
bloco 8
bloco 9
par (0,4,8)
par (1,5,9)
bloco 2
bloco 3
bloco 6
bloco 7
bloco 10
bloco 11
par (2,6,10)
par (3,7,11)
bloco 20
bloco 21
bloco 12
bloco 13
bloco 16
bloco 17
par (12,16,20) par (13,17,21)
bloco 20
bloco 21
bloco 22
bloco 23
bloco 14
bloco 15
bloco 18
bloco 19
par (14,18,22) par (15,19,23)
bloco 22
bloco 23
bloco 24
bloco 25
bloco 24
bloco 25
par (24,28,32) par (25,29,33)
bloco 28
bloco 29
bloco 32
bloco 33
bloco 26
bloco 27
par (26,30,34) par (27,31,35)
bloco 30
bloco 31
bloco 34
bloco 35
bloco 26
bloco 27
bloco 28
bloco 29
bloco 30
bloco 31
bloco 32
bloco 33
...
disco lgico
par (36,40,44) par (37,41,45)
bloco 36
bloco 37
bloco 40
bloco 41
bloco 44
bloco 45
par (38,42,46) par (39,43,47)
bloco 38
bloco 39
bloco 42
bloco 43
bloco 46
bloco 47
disco fsico 0
disco fsico 1
disco fsico 2
disco fsico 3

RAID 6 : uma extenso do nvel RAID 5 que utiliza blocos com cdigos
corretores de erros de Reed-Solomon, alm dos blocos de paridade.
Esta redundncia adicional permite tolerar falhas simultneas de at
dois discos.
Alm dos nveis padronizados, no mercado podem ser encontrados
produtos oferecendo outros nveis RAID, como 1+0, 0+1, 50, 100, etc., que
muitas vezes implementam combinaes dos nveis bsicos ou solues
proprietrias. Outra observao importante que os vrios nveis de RAID
no tm necessariamente uma relao hierrquica entre si, ou seja, um
sistema RAID 3 no necessariamente melhor que um sistema RAID 2.
Uma descrio mais aprofundada dos vrios nveis RAID, de suas variantes
e caractersticas pode ser encontrada em [Chen et al., 1994] e [SNIA, 2009].
c Carlos Maziero
299
7.5
7: Interfaces de rede
Interfaces de rede
network I/O (modelo em camadas)
7.6
Dispositivos USB
7.7
Interfaces de udio
captulo separado sobre E/S de multimdia (udio e vdeo, codecs)?
7.8
Interface grfica
7.9
Mouse e teclado
falar de terminal e e/s serial?
7.10
Outros tpicos
como deve ser tratada a gerncia de energia?

tratar relgio em separado?
ioctl
sistemas de arquivos /dev, /proc e /sys
major/minor numbers
gesto de mdulos: insmod, lsmod, modprobe
acesso a barramentos: lsusb, lspci, ...
Captulo 8
Segurana de sistemas
Este mdulo trata dos principais aspectos de segurana envolvidos na construo e utilizao de um sistema operacional.
Inicialmente so apresentados conceitos bsicos de segurana e criptografia; em seguida, so descritos aspectos conceituais e mecanismos
relacionados autenticao de usurios, controle de acesso a recursos
e servios, integridade e privacidade do sistema operacional, das
aplicaes e dos dados armazenados. Grande parte dos tpicos de
segurana apresentados neste captulo no so exclusivos de sistemas
operacionais, mas se aplicam a sistemas de computao em geral.
8.1
Introduo
A segurana de um sistema de computao diz respeito garantia de

algumas propriedades fundamentais associadas s informaes e recursos
presentes nesse sistema. Por informao, compreende-se todos os recursos
disponveis no sistema, como registros de bancos de dados, arquivos, reas
de memria, portas de entrada/sada, conexes de rede, configuraes,
etc.
Em Portugus, a palavra segurana abrange muitos significados
distintos e por vezes conflitantes. Em Ingls, as palavras security, safety
e reliability permitem definir mais precisamente os diversos aspectos
da segurana: a palavra security se relaciona a ameaas intencionais,
como intruses, ataques e roubo de informaes; a palavra safety se
relaciona a problemas que possam ser causados pelo sistema aos seus
c Carlos Maziero
301
8: Conceitos bsicos
usurios ou ao ambiente, como erros de programao que possam provocar

acidentes; por fim, o termo reliability usado para indicar sistemas
confiveis, construdos para tolerar erros de software, de hardware ou dos
usurios [Avizienis et al., 2004]. Neste captulo sero considerados somente
os aspectos de segurana relacionados palavra inglesa security, ou seja,
a proteo contra ameaas intencionais.
Este captulo trata dos principais aspectos de segurana envolvidos na
construo e operao de um sistema operacional. A primeira parte do
captulo apresentada conceitos bsicos de segurana, como as propriedades
e princpios de segurana, ameaas, vulnerabilidades e ataques tpicos em
sistemas operacionais, concluindo com uma descrio da infra-estrutura de
segurana tpica de um sistema operacional. A seguir, apresentada uma
introduo criptografia. Na sequncia, so descritos aspectos conceituais
e mecanismos relacionados autenticao de usurios, controle de acesso a
recursos e integridade do sistema. Tambm so apresentados os principais
conceitos relativos ao registro de dados de operao para fins de auditoria.
Grande parte dos tpicos de segurana apresentados neste captulo no
so exclusivos de sistemas operacionais, mas se aplicam a sistemas de
computao em geral.
8.2
Conceitos bsicos
Nesta seo so apresentados alguns conceitos fundamentais, importantes para o estudo da segurana de sistemas computacionais. Em particular,
so enumeradas as propriedades que caracterizam a segurana de um sistema, so definidos os principais termos em uso na rea, e so apresentados
os principais elementos que compe a arquitetura de segurana de um
sistema.
8.2.1
Propriedades e princpios de segurana
A segurana de um sistema de computao pode ser expressa atravs de

algumas propriedades fundamentais [Amoroso, 1994]:
Confidencialidade : os recursos presentes no sistema s podem ser consultados por usurios devidamente autorizados a isso;
c Carlos Maziero
302
8: Propriedades e princpios de segurana
Integridade : os recursos do sistema s podem ser modificados ou destrudos pelos usurios autorizados a efetuar tais operaes;
Disponibilidade : os recursos devem estar disponveis para os usurios
que tiverem direito de us-los, a qualquer momento.
Alm destas, outras propriedades importantes esto geralmente associadas segurana de um sistema:
Autenticidade : todas as entidades do sistema so autnticas ou genunas; em outras palavras, os dados associados a essas entidades so
verdadeiros e correspondem s informaes do mundo real que elas
representam, como as identidades dos usurios, a origem dos dados
de um arquivo, etc.;
Irretratabilidade : Todas as aes realizadas no sistema so conhecidas e
no podem ser escondidas ou negadas por seus autores; esta propriedade tambm conhecida como irrefutabilidade ou no-repudiao.
funo do sistema operacional garantir a manuteno das propriedades
de segurana para todos os recursos sob sua responsabilidade. Essas propriedades podem estar sujeitas a violaes decorrentes de erros de software
ou humanos, praticadas por indivduos mal-intencionados (maliciosos),
internos ou externos ao sistema.
Alm das tcnicas usuais de engenharia de software para a produo de sistemas corretos, a construo de sistemas computacionais seguros pautada por uma srie de princpios especficos, relativos tanto construo do sistema quanto ao comportamento dos
usurios e dos atacantes.
Alguns dos princpios mais relevantes,
compilados a partir de [Saltzer and Schroeder, 1975, Lichtenstein, 1997,
Pfleeger and Pfleeger, 2006], so indicados a seguir:
Privilgio mnimo : todos os usurios e programas devem operar com o
mnimo possvel de privilgios ou permisses de acesso. Dessa forma,
os danos provocados por erros ou aes maliciosas intencionais sero
minimizados.
Mediao completa : todos os acessos a recursos, tanto diretos quanto
indiretos, devem ser verificados pelos mecanismos de segurana. Eles
devem estar dispostos de forma a ser impossvel contorn-los.
c Carlos Maziero
303
8: Propriedades e princpios de segurana
Default seguro : o mecanismo de segurana deve identificar claramente

os acessos permitidos; caso um certo acesso no seja explicitamente
permitido, ele deve ser negado. Este princpio impede que acessos inicialmente no-previstos no projeto do sistema sejam inadvertidamente
autorizados.
Economia de mecanismo : o projeto de um sistema de proteo deve ser
pequeno e simples, para que possa ser facilmente e profundamente
analisado, testado e validado.
Separao de privilgios : sistemas de proteo baseados em mais de um
controle so mais robustos, pois se o atacante conseguir burlar um
dos controles, mesmo assim no ter acesso ao recurso. Um exemplo
tpico o uso de mais de uma forma de autenticao para acesso ao
sistema (como um carto e uma senha, nos sistemas bancrios).
Compartilhamento mnimo : mecanismos compartilhados entre usurios
so fontes potenciais de problemas de segurana, devido possibilidade de fluxos de informao imprevistos entre usurios. Por isso, o
uso de mecanismos compartilhados deve ser minimizado, sobretudo
se envolver reas de memria compartilhadas. Por exemplo, caso
uma certa funcionalidade do sistema operacional possa ser implementada como chamada ao ncleo ou como funo de biblioteca, deve-se
preferir esta ltima forma, pois envolve menos compartilhamento.
Projeto aberto : a robustez do mecanismo de proteo no deve depender
da ignorncia dos atacantes; ao invs disso, o projeto deve ser pblico
e aberto, dependendo somente do segredo de poucos itens, como
listas de senhas ou chaves criptogrficas. Um projeto aberto tambm
torna possvel a avaliao por terceiros independentes, provendo
confirmao adicional da segurana do mecanismo.
Proteo adequada : cada recurso computacional deve ter um nvel de
proteo coerente com seu valor intrnseco. Por exemplo, o nvel de
proteo requerido em um servidor Web de servios bancrio bem
distinto daquele de um terminal pblico de acesso Internet.
Facilidade de uso : o uso dos mecanismos de segurana deve ser fcil e
intuitivo, caso contrrio eles sero evitados pelos usurios.
c Carlos Maziero
304
8: Ameaas
Eficincia : os mecanismos de segurana devem ser eficientes no uso dos

recursos computacionais, de forma a no afetar significativamente o
desempenho do sistema ou as atividades de seus usurios.
Elo mais fraco : a segurana do sistema limitada pela segurana de seu
elemento mais vulnervel, seja ele o sistema operacional, as aplicaes,
a conexo de rede ou o prprio usurio.
Esses princpios devem pautar a construo, configurao e operao de
qualquer sistema computacional com requisitos de segurana. A imensa
maioria dos problemas de segurana dos sistemas atuais provm da noobservao desses princpios.
8.2.2
Ameaas
Como ameaa, pode ser considerada qualquer ao que coloque em

risco as propriedades de segurana do sistema descritas na seo anterior.
Alguns exemplos de ameaas s propriedades bsicas de segurana seriam:
Ameaas confidencialidade: um processo vasculhar as reas de memria
de outros processos, arquivos de outros usurios, trfego de rede nas
interfaces locais ou reas do ncleo do sistema, buscando dados
sensveis como nmeros de carto de crdito, senhas, e-mails privados,
etc.;
Ameaas integridade: um processo alterar as senhas de outros usurios,
instalar programas, drivers ou mdulos de ncleo maliciosos, visando
obter o controle do sistema, roubar informaes ou impedir o acesso
de outros usurios;
Ameaas disponibilidade: um usurio alocar para si todos os recursos
do sistema, como a memria, o processador ou o espao em disco,
para impedir que outros usurios possam utiliz-lo.
Obviamente, para cada ameaa possvel, devem existir estruturas no
sistema operacional que impeam sua ocorrncia, como controles de acesso
s reas de memria e arquivos, quotas de uso de memria e processador,
verificao de autenticidade de drivers e outros softwares, etc.
c Carlos Maziero
305
8: Vulnerabilidades
As ameaas podem ou no se concretizar, dependendo da existncia e da

correo dos mecanismos construdos para evit-las ou impedi-las. As ameaas podem se tornar realidade medida em que existam vulnerabilidades
que permitam sua ocorrncia.
8.2.3
Vulnerabilidades
Uma vulnerabilidade um defeito ou problema presente na especificao,

implementao, configurao ou operao de um software ou sistema, que
possa ser explorado para violar as propriedades de segurana do mesmo.
Alguns exemplos de vulnerabilidades so descritos a seguir:
um erro de programao no servio de compartilhamento de arquivos, que permita a usurios externos o acesso a outros arquivos do
computador local, alm daqueles compartilhados;
uma conta de usurio sem senha, ou com uma senha pr-definida pelo
fabricante, que permita a usurios no-autorizados acessar o sistema;
ausncia de quotas de disco, permitindo a um nico usurio alocar
todo o espao em disco para si e assim impedir os demais usurios de
usar o sistema.
A grande maioria das vulnerabilidades ocorre devido a erros de programao, como, por exemplo, no verificar a conformidade dos dados recebidos de um usurio ou da rede. Em um exemplo clssico, o processo servidor
de impresso lpd, usado em alguns UNIX, pode ser instrudo a imprimir um
arquivo e a seguir apag-lo, o que til para imprimir arquivos temporrios.
Esse processo executa com permisses administrativas pois precisa acessar
a porta de entrada/sada da impressora, o que lhe confere acesso a todos os
arquivos do sistema. Por um erro de programao, uma verso antiga do
processo lpd no verificava corretamente as permisses do usurio sobre o
arquivo a imprimir; assim, um usurio malicioso podia pedir a impresso
(e o apagamento) de arquivos do sistema. Em outro exemplo clssico, uma
verso antiga do servidor HTTP Microsoft IIS no verificava adequadamente
os pedidos dos clientes; por exemplo, um cliente que solicitasse a URL
http://www.servidor.com/../../../../windows/system.ini, receberia
como resultado o contedo do arquivo de sistema system.ini, ao invs de
ter seu pedido recusado.
c Carlos Maziero
306
8: Vulnerabilidades
Uma classe especial de vulnerabilidades decorrentes de erros de programao so os chamados estouros de buffer e de pilha (buffer/stack overflows).
Nesse erro, o programa escreve em reas de memria indevidamente, com
resultados imprevisveis, como mostra o exemplo a seguir e o resultado de
sua execuo:
#include <stdio.h>
#include <stdlib.h>
1
2
3
int i, j, buffer[20], k; // declara buffer[0] a buffer[19]
4
5
int main()
{
i = j = k = 0 ;
6
7
8
9
for (i = 0; i<= 20; i++) // usa buffer[0] a buffer[20] <-- erro!

buffer[i] = random() ;
10
11
12
printf ("i: %d\nj: %d\nk: %d\n", i, j, k) ;
13
14
return(0);
15
16
A execuo desse cdigo gera o seguinte resultado:

1
2
3
4
5
host:~> cc buffer-overflow.c -o buffer-overflow

host:~> buffer-overflow
i: 21
j: 35005211
k: 0
Pode-se observar que os valores i = 21 e k = 0 so os previstos, mas

o valor da varivel j mudou misteriosamente de 0 para 35005211. Isso
ocorreu porque, ao acessar a posio buffer[20], o programa extrapolou o
tamanho do vetor e escreveu na rea de memria sucessiva1 , que pertence
varivel j. Esse tipo de erro muito frequente em linguagens como C
e C++, que no verificam os limites de alocao das variveis durante a
1
As variveis no so alocadas na memria necessariamente na ordem em que so

declaradas no cdigo-fonte. A ordem de alocao das variveis varia com o compilador
usado e depende de vrios fatores, como a arquitetura do processador, estratgias de
otimizao de cdigo, etc.
c Carlos Maziero
307
8: Ataques
execuo. O erro de estouro de pilha similar a este, mas envolve variveis

alocadas na pilha usada para o controle de execuo de funes.
Se a rea de memria invadida pelo estouro de buffer contiver cdigo
executvel, o processo pode ter erros de execuo e ser abortado. A pior
situao ocorre quando os dados a escrever no buffer so lidos do terminal
ou recebidos atravs da rede: caso o atacante conhea a organizao da
memria do processo, ele pode escrever inserir instrues executveis na
rea de memria invadida, mudando o comportamento do processo ou
abortando-o. Caso o buffer esteja dentro do ncleo, o que ocorre em drivers e
no suporte a protocolos de rede como o TCP/IP, um estouro de buffer pode
travar o sistema ou permitir acessos indevidos a recursos. Um bom exemplo
o famoso Ping of Death [Pfleeger and Pfleeger, 2006], no qual um pacote
de rede no protocolo ICMP, com um contedo especfico, podia paralisar
computadores na rede local.
Alm dos estouros de buffer e pilha, h uma srie de outros erros de programao e de configurao que podem constituir vulnerabilidades, como
o uso descuidado das strings de formatao de operaes de entrada/sada
em linguagens como C e C++ e condies de disputa na manipulao de
arquivos compartilhados. Uma explicao mais detalhada desses erros e de
suas implicaes pode ser encontrada em [Pfleeger and Pfleeger, 2006].
8.2.4
Ataques
Um ataque o ato de utilizar (ou explorar) uma vulnerabilidade

para violar uma propriedade de segurana do sistema. De acordo com
[Pfleeger and Pfleeger, 2006], existem basicamente quatro tipos de ataques,
representados na Figura 8.1:
Interrupo : consiste em impedir o fluxo normal das informaes ou
acessos; um ataque disponibilidade do sistema;
Interceptao : consiste em obter acesso indevido a um fluxo de informaes, sem necessariamente modific-las; um ataque confidencialidade;
Modificao : consiste em modificar de forma indevida informaes ou
partes do sistema, violando sua integridade;
Fabricao : consiste em produzir informaes falsas ou introduzir mdulos
ou componentes maliciosos no sistema; um ataque autenticidade.
c Carlos Maziero
308
8: Ataques
interceptao
interrupo
fonte
fonte
destino
atacante
atacante
fabricao
modificao
fonte
destino
fonte
destino
atacante
atacante
Figura
8.1:
Tipos
bsicos
[Pfleeger and Pfleeger, 2006]).
destino
de
ataques
(inspirado
em
Existem ataques passivos, que visam capturar informaes confidenciais, e ataques ativos, que visam introduzir modificaes no sistema para
beneficiar o atacante ou impedir seu uso pelos usurios vlidos. Alm disso,
os ataques a um sistema operacional podem ser locais, quando executados
por usurios vlidos do sistema, ou remotos, quando so realizados atravs
da rede, sem fazer uso de uma conta de usurio local. Um programa
especialmente construdo para explorar uma determinada vulnerabilidade
de sistema e realizar um ataque denominado exploit.
A maioria dos ataques a sistemas operacionais visa aumentar o poder
do atacante dentro do sistema, o que denominado elevao de privilgios
(privilege escalation). Esses ataques geralmente exploram vulnerabilidades
em programas do sistema (que executam com mais privilgios), ou do
prprio ncleo, atravs de chamadas de sistema, para receber os privilgios
do administrador.
Por outro lado, os ataques de negao de servios (DoS Denial of Service)
visam prejudicar a disponibilidade do sistema, impedindo que os usurios
vlidos do sistema possam utiliz-lo, ou seja, que o sistema execute suas
funes. Esse tipo de ataque muito comum em ambientes de rede, com
a inteno de impedir o acesso a servidores Web, DNS e de e-mail. Em
c Carlos Maziero
309
8: Ataques
um sistema operacional, ataques de negao de servio podem ser feitos

com o objetivo de consumir todos os recursos locais, como processador,
memria, arquivos abertos, sockets de rede ou semforos, dificultando ou
mesmo impedindo o uso desses recursos pelos demais usurios.
O antigo ataque fork bomb dos sistemas UNIX um exemplo trivial de
ataque DoS local: ao executar, o processo atacante se reproduz rapidamente,
usando a chamada de sistema fork (vide cdigo a seguir). Cada processo
filho continua executando o mesmo cdigo do processo pai, criando novos
processos filhos, e assim sucessivamente. Em consequncia, a tabela de
processos do sistema rapidamente preenchida, impedindo a criao de
processos pelos demais usurios. Alm disso, o grande nmero de processos
solicitando chamadas de sistema mantm o ncleo ocupado, impedindo os
a execuo dos demais processos.
1
#include <unistd.h>
2
3
4
5
6
7
int main()
{
while (1)
fork() ;
}
// lao infinito
// reproduz o processo
Ataques similares ao fork bomb podem ser construdos para outros

recursos do sistema operacional, como memria, descritores de arquivos
abertos, sockets de rede e espao em disco. Cabe ao sistema operacional impor
limites mximos (quotas) de uso de recursos para cada usurio e definir
mecanismos para detectar e conter processos excessivamente gulosos.
Recentemente tm ganho ateno os ataques confidencialidade, que
visam roubar informaes sigilosas dos usurios. Com o aumento do uso
da Internet para operaes financeiras, como acesso a sistemas bancrios e
servios de compras online, o sistema operacional e os navegadores manipulam informaes sensveis, como nmeros de cartes de crdito, senhas
de acesso a contas bancrias e outras informaes pessoais. Programas
construdos com a finalidade especfica de realizar esse tipo de ataque so
denominados spyware.
Deve ficar clara a distino entre ataques e incidentes de segurana. Um
incidente de segurana qualquer fato intencional ou acidental que comprometa uma das propriedades de segurana do sistema. A intruso de um
sistema ou um ataque de negao de servios so considerados incidentes de
segurana, assim como o vazamento acidental de informaes confidenciais.
c Carlos Maziero
310
8.2.5
8: Malwares
Malwares
Denomina-se genericamente malware todo programa cuja inteno

realizar atividades ilcitas, como realizar ataques, roubar informaes
ou dissimular a presena de intrusos em um sistema. Existe uma
grande diversidade de malwares, destinados s mais diversas finalidades
[Shirey, 2000, Pfleeger and Pfleeger, 2006], como:
Vrus : um vrus de computador um trecho de cdigo que se infiltra em
programas executveis existentes no sistema operacional, usando-os
como suporte para sua execuo e replicao2 . Quando um programa
infectado executado, o vrus tambm se executa, infectando outros
executveis e eventualmente executando outras aes danosas. Alguns tipos de vrus so programados usando macros de aplicaes
complexas, como editores de texto, e usam os arquivos de dados
dessas aplicaes como suporte. Outros tipos de vrus usam o cdigo
de inicializao dos discos e outras mdias como suporte de execuo.
Worm : ao contrrio de um vrus, um verme um programa autnomo,
que se propaga sem infectar outros programas. A maioria dos vermes
se propaga explorando vulnerabilidades nos servios de rede, que os
permitam invadir e instalar-se em sistemas remotos. Alguns vermes
usam o sistema de e-mail como vetor de propagao, enquanto outros
usam mecanismos de auto-execuo de mdias removveis (como
pendrives) como mecanismo de propagao. Uma vez instalado em um
sistema, o verme pode instalar spywares ou outros programas nocivos.
Trojan horse : de forma anloga ao personagem da mitologia grega, um
cavalo de Tria computacional um programa com duas funcionalidades: uma funcionalidade lcita conhecida de seu usurio e outra
ilcita, executada sem que o usurio a perceba. Muitos cavalos de Tria
so usados como vetores para a instalao de outros malwares. Um
exemplo clssico o famoso Happy New Year 99, distribudo atravs de
e-mails, que usava uma animao de fogos de artifcio como fachada
para a propagao de um verme. Para convencer o usurio a executar o cavalo de Tria podem ser usadas tcnicas de engenharia social
[Mitnick and Simon, 2002].
2
De forma anloga, um vrus biolgico precisa de uma clula hospedeira, pois usa o
material celular como suporte para sua existncia e replicao.
c Carlos Maziero
311
8: Malwares
Exploit : um programa escrito para explorar vulnerabilidades conhecidas,

como prova de conceito ou como parte de um ataque. Os exploits
podem estar incorporados a outros malwares (como vermes e trojans)
ou constiturem ferramentas autnomas, usadas em ataques manuais.
Packet sniffer : um farejador de pacotes captura pacotes de rede do
prprio computador ou da rede local, analisando-os em busca de
informaes sensveis como senhas e dados bancrios. A criptografia
(Seo 8.3) resolve parcialmente esse problema, embora um sniffer na
mquina local possa capturar os dados antes que sejam cifrados, ou
depois de decifrados.
Keylogger : software dedicado a capturar e analisar as informaes digitadas pelo usurio na mquina local, sem seu conhecimento. Essas
informaes podem ser transferidas a um computador remoto periodicamente ou em tempo real, atravs da rede.
Rootkit : um conjunto de programas destinado a ocultar a presena de
um intruso no sistema operacional. Como princpio de funcionamento,
o rootkit modifica os mecanismos do sistema operacional que mostram
os processos em execuo, arquivos nos discos, portas e conexes de
rede, etc., para ocultar o intruso. Os rootkits mais simples substituem
utilitrios do sistema, como ps (lista de processos), ls (arquivos),
netstat (conexes de rede) e outros, por verses adulteradas que
no mostrem os arquivos, processos e conexes de rede do intruso.
Verses mais elaboradas de rootkits substituem bibliotecas do sistema
operacional ou modificam partes do prprio ncleo, o que torna
complexa sua deteco e remoo.
Backdoor : uma porta dos fundos um programa que facilita a entrada
posterior do atacante em um sistema j invadido. Geralmente a porta
dos fundos criada atravs um processo servidor de conexes remotas
(usando SSH, telnet ou um protocolo ad-hoc). Muitos backdoors so
instalados a partir de trojans, vermes ou rootkits.
Deve-se ter em mente que h na mdia e na literatura muita confuso em
relao nomenclatura de malwares; alm disso, muitos malwares tm vrias
funcionalidades e se encaixam em mais de uma categoria. Esta seo teve
como objetivo dar uma definio tecnicamente precisa de cada categoria,
sem a preocupao de mapear os exemplos reais nessas categorias.
c Carlos Maziero
312
8.2.6
8: Infraestrutura de segurana
Infraestrutura de segurana
De forma genrica, o conjunto de todos os elementos de hardware e

software considerados crticos para a segurana de um sistema so denominados Base Computacional Confivel (TCB Trusted Computing Base)
ou ncleo de segurana (security kernel). Fazem parte da TCB todos os
elementos do sistema cuja falha possa representar um risco sua segurana.
Os elementos tpicos de uma base de computao confivel incluem os
mecanismos de proteo do hardware (tabelas de pginas/segmentos, modo
usurio/ncleo do processador, instrues privilegiadas, etc.) e os diversos
subsistemas do sistema operacional que visam garantir as propriedades
bsicas de segurana, como o controle de acesso aos arquivos, acesso s
portas de rede, etc.
O sistema operacional emprega vrias tcnicas complementares para
garantir a segurana de um sistema operacional. Essas tcnicas esto
classificadas nas seguintes grandes reas:
Autenticao : conjunto de tcnicas usadas para identificar inequivocamente usurios e recursos em um sistema; podem ir de simples pares
login/senha at esquemas sofisticados de biometria ou certificados criptogrficos. No processo bsico de autenticao, um usurio externo se
identifica para o sistema atravs de um procedimento de autenticao;
no caso da autenticao ser bem sucedida, aberta uma sesso, na qual
so criados uma ou mais entidades (processos, threads, transaes, etc.)
para representar aquele usurio dentro do sistema.
Controle de acesso : tcnicas usadas para definir quais aes so permitidas
e quais so negadas no sistema; para cada usurio do sistema, devem
ser definidas regras descrevendo as aes que este pode realizar no
sistema, ou seja, que recursos este pode acessar e sob que condies.
Normalmente, essas regras so definidas atravs de uma poltica de
controle de acesso, que imposta a todos os acessos que os usurios
efetuam sobre os recursos do sistema.
Auditoria : tcnicas usadas para manter um registro das atividades efetuadas no sistema, visando a contabilizao de uso dos recursos, a
anlise posterior de situaes de uso indevido ou a identificao de
comportamento suspeitos.
c Carlos Maziero
313
8: Infraestrutura de segurana
A Figura 8.2 ilustra alguns dos conceitos vistos at agora. Nessa figura, as
partes indicadas em cinza e os mecanismos utilizados para implement-las
constituem a base de computao confivel do sistema.
auditoria
auditoria
evento
humanos
autenticao
sistemas
externos
usurios
dados de
auditoria
evento
processos
threads
transaes
controle
de acesso
dados de
autenticao
polticas
de controle
de acesso
autenticao
controle de acesso
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
arquivos
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
outros
sujeitos
ou
sistemas
registros
recursos
Figura 8.2: Base de computao confivel de um sistema operacional.

Sob uma tica mais ampla, a base de computao confivel de um sistema
informtico compreende muitos fatores alm do sistema operacional em si.
A manuteno das propriedades de segurana depende do funcionamento
correto de todos os elementos do sistema, do hardware ao usurio final.
O hardware fornece vrias funcionalidades essenciais para a proteo
do sistema: os mecanismos de memria virtual permitem isolar o ncleo
e os processos entre si; o mecanismo de interrupo de software prov
uma interface controlada de acesso ao ncleo; os nveis de execuo do
processador permitem restringir as instrues e as portas de entrada sada
acessveis aos diversos softwares que compem o sistema; alm disso, muitos
tipos de hardware permitem impedir operaes de escrita ou execuo de
cdigo em certas reas de memria.
No nvel do sistema operacional surgem os processos isolados entre si,
as contas de usurios, os mecanismos de autenticao e controle de acesso
e os registros de auditoria. Em paralelo com o sistema operacional esto
os utilitrios de segurana, como anti-vrus, verificadores de integridade,
detectores de intruso, entre outros.
c Carlos Maziero
314
8: Fundamentos de criptografia
As linguagens de programao tambm desempenham um papel importante nesse contexto, pois muitos problemas de segurana tm origem em
erros de programao. O controle estrito de ndices em vetores, a restrio
do uso de ponteiros e a limitao de escopo de nomes para variveis e
funes so exemplos de aspectos importantes para a segurana de um
programa. Por fim, as aplicaes tambm tm responsabilidade em relao
segurana, no sentido de ter implementaes corretas e validar todos
os dados manipulados. Isso particularmente importante em aplicaes
multi-usurios (como sistemas corporativos e sistemas Web) e processos
privilegiados que recebam requisies de usurios ou da rede (servidores
de impresso, de DNS, etc.).
8.3
Fundamentos de criptografia
As tcnicas criptogrficas so extensivamente usadas na segurana de

sistemas, para garantir a confidencialidade e integridade dos dados. Alm
disso, elas desempenham um papel importante na autenticao de usurios e
recursos. O termo criptografia provm das palavras gregas kryptos (oculto,
secreto) e graphos (escrever). Assim, a criptografia foi criada para codificar
informaes, de forma que somente as pessoas autorizadas pudessem ter
acesso ao seu contedo.
Alguns conceitos fundamentais para compreender as tcnicas criptogrficas so: o texto aberto, que a mensagem ou informao a ocultar; o texto
cifrado, que a informao codificada; o cifrador, mecanismo responsvel
por cifrar/decifrar as informaes, e as chaves, necessrias para poder cifrar
ou decifrar as informaes [Menezes et al., 1996].
8.3.1
Cifragem e decifragem
Uma das mais antigas tcnicas criptogrficas conhecidas o cifrador de

Csar, usado pelo imperador romano Jlio Csar para se comunicar com seus
generais. O algoritmo usado nesse cifrador bem simples: cada caractere
do texto aberto substitudo pelo k-simo caractere sucessivo no alfabeto.
Assim, considerando k = 2, a letra A seria substituda pela letra C, a
letra R pela T, e assim por diante. Usando esse algoritmo, a mensagem
secreta Reunir todos os generais para o ataque seria cifrada da seguinte
forma:
c Carlos Maziero
315
mensagem aberta:
mensagem cifrada com k = 1:
8: Criptografia simtrica e assimtrica
Reunir
Sfvojs
Tgwpkt
Uhxqlu
todos
upept
vqfqu
wrgrv
os
pt
qu
rv
generais
hfofsbjt
igpgtcku
jhqhudlv
para
qbsb
rctc
sdud
o
p
q
r
ataque
bubrvf
cvcswg
dwdtxh
Para decifrar uma mensagem no cifrador de Csar, necessrio conhecer

a mensagem cifrada e o valor de k utilizado para cifrar a mensagem, que
denominado chave criptogrfica. Caso essa chave no seja conhecida,
possvel tentar quebrar a mensagem cifrada testando todas as chaves
possveis, o que conhecido como anlise exaustiva ou de fora bruta.
No caso do cifrador de Csar a anlise exaustiva trivial, pois h somente
26 valores possveis para a chave k.
O nmero de chaves possveis para um algoritmo de cifragem conhecido como o seu espao de chaves. De acordo com princpios enunciados
pelo criptgrafo Auguste Kerckhoffs em 1883, o segredo de uma tcnica
criptogrfica no deve residir no algoritmo em si, mas no espao de chaves
que ele prov. Seguindo esses princpios, a criptografia moderna se baseia
em algoritmos pblicos, bem avaliados pela comunidade cientfica, para
os quais o espao de chaves muito grande, tornando invivel qualquer
anlise exaustiva. Por exemplo, o algoritmo de criptografia AES (Advanced
Encryption Standard) adotado como padro pelo governo americano, usando
chaves de 128 bits, oferece um espao de chaves com 2128 possibilidades,
ou seja, 340.282.366.920.938.463.463.374.607.431.768.211.456 chaves diferentes... Se pudssemos analisar um bilho de chaves por segundo, ainda
assim seriam necessrios 10 sextilhes de anos para testar todas as chaves
possveis!
No restante do texto, a operao de cifragem de um contedo x usando
uma chave k ser representada por {x}k e a decifragem de um contedo x
usando uma chave k ser representada por {x}1
.
k
8.3.2
Criptografia simtrica e assimtrica
De acordo com o tipo de chave utilizada, os algoritmos de criptografia

se dividem em dois grandes grupos: algoritmos simtricos e algoritmos
assimtricos. Nos algoritmos simtricos, a mesma chave k usada para cifrar
a informao deve ser usada para decifr-la. Essa propriedade pode ser
expressa em termos matemticos:
c Carlos Maziero
316
0
{ { x }k }1
k0 = x k = k
O cifrador de Csar um exemplo tpico de cifrador simtrico: se

usarmos k = 2 para cifrar um texto, teremos de usar k = 2 para decifr-lo.
Os algoritmos simtricos mais conhecidos e usados atualmente so o DES
(Data Encryption Standard) e o AES (Advanced Encryption Standard).
Os algoritmos simtricos so muito teis para a cifragem de dados
em um sistema local, como documentos ou arquivos em um disco rgido.
Todavia, se a informao cifrada tiver de ser enviada a outro usurio, a chave
criptogrfica usada ter de ser informada a ele de alguma forma segura (de
forma a preservar seu segredo). A Figura 8.3 ilustra o funcionamento bsico
de um sistema de criptografia simtrica.
texto aberto
texto aberto
Ille nihil dubitat qui

nullam scientiam habet
(Nada duvida quem nada sabe)

texto cifrado
cifrar
chave secreta
6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
ca974d8cc5d986b6c48fba534eab
2eb4d39273910b72c869c54521c1
c5df85cb3a37d2aaa6f19b560ead
a9eb92c5e8e95
a chave secreta transferida

atravs de um meio seguro
decifrar
chave secreta
Figura 8.3: Criptografia simtrica.

Por outro lado, os algoritmos assimtricos se caracterizam pelo uso
de um par de chaves complementares: uma chave pblica kp e uma chave
privada kv. Uma informao cifrada com uso de uma chave pblica s
poder ser decifrada atravs da chave privada correspondente, e vice-versa.
Considerando um usurio u com suas chaves pblica kp(u) e privada kv(u),
temos:
c Carlos Maziero
317
{ { x }kp(u) }1
= x k = kv(u)
k
{ { x }kv(u) }1
= x k = kp(u)
k
Essas duas chaves esto fortemente relacionadas: para cada chave pblica
h uma nica chave privada correspondente, e vice-versa. Todavia, no
possvel calcular uma das chaves a partir da outra. Como o prprio nome
diz, geralmente as chaves pblicas so amplamente conhecidas e divulgadas
(por exemplo, em uma pgina Web ou um repositrio de chaves pblicas),
enquanto as chaves privadas correspondentes so mantidas em segredo por
seus proprietrios. Alguns algoritmos assimtricos bem conhecidos so o
RSA (Rivest-Shamir-Adleman) e o algoritmo de Diffie-Hellman. A Figura 8.4
ilustra o funcionamento da criptografia assimtrica.
texto aberto
texto aberto


texto cifrado
cifrar
chave pblica
6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
2eb4d39273910b72c869c54521c1
a9eb92c5e8e95
decifrar
chave privada
Figura 8.4: Criptografia assimtrica.

Um exemplo de uso da criptografia assimtrica mostrado na Figura
8.5. Nele, a usuria Alice deseja enviar um documento cifrado ao usurio
Beto3 . Para tal, Alice busca a chave pblica de Beto previamente divulgada
3
Textos em ingls habitualmente usam os nomes Alice, Bob, Carol e Dave para explicar
algoritmos e protocolos criptogrficos, em substituio s letras A, B, C e D. Neste texto
usaremos a mesma abordagem, mas com nomes em portugus.
c Carlos Maziero
318
em um chaveiro pblico (que pode ser um servidor Web, por exemplo) e a

usa para cifrar o documento que ser enviado a Beto. Somente Beto poder
decifrar esse documento, pois s ele possui a chave privada correspondente
chave pblica usada para cifr-lo. Outros usurios podero at ter acesso
ao documento cifrado, mas no conseguiro decifr-lo.
texto cifrado
Alice
texto aberto
3: cifrar
6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
2eb4d39273910b72c869c54521c1
a9eb92c5e8e95
4: envio do texto cifrado
Beto
texto aberto
5: decifrar
chave pblica chave privada
2: Alice obtm a chave

pblica de Beto
Chaveiro pblico
Alice
1: Beto divulga
sua chave pblica
Beto Carol Davi
Figura 8.5: Exemplo de uso da criptografia assimtrica.

A criptografia assimtrica tambm pode ser usada para identificar a
autoria de um documento. Por exemplo, se Alice criar um documento
e cifr-lo com sua chave privada, qualquer usurio que tiver acesso ao
documento poder decifr-lo e l-lo, pois a chave pblica de Alice est
publicamente acessvel. Todavia, o fato do documento poder ser decifrado
usando a chave pblica de Alice significa que ela a autora legtima do
mesmo, pois s ela teria acesso chave privada que foi usada para cifr-lo.
Esse mecanismo usado na criao das assinaturas digitais (Seo 8.3.4).
Embora mais versteis, os algoritmos de cifragem assimtricos costumam
exigir muito mais processamento que os algoritmos simtricos equivalentes.
Por isso, muitas vezes ambos so usados em associao. Por exemplo, os
protocolos de rede seguros baseados em TLS (Transport Layer Security), como
o SSH e HTTPS, usam criptografia assimtrica somente durante o incio
de cada conexo, para negociar uma chave simtrica comum entre os dois
c Carlos Maziero
319
8: Resumo criptogrfico
computadores que se comunicam. Essa chave simtrica, chamada chave de

sesso, ento usada para cifrar/decifrar os dados trocados entre os dois
computadores durante aquela conexo, sendo descartada quando a sesso
encerra.
8.3.3
Resumo criptogrfico
Um resumo criptogrfico (cryptographic hash) [Menezes et al., 1996] uma

funo que gera uma sequncia de bytes de tamanho pequeno e fixo
(algumas dezenas ou centenas de bytes) a partir de um conjunto de dados
de tamanho varivel aplicado como entrada. Os resumos criptogrficos so
frequentemente usados para identificar unicamente um arquivo ou outra
informao digital, ou para atestar sua integridade: caso o contedo de um
documento digital seja modificado, seu resumo tambm ser alterado.
Em termos matemticos, os resumos criptogrficos so um tipo de funo
unidirecional (one-way function). Uma funo f (x) chamada unidirecional
quando seu clculo direto (y = f (x)) simples, mas o clculo de sua inversa
(x = f 1 (y)) impossvel ou invivel em termos computacionais. Um
exemplo clssico de funo unidirecional a fatorao do produto de dois
nmeros primos grandes: considere a funo f (p, q) = p q, onde p e q so
inteiros primos. Calcular y = f (p, q) simples e rpido, mesmo se p e q
forem grandes; entretanto, fatorizar y para obter de volta os primos p e q
pode ser computacionalmente invivel, se y tiver muitos dgitos4 .
Idealmente, uma funo de resumo criptogrfico deve gerar sempre
a mesma sada para a mesma entrada, e sadas diferentes para entradas
diferentes. No entanto, como o nmero de bytes do resumo pequeno,
podem ocorrer colises. Uma coliso ocorre quando duas entradas distintas
x e x0 geram o mesmo valor de resumo (hash(x) = hash(x0 ) para x , x0 ).
Obviamente, bons algoritmos de resumo buscam minimizar essa possibilidade. Outras propriedades desejveis dos resumos criptogrficos so o
espalhamento, em que uma modificao em um trecho especfico dos dados
de entrada gera modificaes em partes diversas do resumo, e a sensibilidade,
em que uma pequena modificao nos dados de entrada pode gerar grandes
mudanas no resumo.
Os algoritmos de resumo criptogrfico mais conhecidos e utilizados
atualmente so o MD5 e o SHA1 [Menezes et al., 1996]. No Linux, os
4
Em 2005, um grupo de pesquisadores alemes fatorizou um inteiro com 200 dgitos,

usando 80 processadores Opteron calculando durante mais de de cinco meses.
c Carlos Maziero
320
8: Assinatura digital
comandos md5sum e sha1sum permitem calcular respectivamente os resumos

MD5 e SHA1 de arquivos comuns:
1
2
3
4
5
maziero:~> md5sum *
62ec3f9ff87f4409925a582120a40131
0920785a312bd88668930f761de740bf
45acbba4b57317f3395c011fbd43d68d
6c332adb037265a2019077e09a024d0c
header.tex
main.pdf
main.tex
main.tex~
6
7
8
9
10
11
maziero:~> sha1sum *
742c437692369ace4bf0661a8fe5741f03ecb31a
9f9f52f48b75fd2f12fa297bdd5e1b13769a3139
d6973a71e5c30d0c05d762e9bc26bb073d377a0b
cf1670f22910da3b9abf06821e44b4ad7efb5460
8.3.4
header.tex
main.pdf
main.tex
main.tex~
Assinatura digital
Os mecanismos de criptografia assimtrica e resumos criptogrficos

previamente apresentados permitem efetuar a assinatura digital de documentos eletrnicos. A assinatura digital uma forma de verificar a autoria
e integridade de um documento, sendo por isso o mecanismo bsico utilizado na construo dos certificados digitais, amplamente empregados para a
autenticao de servidores na Internet.
Em termos gerais, a assinatura digital de um documento um resumo
digital do mesmo, cifrado usando a chave privada de seu autor (ou de quem
o est assinando). Sendo um documento d emitido pelo usurio u, sua
assinatura digital s(d, u) definida por
s(d, u) = {hash(d)}kv(u)
onde hash(x) uma funo de resumo criptogrfico conhecida, {x}k indica a
cifragem de x usando uma chave k e kv(u) a chave privada do usurio u.
Para verificar a validade da assinatura, basta calcular novamente o resumo
r0 = hash(d) e compar-lo com o resumo obtido da assinatura, decifrada
usando a chave pblica de u (r00 = {s}1
). Se ambos forem iguais (r0 = r00 ),
kp(u)
o documento foi realmente assinado por u e est ntegro, ou seja, no foi
modificado desde que u o assinou [Menezes et al., 1996].
A Figura 8.6 ilustra o processo de assinatura digital e verificao de um
documento. Os passos do processo so:
c Carlos Maziero
321
8: Certificado de chave pblica
1. Alice divulga sua chave pblica kpa em um repositrio acessvel

publicamente;
2. Alice calcula o resumo digital r do documento d a ser assinado;
3. Alice cifra o resumo r usando sua chave privada kva , obtendo uma
assinatura digital s;
4. A assinatura s e o documento original d, em conjunto, constituem o
documento assinado por Alice: [d, s];
5. Beto obtm o documento assinado por Alice ([d0 , s0 ], com d0 = d e s0 = s
se ambos estiverem ntegros);
6. Beto recalcula o resumo digital r0 = hash(d0 ) do documento, usando o
mesmo algoritmo empregado por Alice;
7. Beto obtm a chave pblica kpa de Alice e a usa para decifrar a
assinatura s0 do documento, obtendo um resumo r00 (r00 = r se s foi
realmente cifrado com a chave kva e se s0 = s) ;
8. Beto compara o resumo r0 do documento com o resumo r00 obtido da
assinatura digital; se ambos forem iguais (r0 = r00 ), o documento foi
assinado por Alice e est ntegro, assim como sua assinatura.
8.3.5
Certificado de chave pblica
A identificao confivel do proprietrio de uma chave pblica fundamental para o funcionamento correto das tcnicas de criptografia assimtrica e de assinatura digital. Uma chave pblica composta por uma
mera sequncia de bytes que no permite a identificao direta de seu
proprietrio. Por isso, torna-se necessria uma estrutura complementar
para fazer essa identificao. A associao entre chaves pblicas e seus
respectivos proprietrios realizada atravs dos certificados digitais. Um
certificado digital um documento digital assinado, composto das seguintes
partes [Menezes et al., 1996]:
A chave pblica do proprietrio do certificado;
c Carlos Maziero
322
Ille nihil
dubitat qui
nullam
scientiam
habet
(Nada duvida
quem
nada sabe)
Ille nihil
dubitat qui
nullam
scientiam
habet
(Nada duvida
quem
nada sabe)
d'
hash
3423a2e67ba6fc
5b432c2d9f0588
4aef7f7362a74d
hash
6fce39f0908827
ca54cdf5889068
7f734aef674d2a
6fce39f0908827
ca54cdf5889068
7f734aef674d2a
documento
assinado
por Alice
resumo
s
r'=r'' ?
r'
sim
assinatura
vlida
s'
6fce39f0908827
ca54cdf5889068
7f734aef674d2a
r''
cifrar
Alice
chave
privada
chave
pblica
decifrar
Chaveiro pblico
chave pblica de Alice

Alice
Beto Carol Davi
Figura 8.6: Assinatura e verificao de uma assinatura digital.

Identidade do proprietrio do certificado (nome, endereo, e-mail,
URL, nmero IP e/ou outras informaes que permitam identific-lo
unicamente)5 ;
Outras informaes, como perodo de validade do certificado, algoritmos de criptografia e resumos preferidos ou suportados, etc.;
Uma ou mais assinaturas digitais do contedo, emitidas por entidades
consideradas confiveis pelos usurios dos certificados.
Dessa forma, um certificado digital amarra uma identidade a uma
chave pblica. Para verificar a validade de um certificado, basta usar as
chaves pblicas das entidades que o assinaram. Existem vrios tipos de
certificados digitais com seus formatos e contedos prprios, sendo os
certificados PGP e X.509 aqueles mais difundidos [Mollin, 2000].
5
Deve-se ressaltar que um certificado pode pertencer a um usurio humano, a um

sistema computacional ou qualquer mdulo de software que precise ser identificado de
forma inequvoca.
c Carlos Maziero
323
Todo certificado deve ser assinado por alguma entidade considerada

confivel pelos usurios do sistema. Essas entidades so normalmente
denominadas Autoridades Certificadoras (AC ou CA Certification Authorities).
Como as chaves pblicas das ACs devem ser usadas para verificar a validade de um certificado, surge um problema: como garantir que uma chave
pblica realmente pertence a uma dada autoridade certificadora? A soluo
simples: basta criar um certificado para essa AC, assinado por outra AC
ainda mais confivel. Dessa forma, pode-se construir uma estrutura hierrquica de certificao, na qual a AC de ordem mais elevada (denominada
AC raiz) assina os certificados de outras ACs, e assim sucessivamente, at
chegar aos certificados dos usurios e demais entidades do sistema, como
mostra o exemplo da Figura 8.7. Uma estrutura de certificao se chama
Infra-estrutura de Chaves Pblicas (ICP ou PKI - Public-Key Infrastructure). Em
uma ICP convencional (hierrquica), a chave pblica da AC raiz deve ser
conhecida de todos e considerada ntegra [Mollin, 2000].
chave pblica
AC raiz
identificao
d s lj k l s
assinatura
29-05-2009
lsd jsfhd
dfh kds
ks
lk
d sk
f dsjh
ACs
secundrias
dfh kds
ks
f dsjh
f dsjh
k
d sk
f dsjh
d sk
f dsjh
dfh kds
ks
dfh kds
ks
d sk
dfh kds
ks
lsd jsfhd
lsd jsfhd
lsd jsfhd
dfh kds
ks
d s lj k l s
d
lk
29-05-2009
d sk
d s lj k l s
29-05-2009
lsd jsfhd
lk
d s lj k l s
29-05-2009
lk
d sk
f dsjh
lsd jsfhd
dfh kds
ks
d s lj k l s
d
lsd jsfhd
d s lj k l s
d
lk
29-05-2009
lk
29-05-2009
d s lj k l s
d
lk
29-05-2009
d sk
f dsjh
Figura 8.7: Infra-estrutura de chaves pblicas hierrquica.
c Carlos Maziero
324
8.4
8: Autenticao
Autenticao
O objetivo da autenticao consiste em identificar as diversas entidades

de um sistema computacional. Atravs da autenticao, o usurio interessado em acessar o sistema comprova que ele/a realmente quem afirma
ser. Para tal podem ser usadas vrias tcnicas, sendo as mais relevantes
apresentadas nesta seo.
Inicialmente, a autenticao visava apenas identificar usurios, para
garantir que somente usurios devidamente credenciados teriam acesso
ao sistema. Atualmente, em muitas circunstncias tambm necessrio o
oposto, ou seja, identificar o sistema para o usurio, ou mesmo sistemas
entre si. Por exemplo, quando um usurio acessa um servio bancrio via
Internet, deseja ter certeza de que o sistema acessado realmente aquele do
banco desejado, e no um sistema falso, construdo para roubar seus dados
bancrios. Outro exemplo ocorre durante a instalao de componentes
de software como drivers: o sistema operacional deve assegurar-se que o
software a ser instalado provm de uma fonte confivel e no foi corrompido
por algum contedo malicioso.
8.4.1
Usurios e grupos
A autenticao geralmente o primeiro passo no acesso de um usurio

a um sistema computacional. Caso a autenticao do usurio tenha sucesso,
so criados processos para represent-lo dentro do sistema. Esses processos
interagem com o usurio atravs da interface e executam as aes desejadas
por ele dentro do sistema, ou seja, agem em nome do usurio. A presena de
um ou mais processos agindo em nome de um usurio dentro do sistema
denominada uma sesso de usurio (user session ou working session). A sesso
de usurio inicia imediatamente aps a autenticao do usurio (login ou
logon) e termina quando seu ltimo processo encerrado, na desconexo
(logout ou logoff ). Um sistema operacional servidor ou desktop tpico suporta
vrias sesses de usurios simultaneamente.
A fim de permitir a implementao das tcnicas de controle de acesso e
auditoria, cada processo deve ser associado a seu respectivo usurio atravs
de um identificador de usurio (UID - User IDentifier), geralmente um nmero
inteiro usado como chave em uma tabela de usurios cadastrados (como
o arquivo /etc/passwd dos sistemas UNIX). O identificador de usurio
usado pelo sistema operacional para definir o proprietrio de cada entidade
c Carlos Maziero
325
8: Tcnicas de autenticao
e recurso conhecido: processo, arquivo, rea de memria, semforo, etc.

habitual tambm classificar os usurios em grupos, como professores, alunos,
contabilidade, engenharia, etc. Cada grupo identificado atravs de um
identificador de grupo (GID - Group IDentifier). A organizao dos grupos de
usurios pode ser hierrquica ou arbitrria. O conjunto de informaes que
relaciona um processo ao seu usurio e grupo geralmente denominado
credenciais do processo.
Normalmente, somente usurios devidamente autenticados podem ter
acesso aos recursos de um sistema. Todavia, alguns recursos podem estar
disponveis abertamente, como o caso de pastas de arquivos pblicas em
rede e pginas em um servidor Web pblico. Nestes casos, assume-se a
existncia de um usurio fictcio convidado (guest, nobody, anonymous ou
outros), ao qual so associados todos os acessos externos no-autenticados
e para o qual so definidas polticas de segurana especficas.
8.4.2
Tcnicas de autenticao
As tcnicas usadas para a autenticao de um usurio podem ser classificadas em trs grandes grupos:
SYK Something You Know (algo que voc sabe): estas tcnicas de
autenticao so baseadas em informaes conhecidas pelo usurio,
como seu nome de login e sua senha. So consideradas tcnicas de
autenticao fracas, pois a informao necessria para a autenticao
pode ser facilmente comunicada a outras pessoas, ou mesmo roubada.
SYH Something You Have (algo que voc tem): so tcnicas que se
baseiam na posse de alguma informao mais complexa, como um
certificado digital ou uma chave criptogrfica, ou algum dispositivo
material, como um smartcard, um carto magntico, um cdigo de
barras, etc. Embora sejam mais robustas que as tcnicas SYK, estas
tcnicas tambm tm seus pontos fracos, pois dispositivos materiais,
como cartes, tambm podem ser roubados ou copiados.
SYA Something You Are (algo que voc ): se baseiam em caractersticas intrinsecamente associadas ao usurio, como seus dados biomtricos: impresso digital, padro da ris, timbre de voz, etc. So
tcnicas mais complexas de implementar, mas so potencialmente
mais robustas que as anteriores.
c Carlos Maziero
326
8: Senhas
Muitos sistemas implementam somente a autenticao por login/senha

(SYK). Sistemas mais recentes tm suporte a tcnicas SYH atravs de smartcards ou a tcnicas SYA usando biometria, como os sensores de impresso
digital. Alguns servios de rede, como HTTP e SSH, tambm podem usar
autenticao pelo endereo IP do cliente (SYA) ou atravs de certificados
digitais (SYH).
Sistemas computacionais com fortes requisitos de segurana geralmente
implementam mais de uma tcnica de autenticao, o que chamado de
autenticao multi-fator. Por exemplo, um sistema militar pode exigir senha e
reconhecimento de ris para o acesso de seus usurios, enquanto um sistema
bancrio pode exigir uma senha e o carto emitido pelo banco. Essas tcnicas
tambm podem ser usadas de forma gradativa: uma autenticao bsica
solicitada para o usurio acessar o sistema e executar servios simples (como
consultar o saldo de uma conta bancria); se ele solicitar aes consideradas
crticas (como fazer transferncias de dinheiro para outras contas), o sistema
pode exigir mais uma autenticao, usando outra tcnica.
8.4.3
Senhas
A grande maioria dos sistemas operacionais de propsito geral implementam a tcnica de autenticao SYK baseada em login/senha. Na
autenticao por senha, o usurio informa ao sistema seu identificador de
usurio (nome de login) e sua senha, que normalmente uma sequncia de
caracteres memorizada por ele. O sistema ento compara a senha informada
pelo usurio com a senha previamente registrada para ele: se ambas forem
iguais, o acesso consentido.
A autenticao por senha simples mas muito frgil, pois implica no
armazenamento das senhas em aberto no sistema, em um arquivo ou
base de dados. Caso o arquivo ou base seja exposto devido a algum erro
ou descuido, as senhas dos usurios estaro visveis. Para evitar o risco
de exposio indevida das senhas, so usadas funes unidirecionais para
armazen-las, como os resumos criptogrficos (Seo 8.3.3).
A autenticao por senhas usando um resumo criptogrfico bem
simples: ao registrar a senha s de um novo usurio, o sistema calcula seu
resumo (r = hash(s)), e o armazena. Mais tarde, quando esse usurio solicitar
sua autenticao, ele informar uma senha s0 ; o sistema ento calcular
novamente seu resumo r0 = hash(s0 ) e ir compar-lo ao resumo previamente
armazenado (r0 = r). Se ambos forem iguais, a senha informada pelo usurio
c Carlos Maziero
327
8: Senhas descartveis
considerada autntica e o acesso do usurio ao sistema permitido. Com

essa estratgia, as senhas no precisam ser armazenadas em aberto no
sistema, aumentando sua segurana.
Caso um intruso tenha acesso aos resumos das senhas dos usurios,
ele no conseguir calcular de volta as senhas originais (pois o resumo foi
calculado por uma funo unidirecional), mas pode tentar obter as senhas
indiretamente, atravs do ataque do dicionrio. Nesse ataque, o invasor usa
o algoritmo de resumo para cifrar palavras conhecidas ou combinaes
delas, comparando os resumo obtidos com aqueles presentes no arquivo
de senhas. Caso detecte algum resumo coincidente, ter encontrado a
senha correspondente. O ataque do dicionrio permite encontrar senhas
consideradas fracas, por serem muito curtas ou baseadas em palavras
conhecidas. Por isso, muitos sistemas operacionais definem polticas rgidas
para as senhas, impedindo o registro de senhas bvias ou muito curtas e
restringindo o acesso ao repositrio dos resumos de senhas.
8.4.4
Senhas descartveis
Um problema importante relacionado autenticao por senhas reside

no risco de roubo da senhas. Por ser uma informao esttica, caso uma
senha seja roubada, o malfeitor poder us-la enquanto o roubo no for
percebido e a senha substituda. Para evitar esse problema, so propostas
tcnicas de senhas descartveis (OTP - One-Time Passwords). Como o nome
diz, uma senha descartvel s pode ser usada uma nica vez, perdendo
sua validade aps esse uso. O usurio deve ento ter em mos uma lista
de senhas pr-definidas, ou uma forma de ger-las quando necessrio. H
vrias formas de se produzir e usar senhas descartveis, entre elas:
Armazenar uma lista sequencial de senhas (ou seus resumos) no
sistema e fornecer essa lista ao usurio, em papel ou outro suporte.
Quando uma senha for usada com sucesso, o usurio e o sistema a
eliminam de suas respectivas listas.
Uma variante da lista de senhas conhecida como algoritmo OTP de
Lamport [Menezes et al., 1996]. Ele consiste em criar uma sequncia
de senhas s0 , s1 , s2 , , sn com s0 aleatrio e si = hash(si1 ) i > 0, sendo
hash(x) uma funo de resumo criptogrfico conhecida. O valor de sn
informado ao servidor previamente. Ao acessar o servidor, o cliente
informa o valor de sn1 . O servidor pode ento comparar hash(sn1 )
c Carlos Maziero
328
8: Tcnicas biomtricas
com o valor de sn previamente informado: se forem iguais, o cliente

est autenticado e ambos podem descartar sn . O servidor armazena
sn1 para validar a prxima autenticao, e assim sucessivamente. Um
intruso que conseguir capturar uma senha si no poder us-la mais
tarde, pois no conseguir calcular si1 = hash1 (si ).
Gerar senhas temporrias sob demanda, atravs de um dispositivo
ou software externo usado pelo cliente; as senhas temporrias podem
ser geradas por um algoritmo de resumo que combine uma senha prdefinida com a data/horrio corrente. Dessa forma, cliente e servidor
podem calcular a senha temporria de forma independente. Como o
tempo uma informao importante nesta tcnica, o dispositivo ou
software gerador de senhas do cliente deve estar sincronizado com o
relgio do servidor. Dispositivos OTP como o mostrado na Figura 8.8
so frequentemente usados em sistemas de Internet Banking.
Figura 8.8: Um dispositivo gerador de senhas descartveis.
8.4.5
Tcnicas biomtricas
A biometria (biometrics) consiste em usar caractersticas fsicas ou comportamentais de um indivduo, como suas impresses digitais ou seu timbre
de voz, para identific-lo unicamente perante o sistema. Diversas caractersticas podem ser usadas para a autenticao biomtrica; no entanto, elas
devem obedecer a um conjunto de princpios bsicos [Jain et al., 2004]:
Universalidade: a caracterstica biomtrica deve estar presente em todos
os indivduos que possam vir a ser autenticados;
c Carlos Maziero
329
8: Tcnicas biomtricas
Singularidade (ou unicidade): dois indivduos quaisquer devem apresentar valores distintos para a caracterstica em questo;
Permanncia: a caracterstica no deve mudar ao longo do tempo, ou
ao menos no deve mudar de forma abrupta;
Mensurabilidade: a caracterstica em questo deve ser facilmente mensurvel em termos quantitativos.
As caractersticas biomtricas usadas em autenticao podem ser fsicas ou
comportamentais. Como caractersticas fsicas so consideradas, por exemplo,
o DNA, a geometria das mos, do rosto ou das orelhas, impresses digitais,
o padro da ris (padres na parte colorida do olho) ou da retina (padres de
vasos sanguneos no fundo do olho). Como caractersticas comportamentais
so consideradas a assinatura, o padro de voz e a dinmica de digitao
(intervalos de tempo entre teclas digitadas), por exemplo.
Os sistemas mais populares de autenticao biomtrica atualmente so
os baseados em impresses digitais e no padro de ris. Esses sistemas
so considerados confiveis, por apresentarem taxas de erro relativamente
baixas, custo de implantao/operao baixo e facilidade de coleta dos dados
biomtricos. A Figura 8.9 apresenta alguns exemplos de caractersticas
biomtricas empregadas nos sistemas atuais.
iris
retina
retina e ris
padro de voz
impresso digital
Figura 8.9: Exemplo de caractersticas biomtricas.

Um sistema biomtrico tpico composto de um sensor, responsvel por
capturar dados biomtricos de uma pessoa; um extrator de caractersticas, que
processa os dados do sensor para extrair suas caractersticas mais relevantes;
um comparador, cuja funo comparar as caractersticas extradas do
indivduo sob anlise com dados previamente armazenados, e um banco de
dados contendo as caractersticas biomtricas dos usurios registrados no
c Carlos Maziero
330
8: Desafio-resposta
sistema [Jain et al., 2004]. O sistema pode funcionar de dois modos: no modo
de autenticao, ele verifica se as caractersticas biomtricas de um indivduo
(previamente identificado por algum outro mtodo, como login/senha,
carto, etc.) correspondem s suas caractersticas biomtricas previamente
armazenadas. Desta forma, a biometria funciona como uma autenticao
complementar. No modo de identificao, o sistema biomtrico visa identificar
o indivduo a quem correspondem as caractersticas biomtricas coletadas
pelo sensor, dentre todos aqueles presentes no banco de dados. A Figura
8.10 mostra os principais elementos de um sistema biomtrico tpico.
dados
biomtricos
sensor
dados
biomtricos
sistema biomtrico
extrator de
caractersticas
coleta/registro
caractersticas
relevantes
humanos
senha
carto
etc.
autenticador
identidade
comparador
usurios
cadastrados
base de
dados
resultado (identificao ou autenticao)
Figura 8.10: Um sistema biomtrico tpico.
8.4.6
Desafio-resposta
Em algumas situaes o uso de senhas indesejvel, pois sua exposio

indevida pode comprometer a segurana do sistema. Um exemplo disso
so os servios via rede: caso o trfego de rede possa ser capturado por um
intruso, este ter acesso s senhas transmitidas entre o cliente e o servidor.
Uma tcnica interessante para resolver esse problema so os protocolos de
desafio-resposta.
A tcnica de desafio-resposta se baseia sobre um segredo s previamente
definido entre o cliente e o servidor (ou o usurio e o sistema), que pode
ser uma senha ou uma chave criptogrfica, e um algoritmo de cifragem ou
resumo hash(x), tambm previamente definido. No incio da autenticao, o
servidor escolhe um valor aleatrio d e o envia ao cliente, como um desafio. O
cliente recebe esse desafio, o concatena com seu segredo s, calcula o resumo
da concatenao e a devolve ao servidor, como resposta (r = hash(s k d)). O
servidor executa a mesma operao de seu lado, usando o valor do segredo
c Carlos Maziero
331
8: Certificados de autenticao
armazenado localmente (s0 ) e compara o resultado obtido r0 = hash(s0 k d)

com a resposta r fornecida pelo cliente. Se ambos os resultados forem iguais,
os segredos so iguais (r = r0 s = s0 ) e o cliente considerado autntico.
A Figura 8.11 apresenta os passos desse algoritmo.
Cliente
senha s
Servidor
solicita acesso
desao(d)
senha s'
dene d
aleatrio
r=hash(s||d)
resposta(r)
aceito/recusado
r'=hash(s'||d)
aceito se r'=r
(implica s'=s)
requisies (caso aceito)

t
Figura 8.11: Autenticao por desafio-resposta.

A estratgia de desafio-resposta robusta, porque o segredo s nunca
exposto fora do cliente nem do servidor; alm disso, como o desafio d
aleatrio e a resposta cifrada, intrusos que eventualmente conseguirem
capturar d ou r no podero utiliz-los para se autenticar nem para descobrir
s. Variantes dessa tcnica so usadas em vrios protocolos de rede.
8.4.7
Certificados de autenticao
Uma forma cada vez mais frequente de autenticao envolve o uso de

certificados digitais. Conforme apresentado na Seo 8.3.5, um certificado
digital um documento assinado digitalmente, atravs de tcnicas de
criptografia assimtrica e resumo criptogrfico. Os padres de certificados
PGP e X.509 definem certificados de autenticao (ou de identidade), cujo
objetivo identificar entidades atravs de suas chaves pblicas. Um
c Carlos Maziero
332
8: Kerberos
certificado de autenticao conforme o padro X.509 contm as seguintes

informaes [Mollin, 2000]:
Nmero de verso do padro X.509 usado no certificado;
Chave pblica do proprietrio do certificado e indicao do algoritmo
de criptografia ao qual ela est associada e eventuais parmetros;
Nmero serial nico, definido pelo emissor do certificado (quem o
assinou);
Identificao detalhada do proprietrio do certificado, definida de
acordo com normas do padro X.509;
Perodo de validade do certificado (datas de incio e final de validade);
Identificao da Autoridade Certificadora que emitiu/assinou o certificado;
Assinatura digital do certificado e indicao do algoritmo usado na
assinatura e eventuais parmetros;
Os certificados digitais so o principal mecanismo usado para verificar
a autenticidade de servios acessveis atravs da Internet, como bancos
e comrcio eletrnico. Nesse caso, eles so usados para autenticar os
sistemas para os usurios. No entanto, cada vez mais frequente o uso de
certificados para autenticar os prprios usurios. Nesse caso, um smartcard
ou um dispositivo USB contendo o certificado conectado ao sistema para
permitir a autenticao do usurio.
8.4.8
Kerberos
O sistema de autenticao Kerberos foi proposto pelo MIT nos anos 80

[Neuman and Tso, 1994]. Hoje, esse sistema utilizado para centralizar
a autenticao de rede em vrios sistemas operacionais, como Windows,
Solaris, MacOS X e Linux. O sistema Kerberos se baseia na noo de tickets,
que so obtidos pelos clientes junto a um servio de autenticao e podem
ser usados para acessar os demais servios da rede. Os tickets so cifrados
usando criptografia simtrica DES e tm validade limitada, para aumentar
sua segurana.
c Carlos Maziero
333
8: Kerberos
Os principais componentes de um sistema Kerberos so o Servio de

Autenticao (AS - Authentication Service), o Servio de Concesso de Tickets
(TGS - Ticket Granting Service), a base de chaves, os clientes e os servios de
rede que os clientes podem acessar. Juntos, o AS e o TGS constituem o Centro
de Distribuio de Chaves (KDC - Key Distribution Center). O funcionamento
bsico do sistema Kerberos, ilustrado na Figura 8.12, relativamente simples:
o cliente se autentica junto ao AS (passo 1) e obtm um ticket de acesso
ao servio de tickets TGS (passo 2). A seguir, solicita ao TGS um ticket de
acesso ao servidor desejado (passos 3 e 4). Com esse novo ticket, ele pode
se autenticar junto ao servidor desejado e solicitar servios (passos 5 e 6).
Key Distribution Center
1
T1
client
3
Authentication
Service
Ticket
Granting
Service
T1
T2
6
T2
users/keys
database
server
Figura 8.12: Viso geral do servio Kerberos.

No Kerberos, cada cliente c possui uma chave secreta kc registrada no
servidor de autenticao AS. Da mesma forma, cada servidor s tambm tem
sua chave ks registrada no AS. As chaves so simtricas, usando cifragem
DES, e somente so conhecidas por seus respectivos proprietrios e pelo
AS. Os seguintes passos detalham o funcionamento do Kerberos verso 5
[Neuman and Tso, 1994]:
1. Uma mquina cliente c desejando acessar um determinado servidor
s envia uma solicitao de autenticao ao servio de autenticao
(AS); essa mensagem m1 contm sua identidade (c), a identidade do
servio desejado (tgs), um prazo de validade solicitado (ts) e um
nmero aleatrio (n1 ) que ser usado para verificar se a resposta do
AS corresponde ao pedido efetuado:
c Carlos Maziero
334
8: Kerberos
m1 = [c tgs ts n1 ]
2. A resposta do AS (mensagem m2 ) contm duas partes: a primeira
parte contm a chave de sesso a ser usada na comunicao com o
TGS (kctgs ) e o nmero aleatrio n1 , ambos cifrados com a chave do
cliente kc registrada no AS; a segunda parte um ticket cifrado com a
chave do TGS (ktgs ), contendo a identidade do cliente (c), o prazo de
validade do ticket concedido pelo AS (tv) e uma chave de sesso kctgs ,
a ser usada na interao com o TGS:
m2 = [{kctgs n1 }kc Tctgs ]
onde Tctgs = {c tv kctgs }ktgs
O ticket Tctgs fornecido pelo AS para permitir o acesso ao TGS

chamado TGT (Ticket Granting Ticket), e possui um prazo de validade
limitado (geralmente de algumas horas). Ao receber m2 , o cliente tem
acesso chave de sesso kctgs e ao ticket TGT. Todavia, esse ticket
cifrado com a chave ktgs e portanto somente o TGS poder abr-lo.
3. A seguir, o cliente envia uma solicitao ao TGS (mensagem m3 ) para
obter um ticket de acesso ao servidor desejado s. Essa solicitao
contm a identidade do cliente (c) e a data atual (t), ambos cifrados
com a chave de sesso kctgs , o ticket TGT recebido em m2 , a identidade
do servidor s e um nmero aleatrio n2 :
m3 = [{c t}kctgs Tctgs s n2 ]
4. Aps verificar a validade do ticket TGT, o TGS devolve ao cliente uma
mensagem m4 contendo a chave de sesso kcs a ser usada no acesso ao
servidor s e o nmero aleatrio n2 informado em m3 , ambos cifrados
com a chave de sesso kctgs , e um ticket Tcs cifrado, que deve ser
apresentado ao servidor s:
m4 = [{kcs n}kctgs Tcs ]
onde Tcs = {c tv kcs }ks
c Carlos Maziero
335
8: Infra-estruturas de autenticao
5. O cliente usa a chave de sesso kcs e o ticket Tcs para se autenticar

junto ao servidor s atravs da mensagem m5 . Essa mensagem contm
a identidade do cliente (c) e a data atual (t), ambos cifrados com a
chave de sesso kcs , o ticket Tcs recebido em m4 e o pedido de servio
ao servidor (request), que dependente da aplicao:
m5 = [{c t}kcs Tcs request]
6. Ao receber m5 , o servidor s decifra o ticket Tcs para obter a chave
de sesso kcs e a usa para decifrar a primeira parte da mensagem e
confirmar a identidade do cliente. Feito isso, o servidor pode atender
a solicitao e responder ao cliente, cifrando sua resposta com a chave
de sesso kcs :
m6 = [{reply}kcs ]
Enquanto o ticket de servio Tcs for vlido, o cliente pode enviar
solicitaes ao servidor sem a necessidade de se reautenticar. Da mesma
forma, enquanto o ticket Tctgs for vlido, o cliente pode solicitar tickets de
acesso a outros servidores sem precisar se reautenticar. Pode-se observar
que em nenhum momento as chaves de sesso kctgs e kcs circularam em
aberto atravs da rede. Alm disso, a presena de prazos de validade para
as chaves permite minimizar os riscos de uma eventual captura da chave.
Informaes mais detalhadas sobre o funcionamento do protocolo Kerberos
5 podem ser encontradas em [Neuman et al., 2005].
8.4.9
Infra-estruturas de autenticao
A autenticao um procedimento necessrio em vrios servios de

um sistema computacional, que vo de simples sesses de terminal em
modo texto a servios de rede, como e-mail, bancos de dados e terminais
grficos remotos. Historicamente, cada forma de acesso ao sistema possua
seus prprios mecanismos de autenticao, com suas prprias regras e
informaes. Essa situao dificultava a criao de novos servios, pois
estes deveriam tambm definir seus prprios mtodos de autenticao.
Alm disso, a existncia de vrios mecanismos de autenticao desconexos
prejudicava a experincia do usurio e dificultava a gerncia do sistema.
c Carlos Maziero
336
8: Infra-estruturas de autenticao
Para resolver esse problema, foram propostas infra-estruturas de autenticao (authentication frameworks) que unificam as tcnicas de autenticao,
oferecem uma interface de programao homognea e usam as mesmas
informaes (pares login/senha, dados biomtricos, certificados, etc.). Assim,
as informaes de autenticao so coerentes entre os diversos servios,
novas tcnicas de autenticao podem ser automaticamente usadas por
todos os servios e, sobretudo, a criao de novos servios simplificada.
A viso genrica de uma infra-estrutura de autenticao apresentada
na Figura 8.13. Nela, os vrios mecanismos disponveis de autenticao
so oferecidos s aplicaes atravs de uma interface de programao (API)
padronizada. As principais infra-estruturas de autenticao em uso nos
sistemas operacionais atuais so:
PAM (Pluggable Authentication Modules): proposto inicialmente para o
sistema Solaris, foi depois adotado em vrios outros sistema UNIX,
como FreeBSD, NetBSD, MacOS X e Linux;
XSSO (X/Open Single Sign-On): uma tentativa de extenso e padronizao
do sistema PAM, ainda pouco utilizada;
BSD Auth : usada no sistema operacional OpenBSD; cada mtodo de
autenticao implementado como um processo separado, respeitando
o princpio do privilgio mnimo (vide Seo 8.5.1);
NSS (Name Services Switch): infra-estrutura usada em sistemas UNIX para
definir as bases de dados a usar para vrios servios do sistema
operacional, inclusive a autenticao;
GSSAPI (Generic Security Services API): padro de API para acesso a servios
de segurana, como autenticao, confidencialidade e integridade de
dados;
SSPI (Security Support Provider Interface): variante proprietria da GSSAPI,
especfica para plataformas Windows.
c Carlos Maziero
337
aplicaes e/ou servios
...
endereo IP
biometria
certificados
login/senha
API padronizada
Figura 8.13: Estrutura genrica de uma infra-estrutura de autenticao.
8.5
Controle de acesso
Em um sistema computacional, o controle de acesso consiste em mediar

cada solicitao de acesso de um usurio autenticado a um recurso ou
dado mantido pelo sistema, para determinar se aquela solicitao deve
ser autorizada ou negada [Samarati and De Capitani di Vimercati, 2001].
Praticamente todos os recursos de um sistema operacional tpico esto
submetidos a um controle de acesso, como arquivos, reas de memria,
semforos, portas de rede, dispositivos de entrada/sada, etc. H alguns
conceitos importantes para a compreenso do controle de acesso, como
polticas, modelos e mecanismos. Esses conceitos sero estudados nesta
seo.
Em controle de acesso, habitual classificar as entidades de um sistema
em dois grupos: os sujeitos e os objetos. Sujeitos so todas aquelas entidades que exercem um papel ativo no sistema, como processos, threads ou
transaes. Normalmente um sujeito opera em nome de um usurio, que
pode ser um ser humano ou outro sistema computacional externo. Objetos
so as entidades passivas utilizadas pelos sujeitos, como arquivos, reas de
memria ou registros em um banco de dados. Em alguns casos, um sujeito
pode ser visto como objeto por outro sujeito (por exemplo, quando um
sujeito deve enviar uma mensagem a outro sujeito). Tanto sujeitos quanto
c Carlos Maziero
338
8: Polticas, modelos e mecanismos de controle de acesso
objetos podem ser organizados em grupos e hierarquias, para facilitar a

gerncia da segurana.
8.5.1
Polticas, modelos e mecanismos de controle de acesso
Uma poltica de controle de acesso uma viso abstrata das possibilidades

de acesso a recursos (objetos) pelos usurios (sujeitos) de um sistema. Essa
poltica consiste basicamente de um conjunto de regras definindo os acessos
possveis aos recursos do sistema e eventuais condies necessrias para
permitir cada acesso. Por exemplo, as regras a seguir poderiam constituir
parte da poltica de segurana de um sistema de informaes mdicas:
Mdicos podem consultar os pronturios de seus pacientes;
Mdicos podem modificar os pronturios de seus pacientes enquanto
estes estiverem internados;
O supervisor geral pode consultar os pronturios de todos os pacientes;
Enfermeiros podem consultar apenas os pronturios dos pacientes de
sua seo e somente durante seu perodo de turno;
Assistentes no podem consultar pronturios;
Pronturios de pacientes de planos de sade privados podem ser
consultados pelo responsvel pelo respectivo plano de sade no
hospital;
Pacientes podem consultar seus prprios pronturios (aceitar no
mximo 30 pacientes simultneos).
As regras ou definies individuais de uma poltica so denominadas autorizaes. Uma poltica de controle de acesso pode ter autorizaes baseadas
em identidades (como sujeitos e objetos) ou em outros atributos (como idade,
sexo, tipo, preo, etc.); as autorizaes podem ser individuais (a sujeitos) ou
coletivas (a grupos); tambm podem existir autorizaes positivas (permitindo
o acesso) ou negativas (negando o acesso); por fim, uma poltica pode ter
autorizaes dependentes de condies externas (como o tempo ou a carga do
sistema). Alm da poltica de acesso aos objetos, tambm deve ser definida
uma poltica administrativa, que define quem pode modificar/gerenciar as
polticas vigentes no sistema [Samarati and De Capitani di Vimercati, 2001].
c Carlos Maziero
339
8: Polticas, modelos e mecanismos de controle de acesso
O conjunto de autorizaes de uma poltica deve ser ao mesmo tempo

completo, cobrindo todas as possibilidades de acesso que vierem a ocorrer
no sistema, e consistente, sem regras conflitantes entre si (por exemplo,
uma regra que permita um acesso e outra que negue esse mesmo acesso).
Alm disso, toda poltica deve buscar respeitar o princpio do privilgio
mnimo [Saltzer and Schroeder, 1975], segundo o qual um usurio nunca
deve receber mais autorizaes que aquelas que necessita para cumprir sua
tarefa. A construo e validao de polticas de controle de acesso um
tema complexo, que est fora do escopo deste texto, sendo melhor descrito
em [di Vimercati et al., 2005, di Vimercati et al., 2007].
As polticas de controle de acesso definem de forma abstrata como os
sujeitos podem acessar os objetos do sistema. Existem muitas formas de se
definir uma poltica, que podem ser classificadas em quatro grandes classes:
polticas discricionrias, polticas obrigatrias, polticas baseadas em domnios
e polticas baseadas em papis [Samarati and De Capitani di Vimercati, 2001].
As prximas sees apresentam com mais detalhe cada uma dessas classes
de polticas.
Geralmente a descrio de uma poltica de controle de acesso muito
abstrata e informal. Para sua implementao em um sistema real, ela precisa
ser descrita de uma forma precisa, atravs de um modelo de controle de acesso.
Um modelo de controle de acesso uma representao lgica ou matemtica
da poltica, de forma a facilitar sua implementao e permitir a anlise de
eventuais erros. Em um modelo de controle de acesso, as autorizaes de
uma poltica so definidas como relaes lgicas entre atributos do sujeito
(como seus identificadores de usurio e grupo) atributos do objeto (como
seu caminho de acesso ou seu proprietrio) e eventuais condies externas
(como o horrio ou a carga do sistema). Nas prximas sees, para cada
classe de polticas de controle de acesso apresentada sero discutidos alguns
modelos aplicveis mesma.
Por fim, os mecanismos de controle de acesso so as estruturas necessrias
implementao de um determinado modelo em um sistema real. Como
bem sabido, de fundamental importncia a separao entre polticas e
mecanismos, para permitir a substituio ou modificao de polticas de
controle de acesso de um sistema sem incorrer em custos de modificao
de sua implementao. Assim, um mecanismo de controle de acesso ideal
deveria ser capaz de suportar qualquer poltica de controle de acesso.
c Carlos Maziero
340
8.5.2
8: Polticas discricionrias
Polticas discricionrias
As polticas discricionrias (DAC - Discretionary Access Control) se baseiam

na atribuio de permisses de forma individualizada, ou seja, pode-se
claramente conceder (ou negar) a um sujeito especfico s a permisso de
executar a ao a sobre um objeto especfico o. Em sua forma mais simples,
as regras de uma poltica discricionria tm a forma hs, o, +ai ou hs, o, ai,
para respectivamente autorizar ou negar a ao a do sujeito s sobre o objeto
o (tambm podem ser definidas regras para grupos de usurios e/ou de
objetos devidamente identificados). Por exemplo:
O usurio Beto pode ler e escrever arquivos em /home/beto
Usurios do grupo admin podem ler os arquivos em /suporte
O responsvel pela administrao das permisses de acesso a um objeto
pode ser o seu proprietrio ou um administrador central. A definio de
quem estabelece as regras da poltica de controle de acesso inerente a uma
poltica administrativa, independente da poltica de controle de acesso em
si6 .
Matriz de controle de acesso
O modelo matemtico mais simples e conveniente para representar
polticas discricionrias a Matriz de Controle de Acesso, proposta em
[Lampson, 1971]. Nesse modelo, as autorizaes so dispostas em uma
matriz, cujas linhas correspondem aos sujeitos do sistema e cujas colunas
correspondem aos objetos. Em termos formais, considerando um conjunto
de sujeitos S = {s1 , s2 , . . . , sm }, um conjunto de objetos O = {o1 , o2 , . . . , on } e
um conjunto de aes possveis sobre os objetos A = {a1 , a2 , . . . , ap }, cada
elemento Mi j da matriz de controle de acesso um sub-conjunto (que pode
ser vazio) do conjunto de aes possveis, que define as aes que si S
pode efetuar sobre o j O:
6
Muitas polticas de controle de acesso discricionrias so baseadas na noo de que

cada recurso do sistema possui um proprietrio, que decide quem pode acessar o recurso.
Isso ocorre por exemplo nos sistemas de arquivos, onde as permisses de acesso a cada
arquivo ou diretrio so definidas pelo respectivo proprietrio. Contudo, a noo de
proprietrio de um recurso no essencial para a construo de polticas discricionrias
[Shirey, 2000].
c Carlos Maziero
341
Alice
Beto
f ile1
read
write
remove
read
write
Carol
Davi
read
f ile2
read
write
program1
execute
read
write
remove
read
read
execute
append
read
socket1
write
read
write
read
append
Tabela 8.1: Uma matriz de controle de acesso
si S, o j O, Mi j A
Por exemplo, considerando um conjunto de sujeitos S =

{Alice, Beto, Carol, Davi}, um conjunto de objetos O = { f ile1 , f ile2 , program1 , socket
e um conjunto de aes A = {read, write, execute, remove}, podemos ter uma
matriz de controle de acesso como a apresentada na Tabela 8.1.
Apesar de simples, o modelo de matriz de controle de acesso suficientemente flexvel para suportar polticas administrativas. Por exemplo,
considerando uma poltica administrativa baseada na noo de proprietrio
do recurso, poder-se-ia considerar que que cada objeto possui um ou mais
proprietrios (owner), e que os sujeitos podem modificar as entradas da
matriz de acesso relativas aos objetos que possuem. Uma matriz de controle
de acesso com essa poltica administrativa apresentada na Tabela 8.2.
Embora seja um bom modelo conceitual, a matriz de acesso inadequada
para implementao. Em um sistema real, com milhares de sujeitos e milhes
de objetos, essa matriz pode se tornar gigantesca e consumir muito espao.
Como em um sistema real cada sujeito tem seu acesso limitado a um
pequeno grupo de objetos (e vice-versa), a matriz de acesso geralmente
esparsa, ou seja, contm muitas clulas vazias. Assim, algumas tcnicas
simples podem ser usadas para implementar esse modelo, como as tabelas
de autorizaes, as listas de controle de acesso e as listas de capacidades
[Samarati and De Capitani di Vimercati, 2001], explicadas a seguir.
c Carlos Maziero
342
Alice
Beto
f ile1
read
write
remove
owner
read
write
Carol
Davi
read
f ile2
read
write
program1
execute
read
write
remove
owner
read
read
owner
execute
write
read
socket1
write
read
write
read
write
owner
Tabela 8.2: Uma matriz de controle de acesso com poltica administrativa

Tabela de autorizaes
Na abordagem conhecida como Tabela de Autorizaes, as entradas novazias da matriz so relacionadas em uma tabela com trs colunas: sujeitos,
objetos e aes, onde cada tupla da tabela corresponde a uma autorizao.
Esta abordagem muito utilizada em sistemas gerenciadores de bancos
de dados (DBMS - Database Management Systems), devido sua facilidade
de implementao e consulta nesse tipo de ambiente. A Tabela 8.3 mostra
como ficaria a matriz de controle de acesso da Tabela 8.2 sob a forma de
uma tabela de autorizaes.
Listas de controle de acesso
Outra abordagem usual a Lista de Controle de Acesso. Nesta abordagem, para cada objeto definida uma lista de controle de acesso (ACL Access Control List), que contm a relao de sujeitos que podem acess-lo,
com suas respectivas permisses. Cada lista de controle de acesso corresponde a uma coluna da matriz de controle de acesso. Como exemplo, as
listas de controle de acesso relativas matriz de controle de acesso da Tabela
8.2 seriam:
c Carlos Maziero
343
Sujeito
Alice
Alice
Alice
Alice
Alice
Alice
Alice
Alice
Beto
Beto
Beto
Beto
Beto
Beto
Beto
Beto
Carol
Carol
Carol
Carol
Davi
Davi
Davi
Davi
Davi
Davi
Objeto
f ile1
f ile1
f ile1
f ile1
f ile2
f ile2
program1
socket1
f ile1
f ile1
f ile2
f ile2
f ile2
f ile2
program1
socket1
f ile2
program1
socket1
socket1
f ile1
f ile2
program1
socket1
socket1
socket1
Ao
read
write
remove
owner
read
write
execute
write
read
write
read
write
remove
owner
read
owner
read
execute
read
write
read
write
read
read
write
owner
Tabela 8.3: Tabela de autorizaes
c Carlos Maziero
344
ACL( f ile1 ) = { Alice : (read, write, remove, owner),

Beto : (read, write),
Davi : (read) }
ACL( f ile2 ) = { Alice : (read, write),
Beto : (read, write, remove, owner),
Carol : (read),
Davi : (write) }
ACL(program1 ) = { Alice : (execute),
Beto : (read, owner),
Carol : (execute),
Davi : (read) }
ACL(socket1 ) = { Alice : (write),
Carol : (read, write),
Davi : (read, write, owner) }
Esta forma de implementao a mais frequentemente usada em sistemas

operacionais, por ser simples de implementar e bastante robusta. Por
exemplo, o sistema de arquivos associa uma ACL a cada arquivo ou
diretrio, para indicar quem so os sujeitos autorizados a acess-lo. Em
geral, somente o proprietrio do arquivo pode modificar sua ACL, para
incluir ou remover permisses de acesso.
Listas de capacidades
Uma terceira abordagem possvel para a implementao da matriz de
controle de acesso a Lista de Capacidades (CL - Capability List), ou seja,
uma lista de objetos que um dado sujeito pode acessar e suas respectivas
permisses sobre os mesmos. Cada lista de capacidades corresponde a
uma linha da matriz de acesso. Como exemplo, as listas de capacidades
correspondentes matriz de controle de acesso da Tabela 8.2 seriam:
CL(Alice) = { f ile1 : (read, write, remove, owner),
c Carlos Maziero
345
8: Polticas obrigatrias
f ile2 : (read, write),

program1 : (execute),
socket1 : (write) }
CL(Beto) = { f ile1 : (read, write),
f ile2 : (read, write, remove, owner),
program1 : (read, owner) }
CL(Carol) = { f ile2 : (read),
program1 : (execute),
socket1 : (read, write) }
CL(Davi) = { f ile1 : (read),
f ile2 : (write),
program1 : (read),
socket1 : (read, write, owner) }
Uma capacidade pode ser vista como uma ficha ou token: sua posse
d ao proprietrio o direito de acesso ao objeto em questo. Capacidades
so pouco usadas em sistemas operacionais, devido sua dificuldade
de implementao e possibilidade de fraude, pois uma capacidade mal
implementada pode ser transferida deliberadamente a outros sujeitos, ou
modificada pelo prprio proprietrio para adicionar mais permisses a ela.
Outra dificuldade inerente s listas de capacidades a administrao das
autorizaes: por exemplo, quem deve ter permisso para modificar uma
lista de capacidades, e como retirar uma permisso concedida anteriormente
a um sujeito? Alguns sistemas operacionais que implementam o modelo de
capacidades so discutidos na Seo 8.5.6.
8.5.3
Polticas obrigatrias
Nas polticas obrigatrias (MAC - Mandatory Access Control) o controle de acesso definido por regras globais incontornveis, que
no dependem das identidades dos sujeitos e objetos nem da vontade de seus proprietrios ou mesmo do administrador do sistema
[Samarati and De Capitani di Vimercati, 2001]. Essas regras so normalmente baseadas em atributos dos sujeitos e/ou dos objetos, como mostram
estes exemplos bancrios (fictcios):
c Carlos Maziero
346
Cheques com valor acima de R$ 5.000,00 devem ser necessariamente

depositados e no podem ser descontados;
Clientes com renda mensal acima de R$3.000,00 no tm acesso ao
crdito consignado.
Uma das formas mais usuais de poltica obrigatria so as polticas multinvel (MLS - Multi-Level Security), que se baseiam na classificao de sujeitos
e objetos do sistema em nveis de segurana (clearance levels) e na definio
de regras usando esses nveis. Um exemplo bem conhecido de escala de
nveis de classificao aquela usada pelo governo britnico para definir a
confidencialidade de um documento:
TS: Top Secret (Ultrassecreto)
S: Secret (Secreto)
C: Confidential (Confidencial)
R: Restrict (Reservado)
U: Unclassified (Pblico)
Em uma poltica MLS, considera-se que os nveis de segurana esto
ordenados entre si (por exemplo, U < R < C < S < TS) e so associados a
todos os sujeitos e objetos do sistema, sob a forma de habilitao dos sujeitos
(h(si )) e classificao dos objetos (c(o j )). As regras da poltica so ento
estabelecidas usando essas habilitaes e classificaes, como mostram os
modelos descritos a seguir.
Modelo de Bell-LaPadula
Um modelo de controle de acesso que permite formalizar polticas multinvel o de Bell-LaPadula [Bell and LaPadula, 1974], usado para garantir a
confidencialidade das informaes. Esse modelo consiste basicamente de
duas regras:
No-Read-Up (no ler acima, ou propriedade simples): impede que
um sujeito leia objetos que se encontrem em nveis de segurana
acima do seu. Por exemplo, um sujeito habilitado como confidencial
(C) somente pode ler objetos cuja classificao seja confidencial (C),
c Carlos Maziero
347
reservada (R) ou pblica (U). Considerando um sujeito s e um objeto

o, formalmente temos:
request(s, o, read) h(s) c(o)
No-Write-Down (no escrever abaixo, ou propriedade ?): impede
que um sujeito escreva em objetos abaixo de seu nvel de segurana,
para evitar o vazamento de informaes dos nveis superiores para
os inferiores. Por exemplo, um sujeito habilitado como confidencial
somente pode escrever em objetos cuja classificao seja confidencial,
secreta ou ultrassecreta. Formalmente, temos:
request(s, o, write) h(s) c(o)
Pode-se perceber facilmente que a poltica obrigatria representada pelo
modelo de Bell-LaPadula visa proteger a confidencialidade das informaes
do sistema, evitando que estas fluam dos nveis superiores para os inferiores.
Todavia, nada impede um sujeito com baixa habilitao escrever sobre um
objeto de alta classificao, destruindo seu contedo.
Modelo de Biba
Para garantir a integridade das informaes, um modelo dual ao de
Bell-LaPadula foi proposto por Biba [Biba, 1977]. Esse modelo define nveis
de integridade i(x) para sujeitos e objetos (como Baixa, Mdia, Alta e Sistema,
com B < M < A < S), e tambm possui duas regras bsicas:
No-Write-Up (no escrever acima, ou propriedade simples de integridade): impede que um sujeito escreva em objetos acima de seu
nvel de integridade, preservando-os ntegros. Por exemplo, um sujeito de integridade mdia (M) somente pode escrever em objetos de
integridade baixa (B) ou mdia (M). Formalmente, temos:
request(s, o, write) i(s) i(o)
No-Read-Down (no ler abaixo, ou propriedade ? de integridade):
impede que um sujeito leia objetos em nveis de integridade abaixo do
c Carlos Maziero
348
seu, para no correr o risco de ler informao duvidosa. Por exemplo,

um sujeito com integridade alta (A) somente pode ler objetos com
integridade alta (A) ou de sistema (S). Formalmente, temos:
request(s, o, read) i(s) i(o)
A poltica obrigatria definida atravs do modelo de Biba evita violaes
de integridade, mas no garante a confidencialidade das informaes. Para
que as duas polticas (confidencialidade e integridade) possam funcionar em
conjunto, necessrio portanto associar a cada sujeito e objeto do sistema
um nvel de confidencialidade e um nvel de integridade, possivelmente
distintos.
importante observar que, na maioria dos sistemas reais, as polticas
obrigatrias no substituem as polticas discricionrias, mas as complementam. Em um sistema que usa polticas obrigatrias, cada acesso a
recurso verificado usando a politica obrigatria e tambm uma politica
discricionria; o acesso permitido somente se ambas as politicas o autorizarem. A ordem de avaliao das polticas MAC e DAC obviamente no afeta
o resultado final, mas pode ter impacto sobre o desempenho do sistema.
Por isso, deve-se primeiro avaliar a poltica mais restritiva, ou seja, aquela
que tem mais probabilidades de negar o acesso.
Categorias
Uma extenso frequente s polticas multi-nvel a noo de categorias
ou compartimentos. Uma categoria define uma rea funcional dentro do
sistema computacional, como pessoal, projetos, financeiro, suporte,
etc. Normalmente o conjunto de categorias esttico no h uma ordem
hierrquica entre elas. Cada sujeito e cada objeto do sistema so rotulados com uma ou mais categorias; a poltica ento consiste em restringir
o acesso de um sujeito somente aos objetos pertencentes s mesmas categorias dele, ou a um sub-conjunto destas. Dessa forma, um sujeito com
as categorias {suporte, f inanceiro} s pode acessar objetos rotulados como
{suporte, f inanceiro}, {suporte}, { f inanceiro} ou {}. Formalmente: sendo C(s)
o conjunto de categorias associadas a um sujeito s e C(o) o conjunto de
categorias associadas a um objeto o, s s pode acessar o se C(s) C(o)
[Samarati and De Capitani di Vimercati, 2001].
c Carlos Maziero
349
8.5.4
8: Polticas baseadas em domnios e tipos
Polticas baseadas em domnios e tipos
O domnio de segurana de um sujeito define o conjunto de objetos que

ele pode acessar e como pode acess-los. Muitas vezes esse domnio est
definido implicitamente nas regras das polticas obrigatrias ou na matriz de
controle de acesso de uma poltica discricionria. As polticas baseadas em domnios e tipos (DTE - Domain/Type Enforcement policies) [Boebert and Kain, 1985]
tornam explcito esse conceito: cada sujeito s do sistema rotulado com
um atributo constante definindo seu domnio domain(s) e cada objeto o
associado a um tipo type(o), tambm constante.
No modelo de implementao de uma poltica DTE definido em
[Badger et al., 1995], as permisses de acesso de sujeitos a objetos so definidas em uma tabela global chamada Tabela de Definio de Domnios (DDT Domain Definition Table), na qual cada linha associada a um domnio e cada
coluna a um tipo; cada clula DDT[x, y] contm as permisses de sujeitos
do domnio x a objetos do tipo y:
request(s, o, action) action DDT[domain(s), type(o)]
Por sua vez, as interaes entre sujeitos (trocas de mensagens, sinais,
etc.) so reguladas atravs de uma Tabela de Interao entre Domnios (DIT
- Domain Interaction Table). Nessa tabela, linhas e colunas correspondem
a domnios e cada clula DIT[x, y] contm as interaes possveis de um
sujeito no domnio x sobre um sujeito no domnio y:
request(si , s j , interaction) interaction DIT[domain(si ), domain(s j )]
Eventuais mudanas de domnio podem ser associadas a programas executveis rotulados como pontos de entrada (entry points). Quando um processo
precisa mudar de domnio, ele executa o ponto de entrada correspondente
ao domnio de destino, se tiver permisso para tal.
O cdigo a seguir define uma poltica de controle de acesso DTE, usada
como exemplo em [Badger et al., 1995]. Essa poltica est representada
graficamente (de forma simplificada) na Figura 8.14.
1
2
3
4
5
6
/* type definitions
type unix_t,
/*
specs_t,
/*
budget_t,
/*
rates_t;
/*
*/
normal UNIX files, programs, etc. */
engineering specifications */
budget projections */
labor rates */
c Carlos Maziero
350
8: Polticas baseadas em domnios e tipos
#define DEFAULT (/bin/sh), (/bin/csh), (rxd->unix_t) /* macro */
8
9
10
11
12
13
14
15
/* domain definitions */
domain engineer_d = DEFAULT, (rwd->specs_t);
domain project_d = DEFAULT, (rwd->budget_t), (rd->rates_t);
domain accounting_d = DEFAULT, (rd->budget_t), (rwd->rates_t);
domain system_d = (/etc/init), (rwxd->unix_t), (auto->login_d);
domain login_d
= (/bin/login), (rwxd->unix_t),
(exec-> engineer_d, project_d, accounting_d);
16
17
initial_domain system_d; /* system starts in this domain */
18
19
20
21
22
23
/* assign
assign -r
assign -r
assign -r
assign -r
resources (files and directories) to types */

unix_t /;
/* default for all files */
specs_t /projects/specs;
budget_t /projects/budget;
rates_t /projects/rates;
acessos
system_d
transies
*_t tipos
init
*_d domnios
pontos de entrada
login_d
accounting_d
engineer_d
sh
sh
login
edit
csh
rwxd
rwxd
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
unix_t
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
r-x
csh
rd
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
cad
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
budget_t
r-x
rxd
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
rwd
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
specs_t
Figura 8.14: Exemplo de poltica baseada em domnios e tipos.

A implementao direta desse modelo sobre um sistema real pode
ser invivel, pois exige a classificao de todos os sujeitos e objetos do mesmo em domnios e tipos. Para atenuar esse problema,
c Carlos Maziero
351
8: Polticas baseadas em papis
[Badger et al., 1995, Cowan et al., 2000] propem o uso de tipagem implcita: todos os objetos que satisfazem um certo critrio (como por exemplo ter
como caminho /usr/local/*) so automaticamente classificados em um
dado tipo. Da mesma forma, os domnios podem ser definidos pelos nomes
dos programas executveis que os sujeitos executam (como /usr/bin/httpd
e /usr/lib/httpd/plugin/* para o domnio do servidor Web). Alm disso,
ambos os autores propem linguagens para a definio dos domnios e tipos
e para a descrio das polticas de controle de acesso.
8.5.5
Polticas baseadas em papis
Um dos principais problemas de segurana em um sistema computacional a administrao correta das polticas de controle de acesso. As
polticas MAC so geralmente consideradas pouco flexveis e por isso as
polticas DAC acabam sendo muito mais usadas. Todavia, gerenciar as
autorizaes medida em que usurios mudam de cargo e assumem novas
responsabilidades, novos usurios entram na empresa e outros saem pode
ser uma tarefa muito complexa e sujeita a erros.
Esse problema pode ser reduzido atravs do controle de acesso baseado em
papis (RBAC - Role-Based Access Control) [Sandhu et al., 1996]. Uma poltica
RBAC define um conjunto de papis no sistema, como diretor, gerente,
suporte, programador, etc. e atribui a cada papel um conjunto de
autorizaes. Essas autorizaes podem ser atribudas aos papis de forma
discricionria ou obrigatria.
Para cada usurio do sistema definido um conjunto de papis que
este pode assumir. Durante sua sesso no sistema (geralmente no incio),
o usurio escolhe os papis que deseja ativar e recebe as autorizaes
correspondentes, vlidas at este desativar os papis correspondentes ou
encerrar sua sesso. Assim, um usurio autorizado pode ativar os papis
de professor ou de aluno dependendo do que deseja fazer no sistema.
Os papis permitem desacoplar os usurios das permisses. Por isso,
um conjunto de papis definido adequadamente bastante estvel, restando
gerncia apenas atribuir a cada usurio os papis a que este tem direito. A
Figura 8.15 apresenta os principais componentes de uma poltica RBAC.
Existem vrios modelos para a implementao de polticas baseadas em
papis, como os apresentados em [Sandhu et al., 1996]. Por exemplo, no
modelo RBAC hierrquico os papis so classificados em uma hierarquia, na
qual os papis superiores herdam as permisses dos papis inferiores. No
c Carlos Maziero
352
8: Mecanismos de controle de acesso
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
professor
diretor
aluno
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
arquivos
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
outros
sujeitos
ou
sistemas
suporte
registros
usurios
ativaes
papis
permisses
objetos
Figura 8.15: Polticas baseadas em papis.

modelo RBAC com restries possvel definir restries ativao de papis,
como o nmero mximo de usurios que podem ativar um determinado
papel simultaneamente ou especificar que dois papis so conflitantes e no
podem ser ativados pelo mesmo usurio simultaneamente.
8.5.6
Mecanismos de controle de acesso
A implementao do controle de acesso em um sistema computacional

deve ser independente das polticas de controle de acesso adotadas. Como
nas demais reas de um sistema operacional, a separao entre mecanismo
e poltica importante, por possibilitar trocar a poltica de controle de
acesso sem ter de modificar a implementao do sistema. A infra-estrutura
de controle de acesso deve ser ao mesmo tempo inviolvel (impossvel de
adulterar ou enganar) e incontornvel (todos os acessos aos recursos do
sistema devem passar por ela).
c Carlos Maziero
353
Infra-estrutura bsica
A arquitetura bsica de uma infra-estrutura de controle de acesso tpica
composta pelos seguintes elementos (Figura 8.16):
Bases de sujeitos e objetos (User/Object Bases): relao dos sujeitos e objetos que compem o sistema, com seus respectivos atributos;
Base de polticas (Policy Base): base de dados contendo as regras que
definem como e quando os objetos podem ser acessados pelos sujeitos,
ou como/quando os sujeitos podem interagir entre si;
Monitor de referncias (Reference monitor): elemento que julga a pertinncia de cada pedido de acesso. Com base em atributos do sujeito e do
objeto (como suas respectivas identidades), nas regras da base de polticas e possivelmente em informaes externas (como horrio, carga
do sistema, etc.), o monitor decide se um acesso deve ser permitido
ou negado;
Mediador (impositor ou Enforcer): elemento que medeia a interao entre
sujeitos e objetos; a cada pedido de acesso a um objeto, o mediador
consulta o monitor de referncias e permite/nega o acesso, conforme a
deciso deste ltimo.
importante observar que os elementos dessa estrutura so componentes
lgicos, que no impem uma forma de implementao rgida. Por exemplo,
em um sistema operacional convencional, o sistema de arquivos possui
sua prpria estrutura de controle de acesso, com permisses de acesso
armazenadas nos prprios arquivos, e um pequeno monitor/mediador
associado a algumas chamadas de sistema, como open e mmap. Outros
recursos (como reas de memria ou semforos) possuem suas prprias
regras e estruturas de controle de acesso, organizadas de forma diversa.
Controle de acesso em UNIX
Os sistemas operacionais do mundo UNIX implementam um sistema
de ACLs bsico bastante rudimentar, no qual existem apenas trs sujeitos:
user (o dono do recurso), group (um grupo de usurios ao qual o recurso
est associado) e others (todos os demais usurios do sistema). Para cada
objeto existem trs possibilidades de acesso: read, write e execute, cuja
c Carlos Maziero
354
sujeitos
objetos
permite
acessos
mediador
aes
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
outros
sujeitos
ou
sistemas
nega
processos
threads
transaes
informaes externas
(horrio, etc)
base de
sujeitos
sujeito,
objeto,
ao
arquivos
deciso
monitor de
referncias
base de
polticas
eventos
para os registros
de auditoria
base de
objetos
Figura 8.16: Estrutura genrica de uma infra-estrutura de controle de acesso.

semntica depende do tipo de objeto (arquivo, diretrio, socket de rede, rea
de memria compartilhada, etc.). Dessa forma, so necessrios apenas 9
bits por arquivo para definir suas permisses bsicas de acesso.
A Figura 8.17 apresenta uma listagem de diretrio tpica em UNIX. Nessa
listagem, o arquivo hello-unix.c pode ser acessado em leitura e escrita por
seu proprietrio (o usurio maziero, com permisses rw-), em leitura pelos
usurios do grupo prof (permisses r--) e em leitura pelos demais usurios
do sistema (permisses r--). J o arquivo hello-unix pode ser acessado em
leitura, escrita e execuo por seu proprietrio (permisses rwx), em leitura
e execuo pelos usurios do grupo prof (permisses r-x) e no pode ser
acessado pelos demais usurios (permisses ---). No caso de diretrios, a
permisso de leitura autoriza a listagem do diretrio, a permisso de escrita
autoriza sua modificao (criao, remoo ou renomeao de arquivos ou
sub-diretrios) e a permisso de execuo autoriza usar aquele diretrio
como diretrio de trabalho ou parte de um caminho.
c Carlos Maziero
355
tipo (arquivo, diretrio, atalho, ...)

permisses (proprietrio)
permisses (grupo)
permisses (terceiros)
nmero de ligaes
proprietrio
grupo
tamanho em bytes
data/hora da ltima modificao
nome
Figura 8.17: Listas de controle de acesso em UNIX.

importante destacar que o controle de acesso normalmente realizado
apenas durante a abertura do arquivo, para a criao de seu descritor em
memria. Isso significa que, uma vez aberto um arquivo por um processo,
este ter acesso ao arquivo enquanto o mantiver aberto, mesmo que as
permisses do arquivo sejam modificadas para impedir esse acesso. O
controle contnuo de acesso a arquivos pouco frequentemente implementado em sistemas operacionais, porque verificar as permisses de acesso a
cada operao de leitura ou escrita teria um forte impacto negativo sobre o
desempenho do sistema.
Dessa forma, um descritor de arquivo aberto pode ser visto como uma
capacidade (vide Seo 8.5.2), pois a posse do descritor permite ao processo
acessar o arquivo referenciado por ele. O processo recebe esse descritor ao
abrir o arquivo e deve apresent-lo a cada acesso subsequente; o descritor
pode ser transferido aos processos filhos ou at mesmo a outros processos,
outorgando a eles o acesso ao arquivo aberto. A mesma estratgia usada
em sockets de rede, semforos e outros mecanismos de IPC.
O padro POSIX 1003.1e definiu ACLs mais detalhadas para o sistema
de arquivos, que permitem definir permisses para usurios e grupos
especficos alm do proprietrio do arquivo. Esse padro parcialmente
implementado em vrios sistemas operacionais, como o Linux e o FreeBSD.
c Carlos Maziero
356
No Linux, os comandos getfacl e setfacl permitem manipular essas

ACLs, como mostra o exemplo a seguir:
1
2
host:~> ll
-rw-r--r-- 1 maziero prof 2450791 2009-06-18 10:47 main.pdf
3
4
5
6
7
8
9
10
host:~> getfacl main.pdf

# file: main.pdf
# owner: maziero
# group: maziero
user::rwgroup::r-other::r--
11
12
host:~> setfacl -m diogo:rw,rafael:rw main.pdf
13
14
15
16
17
18
19
20
21
22
23
host:~> getfacl main.pdf

# file: main.pdf
# owner: maziero
# group: maziero
user::rwuser:diogo:rwuser:rafael:rwgroup::r-mask::rwother::r--
No exemplo, o comando da linha 12 define permisses de leitura e escrita

especficas para os usurios diogo e rafael sobre o arquivo main.pdf. Essas
permisses estendidas so visveis na linha 19 e 20, junto com as permisses
UNIX bsicas (nas linhas 18, 21 e 23).
Controle de acesso em Windows
Os sistemas Windows baseados no ncleo NT (NT, 2000, XP, Vista e sucessores) implementam mecanismos de controle de acesso bastante sofisticados
[Brown, 2000, Russinovich and Solomon, 2004]. Em um sistema Windows,
cada sujeito (computador, usurio, grupo ou domnio) unicamente identificado por um identificador de segurana (SID - Security IDentifier). Cada
c Carlos Maziero
357
sujeito do sistema est associado a um token de acesso, criado no momento

em que o respectivo usurio ou sistema externo se autentica no sistema. A
autenticao e o incio da sesso do usurio so gerenciados pelo LSASS
(Local Security Authority Subsystem), que cria os processos iniciais e os associa
ao token de acesso criado para aquele usurio. Esse token normalmente
herdado pelos processos filhos, at o encerramento da sesso do usurio. Ele
contm o identificador do usurio (SID), dos grupos aos quais ele pertence,
privilgios a ele associados e outras informaes. Privilgios so permisses para realizar operaes genricas, que no dependem de um recurso
especfico, como reiniciar o computador, carregar um driver ou depurar um
processo.
Por outro lado, cada objeto do sistema est associado a um descritor
de segurana (SD - Security Descriptor). Como objetos, so considerados
arquivos e diretrios, processos, impressoras, servios e chaves de registros,
por exemplo. Um descritor de segurana indica o proprietrio e o grupo
primrio do objeto, uma lista de controle de acesso de sistema (SACL - System
ACL), uma lista de controle de acesso discricionria (DACL - Discretionary
ACL) e algumas informaes de controle.
A DACL contm uma lista de regras de controle de acesso ao objeto, na
forma de ACEs (Access Control Entries). Cada ACE contm um identificador
de usurio ou grupo, um modo de autorizao (positiva ou negativa), um
conjunto de permisses (ler, escrever, executar, remover, etc.), sob a forma
de um mapa de bits. Quando um sujeito solicita acesso a um recurso, o
SRM (Security Reference Monitor) compara o token de acesso do sujeito com as
entradas da DACL do objeto, para permitir ou negar o acesso. Como sujeitos
podem pertencer a mais de um grupo e as ACEs podem ser positivas ou
negativas, podem ocorrer conflitos entre as ACEs. Por isso, um mecanismo
de resoluo de conflitos acionado a cada acesso solicitado ao objeto.
A SACL define que tipo de operaes sobre o objeto devem ser registradas
pelo sistema, sendo usada basicamente para para fins de auditoria (Seo
8.6). A estrutura das ACEs de auditoria similar das ACEs da DACL,
embora defina quais aes sobre o objeto em questo devem ser registradas
para quais sujeitos. A Figura 8.18 ilustra alguns dos componentes da
estrutura de controle de acesso dos sistemas Windows.
c Carlos Maziero
358
usurio

recurso
sujeito
logon
Local
Security
Authority
Subsystem
processo
ou
thread
solicitao
de acesso
Security
Reference
Monitor
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
acesso
autorizado
AT
eventos
registros
de
auditoria
access
token
Token ID
Owner SID
Group1 SID
Group2 SID
...
Flags
Privileges
...
SD
eventos
registros
de
auditoria
security
descriptor
Revision number
Owner SID
Group SID
Flags
DACL
ACE
ACE
ACE
ACE
...
SACL
ACE
ACE
ACE
ACE
...
Figura 8.18: Listas de controle de acesso no Windows.

Outros mecanismos
As polticas de segurana bsicas utilizadas na maioria dos sistemas
operacionais so discricionrias, baseadas nas identidades dos usurios e
em listas de controle de acesso. Entretanto, polticas de segurana mais
sofisticadas vm sendo gradualmente agregadas aos sistemas operacionais
mais complexos, visando aumentar sua segurana. Algumas iniciativas
dignas de nota so apresentadas a seguir:
O SELinux um mecanismo de controle de acesso multipolticas, desenvolvido pela NSA (National Security Agency, USA)
[Loscocco and Smalley, 2001] a partir da arquitetura flexvel de segurana Flask (Flux Advanced Security Kernel) [Spencer et al., 1999]. Ele
constitui uma infra-estrutura complexa de segurana para o ncleo
Linux, capaz de aplicar diversos tipos de polticas obrigatrias aos
recursos do sistema operacional. A poltica default do SELinux
baseada em RBAC e DTE, mas ele tambm capaz de implementar
polticas de segurana multi-nvel. O SELinux tem sido criticado
devido sua complexidade, que torna difcil sua compreenso e
configurao. Em consequncia, outros projetos visando adicionar
c Carlos Maziero
359
polticas MAC mais simples e fceis de usar ao ncleo Linux tm sido

propostos, como LIDS, SMACK e AppArmor.
O sistema operacional Windows Vista incorpora uma poltica denominada Mandatory Integrity Control (MIC) que associa aos processos e recursos os nveis de integridade Low, Medium, High e System
[Microsoft, 2007], de forma similar ao modelo de Biba (Seo 8.5.3). Os
processos normais dos usurios so classificados como de integridade
mdia, enquanto o navegador Web e executveis provindos da Internet
so classificados como de integridade baixa. Alm disso, o Vista conta
com o UAC (User Account Control) que aplica uma poltica baseada em
RBAC: um usurio com direitos administrativos inicia sua sesso como
usurio normal, e somente ativa seu papel administrativo quando
necessita efetuar uma ao administrativa.
O projeto TrustedBSD [Watson, 2001] implementa ACLs no padro
POSIX, capacidades POSIX e o suporte a polticas obrigatrias como
Bell LaPadula, Biba, categorias e TE/DTE. Uma verso deste projeto
foi portada para o MacOS X, sendo denominada MacOS X MAC
Framework.
Desenvolvido nos anos 90, o sistema operacional experimental EROS
(Extremely Reliable Operating System) [Shapiro and Hardy, 2002] implementou um modelo de controle de acesso totalmente baseado em
capacidades. Nesse modelo, todas as interfaces dos componentes do
sistema s so acessveis atravs de capacidades, que so usadas para
nomear as interfaces e para controlar seu acesso. O sistema EROS
deriva de desenvolvimentos anteriores feitos no sistema operacional
KeyKOS para a plataforma S/370 [Bomberger et al., 1992].
Em 2009, o sistema operacional experimental SeL4, que estende o
sistema micro-ncleo L4 [Liedtke, 1996] com um modelo de controle
de acesso baseado em capacidades similar ao utilizado no sistema
EROS, tornou-se o primeiro sistema operacional cuja segurana foi
formalmente verificada [Klein et al., 2009]. A verificao formal
uma tcnica de engenharia de software que permite demonstrar
matematicamente que a implementao do sistema corresponde sua
especificao, e que a especificao est completa e sem erros.
c Carlos Maziero
360
8: Mudana de privilgios
O sistema Trusted Solaris [Sun Microsystems, 2000] implementa vrias

polticas de segurana: em MLS (Multi-Level Security), nveis de segurana so associados aos recursos do sistema e aos usurios. Alm
disso, a noo de domnios implementada atravs de compartimentos: um recurso associado a um determinado compartimento s
pode ser acessado por sujeitos no mesmo compartimento. Para limitar
o poder do super-usurio, usada uma poltica de tipo RBAC, que
divide a administrao do sistema em vrios papis de podem ser
atribudos a usurios distintos.
8.5.7
Mudana de privilgios
Normalmente, os processos em um sistema operacional so sujeitos que

representam o usurio que os lanou. Quando um novo processo criado,
ele herda as credenciais de seu processo-pai, ou seja, seus identificadores
de usurio e de grupo. Na maioria dos mecanismos de controle de acesso
usados em sistemas operacionais, as permisses so atribudas aos processos
em funo de suas credenciais. Com isso, normalmente cada novo processo
herda as mesmas permisses de seu processo-pai, pois possui as mesmas
credenciais dele.
O uso de privilgios fixos adequado para o uso normal do sistema, pois
os processos de cada usurio s devem ter acesso aos recursos autorizados
para esse usurio. Entretanto, em algumas situaes esse mecanismo se
mostra inadequado. Por exemplo, caso um usurio precise executar uma
tarefa administrativa, como instalar um novo programa, modificar uma
configurao de rede ou atualizar sua senha, alguns de seus processos
devem possuir permisses para as aes necessrias, como editar arquivos
de configurao do sistema. Os sistemas operacionais atuais oferecem
diversas abordagens para resolver esse problema:
Usurios administrativos : so associadas permisses administrativas s
sesses de trabalho de alguns usurios especficos, permitindo que
seus processos possam efetuar tarefas administrativas, como instalar
softwares ou mudar configuraes. Esta a abordagem utilizada em
alguns sistemas operacionais de amplo uso. Algumas implementaes
definem vrios tipos de usurios administrativos, com diferentes tipos
de privilgios, como acessar dispositivos externos, lanar mquinas
virtuais, reiniciar o sistema, etc. Embora simples, essa soluo falha,
c Carlos Maziero
361
pois se algum programa com contedo malicioso for executado por

um usurio administrativo, ter acesso a todas as suas permisses.
Permisses temporrias : conceder sob demanda a certos processos do
usurio as permisses de que necessitam para realizar aes administrativas; essas permisses podem ser descartadas pelo processo assim
que concluir as aes. Essas permisses podem estar associadas a
papis administrativos (Seo 8.5.5), ativados quando o usurio tiver
necessidade deles. Esta a abordagem usada pela infra-estrutura UAC
(User Access Control) [Microsoft, 2007], na qual um usurio administrativo inicia sua sesso de trabalho como usurio normal, e somente
ativa seu papel administrativo quando necessita efetuar uma ao administrativa, desativando-o imediatamente aps a concluso da ao.
A ativao do papel administrativo pode impor um procedimento de
reautenticao.
Mudana de credenciais : permitir que certos processos do usurio mudem de identidade, assumindo a identidade de algum usurio com
permisses suficientes para realizar a ao desejada; pode ser considerada uma variante da atribuio de permisses temporrias. O
exemplo mais conhecido de implementao desta abordagem so os
flags setuid e setgid do UNIX, explicados a seguir.
Monitores : definir processos privilegiados, chamados monitores ou supervisores, recebem pedidos de aes administrativas dos processos
no-privilegiados, atravs de uma API pr-definida; os pedidos dos
processos normais so validados e atendidos. Esta a abordagem
definida como separao de privilgios em [Provos et al., 2003], e tambm usada na infra-estrutura PolicyKit, usada para autorizar tarefas
administrativas em ambientes desktop Linux.
Um mecanismo amplamente usado para mudana de credenciais consiste
dos flags setuid e setgid dos sistemas UNIX. Se um arquivo executvel tiver
o flag setuid habilitado (indicado pelo caractere s em suas permisses
de usurio), seus processos assumiro as credenciais do proprietrio do
arquivo. Portanto, se o proprietrio de um arquivo executvel for o usurio
root, os processos lanados a partir dele tero todos os privilgios do usurio
root, independente de quem o tiver lanado. De forma similar, processos
lanados a partir de um arquivo executvel com o flag setgid habilitado
c Carlos Maziero
362
tero as credenciais do grupo associado ao arquivo. A Figura 8.19 ilustra esse

mecanismo: o primeiro caso representa um executvel normal (sem esses
flags habilitados); um processo filho lanado a partir do executvel possui as
mesmas credenciais de seu pai. No segundo caso, o executvel pertence ao
usurio root e tem o flag setuid habilitado; assim, o processo filho assume a
identidade do usurio root e, em consequncia, suas permisses de acesso.
No ltimo caso, o executvel pertence ao usurio root e tem o flag setgid
habilitado; assim, o processo filho pertencer ao grupo mail.
processo pai
arquivo executvel
processo filho
Permisses e proprietrio/grupo do arquivo
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi
flag setuid habilitado
flag setgid habilitado
Figura 8.19: Funcionamento dos flags setuid e setgid do UNIX.

Os flags setuid e setgid so muito utilizados em programas administrativos no UNIX, como troca de senha e agendamento de tarefas, sempre que
for necessrio efetuar uma operao inacessvel a usurios normais, como
modificar o arquivo de senhas. Todavia, esse mecanismo pode ser perigoso,
pois o processo filho recebe todos os privilgios do proprietrio do arquivo,
o que contraria o princpio do privilgio mnimo. Por exemplo, o programa
c Carlos Maziero
363
passwd deveria somente receber a autorizao para modificar o arquivo

de senhas (/etc/passwd) e nada mais, pois o super-usurio (root user) tem
acesso a todos os recursos do sistema e pode efetuar todas as operaes
que desejar. Se o programa passwd contiver erros de programao, ele
pode ser induzido pelo seu usurio a efetuar aes no-previstas, visando
comprometer a segurana do sistema (vide Seo 8.2.3).
Uma alternativa mais segura aos flags setuid e setgid so os privilgios POSIX (POSIX Capabilities7 ), definidos no padro POSIX 1003.1e
[Gallmeister, 1994]. Nessa abordagem, o poder absoluto do super-usurio
dividido em um grande nmero de pequenos privilgios especficos, que
podem ser atribudos a certos processos do sistema. Como medida adicional de proteo, cada processo pode ativar/desativar os privilgios que
possui em funo de sua necessidade. Vrios sistemas UNIX implementam
privilgios POSIX, como o caso do Linux, que implementa:
CAP_CHOWN: alterar o proprietrio de um arquivo qualquer;
CAP_USER_DEV: abrir dispositivos;
CAP_USER_FIFO: usar pipes (comunicao);
CAP_USER_SOCK: abrir sockets de rede;
CAP_NET_BIND_SERVICE: abrir portas de rede com nmero abaixo de
1024;
CAP_NET_RAW: abrir sockets de baixo nvel (raw sockets);
CAP_KILL: enviar sinais para processos de outros usurios.
... (outros +30 privilgios)
Para cada processo so definidos trs conjuntos de privilgios: Permitidos
(P), Efetivos (E) e Herdveis (H). Os privilgios permitidos so aqueles que
o processo pode ativar quando desejar, enquanto os efetivos so aqueles
ativados no momento (respeitando-se E P). O conjunto de privilgios
herdveis H usado no clculo dos privilgios transmitidos aos processos
7
O padro POSIX usou indevidamente o termo capacidade para definir o que na

verdade so privilgios associados aos processos. O uso indevido do termo POSIX
Capabilities perdura at hoje em vrios sistemas, como o caso do Linux.
c Carlos Maziero
364
8: Auditoria
filhos. Os privilgios POSIX tambm podem ser atribudos a programas

executveis em disco, substituindo os tradicionais (e perigosos) flags setuid
e setgid. Assim, quando um executvel for lanado, o novo processo recebe
um conjunto de privilgios calculado a partir dos privilgios atribudos
ao arquivo executvel e aqueles herdados do processo-pai que o criou
[Bovet and Cesati, 2005].
Um caso especial de mudana de credenciais ocorre em algumas circunstncias, quando necessrio reduzir as permisses de um processo.
Por exemplo, o processo responsvel pela autenticao de usurios em um
sistema operacional deve criar novos processos para iniciar a sesso de
trabalho de cada usurio. O processo autenticador geralmente executa com
privilgios elevados, para poder acessar a bases de dados de autenticao
dos usurios, enquanto os novos processos devem receber as credenciais
do usurio autenticado, que normalmente tem menos privilgios. Em
UNIX, um processo pode solicitar a mudana de suas credenciais atravs da
chamada de sistema setuid(), entre outras. Em Windows, o mecanismo
conhecido como impersonation permite a um processo ou thread abandonar
temporariamente seu token de acesso e assumir outro, para realizar uma tarefa em nome do sujeito correspondente [Russinovich and Solomon, 2004].
8.6
Auditoria
Na rea de segurana de sistemas, o termo auditar significa recolher

dados sobre o funcionamento de um sistema ou aplicao e analis-los para
descobrir vulnerabilidades ou violaes de segurana, ou para examinar
violaes j constatadas, buscando suas causas e possveis consequncias8
[Sandhu and Samarati, 1996]. Os dois pontos-chave da auditoria so portanto a coleta de dados e a anlise desses dados, que sero discutidas a
seguir.
8.6.1
Coleta de dados
Um sistema computacional em funcionamento processa uma grande

quantidade de eventos. Destes, alguns podem ser de importncia para a
segurana do sistema, como a autenticao de um usurio (ou uma tentativa
malsucedida de autenticao), uma mudana de credenciais, o lanamento
8
A anlise de violaes j ocorridas comumente conhecida como anlise post-mortem.
c Carlos Maziero
365
8: Coleta de dados
ou encerramento de um servio, etc. Os dados desses eventos devem ser

coletados a partir de suas fontes e registrados de forma adequada para a
anlise e arquivamento.
Dependendo da natureza do evento, a coleta de seus dados pode ser feita
no nvel da aplicao, de sub-sistema ou do ncleo do sistema operacional:
Aplicao : eventos internos aplicao, cuja semntica especfica ao
seu contexto. Por exemplo, as aes realizadas por um servidor
HTTP, como pginas fornecidas, pginas no encontradas, erros de
autenticao, pedidos de operaes no suportadas, etc. Normalmente
esses eventos so registrados pela prpria aplicao, muitas vezes
usando formatos prprios para os dados.
Sub-sistema : eventos no especficos a uma aplicao, mas que ocorrem no
espao de usurio do sistema operacional. Exemplos desses eventos
so a autenticao de usurios (ou erros de autenticao), lanamento
ou encerramento de servios do sistema, atualizaes de softwares
ou de bibliotecas, criao ou remoo de usurios, etc. O registro
desses eventos normalmente fica a cargo dos processos ou bibliotecas
responsveis pelos respectivos sub-sistemas.
Ncleo : eventos que ocorrem dentro do ncleo do sistema, sendo inacessveis aos processos. o caso dos eventos envolvendo o hardware, como
a deteco de erros ou mudana de configuraes, e de outros eventos
internos do ncleo, como a criao de sockets de rede, semforos, rea
de memria compartilhada, reinicializao do sistema, etc.
Um aspecto importante da coleta de dados para auditoria sua forma
de representao. A abordagem mais antiga e comum, amplamente disseminada, o uso de arquivos de registro (logfiles). Um arquivo de registro
contm uma sequncia cronolgica de descries textuais de eventos associados a uma fonte de dados, geralmente uma linha por evento. Um
exemplo clssico dessa abordagem so os arquivos de registro do sistema
UNIX; a listagem a seguir apresenta um trecho do contedo do arquivo
/var/log/security, geralmente usado para reportar eventos associados
autenticao de usurios:
c Carlos Maziero
366
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
...
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
Sep
...
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
23:02:09
23:19:57
23:34:14
23:57:16
00:08:16
00:35:24
00:42:19
00:49:06
00:53:40
00:53:55
01:08:43
01:12:41
01:12:41
01:12:41
01:38:26
02:18:29
02:18:29
02:18:29
09:06:33
06:06:34
06:06:34
06:06:57
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
espec
8: Coleta de dados
sudo: e89602174 : user NOT in sudoers ; TTY=pts/1 ; USER=root ; COMMAND=/bi

userhelper[20480]: running /sbin/halt with user_u:system_r:hotplug_t cont
sshd[6302]: pam_unix(sshd:auth): failure; rhost=210.210.102.173 user=root
sshd[6302]: Failed password for root from 210.103.210.173 port 14938 ssh2
sshd[6303]: Received disconnect from 210.103.210.173: 11: Bye Bye
gdm[9447]: pam_unix(gdm:session): session opened for user rodr by (uid=0)
gdm[857]: pam_unix(gdm:session): session closed for user rafael3
userhelper[11031]: running /sbin/halt with user_u:system_r:hotplug_t cont
gdm[12199]: pam_unix(gdm:session): session opened for user rafael3 by (uid=
gdm[12199]: pam_unix(gdm:session): session closed for user rafael3
gdm[9447]: pam_unix(gdm:session): session closed for user rodr
sshd[14125]: Accepted password for rodr from 189.30.227.212 port 1061 ssh2
sshd[14125]: pam_unix(sshd:session): session opened for user rodr by (uid=0
sshd[14127]: subsystem request for sftp
sshd[14125]: pam_unix(sshd:session): session closed for user rodr
sshd[17048]: Accepted password for e89062004 from 20.0.0.56 port 54233 ssh2
sshd[17048]: pam_unix(sshd:session): session opened for user e89062004 by (
sshd[17048]: pam_unix(sshd:session): session closed for user e89062004
sshd[25002]: Postponed publickey for mzr from 159.71.224.62 port 52372 ssh2
sshd[25001]: Accepted publickey for mzr from 159.71.224.62 port 52372 ssh2
sshd[25001]: pam_unix(sshd:session): session opened for user mzr by (uid=0)
su: pam_unix(su-l:session): session opened for user root by mzr(uid=500)
A infra-estrutura tradicional de registro de eventos dos sistemas UNIX

constituda por um daemon9 chamado syslogd (System Log Daemon).
Esse daemon usa um socket local e um socket UDP para receber mensagens
descrevendo eventos, geradas pelos demais sub-sistemas e aplicaes atravs
de uma biblioteca especfica. Os eventos so descritos por mensagens de
texto e so rotulados por suas fontes em servios (AUTH, KERN, MAIL, etc.) e
nveis (INFO, WARNING, ALERT, etc.). A partir de seu arquivo de configurao, o
processo syslogd registra a data de cada evento recebido e decide seu destino:
armazenar em um arquivo, enviar a um terminal, avisar o administrador,
ativar um programa externo ou enviar o evento a um daemon em outro
computador so as principais possibilidades. A Figura 8.20 apresenta os
principais componentes dessa arquitetura.
Os sistemas Windows mais recentes usam uma arquitetura similar,
embora mais sofisticada do ponto de vista do formato dos dados, pois os
eventos so descritos em formato XML (a partir do Windows Vista). O
servio Windows Event Log assume o papel de centralizador de eventos,
recebendo mensagens de vrias fontes, entre elas os componentes do
subsistema de segurana (LSASS e SRM, Seo 8.5.6), as aplicaes e o
9
Processo que executa em segundo plano, sem estar associado a uma interface com o
usurio, como um terminal ou janela.
c Carlos Maziero
367
8: Coleta de dados
terminal
servio
de e-mail
servio
SSH
servio de
autenticao
syslogd
rede
eventos
kernel
logger
servio de
impresso
eventos do
ncleo
ncleo
root:~>
syslog: system reboot
syslog:
shutdown now
terminal
logfiles
Illenihild
ubitatquin
Illenihild
ullamscientiam
ubitatquin
habet(Nadaduvi
Illenihild
ullamscientiam
daquemnadasabe
ubitatquin
habet(Nadaduvi
)Illenihildubi
ullamscientiam
daquemnadasabe
tatquinullamsc
habet(Nadaduvi
)Illenihildubi
ientiamhabet(N
daquemnadasabe
tatquinullamsc
adaduvidaquemn
)Illenihildubi
ientiamhabet(N
adasabe)Illeni
tatquinullamsc
adaduvidaquemn
hildubitatquin
ientiamhabet(N
adasabe)Illeni
ullamscientiam
adaduvidaquemn
hildubitatquin
habet(Nadaduvi
adasabe)Illeni
ullamscientiam
hildubitatquin
habet(Nadaduvi
ullamscientiam
habet(Nadaduvi
syslogd
Figura 8.20: O servio de logs em UNIX.

prprio ncleo. Conforme visto anteriormente, o componente LSASS gera
eventos relativos autenticao dos usurios, enquanto o SRM registra os
acessos a cada objeto de acordo com as regras de auditoria definidas em sua
SACL (System ACLs). Alm disso, aplicaes externas podem se registrar
junto ao sistema de logs para receber eventos de interesse, atravs de uma
interface de acesso baseada no modelo publish/subscribe.
Alm dos exemplos aqui apresentados, muitos sistemas operacionais
implementam arquiteturas especficas para auditoria, como o caso do BSM
(Basic Security Module) do sistema Solaris e sua implementao OpenBSM
para o sistema operacional OpenBSD. O sistema MacOS X tambm prov
uma infra-estrutura de auditoria, na qual o administrador pode registrar os
eventos de seu interesse e habilitar a gerao de registros.
Alm da coleta de eventos do sistema medida em que eles ocorrem,
outras formas de coleta de dados para auditoria so frequentes. Por exemplo,
ferramentas de segurana podem vasculhar o sistema de arquivos em busca
de arquivos com contedo malicioso, ou varrer as portas de rede para
procurar servios suspeitos.
c Carlos Maziero
368
8.6.2
8: Anlise de dados
Anlise de dados
Uma vez registrada a ocorrncia de um evento de interesse para a segurana do sistema, deve-se proceder sua anlise. O objetivo dessa anlise
sobretudo identificar possveis violaes da segurana em andamento ou j
ocorridas. Essa anlise pode ser feita sobre os registros dos eventos medida
em que so gerados (chamada anlise online) ou sobre registros previamente
armazenados (anlise offline). A anlise online visa detectar problemas de
segurana com rapidez, para evitar que comprometam o sistema. Como
essa anlise deve ser feita simultaneamente ao funcionamento do sistema,
importante que seja rpida e leve, para no prejudicar o desempenho do
sistema nem interferir nas operaes em andamento. Um exemplo tpico de
anlise online so os anti-vrus, que analisam os arquivos medida em que
estes so acessados pelos usurios.
Por sua vez, a anlise offline realizada com dados previamente coletados,
possivelmente de vrios sistemas. Como no tem compromisso com uma
resposta imediata, pode ser mais profunda e detalhada, permitindo o uso de
tcnicas de minerao de dados para buscar correlaes entre os registros,
que possam levar descoberta de problemas de segurana mais sutis. A
anlise offline usada em sistemas de deteco de intruso, por exemplo,
para analisar a histria do comportamento de cada usurio. Alm disso,
frequentemente usada em sistemas de informao bancrios, para se analisar
o padro de uso dos cartes de dbito e crdito dos correntista e identificar
fraudes.
As ferramentas de anlise de registros de segurana podem adotar
basicamente duas abordagens: anlise por assinaturas ou anlise por
anomalias. Na anlise por assinaturas, a ferramenta tem acesso a uma base de
dados contendo informaes sobre os problemas de segurana conhecidos
que deve procurar. Se algum evento ou registro se encaixar nos padres
descritos nessa base, ele considerado uma violao de segurana. Um
exemplo clssico dessa abordagem so os programas anti-vrus: um antivrus tpico varre o sistema de arquivos em busca de contedos maliciosos.
O contedo de cada arquivo verificado junto a uma base de assinaturas,
que contm descries detalhadas dos vrus conhecidos pelo software; se
o contedo de um arquivo coincidir com uma assinatura da base, aquele
arquivo considerado suspeito. Um problema com essa forma de anlise
sua incapacidade de detectar novas ameaas, como vrus desconhecidos,
cuja assinatura no esteja na base.
c Carlos Maziero
369
8: Auditoria preventiva
Por outro lado, uma ferramenta de anlise por anomalias conta com
uma base de dados descrevendo o que se espera como comportamento ou
contedo normal do sistema. Eventos ou registros que no se encaixarem
nesses padres de normalidade so considerados como violaes potenciais
da segurana, sendo reportados ao administrador do sistema. A anlise
por anomalias, tambm chamada de anlise baseada em heursticas,
utilizada em certos tipos de anti-vrus e sistemas de deteco de intruso,
para detectar vrus ou ataques ainda desconhecidos. Tambm muito usada
em sistemas de informao bancrios, para detectar fraudes envolvendo o
uso das contas e cartes bancrios. O maior problema com esta tcnica
caracterizar corretamente o que se espera como comportamento normal,
o que pode ocasionar muitos erros.
8.6.3
Auditoria preventiva
Alm da coleta e anlise de dados sobre o funcionamento do sistema, a

auditoria pode agir de forma preventiva, buscando problemas potenciais
que possam comprometer a segurana do sistema. H um grande nmero
de ferramentas de auditoria, que abordam aspectos diversos da segurana
do sistema, entre elas [Pfleeger and Pfleeger, 2006]:
Vulnerability scanner: verifica os softwares instalados no sistema e
confronta suas verses com uma base de dados de vulnerabilidades
conhecidas, para identificar possveis fragilidades. Pode tambm
investigar as principais configuraes do sistema, com o mesmo
objetivo. Como ferramentas deste tipo podem ser citadas: Metasploit,
Nessus Security Scanner e SAINT (System Administrators Integrated
Network Tool).
Port scanner: analisa as portas de rede abertas em um computador
remoto, buscando identificar os servios de rede oferecidos pela
mquina, as verses do softwares que atendem esses servios e a
identificao do prprio sistema operacional subjacente. O NMap
provavelmente o scanner de portas mais conhecido atualmente.
Password cracker: conforme visto na Seo 8.4.3, as senhas dos usurios
de um sistema so armazenadas na forma de resumos criptogrficos,
para aumentar sua segurana. Um quebrador de senhas tem por
finalidade tentar descobrir as senhas dos usurios, para avaliar sua
c Carlos Maziero
370
8: Auditoria preventiva
robustez. A tcnica normalmente usada por estas ferramentas o

ataque do dicionrio, que consiste em testar um grande nmero de
palavras conhecidas, suas variantes e combinaes, confrontando seus
resumos com os resumos das senhas armazenadas. Quebradores de
senhas bem conhecidos so o John the Ripper para UNIX e Cain and
Abel para ambientes Windows.
Rootkit scanner: visa detectar a presena de rootkits (vide Seo 8.2.2)
em um sistema, normalmente usando uma tcnica offline baseada
em assinaturas. Como os rootkits podem comprometer at o ncleo
do sistema operacional instalado no computador, normalmente as
ferramentas de deteco devem ser aplicadas a partir de outro sistema,
carregado a partir de uma mdia externa confivel (CD ou DVD).
Verificador de integridade: a segurana do sistema operacional depende
da integridade do ncleo e dos utilitrios necessrios administrao
do sistema. Os verificadores de integridade so programas que analisam periodicamente os principais arquivos do sistema operacional,
comparando seu contedo com informaes previamente coletadas.
Para agilizar a verificao de integridade so utilizadas somas de
verificao (checksums) ou resumos criptogrficos como o MD5 e SHA1.
Essa verificao de integridade pode se estender a outros objetos do
sistema, como a tabela de chamadas de sistema, as portas de rede
abertas, os processos de sistema em execuo, o cadastro de softwares
instalados, etc. Um exemplo clssico de ferramenta de verificao de
integridade o Tripwire [Tripwire, 2003], mas existem diversas outras
ferramentas mais recentes com propsitos similares.
Captulo 9
Virtualizao de sistemas
As tecnologias de virtualizao do ambiente de execuo de aplicaes ou de plataformas de hardware tm sido objeto da ateno
crescente de pesquisadores, fabricantes de hardware/software, administradores de sistemas e usurios avanados. Os recentes avanos
nessa rea permitem usar mquinas virtuais com os mais diversos
objetivos, como a segurana, a compatibilidade de aplicaes legadas
ou a consolidao de servidores. Este captulo apresenta os principais
conceitos, arquiteturas e implementaes de ambientes virtuais de
execuo, como mquinas virtuais, emuladores e contineres.
9.1
Conceitos bsicos
As tecnologias de virtualizao do ambiente de execuo de aplicaes

ou de plataformas de hardware tm sido objeto da ateno crescente de
pesquisadores, fabricantes de hardware/software, administradores de sistemas e usurios avanados. A virtualizao de recursos um conceito
relativamente antigo, mas os recentes avanos nessa rea permitem usar
mquinas virtuais com os mais diversos objetivos, como a segurana, a
compatibilidade de aplicaes legadas ou a consolidao de servidores. Este
captulo apresenta os principais conceitos, arquiteturas e tcnicas usadas
para a implementao de ambientes virtuais de execuo.
c Carlos Maziero
372
9.1.1
9: Um breve histrico
Um breve histrico
O conceito de mquina virtual no recente. Os primeiros passos

na construo de ambientes de mquinas virtuais comearam na dcada
de 1960, quando a IBM desenvolveu o sistema operacional experimental
M44/44X. A partir dele, a IBM desenvolveu vrios sistemas comerciais
suportando virtualizao, entre os quais o famoso OS/370 [Goldberg, 1973,
Goldberg and Mager, 1979]. A tendncia dominante nos sistemas naquela
poca era fornecer a cada usurio um ambiente mono-usurio completo, com
seu prprio sistema operacional e aplicaes, completamente independente
e desvinculado dos ambientes dos demais usurios.
Na dcada de 1970, os pesquisadores Popek & Goldberg formalizaram
vrios conceitos associados s mquinas virtuais, e definiram as condies
necessrias para que uma plataforma de hardware suporte de forma eficiente
a virtualizao [Popek and Goldberg, 1974]; essas condies so discutidas
em detalhe na Seo 9.2.1. Nessa mesma poca surgem as primeiras
experincias concretas de utilizao de mquinas virtuais para a execuo
de aplicaes, com o ambiente UCSD p-System, no qual programas Pascal
so compilados para execuo sobre um hardware abstrato denominado
P-Machine.
Na dcada de 1980, com a popularizao de plataformas de hardware
baratas como o PC, a virtualizao perdeu importncia. Afinal, era mais
barato, simples e verstil fornecer um computador completo a cada usurio,
que investir em sistemas de grande porte, caros e complexos. Alm disso, o
hardware do PC tinha desempenho modesto e no provia suporte adequado
virtualizao, o que inibiu o uso de ambientes virtuais nessas plataformas.
Com o aumento de desempenho e funcionalidades do hardware PC e o
surgimento da linguagem Java, no incio dos anos 90, o interesse pelas tecnologias de virtualizao voltou tona. Apesar da plataforma PC Intel ainda
no oferecer um suporte adequado virtualizao, solues engenhosas
como as adotadas pela empresa VMWare permitiram a virtualizao nessa
plataforma, embora com desempenho relativamente modesto. Atualmente,
as solues de virtualizao de linguagens e de plataformas vm despertando grande interesse do mercado. Vrias linguagens so compiladas para
mquinas virtuais portveis e os processadores mais recentes trazem um
suporte nativo virtualizao.
c Carlos Maziero
373
9.1.2
9: Interfaces de sistema
Interfaces de sistema
Uma mquina real formada por vrios componentes fsicos que fornecem operaes para o sistema operacional e suas aplicaes. Iniciando pelo
ncleo do sistema real, o processador central (CPU) e o chipset da placa-me
fornecem um conjunto de instrues e outros elementos fundamentais para
o processamento de dados, alocao de memria e processamento de entrada/sada. Os sistemas de computadores so projetados com basicamente
trs componentes: hardware, sistema operacional e aplicaes. O papel do
hardware executar as operaes solicitadas pelas aplicaes atravs do
sistema operacional. O sistema operacional recebe as solicitaes das operaes (por meio das chamadas de sistema) e controla o acesso ao hardware
principalmente nos casos em que os componentes so compartilhados,
como o sistema de memria e os dispositivos de entrada/sada.
Os sistemas de computao convencionais so caracterizados por nveis
de abstrao crescentes e interfaces bem definidas entre eles. As abstraes
oferecidas pelo sistema s aplicaes so construdas de forma incremental,
em nveis separados por interfaces bem definidas e relativamente padronizadas. Cada interface encapsula as abstraes dos nveis inferiores, permitindo
assim o desenvolvimento independente dos vrios nveis, o que simplifica
a construo e evoluo dos sistemas. As interfaces existentes entre os
componentes de um sistema de computao tpico so:
Conjunto de instrues (ISA Instruction Set Architecture): a interface
bsica entre o hardware e o software, sendo constituda pelas instrues
em cdigo de mquina aceitas pelo processador e todas as operaes
de acesso aos recursos do hardware (acesso fsico memria, s portas
de entrada/sada, ao relgio do sistema, etc.). Essa interface dividida
em duas partes:
Instrues de usurio (User ISA): compreende as instrues do
processador e demais itens de hardware acessveis aos programas
do usurio, que executam com o processador operando em modo
no-privilegiado;
Instrues de sistema (System ISA): compreende as instrues do
processador e demais itens de hardware, unicamente acessveis
ao ncleo do sistema operacional, que executa em modo privilegiado;
c Carlos Maziero
374
9: Compatibilidade entre interfaces
Chamadas de sistema (syscalls): o conjunto de operaes oferecidas pelo

ncleo do sistema operacional aos processos dos usurios. Essas chamadas permitem um acesso controlado das aplicaes aos dispositivos
perifricos, memria e s instrues privilegiadas do processador.
Chamadas de bibliotecas (libcalls): bibliotecas oferecem um grande nmero de funes para simplificar a construo de programas; alm
disso, muitas chamadas de biblioteca encapsulam chamadas do sistema operacional, para tornar seu uso mais simples. Cada biblioteca
possui uma interface prpria, denominada Interface de Programao de
Aplicaes (API Application Programming Interface). Exemplos tpicos
de bibliotecas so a LibC do UNIX (que oferece funes como fopen e
printf), a GTK+ (Gimp ToolKit, que permite a construo de interfaces
grficas) e a SDL (Simple DirectMedia Layer, para a manipulao de
udio e vdeo).
A Figura 9.1 apresenta essa viso conceitual da arquitetura de um sistema
computacional, com seus vrios componentes e as respectivas interfaces
entre eles.
aplicaes de usurio
bibliotecas
chamadas de biblioteca
chamadas de sistema
system ISA
ncleo do SO
user ISA
hardware
Figura 9.1: Componentes e interfaces de um sistema computacional.
9.1.3
Compatibilidade entre interfaces
Para que programas e bibliotecas possam executar sobre uma determinada plataforma, necessrio que tenham sido compilados para ela,
respeitando o conjunto de instrues do processador em modo usurio
(User ISA) e o conjunto de chamadas de sistema oferecido pelo sistema
operacional. A viso conjunta dessas duas interfaces (User ISA + syscalls)
denominada Interface Binria de Aplicao (ABI Application Binary Interface).
c Carlos Maziero
375
Da mesma forma, um sistema operacional s poder executar sobre uma

plataforma de hardware se tiver sido construdo e compilado de forma a
respeitar sua interface ISA (User/System ISA). A Figura 9.2 representa essas
duas interfaces.
aplicaes de usurio
aplicaes de usurio
bibliotecas
bibliotecas
ABI
ncleo do SO
ncleo do SO
ISA
hardware
hardware
Figura 9.2: Interfaces de sistema ISA e ABI [Smith and Nair, 2004].
Nos sistemas computacionais de mercado atuais, as interfaces de baixo
nvel ISA e ABI so normalmente fixas, ou pouco flexveis. Geralmente
no possvel criar novas instrues de processador ou novas chamadas
de sistema operacional, ou mesmo mudar sua semntica para atender s
necessidades especficas de uma determinada aplicao. Mesmo se isso
fosse possvel, teria de ser feito com cautela, para no comprometer o
funcionamento de outras aplicaes.
Os sistemas operacionais, assim como as aplicaes, so projetados para
aproveitar o mximo dos recursos que o hardware fornece. Normalmente
os projetistas de hardware, sistema operacional e aplicaes trabalham de
forma independente (em empresas e tempos diferentes). Por isso, esses
trabalhos independentes geraram, ao longo dos anos, vrias plataformas
computacionais diferentes e incompatveis entre si.
Observa-se ento que, embora a definio de interfaces seja til, por
facilitar o desenvolvimento independente dos vrios componentes do sistema, torna pouco flexveis as interaes entre eles: um sistema operacional
s funciona sobre o hardware (ISA) para o qual foi construdo, uma biblioteca s funciona sobre a ABI para a qual foi projetada e uma aplicao
tem de obedecer a ABIs/APIs pr-definidas. A Figura 9.3, extrada de
[Smith and Nair, 2004], ilustra esses problemas de compatibilidade entre
interfaces.
A baixa flexibilidade na interao entre as interfaces dos componentes
de um sistema computacional traz vrios problemas [Smith and Nair, 2004]:
c Carlos Maziero
376
Aplics Solaris
Aplics Windows
Aplics Linux
Solaris
Windows
Linux
Sparc
x86
Aplics Windows
Windows
x86
Aplics Windows
Problemas!
Linux
Sparc
Figura 9.3:
Problemas
[Smith and Nair, 2004].
x86
de
compatibilidade
entre
interfaces
Baixa portabilidade: a mobilidade de cdigo e sua interoperabilidade

so requisitos importantes dos sistemas atuais, que apresentam grande
conectividade de rede e diversidade de plataformas. A rigidez das
interfaces de sistema atuais dificulta sua construo, por acoplar excessivamente as aplicaes aos sistemas operacionais e aos componentes
do hardware.
Barreiras de inovao: a presena de interfaces rgidas dificulta a construo de novas formas de interao entre as aplicaes e os dispositivos
de hardware (e com os usurios, por consequncia). Alm disso, as
interfaces apresentam uma grande inrcia evoluo, por conta da
necessidade de suporte s aplicaes j existentes.
Otimizaes inter-componentes: aplicaes, bibliotecas, sistemas operacionais e hardware so desenvolvidos por grupos distintos, geralmente
com pouca interao entre eles. A presena de interfaces rgidas a
respeitar entre os componentes leva cada grupo a trabalhar de forma
isolada, o que diminui a possibilidade de otimizaes que envolvam
mais de um componente.
Essas dificuldades levaram investigao de outras formas de relacionamento entre os componentes de um sistema computacional. Uma das
abordagens mais promissoras nesse sentido o uso da virtualizao, que
ser apresentada na prxima seo.
c Carlos Maziero
377
9.1.4
9: Virtualizao de interfaces
Virtualizao de interfaces
Conforme visto, as interfaces padronizadas entre os componentes do

sistema de computao permitem o desenvolvimento independente dos
mesmos, mas tambm so fonte de problemas de interoperabilidade, devido
sua pouca flexibilidade. Por isso, no possvel executar diretamente em
um processador Intel/AMD uma aplicao compilada para um processador
ARM: as instrues em linguagem de mquina do programa no sero
compreendidas pelo processador Intel. Da mesma forma, no possvel
executar diretamente em Linux uma aplicao escrita para um sistema
Windows, pois as chamadas de sistema emitidas pelo programa Windows
no sero compreendidas pelo sistema operacional Linux subjacente.
Todavia, possvel contornar esses problemas de compatibilidade atravs
de uma camada de virtualizao construda em software. Usando os servios
oferecidos por uma determinada interface de sistema, possvel construir
uma camada de software que oferea aos demais componentes uma outra
interface. Essa camada de software permitir o acoplamento entre interfaces
distintas, de forma que um programa desenvolvido para a plataforma A
possa executar sobre uma plataforma distinta B.
Usando os servios oferecidos por uma determinada interface de sistema,
a camada de virtualizao constri outra interface de mesmo nvel, de acordo
com as necessidades dos componentes de sistema que faro uso dela. A
nova interface de sistema, vista atravs dessa camada de virtualizao,
denominada mquina virtual. A camada de virtualizao em si denominada
hipervisor ou monitor de mquina virtual.
A Figura 9.4, extrada de [Smith and Nair, 2004], apresenta um exemplo
de mquina virtual, onde um hipervisor permite executar um sistema
operacional Windows e suas aplicaes sobre uma plataforma de hardware
Sparc, distinta daquela para a qual esse sistema operacional foi projetado
(Intel/AMD).
Um ambiente de mquina virtual consiste de trs partes bsicas, que
podem ser observadas na Figura 9.4:
O sistema real, nativo ou hospedeiro (host system), que contm os
recursos reais de hardware e software do sistema;
o sistema virtual, tambm denominado sistema convidado (guest system),
que executa sobre o sistema virtualizado; em alguns casos, vrios
c Carlos Maziero
378
sistema
convidado
monitor
sistema
hospedeiro
9: Virtualizao de interfaces
Aplics Windows
Aplics Windows
Windows
Windows
camada de
virtualizao
Sparc
x86
Mquina
Virtual
Figura 9.4: Uma mquina virtual [Smith and Nair, 2004].

sistemas virtuais podem coexistir, executando simultaneamente sobre
o mesmo sistema real;
a camada de virtualizao, chamada hipervisor ou monitor (VMM
Virtual Machine Monitor), que constri as interfaces virtuais a partir da
interface real.
importante ressaltar a diferena entre os termos virtualizao e emulao. A emulao na verdade uma forma de virtualizao: quando
um hipervisor virtualiza integralmente uma interface de hardware ou de
sistema operacional, geralmente chamado de emulador. Por exemplo, a
mquina virtual Java, que constri um ambiente completo para a execuo
de bytecodes a partir de um processador real que no executa bytecodes, pode
ser considerada um emulador.
A virtualizao abre uma srie de possibilidades interessantes para a
composio de um sistema de computao, como por exemplo (Figura 9.5):
Emulao de hardware: um sistema operacional convidado e suas
aplicaes, desenvolvidas para uma plataforma de hardware A, so
executadas sobre uma plataforma de hardware distinta B.
Emulao de sistema operacional: aplicaes construdas para um sistema
operacional X so executadas sobre outro sistema operacional Y.
Otimizao dinmica: as instrues de mquina das aplicaes so
traduzidas durante a execuo em outras instrues mais eficientes
para a mesma plataforma.
Replicao de hardware: so criadas vrias instncias virtuais de um
mesmo hardware real, cada uma executando seu prprio sistema
operacional convidado e suas respectivas aplicaes.
c Carlos Maziero
379
Aplicaes
SO
9: Virtualizao versus abstrao
Aplicaes
Aplicaes
Aplics
hipervisor
OS 1
Aplics
OS 2
SO
hipervisor
hv
SO
Sparc 1
hardware
hardware 2
hardware 2
emulao
de hardware
emulao do SO
otimizao dinmica
hipervisor
hardware 2
replicao
de hardware
Figura 9.5: Possibilidades de virtualizao [Smith and Nair, 2004].
9.1.5
Virtualizao versus abstrao
Embora a virtualizao possa ser vista como um tipo de abstrao, existe

uma clara diferena entre os termos abstrao e virtualizao, no contexto de sistemas operacionais [Smith and Nair, 2004]. Um dos principais
objetivos dos sistemas operacionais oferecer uma viso de alto nvel dos
recursos de hardware, que seja mais simples de usar e menos dependente
das tecnologias subjacentes. Essa viso abstrata dos recursos construda
de forma incremental, em nveis de abstrao crescentes. Exemplos tpicos
dessa estruturao em nveis de abstrao so os subsistemas de rede e de
disco em um sistema operacional convencional. No sub-sistema de arquivos,
cada nvel de abstrao trata de um problema: interao com o dispositivo
fsico de armazenamento, escalonamento de acessos ao dispositivo, gerncia
de buffers e caches, alocao de arquivos, diretrios, controle de acesso, etc.
A Figura 9.6 apresenta os nveis de abstrao de um subsistema de gerncia
de disco tpico.
Por outro lado, a virtualizao consiste em criar novas interfaces a partir
das interfaces existentes. Na virtualizao, os detalhes de baixo nvel da
plataforma real no so necessariamente ocultos, como ocorre na abstrao
de recursos. A Figura 9.7 ilustra essa diferena: atravs da virtualizao,
um processador Sparc pode ser visto pelo sistema convidado como um
processador Intel. Da mesma forma, um disco real no padro SATA pode
ser visto como vrios discos menores independentes, com a mesma interface
(SATA) ou outra interface (IDE).
A Figura 9.8 ilustra outro exemplo dessa diferena no contexto do
armazenamento em disco. A abstrao prov s aplicaes o conceito de
arquivo, sobre o qual estas podem executar operaes simples como read
ou write, por exemplo. J a virtualizao fornece para a camada superior
c Carlos Maziero
380
9: Virtualizao versus abstrao

aplicao
open
write
close
read
abstrao
de arquivo
API do sist. arquivos

Sist. arquivos lgico
diretrios,
permisses
Alocao de arquivos
estratgias de
alocao de arquivos
Sist. arquivos bsico
buering, caching,
escalonamento de disco
Controle de E/S
Operaes de E/S
tratamento de interrupes
dispositivos fsicos
e controladores
Figura 9.6: Nveis de abstrao em um sub-sistema de disco.

i386
dispositivos
virtuais
camada de virtualizao
sparc
disco'
disco''
camada de virtualizao
dispositivos
reais
disco real
Figura 9.7: Virtualizao de recursos do hardware.

apenas um disco virtual, construdo a partir de um arquivo do sistema
operacional real subjacente. Esse disco virtual ter de ser particionado e
formatado para seu uso, da mesma forma que um disco real.
c Carlos Maziero
381
9: A construo de mquinas virtuais
aplicaes
SO convid
SO convid
arquivos
discos
virtuais
Sist Operacional
disco
Hipervisor
disco real
Figura 9.8: Abstrao versus virtualizao de um disco rgido.
9.2
A construo de mquinas virtuais
Conforme apresentado, a virtualizao consiste em reescrever uma ou

mais interfaces do sistema computacional, para oferecer novas interfaces e assim permitir a execuo de sistemas operacionais ou aplicaes
incompatveis com as interfaces originais.
A construo de mquinas virtuais bem mais complexa que possa
parecer primeira vista. Caso os conjuntos de instrues (ISA) do sistema
real e do sistema virtual sejam diferentes, necessrio usar as instrues
da mquina real para simular as instrues da mquina virtual. Alm
disso, necessrio mapear os recursos de hardware virtuais (perifricos
oferecidos ao sistema convidado) sobre os recursos existentes na mquina
real (os perifricos reais). Por fim, pode ser necessrio mapear as chamadas
de sistema emitidas pelas aplicaes do sistema convidado em chamadas
equivalentes no sistema real, quando os sistemas operacionais virtual e real
forem distintos.
Esta seo aborda inicialmente o conceito formal de virtualizao, para
em seguida discutir as principais tcnicas usadas na construo de mquinas
virtuais.
c Carlos Maziero
382
9.2.1
9: Definio formal
Definio formal
Em 1974, os pesquisadores americanos Gerald Popek (UCLA) e Robert

Goldberg (Harvard) definiram uma mquina virtual da seguinte forma
[Popek and Goldberg, 1974]:
Uma mquina virtual vista como uma duplicata eficiente e isolada de
uma mquina real. Essa abstrao construda por um monitor de
mquina virtual (VMM - Virtual Machine Monitor).
O hipervisor ou monitor de mquina virtual descrito por Popek/Goldberg
corresponde camada de virtualizao apresentada na Seo 9.1.4. Para
funcionar de forma correta e eficiente, o hipervisor deve atender a alguns
requisitos bsicos: ele deve prover um ambiente de execuo aos programas
essencialmente idntico ao da mquina real, do ponto de vista lgico.
Programas executando sobre uma mquina virtual devem apresentar, no
pior caso, leves degradaes de desempenho. Alm disso, o hipervisor
deve ter controle completo sobre os recursos do sistema real (o sistema
hospedeiro). A partir desses requisitos, foram estabelecidas as seguintes
propriedades a serem satisfeitas por um hipervisor ideal:
Equivalncia : um hipervisor prov um ambiente de execuo quase idntico ao da mquina real original. Todo programa executando em uma
mquina virtual deve se comportar da mesma forma que o faria em
uma mquina real; excees podem resultar somente de diferenas
nos recursos disponveis (memria, disco, etc.), dependncias de temporizao e a existncia dos dispositivos de entrada/sada necessrios
aplicao.
Controle de recursos : o hipervisor deve possuir o controle completo
dos recursos da mquina real: nenhum programa executando na
mquina virtual deve possuir acesso a recursos que no tenham sido
explicitamente alocados a ele pelo hipervisor, que deve intermediar
todos os acessos. Alm disso, a qualquer instante o hipervisor pode
retirar recursos previamente alocados mquina virtual.
Eficincia : grande parte das instrues do processador virtual (o processador provido pelo hipervisor) deve ser executada diretamente pelo
processador da mquina real, sem interveno do hipervisor. As
instrues da mquina virtual que no puderem ser executadas pelo
c Carlos Maziero
383
9: Definio formal
processador real devem ser interpretadas pelo hipervisor e traduzidas em aes equivalentes no processador real. Instrues simples,
que no afetem outras mquinas virtuais ou aplicaes, podem ser
executadas diretamente no processador real.
Alm dessas trs propriedades bsicas, as propriedades derivadas a seguir so frequentemente associadas a hipervisores
[Popek and Goldberg, 1974, Rosenblum, 2004]:
Isolamento: aplicaes dentro de uma mquina virtual no podem interagir
diretamente (a) com outras mquinas virtuais, (b) com o hipervisor,
ou (c) com o sistema real hospedeiro. Todas as interaes entre
entidades dentro de uma mquina virtual e o mundo exterior devem
ser mediadas pelo hipervisor.
Recursividade: alguns sistemas de mquinas virtuais exibem tambm esta
propriedade: deve ser possvel executar um hipervisor dentro de uma
mquina virtual, produzindo um novo nvel de mquinas virtuais.
Neste caso, a mquina real normalmente denominada mquina de
nvel 0.
Inspeo: o hipervisor tem acesso e controle sobre todas as informaes do
estado interno da mquina virtual, como registradores do processador,
contedo de memria, eventos etc.
Essas propriedades bsicas caracterizam um hipervisor ideal, que nem
sempre pode ser construdo sobre as plataformas de hardware existentes.
A possibilidade de construo de um hipervisor em uma determinada
plataforma definida atravs do seguinte teorema, enunciado e provado
por Popek e Goldberg em [Popek and Goldberg, 1974]:
Para qualquer computador convencional de terceira gerao, um hipervisor pode ser construdo se o conjunto de instrues sensveis
daquele computador for um sub-conjunto de seu conjunto de instrues
privilegiadas.
Para compreender melhor as implicaes desse teorema, necessrio
definir claramente os seguintes conceitos:
c Carlos Maziero
384
9: Definio formal
Computador convencional de terceira gerao: qualquer sistema de computao convencional seguindo a arquitetura de Von Neumann, que
suporte memria virtual e dois modos de operao do processador:
modo usurio e modo privilegiado.
Instrues sensveis: so aquelas que podem consultar ou alterar o
status do processador, ou seja, os registradores que armazenam o
status atual da execuo na mquina real;
Instrues privilegiadas: so acessveis somente por meio de cdigos
executando em nvel privilegiado (cdigo de ncleo). Caso um
cdigo no-privilegiado tente executar uma instruo privilegiada,
uma exceo (interrupo) deve ser gerada, ativando uma rotina de
tratamento previamente especificada pelo ncleo do sistema real.
De acordo com esse teorema, toda instruo sensvel deve ser tambm
privilegiada. Assim, quando uma instruo sensvel for executada por
um programa no-privilegiado (um ncleo convidado ou uma aplicao
convidada), provocar a ocorrncia de uma interrupo. Essa interrupo
pode ser usada para ativar uma rotina de interpretao dentro do hipervisor,
que ir simular o efeito da instruo sensvel (ou seja, interpret-la), de
acordo com o contexto onde sua execuo foi solicitada (mquina virtual ou
hipervisor). Obviamente, quanto maior o nmero de instrues sensveis,
maior o volume de interpretao de cdigo a realizar, e menor o desempenho
da mquina virtual.
No caso de processadores que no atendam as restries de Popek/Goldberg, podem existir instrues sensveis que executem sem gerar
interrupes, o que impede o hipervisor de intercept-las e interpret-las.
Uma soluo possvel para esse problema a traduo dinmica das instrues
sensveis presentes nos programas de usurio: ao carregar um programa na
memria, o hipervisor analisa seu cdigo e substitui essas instrues sensveis por chamadas a rotinas que as interpretam dentro do hipervisor. Isso
implica em um tempo maior para o lanamento de programas, mas torna
possvel a virtualizao. Outra tcnica possvel para resolver o problema
a para-virtualizao, que se baseia em reescrever parte do sistema convidado
para no usar essas instrues sensveis. Ambas as tcnicas so discutidas a
seguir.
c Carlos Maziero
385
9.2.2
9: Suporte de hardware
Suporte de hardware
Na poca em que Popek e Goldberg definiram seu principal teorema,

o hardware dos mainframes IBM suportava parcialmente as condies
impostas pelo mesmo. Esses sistemas dispunham de uma funcionalidade chamada execuo direta, que permitia a uma mquina virtual acessar
nativamente o hardware para execuo de instrues. Esse mecanismo
permitia que aqueles sistemas obtivessem, com a utilizao de mquinas
virtuais, desempenho similar ao de sistemas convencionais equivalentes
[Goldberg, 1973, Popek and Goldberg, 1974, Goldberg and Mager, 1979].
O suporte de hardware necessrio para a construo de hipervisores eficientes est presente em sistemas de grande porte, como os mainframes, mas
apenas parcial nos micro-processadores de mercado. Por exemplo, a famlia
de processadores Intel Pentium IV (e anteriores) possui 17 instrues sensveis que podem ser executadas em modo usurio sem gerar excees, o que
viola o teorema de Goldberg (Seo 9.2.1) e dificulta a criao de mquinas
virtuais em sistemas que usam esses processadores [Robin and Irvine, 2000].
Alguns exemplos dessas instrues problemticas so:
SGDT/SLDT: permitem ler o registrador que indica a posio e tamanho
das tabelas de segmentos global/local do processo ativo.
SMSW: permite ler o registrador de controle 0, que contm informaes
de status interno do processador.
PUSHF/POPF: empilha/desempilha o valor do registrador EFLAGS, que
tambm contm informaes de status interno do processador.
Para controlar o acesso aos recursos do sistema e s instrues privilegiadas, os processadores atuais usam a noo de anis de proteo herdada
do sistema MULTICS [Corbat and Vyssotsky, 1965]. Os anis definem
nveis de privilgio: um cdigo executando no nvel 0 (anel central) tem
acesso completo ao hardware, enquanto um cdigo executando em um nvel
i > 0 (anis externos) tem menos privilgio. Quanto mais externo o anel
onde um cdigo executa, menor o seu nvel de privilgio. Os processadores
Intel/AMD atuais suportam 4 anis ou nveis de proteo, mas a quase
totalidade dos sistemas operacionais de mercado somente usa os dois anis
extremos: o anel 0 para o ncleo do sistema e o anel 3 para as as aplicaes
dos usurios.
c Carlos Maziero
386
As tcnicas de virtualizao para as plataformas Intel/AMD se baseiam

na reduo de privilgios do sistema operacional convidado: o hipervisor e
o sistema operacional hospedeiro executam no nvel 0, o sistema operacional
convidado executa no nvel 1 ou 2 e as aplicaes do sistema convidado
executam no nvel 3. Essas formas de estruturao de sistema so denominadas modelo 0/1/3 e modelo 0/2/3, respectivamente (Figura 9.9).
Todavia, para que a estratgia de reduo de privilgio possa funcionar,
algumas instrues do sistema operacional convidado devem ser reescritas
dinamicamente, em tempo de carga do sistema convidado na memria, pois
ele foi construdo para executar no nvel 0.
sistema
no-virtualizado
virtualizao com
modelo 0/1/3
virtualizao com
modelo 0/2/3
aplicaes
aplicaes
3 aplicaes
no usado
no usado
2 ncleo convidado
no usado
ncleo convidado
no usado
ncleo do SO
hipervisor
hipervisor
Figura 9.9: Uso dos nveis de proteo em processadores Intel/AMD convencionais.

Por volta de 2005, os principais fabricantes de micro-processadores
(Intel e AMD) incorporaram um suporte bsico virtualizao em seus
processadores, atravs das tecnologias IVT (Intel Virtualization Technology)
e AMD-V (AMD Virtualization), que so conceitualmente equivalentes
[Uhlig et al., 2005]. A idia central de ambas as tecnologias consiste em
definir dois modos possveis de operao do processador: os modos root
e non-root. O modo root equivale ao funcionamento de um processador
convencional, e se destina execuo de um hipervisor. Por outro lado, o
modo non-root se destina execuo de mquinas virtuais. Ambos os modos
suportam os quatro nveis de privilgio, o que permite executar os sistemas
convidados sem a necessidade de reescrita dinmica de seu cdigo.
So tambm definidos dois procedimentos de transio entre modos:
VM entry (transio root non-root) e VM exit (transio non-root root).
Quando operando dentro de uma mquina virtual (ou seja, em modo nonroot), as instrues sensveis e as interrupes podem provocar a transio
VM exit, devolvendo o processador ao hipervisor em modo root. As instru-
c Carlos Maziero
387
es e interrupes que provocam a transio VM exit so configurveis

pelo prprio hipervisor.
Para gerenciar o estado do processador (contedo dos registradores),
definida uma Estrutura de Controle de Mquina Virtual (VMCS - VirtualMachine Control Structure). Essa estrutura de dados contm duas reas: uma
para os sistemas convidados e outra para o hipervisor. Na transio VM
entry, o estado do processador lido a partir da rea de sistemas convidados
da VMCS. J uma transio VM exit faz com que o estado do processador
seja salvo na rea de sistemas convidados e o estado anterior do hipervisor,
previamente salvo na VMCS, seja restaurado. A Figura 9.10 traz uma viso
geral da arquitetura Intel IVT.
rea VMCS
l e salva
o estado do
processador
aplicaes
aplicaes
2 no usado
3 aplicaes
2 no usado
1 no usado
2 no usado
1 no usado
0 ncleo convidado
1 no usado
0 ncleo convidado
3
no usado
no usado
no usado
hipervisor
VM entry
VM exit
modo root
ncleo convidado
modo non-root
Figura 9.10: Viso geral da arquitetura Intel IVT.

Alm da Intel e AMD, outros fabricantes de hardware tm se preocupado
com o suporte virtualizao. Em 2005, a Sun Microsystems incorporou suporte nativo virtualizao em seus processadores UltraSPARC [Yen, 2007].
Em 2007, a IBM props uma especificao de interface de hardware denominada IBM Power ISA 2.04 [IBM, 2007], que respeita os requisitos necessrios
virtualizao do processador e da gesto de memria.
Conforme apresentado, a virtualizao do processador pode obtida
por reescrita dinmica do cdigo executvel ou atravs do suporte nativo
em hardware, usando tecnologias como IVT e AMD-V. Por outro lado, a
c Carlos Maziero
388
9: Formas de virtualizao
virtualizao da memria envolve outros desafios, que exigem modificaes

significativas dos mecanismos de gesto de memria virtual estudados na Seo 5.7. Por exemplo, importante prever o compartilhamento de pginas de
cdigo entre mquinas virtuais, para reduzir a quantidade total de memria
fsica necessria a cada mquina virtual. Outros desafios similares surgem
na virtualizao dos dispositivos de armazenamento e de entrada/sada,
alguns deles sendo analisados em [Rosenblum and Garfinkel, 2005].
9.2.3
Formas de virtualizao
A virtualizao implica na reescrita de interfaces de sistema, para permitir

a interao entre componentes de sistema construdos para plataformas
distintas. Como existem vrias interfaces entre os componentes, tambm h
vrias possibilidades de uso da virtualizao em um sistema. De acordo com
as interfaces em que so aplicadas, as formas mais usuais de virtualizao
so [Rosenblum, 2004, Nanda and Chiueh, 2005]:
Virtualizao do hardware : toda a interface ISA, que permite o acesso
ao hardware, virtualizada. Isto inclui o conjunto de instrues do
processador e as interfaces de acesso aos dispositivos de entrada/sada.
A virtualizao de hardware (ou virtualizao completa) permite
executar um sistema operacional e/ou aplicaes em uma plataforma
totalmente diversa daquela para a qual estes foram desenvolvidos. Esta
a forma de virtualizao mais poderosa e flexvel, mas tambm a de
menor desempenho, uma vez que o hipervisor tem de traduzir toda as
instrues geradas no sistema convidado em instrues do processador
real. A mquina virtual Java (JVM, Seo 9.6.7) um bom exemplo de
virtualizao do hardware. Mquinas virtuais implementando esta
forma de virtualizao so geralmente denominados emuladores de
hardware.
Virtualizao da interface de sistema : virtualiza-se a System ISA, que corresponde ao conjunto de instrues sensveis do processador. Esta
forma de virtualizao bem mais eficiente que a anterior, pois o
hipervisor apenas emula as instrues sensveis do processador virtual,
executadas em modo privilegiado pelo sistema operacional convidado.
As instrues no-sensveis podem ser executadas diretamente pelo
processador real, sem perda de desempenho. Todavia, apenas sistemas convidados desenvolvidos para o mesmo processador podem ser
c Carlos Maziero
389
9: Formas de virtualizao
executados usando esta abordagem. Esta a abordagem clssica de

virtualizao, presente nos sistemas de grande porte (mainframes) e
usada nos ambientes de mquinas virtuais VMWare, VirtualPC e Xen.
Virtualizao de dispositivos de entrada/sada : virtualizam-se as dispositivos fsicos que permitem ao sistema interagir com o mundo exterior.
Esta tcnica implica na construo de dispositivos fsicos virtuais,
como discos, interfaces de rede e terminais de interao com o usurio,
usando os dispositivos fsicos subjacentes. A maioria dos ambientes
de mquinas virtuais usa a virtualizao de dispositivos para oferecer
discos rgidos e interfaces de rede virtuais aos sistemas convidados.
Virtualizao do sistema operacional : virtualiza-se o conjunto de recursos lgicos oferecidos pelo sistema operacional, como rvores de
diretrios, descritores de arquivos, semforos, canais de IPC e nomes
de usurios e grupos. Nesta abordagem, cada mquina virtual pode
ser vista como uma instncia distinta do mesmo sistema operacional
subjacente. Esta a abordagem comumente conhecida como servidores
virtuais, da qual so bons exemplos os ambientes FreeBSD Jails, Linux
VServers e Solaris Zones.
Virtualizao de chamadas de sistema : permite oferecer o conjunto de
chamadas de sistema de uma sistema operacional A usando as chamadas de sistema de um sistema operacional B, permitindo assim a
execuo de aplicaes desenvolvidas para um sistema operacional
sobre outro sistema. Todavia, como as chamadas de sistema so normalmente invocadas atravs de funes de bibliotecas, a virtualizao
de chamadas de sistema pode ser vista como um caso especial de
virtualizao de bibliotecas.
Virtualizao de chamadas de biblioteca : tem objetivos similares ao da
virtualizao de chamadas de sistema, permitindo executar aplicaes
em diferentes sistemas operacionais e/ou com bibliotecas diversas
daquelas para as quais foram construdas. O sistema Wine, que permite
executar aplicaes Windows sobre sistemas UNIX, usa essencialmente
esta abordagem.
Na prtica, essas vrias formas de virtualizao podem ser usadas para
a resoluo de problemas especficos em diversas reas de um sistema de
computao. Por exemplo, vrios sistemas operacionais oferecem facilidades
c Carlos Maziero
390
9: Tipos de mquinas virtuais
de virtualizao de dispositivos fsicos, como por exemplo: interfaces de

rede virtuais que permitem associar mais de um endereo de rede ao
computador, discos rgidos virtuais criados em reas livres da memria
RAM (os chamados RAM disks); rvores de diretrios virtuais criadas para
confinar processos crticos para a segurana do sistema (atravs da chamada
de sistem chroot), emulao de operaes 3D em uma placa grfica que
no as suporta, etc.
9.3
Tipos de mquinas virtuais
Alm de resolver problemas em reas especficas do sistema operacional,

as vrias formas de virtualizao disponveis podem ser combinadas para a
construo de mquinas virtuais. Uma mquina virtual um ambiente de
suporte execuo de software, construdo usando uma ou mais formas
de virtualizao. Conforme as caractersticas do ambiente virtual proporcionado, as mquinas virtuais podem ser classificadas em trs categorias,
representadas na Figura 9.11:
Mquinas virtuais de processo (Process Virtual Machines): tambm chamadas de mquinas virtuais de aplicao, so ambientes construdos para
prover suporte de execuo a apenas um processo ou aplicao convidada especfica. A mquina virtual Java e o ambiente de depurao
Valgrind so exemplos deste tipo de ambiente.
Mquinas virtuais de sistema operacional (Operating System Virtual Machines): so construdas para suportar espaos de usurio distintos
sobre um mesmo sistema operacional. Embora compartilhem o mesmo
ncleo, cada ambiente virtual possui seus prprios recursos lgicos,
como espao de armazenamento, mecanismos de IPC e interfaces de
rede distintas. Os sistemas Solaris Zones e FreeBSD Jails implementam
este conceito.
Mquinas virtuais de sistema (System Virtual Machines): so ambientes de
mquinas virtuais construdos para emular uma plataforma de hardware completa, com processador e perifricos. Este tipo de mquina
virtual suporta sistemas operacionais convidados com aplicaes convidadas executando sobre eles. Como exemplos desta categoria de
mquinas virtuais temos os ambientes VMware e VirtualBox.
c Carlos Maziero
391
Aplics Solaris
9: Mquinas virtuais de processo
Espao de
usurio
Espao de
usurio
Aplic
Java
Aplics Linux
Espao de
usurio
Aplics Linux
JVM
Aplics Windows
Aplics Linux
ncleo Linux ncleo Windows
ncleo Solaris
ncleo Linux
hipervisor
hardware Sparc
hardware x86
hardware x86
VM de processo
VM de sistema
operacional
VM de sistema
(hardware)
Figura 9.11: Mquinas virtuais de processo, de sistema operacional e de

hardware.
Por outro lado, os ambientes de mquinas virtuais tambm podem ser
classificados de acordo com o nvel de similaridade entre as interfaces de
hardware do sistema convidado e do sistema real (ISA - Instruction Set
Architecture, Seo 9.1.2):
Interfaces equivalentes: a interface virtual oferecida ao ambiente convidado reproduz a interface de hardware do sistema real, permitindo
a execuo de aplicaes construdas para o sistema real. Como a
maioria das instrues do sistema convidado pode ser executada diretamente pelo processador (com exceo das instrues sensveis), o
desempenho obtido pelas aplicaes convidadas pode ser prximo do
desempenho de execuo no sistema real. Ambientes como VMWare
so exemplos deste tipo de ambiente.
Interfaces distintas: a interface virtual no tem nenhuma relao com
a interface de hardware do sistema real, ou seja, implementa um
conjunto de instrues distinto, que deve ser totalmente traduzido pelo
hipervisor. Conforme visto na Seo 9.2.1, a interpretao de instrues
impe um custo de execuo significativo ao sistema convidado.
A mquina virtual Java e o ambiente QEmu so exemplos dessa
abordagem.
9.3.1
Mquinas virtuais de processo
Uma mquina virtual de processo ou de aplicao (Process Virtual Machine)

suporta a execuo de um processo ou aplicao individual. Ela criada sob
c Carlos Maziero
392
demanda, no momento do lanamento da aplicao convidada, e destruda

quando a aplicao finaliza sua execuo. O conjunto hipervisor + aplicao
normalmente visto como um nico processo dentro do sistema operacional
subjacente (ou um pequeno conjunto de processos), submetido s mesmas
condies e restries que os demais processos nativos.
Os hipervisores que implementam mquinas virtuais de processo normalmente permitem a interao entre a aplicao convidada e as demais
aplicaes do sistema, atravs dos mecanismos usuais de comunicao e
coordenao entre processos, como mensagens, pipes e semforos. Alm
disso, tambm permitem o acesso normal ao sistema de arquivos e outros
recursos locais do sistema. Estas caractersticas violam a propriedade de
isolamento descrita na Seo 9.2.1, mas so necessrias para que a aplicao
convidada se comporte como uma aplicao normal aos olhos do usurio.
Ao criar a mquina virtual para uma aplicao, o hipervisor pode implementar a mesma interface de hardware (ISA, Seo 9.1.2) da mquina real
subjacente, ou implementar uma interface distinta. Quando a interface da
mquina real preservada, boa parte das instrues do processo convidado
podem ser executadas diretamente, com exceo das instrues sensveis,
que devem ser interpretadas pelo hipervisor.
Os exemplos mais comuns de mquinas virtuais de aplicao que
preservam a interface ISA real so os sistemas operacionais multi-tarefas, os
tradutores dinmicos e alguns depuradores de memria:
Sistemas operacionais multi-tarefas: os sistemas operacionais que suportam vrios processos simultneos, estudados no Captulo 2, tambm
podem ser vistos como ambientes de mquinas virtuais. Em um
sistema multi-tarefas, cada processo recebe um processador virtual (simulado atravs das fatias de tempo do processador real e das trocas
de contexto), uma memria virtual (atravs do espao de endereos
mapeado para aquele processo) e recursos fsicos (acessveis atravs de
chamadas de sistema). Este ambiente de virtualizao to antigo
e to presente em nosso cotidiano que costumamos ignor-lo como
tal. No entanto, ele simplifica muito a tarefa dos programadores, que
no precisam se preocupar com a gesto do compartilhamento desses
recursos entre os processos.
Tradutores dinmicos : um tradutor dinmico consiste em um hipervisor
que analisa e otimiza um cdigo executvel, para tornar sua execuo mais rpida e eficiente. A otimizao no muda o conjunto de
c Carlos Maziero
393
instrues da mquina real usado pelo cdigo, apenas reorganiza

as instrues de forma a acelerar sua execuo. Por ser dinmica, a
otimizao do cdigo feita durante a carga do processo na memria
ou durante a execuo de suas instrues, de forma transparente. O
artigo [Duesterwald, 2005] apresenta uma descrio detalhada desse
tipo de abordagem.
Depuradores de memria :
alguns sistemas de depurao de
erros de acesso memria, como o sistema Valgrind
[Seward and Nethercote, 2005], executam o processo sob depurao em uma mquina virtual. Todas as instrues do programa que
manipulam acessos memria so executadas de forma controlada, a
fim de encontrar possveis erros. Ao depurar um programa, o sistema
Valgrind inicialmente traduz seu cdigo binrio em um conjunto de
instrues interno, manipula esse cdigo para inserir operaes de
verificao de acessos memria e traduz o cdigo modificado de
volta ao conjunto de instrues da mquina real, para em seguida
execut-lo e verificar os acessos memria realizados.
Contudo, as mquinas virtuais de processo mais populares atualmente
so aquelas em que a interface binria de aplicao (ABI, Seo 9.1.2)
requerida pela aplicao diferente daquela oferecida pela mquina real.
Como a ABI composta pelas chamadas do sistema operacional e as
instrues de mquina disponveis aplicao (user ISA), as diferenas
podem ocorrer em ambos esses componentes. Nos dois casos, o hipervisor
ter de fazer tradues dinmicas (durante a execuo) das aes requeridas
pela aplicao em suas equivalentes na mquina real. Como visto, um
hipervisor com essa funo denominado tradutor dinmico.
Caso as diferenas de interface entre aplicao e mquina real se restrinjam s chamadas do sistema operacional, o hipervisor precisa apenas
mapear as chamadas de sistema e de bibliotecas usadas pela aplicao sobre
as chamadas equivalentes oferecidas pelo sistema operacional da mquina
real. Essa a abordagem usada, por exemplo, pelo ambiente Wine, que
permite executar aplicaes Windows em plataformas Unix. As chamadas
de sistema Windows emitidas pela aplicao em execuo so interceptadas
e transformadas em chamadas Unix, de forma dinmica e transparente
(Figura 9.12).
Entretanto, muitas vezes a interface ISA utilizada pela aplicao no
corresponde a nenhum hardware existente, mas a uma mquina abstrata.
c Carlos Maziero
394
9: Mquinas virtuais de sistema operacional
Aplicao
Windows
Chamadas de
sistema Windows
Wine
Chamadas de
sistema UNIX
Linux
Instrues Intel
PC Intel
Figura 9.12: Funcionamento do emulador Wine.

Um exemplo tpico dessa situao ocorre na linguagem Java: um programa
escrito em Java, ao ser compilado, gera um cdigo binrio especfico para
uma mquina abstrata denominada mquina virtual Java (JVM Java Virtual
Machine). A linguagem de mquina executada pela mquina virtual Java
denominada bytecode Java, e no corresponde a instrues de um processador
real. A mquina virtual deve ento interpretar todas as operaes do bytecode,
utilizando as instrues da mquina real subjacente para execut-las. Vrias
linguagens empregam a mesma abordagem (embora usando um bytecode
prprio), como Perl, Python e Smalltalk.
Em termos de desempenho, um programa compilado para um processador abstrato executa mais lentamente que seu equivalente compilado para
um processador real, devido ao custo de interpretao do bytecode. Todavia,
essa abordagem oferece melhor desempenho que linguagens puramente
interpretadas. Alm disso, tcnicas de otimizao como a compilao Justin-Time (JIT), na qual blocos de instrues repetidos frequentemente so
traduzidos e mantidos em cache pelo hipervisor, permitem obter ganhos de
desempenho significativos.
9.3.2
Mquinas virtuais de sistema operacional
Em muitas situaes, a principal ou mesmo nica motivao para o

uso de mquinas virtuais a propriedade de isolamento (Seo 9.2.1).
Esta propriedade tem uma grande importncia no contexto da segurana
de sistemas, por permitir isolar entre si sub-sistemas independentes que
executam sobre o mesmo hardware. Por exemplo, a estratgia organizacional
conhecida como consolidao de servidores advoga o uso de mquinas virtuais
c Carlos Maziero
395
para abrigar os diversos servidores (de nomes, de arquivos, de e-mail, de

Web) de um determinado domnio. Dessa forma, pode-se fazer um uso
mais eficiente do hardware disponvel, preservando o isolamento entre
os servios. Todavia, o impacto da virtualizao de uma plataforma de
hardware ou sistema operacional sobre o desempenho do sistema final pode
ser elevado. As principais fontes desse impacto so a virtualizao dos
recursos (perifricos) da mquina real e a necessidade de traduo binria
dinmica das instrues do processador real.
Uma forma simples e eficiente de implementar o isolamento entre aplicaes ou sub-sistemas em um sistema operacional consiste na virtualizao
do espao de usurio (userspace). Nesta abordagem, denominada mquinas
virtuais de sistema operacional ou servidores virtuais, o espao de usurio do
sistema operacional dividido em reas isoladas denominadas domnios ou
zonas virtuais. A cada domnio virtual alocada uma parcela dos recursos
do sistema operacional, como memria, tempo de processador e espao em
disco. Alm disso, alguns recursos do sistema real podem ser virtualizados,
como o caso frequente das interfaces de rede: cada domnio tem sua
prpria interface virtual e, portanto, seu prprio endereo de rede. Em
vrias implementaes, cada domnio virtual define seu prprio espao de
nomes: assim, possvel encontrar um usurio pedro no domnio d3 e outro
usurio pedro no domnio d7 , sem conflitos. Essa noo de espaos de nomes
distintos pode se estender aos demais recursos do sistema: identificadores
de processos, semforos, rvores de diretrios, etc.
Os processos presentes em um determinado domnio virtual podem
interagir entre si, criar novos processos e usar os recursos presentes naquele
domnio, respeitando as regras de controle de acesso associadas a esses
recursos. Todavia, processos presentes em um domnio no podem ver ou
interagir com processos que estiverem em outro domnio, no podem mudar
de domnio, criar processos em outros domnios, nem consultar ou usar
recursos de outros domnios. Dessa forma, para um determinado domnio,
os demais domnios so mquinas distintas, acessveis somente atravs de
seus endereos de rede. Para fins de gerncia, normalmente definido um
domnio d0 , chamado de domnio inicial, privilegiado ou de gerncia, cujos
processos tm visibilidade e acesso aos recursos dos demais domnios.
Somente processos no domnio d0 podem migrar para outros domnios; uma
vez realizada uma migrao, no h possibilidade de retornar ao domnio
anterior.
c Carlos Maziero
396
O ncleo do sistema operacional o mesmo para todos os domnios

virtuais, e sua interface (conjunto de chamadas de sistema) preservada.
Normalmente apenas uma nova chamada de sistema necessria, para que
um processo no domnio inicial d0 possa solicitar sua migrao para um
outro domnio di . A Figura 9.13 mostra a estrutura tpica de um ambiente de
mquinas virtuais de sistema operacional. Nela, pode-se observar que um
processo pode migrar de d0 para d1 , mas que os processos em d1 no podem
migrar para outros domnios. A comunicao entre processos confinados
em domnios distintos (d2 e d3 ) tambm proibida.
domain 0
(admin)
domain 1
domain 2
domain 3
host OS kernel
hardware
Figura 9.13: Mquinas virtuais de sistema operacional.

H vrias implementaes disponveis de mecanismos para a criao de
domnios virtuais. A tcnica mais antiga implementada pela chamada de
sistema chroot, disponvel na maioria dos sistemas UNIX. Essa chamada
de sistema atua exclusivamente sobre o acesso de um processo ao sistema
de arquivos: o processo que a executa tem seu acesso ao sistema de arquivos
restrito a uma sub-rvore da hierarquia de diretrios, ou seja, ele fica confinado a essa sub-rvore. Os filhos desse processo herdam a mesma viso do
sistema de arquivos, que no pode ser revertida. Por exemplo, um processo
que executa a chamada chroot ("/var/spool/postfix") passa a ver somente a hierarquia de diretrios a partir do diretrio /var/spool/postfix,
que passa a ser seu diretrio raiz. A Figura 9.14 ilustra essa operao.
A chamada de sistema chroot muito utilizada para isolar processos
que oferecem servios rede, como servidores DNS e de e-mail. Se um
processo servidor tiver alguma vulnerabilidade e for subvertido por um
atacante, este s ter acesso ao conjunto de diretrios visveis aos processos
c Carlos Maziero
397
bin etc lib usr var
bin etc lib usr var
bin src spool
bin src spool
postx
etc
lib
var
etc
lib
var
Figura 9.14: A chamada de sistema chroot ("/var/spool/postfix").

do servidor, mantendo fora de alcance o restante da rvore de diretrios do
sistema.
O sistema operacional FreeBSD oferece uma implementao de domnios virtuais mais elaborada, conhecida como Jails
[McKusick and Neville-Neil, 2005] (aqui traduzidas como celas). Um
processo que executa a chamada de sistema jail cria uma nova cela e
colocado dentro dela, de onde no pode mais sair, nem seus filhos. Os
processos dentro de uma cela esto submetidos s seguintes restries:
a viso do sistema operacional se restringe aos processos e recursos
associados quela cela; os demais processos, arquivos e outros recursos
do sistema no-associados cela no so visveis;
somente so permitidas interaes (comunicao e coordenao) entre
processos dentro da mesma cela;
de forma similar chamada chroot, cada cela recebe uma rvore de
diretrios prpria; operaes de montagem/desmontagem de sistemas
de arquivos so proibidas;
cada cela tem um endereo de rede associado, que o nico utilizvel
pelos processos da cela; a configurao de rede (endereo, parmetros
de interface, tabela de roteamento) no pode ser modificada;
no podem ser feitas alteraes no ncleo do sistema, como reconfiguraes ou incluses/excluses de mdulos.
c Carlos Maziero
398
9: Mquinas virtuais de sistema
Essas restries so impostas a todos os processos dentro de uma cela,

mesmo aqueles pertencentes ao administrador (usurio root). Assim, uma
cela constitui uma unidade de isolamento bastante robusta, que pode ser
usada para confinar servios de rede e aplicaes ou usurios considerados
perigosos.
Existem implementaes de estruturas similares s celas do FreeBSD em
outros sistemas operacionais. Por exemplo, o sistema operacional Solaris
implementa o conceito de zonas [Price and Tucker, 2004], que oferecem uma
capacidade de isolamento similar celas, alm de prover um mecanismo de
controle da distribuio dos recursos entre as diferentes zonas existentes.
Outras implementaes podem ser encontradas para o sistema Linux, como
os ambientes Virtuozzo/OpenVZ e Vservers/FreeVPS.
9.3.3
Mquinas virtuais de sistema
Uma mquina virtual de sistema (ou de hardware) prov uma interface de

hardware completa para um ou mais sistemas operacionais convidados, com
suas respectivas aplicaes, que executam de forma isolada e independente.
Cada sistema operacional convidado tem a iluso de executar sozinho sobre
uma plataforma de hardware exclusiva. O hipervisor de sistema fornece aos
sistemas operacionais convidados uma interface de sistema ISA virtual, que
pode ser idntica ao hardware real, ou distinta. Alm disso, ele virtualiza o
acesso aos recursos, para que cada sistema operacional convidado tenha
um conjunto de recursos virtuais prprio, construdo a partir dos recursos
fsicos existentes na mquina real. Assim, cada mquina virtual ter sua
prpria interface de rede, seu prprio disco, sua prpria memria RAM, etc.
Em um ambiente virtual, os sistemas operacionais convidados so fortemente isolados uns dos outros, e normalmente s podem interagir atravs
dos mecanismos de rede, como se estivessem em computadores separados.
Todavia, alguns sistemas de mquinas virtuais permitem o compartilhamento controlado de certos recursos. Por exemplo, os sistemas VMware
Workstation e VirtualBox permitem a definio de diretrios compartilhados
no sistema de arquivos real, que podem ser acessados pelas mquinas
virtuais.
As mquinas virtuais de sistema constituem a primeira abordagem
usada para a construo de hipervisores, desenvolvida na dcada de 1960 e
formalizada por Popek e Goldberg (conforme apresentado na Seo 9.2.1).
Naquela poca, a tendncia de desenvolvimento de sistemas computacionais
c Carlos Maziero
399
9: Mquinas virtuais de sistema
buscava fornecer a cada usurio uma mquina virtual com seus recursos
virtuais prprios, sobre a qual o usurio executava um sistema operacional
mono-tarefa e suas aplicaes. Assim, o compartilhamento de recursos no
era responsabilidade do sistema operacional convidado, mas do hipervisor
subjacente. No entanto, ao longo dos anos 70, como o desenvolvimento de
sistemas operacionais multi-tarefas eficientes e robustos como MULTICS
e UNIX, as mquinas virtuais de sistema perderam gradativamente seu
interesse. Somente no final dos anos 90, com o aumento do poder de processamento dos micro-processadores e o surgimento de novas possibilidades
de aplicao, as mquinas virtuais de sistema foram redescobertas.
Existem basicamente duas arquiteturas de hipervisores de sistema,
apresentados na Figura 9.15:
Hipervisores nativos (ou de tipo I): nesta categoria, o hipervisor executa
diretamente sobre o hardware do computador real, sem um sistema
operacional subjacente. A funo do hipervisor virtualizar os
recursos do hardware (memria, discos, interfaces de rede, etc.) de
forma que cada mquina virtual veja um conjunto de recursos prprio
e independente. Assim, cada mquina virtual se comporta como
um computador completo que pode executar o seu prprio sistema
operacional. Esta a forma mais antiga de virtualizao, encontrada
nos sistemas computacionais de grande porte dos anos 1960-70. Alguns
exemplos de sistemas que empregam esta abordagem so o IBM OS/370,
o VMware ESX Server e o ambiente Xen.
Hipervisores convidados (ou de tipo II): nesta categoria, o hipervisor executa como um processo normal sobre um sistema operacional nativo
subjacente. O hipervisor utiliza os recursos oferecidos pelo sistema
operacional nativo para oferecer recursos virtuais ao sistema operacional convidado que executa sobre ele. Normalmente, um hipervisor
convidado suporta apenas uma mquina virtual com uma instncia de
sistema operacional convidado. Caso mais mquinas sejam necessrias, mais hipervisores devem ser lanados, como processos separados.
Exemplos de sistemas que adotam esta estrutura incluem o VMware
Workstation, o QEMU e o VirtualBox.
Pode-se afirmar que os hipervisores convidados so mais flexveis que
os hipervisores nativos, pois podem ser facilmente instalados/removidos em
mquinas com sistemas operacionais previamente instalados, e podem ser
c Carlos Maziero
400
9: Tcnicas de virtualizao
aplics
OS 1
aplics
aplics
aplics
guest OS
OS 2
hipervisor
host OS
hipervisor
hardware
hardware
hipervisor nativo
hipervisor convidado
Figura 9.15: Arquiteturas de mquinas virtuais de sistema.

facilmente lanados sob demanda. Por outro lado, hipervisores convidados
tm desempenho pior que hipervisores nativos, pois tm de usar os recursos
oferecidos pelo sistema operacional subjacente, enquanto um hipervisor
nativo pode acessar diretamente o hardware real. Tcnicas para atenuar
este problema so discutidas na Seo 9.4.5.
9.4
Tcnicas de virtualizao
A construo de hipervisores implica na definio de algumas estratgias

para a virtualizao. As estratgias mais utilizadas atualmente so a
emulao completa do hardware, a virtualizao da interface de sistema, a
traduo dinmica de cdigo e a para-virtualizao. Alm disso, algumas
tcnicas complementares so usadas para melhorar o desempenho dos
sistemas de mquinas virtuais. Essas tcnicas so discutidas nesta seo.
9.4.1
Emulao completa
Nesta abordagem, toda a interface do hardware virtualizada, incluindo

todas as instrues do processador, a memria e os dispositivos perifricos.
Isso permite oferecer ao sistema operacional convidado uma interface de
hardware distinta daquela fornecida pela mquina real subjacente, caso
seja necessrio. O custo de virtualizao pode ser muito elevado, pois
cada instruo executada pelo sistema convidado tem de ser analisada e
traduzida em uma ou mais instrues equivalentes no computador real. No
entanto, esta abordagem permite executar sistemas operacionais em outras
c Carlos Maziero
401
9: Emulao completa
plataformas, distintas daquela para a qual foram projetados, sem nenhuma

modificao.
Exemplos tpicos de emulao completa abordagem so os sistemas de
mquinas virtuais QEMU, que oferece um processador Intel Pentium II ao
sistema convidado, o MS VirtualPC for MAC, que permite executar o sistema
Windows sobre uma plataforma de hardware PowerPC, e o sistema Hercules,
que emula um computador IBM System/390 sobre um PC convencional de
plataforma Intel.
Um caso especial de emulao completa consiste nos hipervisores embutidos no hardware (codesigned hypervisors). Um hipervisor embutido visto
como parte integrante do hardware e implementa a interface de sistema
(ISA) vista pelos sistemas operacionais e aplicaes daquela plataforma. Entretanto, o conjunto de instrues do processador real somente est acessvel
ao hipervisor, que reside em uma rea de memria separada da memria
principal e usa tcnicas de traduo dinmica (vide Seo 9.4.3) para tratar
as instrues executadas pelos sistemas convidados. Um exemplo tpico
desse tipo de sistema o processador Transmeta Crusoe/Efficeon, que aceita
instrues no padro Intel 32 bits e internamente as converte em um conjunto
de instrues VLIW (Very Large Instruction Word). Como o hipervisor desse
processador pode ser reprogramado para criar novas instrues ou modificar as instrues existentes, ele acabou sendo denominado Code Morphing
Software (Figura 9.16).
Aplicaes
SO
convidado
rea de
memria
separada
hipervisor
tradutor
hardware
cache
ISA de
alto nvel
ISA de
baixo nvel
Figura 9.16: Hipervisor embutido no hardware.
c Carlos Maziero
402
9.4.2
9: Virtualizao da interface de sistema
Virtualizao da interface de sistema
Nesta abordagem, a interface ISA de usurio mantida, apenas as

instrues privilegiadas e os dispositivos (discos, interfaces de rede, etc.)
so virtualizados. Dessa forma, o sistema operacional convidado e as
aplicaes convidadas vem o processador real. Como a quantidade de
instrues a virtualizar reduzida, o desempenho do sistema convidado
pode ficar prximo daquele obtido se ele estivesse executando diretamente
sobre o hardware real.
Cabe lembrar que a virtualizao da interface de sistema s pode ser
aplicada diretamente caso o hardware subjacente atenda os requisitos de
Goldberg e Popek (cf. Seo 9.2.1). No caso de processadores que no
atendam esses requisitos, podem existir instrues sensveis que executem
sem gerar interrupes, impedindo o hipervisor de intercept-las. Nesse
caso, ser necessrio o emprego de tcnicas complementares, como a traduo
dinmica das instrues sensveis. Obviamente, quanto maior o nmero de
instrues sensveis, maior o volume de interpretao de cdigo a realizar, e
menor o desempenho da mquina virtual. Os processadores mais recentes
das famlias Intel e AMD discutidos na Seo 9.2.2 atendem os requisitos de
Goldberg/Popek, e por isso suportam esta tcnica de virtualizao.
Exemplos de sistemas que implementam esta tcnica incluem os ambientes VMware Workstation, VirtualBox, MS VirtualPC e KVM.
9.4.3
Traduo dinmica
Uma tcnica frequentemente utilizada na construo de mquinas virtuais a traduo dinmica (dynamic translation) ou recompilao dinmica
(dynamic recompilation) de partes do cdigo binrio do sistemas convidado
e suas aplicaes. Nesta tcnica, o hipervisor analisa, reorganiza e traduz
as sequncias de instrues emitidas pelo sistema convidado em novas
sequncias de instrues, medida em que a execuo do sistema convidado
avana.
A traduo binria dinmica pode ter vrios objetivos: (a) adaptar
as instrues geradas pelo sistema convidado interface ISA do sistema
real, caso no sejam idnticas; (b) detectar e tratar instrues sensveis
no-privilegiadas (que no geram interrupes ao serem invocadas pelo
sistema convidado); ou (c) analisar, reorganizar e otimizar as sequncias
de instrues geradas pelo sistema convidado, de forma a melhorar o
c Carlos Maziero
403
9: Traduo dinmica
desempenho de sua execuo. Neste ltimo caso, os blocos de instrues

muito frequentes podem ter suas tradues mantidas em cache, para
melhorar ainda mais o desempenho.
A traduo dinmica usada em vrios tipos de hipervisores. Uma
aplicao tpica a construo da mquina virtual Java, onde recebe o nome
de JIT Just-in-Time Bytecode Compiler. Outro uso corrente a construo de
hipervisores para plataformas sem suporte adequado virtualizao, como
os processadores Intel/AMD 32 bits. Neste caso, o cdigo convidado a ser
executado analisado em busca de instrues sensveis, que so substitudas
por chamadas a rotinas apropriadas dentro do supervisor.
No contexto de virtualizao, a traduo dinmica composta basicamente dos seguintes passos [Ung and Cifuentes, 2006]:
1. Desmontagem (disassembling): o fluxo de bytes do cdigo convidado
em execuo decomposto em blocos de instrues. Cada bloco
normalmente composto de uma sequncia de instrues de tamanho
varivel, terminando com uma instruo de controle de fluxo de
execuo;
2. Gerao de cdigo intermedirio: cada bloco de instrues tem sua
semntica descrita atravs de uma representao independente de
mquina;
3. Otimizao: a descrio em alto nvel do bloco de instrues analisada
para aplicar eventuais otimizaes; como este processo realizado
durante a execuo, normalmente somente otimizaes com baixo
custo computacional so aplicveis;
4. Codificao: o bloco de instrues otimizado traduzido para instrues
da mquina fsica, que podem ser diferentes das instrues do cdigo
original;
5. Caching: blocos de instrues com execuo muito frequente tm
sua traduo armazenada em cache, para evitar ter de traduzi-los e
otimiz-los novamente;
6. Execuo: o bloco de instrues traduzido finalmente executado
nativamente pelo processador da mquina real.
Esse processo pode ser simplificado caso as instrues de mquina do
cdigo convidado sejam as mesmas do processador real subjacente, o que
c Carlos Maziero
404
9: Paravirtualizao
torna desnecessrio traduzir os blocos de instrues em uma representao

independente de mquina.
9.4.4
Paravirtualizao
A Seo 9.2.2 mostrou que as arquiteturas de alguns processadores, como

o Intel x86, podem ser difceis de virtualizar, porque algumas instrues
sensveis no podem ser interceptadas pelo hipervisor. Essas instrues
sensveis devem ser ento detectadas e interpretadas pelo hipervisor, em
tempo de carga do cdigo na memria.
Alm das instrues sensveis em si, outros aspectos da interface software/hardware trazem dificuldades ao desenvolvimento de mquinas virtuais
de sistema eficientes. Uma dessas reas o mecanismo de entrega e tratamento de interrupes pelo processador, baseado na noo de um vetor
de interrupes, que contm uma funo registrada para cada tipo de interrupo a tratar. Outra rea da interface software/hardware que pode trazer
dificuldades a gerncia de memria, pois o TLB (Translation Lookaside Buffer,
Seo 5.3.4) dos processadores x86 gerenciado diretamente pelo hardware,
sem possibilidade de interveno direta do hipervisor no caso de uma falta
de pgina.
Em meados dos anos 2000, alguns pesquisadores investigaram a possibilidade de modificar a interface entre o hipervisor e os sistemas operacionais
convidados, oferecendo a estes um hardware virtual que similar, mas
no idntico ao hardware real. Essa abordagem, denominada paravirtualizao, permite um melhor acoplamento entre os sistemas convidados e
o hipervisor, o que leva a um desempenho significativamente melhor das
mquinas virtuais. As modificaes na interface de sistema do hardware
virtual (system ISA) exigem uma adaptao dos sistemas operacionais convidados, para que estes possam executar sobre a plataforma virtual. Em
particular, o hipervisor define uma API denominada chamadas de hipervisor
(hypercalls), que cada sistema convidado deve usar para acessar a interface
de sistema do hardware virtual. Todavia, a interface de usurio (user ISA) do
hardware preservada, permitindo que as aplicaes convidadas executem
sem necessidade de modificaes. A Figura 9.17 ilustra esse conceito.
Os primeiros ambientes a adotar a paravirtualizao foram o Denali
[Whitaker et al., 2002] e o Xen [Barham et al., 2003]. O Denali um ambiente
experimental de paravirtualizao construdo na Universidade de Washington, que pode suportar dezenas de milhares de mquinas virtuais sobre
c Carlos Maziero
405
9: Aspectos de desempenho
aplicaes
aplicaes
Sistema
operacional
modicado
Sistema
operacional
standard
hypercalls
hipervisor
hipervisor
hardware
hardware
hardware
virtualizao
clssica
paravirtualizao
Figura 9.17: Paravirtualizao.

um computador x86 convencional. O projeto Denali no se preocupa em
suportar sistemas operacionais comerciais, sendo voltado execuo macia
de minsculas mquinas virtuais para servios de rede. J o ambiente de
mquinas virtuais Xen (vide Seo 9.6.3) permite executar sistemas operacionais convencionais como Linux e Windows, modificados para executar
sobre um hipervisor.
Embora exija que o sistema convidado seja adaptado ao hipervisor, o
que diminui sua portabilidade, a paravirtualizao permite que o sistema
convidado acesse alguns recursos do hardware diretamente, sem a intermediao ativa do hipervisor. Nesses casos, o acesso ao hardware apenas
monitorado pelo hipervisor, que informa ao sistema convidado seus limites,
como as reas de memria e de disco disponveis. O acesso aos demais
dispositivos, como mouse e teclado, tambm direto: o hipervisor apenas
gerencia os conflitos, no caso de mltiplos sistemas convidados em execuo simultnea. Apesar de exigir modificaes nos sistemas operacionais
convidados, a paravirtualizao tem tido sucesso, por conta do desempenho
obtido nos sistemas virtualizados, alm de simplificar a interface de baixo
nvel dos sistemas convidados.
9.4.5
Aspectos de desempenho
De acordo com os princpios de Goldberg e Popek, o hipervisor deve

permitir que a mquina virtual execute diretamente sobre o hardware sempre
que possvel, para no prejudicar o desempenho dos sistemas convidados.
c Carlos Maziero
406
O hipervisor deve retomar o controle do processador somente quando a

mquina virtual tentar executar operaes que possam afetar o correto
funcionamento do sistema, o conjunto de operaes de outras mquinas
virtuais ou do prprio hardware. O hipervisor deve ento simular com
segurana a operao solicitada e devolver o controle mquina virtual.
Na prtica, os hipervisores nativos e convidados raramente so usados
em sua forma conceitual. Vrias otimizaes so inseridas nas arquiteturas
apresentadas, com o objetivo principal de melhorar o desempenho das aplicaes nos sistemas convidados. Como os pontos cruciais do desempenho
dos sistemas de mquinas virtuais so as operaes de entrada/sada, as
principais otimizaes utilizadas em sistemas de produo dizem respeito a
essas operaes. Quatro formas de otimizao so usuais:
Em hipervisores nativos (Figura 9.18):
1. O sistema convidado (guest system) acessa diretamente o hardware. Essa forma de acesso implementada por modificaes no
ncleo do sistema convidado e no hipervisor. Essa otimizao
implementada, por exemplo, no subsistema de gerncia de
memria do ambiente Xen [Barham et al., 2003].
Em hipervisores convidados (Figura 9.18):
1. O sistema convidado (guest system) acessa diretamente o sistema
nativo (host system). Essa otimizao implementada pelo hipervisor, oferecendo partes da API do sistema nativo ao sistema
convidado. Um exemplo dessa otimizao a implementao
do sistema de arquivos no VMware [VMware, 2000]: em vez de
reconstruir integralmente o sistema de arquivos sobre um dispositivo virtual provido pelo hipervisor, o sistema convidado
faz uso da implementao de sistema de arquivos existente no
sistema nativo.
2. O sistema convidado (guest system) acessa diretamente o hardware.
Essa otimizao implementada parcialmente pelo hipervisor
e parcialmente pelo sistema nativo, pelo uso de um device driver
especfico. Um exemplo tpico dessa otimizao o acesso direto
a dispositivos fsicos como leitor de CDs, hardware grfico e
interface de rede provida pelo sistema VMware aos sistemas
operacionais convidados [VMware, 2000].
c Carlos Maziero
407
3. O hipervisor acessa diretamente o hardware. Neste caso, um

device driver especfico instalado no sistema nativo, oferecendo ao
hipervisor uma interface de baixo nvel para acesso ao hardware
subjacente. Essa abordagem, ilustrada na Figura 9.19, usada
pelo sistema VMware [VMware, 2000].
aplics
OS 1
aplics
aplics
aplics
guest OS
OS 2
1
monitor
host OS
monitor
hardware
hardware
monitor convidado
(tipo II)
monitor nativo
(tipo I)
Figura 9.18: Otimizaes em sistemas de mquinas virtuais.

VM nativa
arquivos no
SO convidado
SO convidado
VM convidada
VM hbrida
arquivos no
SO convidado
arquivos no
SO convidado
SO convidado
SO convidado
disco virtual
disco virtual
disco virtual
Hipervisor
Hipervisor
Hipervisor
arquivo no
SO hospedeiro
driver
SO hospedeiro
disco real
disco real
SO hospedeiro
disco real
Figura 9.19: Desempenho de hipervisores nativos e convidados.
c Carlos Maziero
408
9.5
9: Aplicaes da virtualizao
Aplicaes da virtualizao
Por permitir o acoplamento entre componentes de sistema com interfaces

distintas, a virtualizao tem um grande nmero de aplicaes possveis.
As principais delas sero brevemente discutidas nesta seo.
O campo de aplicao mais conhecido da virtualizao a portabilidade
de aplicaes binrias. Este uso de mquinas virtuais comeou na dcada
de 1970, com o compilador UCSD Pascal. Esse compilador traduzia o
cdigo-fonte Pascal em um cdigo binrio P-Code, para uma mquina
virtual chamada P-Machine. A execuo do cdigo binrio ficava ento a
cargo de uma implementao da P-Machine sobre a mquina-alvo. Para
executar a aplicao em outra plataforma, bastava portar a implementao
da P-Machine. Esse esquema foi posteriormente adotado pelas linguagens
Java, C#, Perl e Python, entre outras, nas quais o cdigo fonte compilado em
um cdigo binrio (bytecode) para uma mquina virtual especfica. Assim,
uma aplicao Java compilada em bytecode pode executar em qualquer
plataforma onde uma implementao da mquina virtual Java (JVM - Java
Virtual Machine) esteja disponvel.
O compartilhamento de hardware outro uso frequente da virtualizao, por tornar possvel executar simultaneamente vrios sistemas
operacionais, ou vrias instncias do mesmo sistema operacional, sobre a
mesma plataforma de hardware. Uma rea de aplicao dessa possibilidade
a chamada consolidao de servidores, que consiste em agrupar vrios servidores de rede (web, e-mail, proxy, banco de dados, etc.) sobre o mesmo
computador: ao invs de instalar vrios computadores fisicamente isolados
para abrigar cada um dos servios, pode ser instalado um nico computador, com maior capacidade, para suportar vrias mquinas virtuais, cada
uma abrigando um sistema operacional convidado e seu respectivo servio
de rede. Essa abordagem visa aproveitar melhor o hardware existente:
como a distribuio dos recursos entre os sistemas convidados pode ser
ajustada dinamicamente, pode-se alocar mais recursos aos servios com
maior demanda em um dado instante.
Alm dessas aplicaes, diversas outras possibilidades de aplicao de
ambientes de mquinas virtuais podem ser encontradas, entre as quais:
Suporte a aplicaes legadas : pode-se preservar ambientes virtuais para
a execuo de aplicaes legadas, sem a necessidade de manter computadores reservados para isso.
c Carlos Maziero
409
Experimentao com redes e sistemas distribudos : possvel construir

uma rede de mquinas virtuais, comunicando por protocolos de rede
como o TCP/IP, sobre um nico computador hospedeiro. Isto torna
possvel o desenvolvimento e implantao de servios de rede e de
sistemas distribudos sem a necessidade de uma rede real, o que
especialmente interessante dos pontos de vista didtico e experimental.
Ensino : em disciplinas de rede e de sistema, um aluno deve ter a possibilidade de modificar as configuraes da mquina para poder realizar
seus experimentos. Essa possibilidade uma verdadeira dor de
cabea para os administradores de laboratrios de ensino. Todavia,
um aluno pode lanar uma mquina virtual e ter controle completo
sobre ela, mesmo no tendo acesso s configuraes da mquina real
subjacente.
Segurana : a propriedade de isolamento provida pelo hipervisor torna
esta abordagem til para isolar domnios, usurios e/ou aplicaes
no-confiveis. As mquinas virtuais de sistema operacional (Seo
9.3.2) foram criadas justamente com o objetivo de isolar sub-sistemas
particularmente crticos, como servidores Web, DNS e de e-mail. Podese tambm usar mquinas virtuais como plataforma de execuo
de programas suspeitos, para inspecionar seu funcionamento e seus
efeitos sobre o sistema operacional convidado.
Desenvolvimento de software de baixo nvel : o uso de mquinas virtuais para o desenvolvimento de software de baixo nvel, como partes
do ncleo do sistema operacional, mdulos e protocolos de rede, tem
vrios benefcios com o uso de mquinas virtuais. Por exemplo, o desenvolvimento e os testes podem ser feitos sobre a mesma plataforma.
Outra vantagem visvel o menor tempo necessrio para instalar e
lanar um ncleo em uma mquina virtual, quando comparado a uma
mquina real. Por fim, a execuo em uma mquina virtual pode ser
melhor acompanhada e depurada que a execuo equivalente em uma
mquina real.
Tolerncia a faltas : muitos hipervisores oferecem suporte ao checkpointing,
ou seja, possibilidade de salvar o estado interno de uma mquina
virtual e de poder restaur-lo posteriormente. Com checkpoints peridicos, torna-se possvel retornar a execuo de uma mquina virtual a
c Carlos Maziero
410
um estado salvo anteriormente, em caso de falhas ou incidentes de

segurana.
Recentemente, a virtualizao vem desempenhando um papel importante na gerncia de sistemas computacionais corporativos, graas facilidade de migrao de mquinas virtuais implementada pelos hipervisores
modernos. Na migrao, uma mquina virtual e seu sistema convidado so
transferidos de um hipervisor para outro, executando em equipamentos distintos, sem ter de reinici-los. A mquina virtual tem seu estado preservado
e prossegue sua execuo no hipervisor de destino assim que a migrao
concluda. De acordo com [Clark et al., 2005], as tcnicas mais frequentes
para implementar a migrao de mquinas virtuais so:
stop-and-copy: consiste em suspender a mquina virtual, transferir o
contedo de sua memria para o hipervisor de destino e retomar a
execuo em seguida. uma abordagem simples, mas implica em
parar completamente os servios oferecidos pelo sistema convidado
enquanto durar a migrao (que pode demorar algumas dezenas de
segundos);
demand-migration: a mquina virtual suspensa apenas durante a
cpia das estruturas de memria do ncleo do sistema operacional
convidado para o hipervisor de destino, o que dura alguns milissegundos. Em seguida, a execuo da mquina virtual retomada e o
restante das pginas de memria da mquina virtual transferido sob
demanda, atravs dos mecanismos de tratamento de faltas de pgina.
Nesta abordagem a interrupo do servio tem durao mnima, mas
a migrao completa pode demorar muito tempo.
pre-copy: consiste basicamente em copiar para o hipervisor de destino
todas as pginas de memria da mquina virtual enquanto esta executa;
a seguir, a mquina virtual suspensa e as pginas modificadas
depois da cpia inicial so novamente copiadas no destino; uma
vez terminada a cpia dessas pginas, a mquina pode retomar sua
execuo no destino. Esta abordagem, usada no hipervisor Xen
[Barham et al., 2003], a que oferece o melhor compromisso entre o
tempo de suspenso do servio e a durao total da migrao.
c Carlos Maziero
411
9.6
9: Ambientes de mquinas virtuais
Ambientes de mquinas virtuais
Esta seo apresenta alguns exemplos de sistemas de mquinas virtuais

de uso corrente. Sero apresentados os sistemas VMWare, FreeBSD Jails, Xen,
User-Mode Linux, QEMU, Valgrind e JVM. Entre eles h mquinas virtuais de
aplicao e de sistema, com virtualizao total ou paravirtualizao, alm
de abordagens hibridas. Eles foram escolhidos por estarem entre os mais
representativos de suas respectivas classes.
9.6.1
VMware
Atualmente, o VMware a mquina virtual para a plataforma x86 de

uso mais difundido, provendo uma implementao completa da interface x86 ao sistema convidado. Embora essa interface seja extremamente
genrica para o sistema convidado, acaba conduzindo a um hipervisor
mais complexo. Como podem existir vrios sistemas operacionais em
execuo sobre mesmo hardware, o hipervisor tem que emular certas instrues para representar corretamente um processador virtual em cada
mquina virtual, fazendo uso intensivo dos mecanismos de traduo dinmica [VMware, 2000, Newman et al., 2005]. Atualmente, a VMware produz
vrios produtos com hipervisores nativos e convidados:
Hipervisor convidado:
VMware Workstation: primeira verso comercial da mquina
virtual, lanada em 1999, para ambientes desktop;
VMware Fusion: verso experimental para o sistema operacional
Mac OS com processadores Intel;
VMware Player: verso gratuita do VMware Workstation, com
as mesmas funcionalidades mas limitado a executar mquinas
virtuais criadas previamente com verses comerciais;
VMWare Server: conta com vrios recursos do VMware Workstation,
mas voltado para pequenas e mdias empresas;
Hipervisor nativo:
VMware ESX Server: para servidores de grande porte, possui um
ncleo proprietrio chamado vmkernel e Utiliza o Red Hat Linux
para prover outros servios, tais como a gerncia de usurios.
c Carlos Maziero
412
9: FreeBSD Jails
O VMware Workstation utiliza as estratgias de virtualizao total e

traduo dinmica (Seo 9.4). O VMware ESX Server implementa ainda
a paravirtualizao. Por razes de desempenho, o hipervisor do VMware
utiliza uma abordagem hbrida (Seo 9.4.5) para implementar a interface
do hipervisor com as mquinas virtuais [Sugerman et al., 2001]. O controle
de exceo e o gerenciamento de memria so realizados por acesso direto
ao hardware, mas o controle de entrada/sada usa o sistema hospedeiro.
Para garantir que no ocorra nenhuma coliso de memria entre o sistema
convidado e o real, o hipervisor VMware aloca uma parte da memria para
uso exclusivo de cada sistema convidado.
Para controlar o sistema convidado, o VMware Workstation intercepta
todas as interrupes do sistema convidado. Sempre que uma exceo causada no convidado, examinada primeiro pelo hipervisor. As interrupes
de entrada/sada so remetidas para o sistema hospedeiro, para que sejam
processadas corretamente. As excees geradas pelas aplicaes no sistema
convidado (como as chamadas de sistema, por exemplo) so remetidas para
o sistema convidado.
9.6.2
FreeBSD Jails
O sistema operacional FreeBSD oferece um mecanismo de confinamento

de processos denominado Jails, criado para aumentar a segurana de servios
de rede. Esse mecanismo consiste em criar domnios de execuo distintos
(denominados jails ou celas), conforme descrito na Seo 9.3.2. Cada cela
contm um subconjunto de processos e recursos (arquivos, conexes de rede)
que pode ser gerenciado de forma autnoma, como se fosse um sistema
separado [McKusick and Neville-Neil, 2005].
Cada domnio criado a partir de um diretrio previamente preparado
no sistema de arquivos. Um processo que executa a chamada de sistema
jail cria uma nova cela e colocado dentro dela, de onde no pode mais
sair, nem seus filhos. Alm disso, os processos em um domnio no podem:
Reconfigurar o ncleo (atravs da chamada sysctl, por exemplo);
Carregar/retirar mdulos do ncleo;
Mudar configuraes de rede (interfaces e rotas);
Montar/desmontar sistemas de arquivos;
c Carlos Maziero
413
9: Xen
Criar novos devices;

Realizar modificaes de configuraes do ncleo em tempo de execuo;
Acessar recursos que no pertenam ao seu prprio domnio.
Essas restries se aplicam mesmo a processos que estejam executando
com privilgios de administrador (root).
Pode-se considerar que o sistema FreeBSD Jails virtualiza somente partes
do sistema hospedeiro, como a rvore de diretrios (cada domnio tem sua
prpria viso do sistema de arquivos), espaos de nomes (cada domnio
mantm seus prprios identificadores de usurios, processos e recursos
de IPC) e interfaces de rede (cada domnio tem sua interface virtual, com
endereo de rede prprio). Os demais recursos (como as instrues de
mquina e chamadas de sistema) so preservadas, ou melhor, podem
ser usadas diretamente. Essa virtualizao parcial demanda um custo
computacional muito baixo, mas exige que todos os sistemas convidados
executem sobre o mesmo ncleo.
9.6.3
Xen
O ambiente Xen um hipervisor nativo para a plataforma x86 que

implementa a paravirtualizao. Ele permite executar sistemas operacionais
como Linux e Windows especialmente modificados para executar sobre
o hipervisor [Barham et al., 2003]. Verses mais recentes do sistema Xen
utilizam o suporte de virtualizao disponvel nos processadores atuais, o
que torna possvel a execuo de sistemas operacionais convidados sem
modificaes, embora com um desempenho ligeiramente menor que no caso
de sistemas paravirtualizados. De acordo com seus desenvolvedores, o custo
e impacto das alteraes nos sistemas convidados so baixos e a diminuio
do custo da virtualizao compensa essas alteraes: a degradao mdia
de desempenho observada em sistemas virtualizados sobre a plataforma
Xen no excede 5%). As principais modificaes impostas pelo ambiente
Xen a um sistema operacional convidado so:
O mecanismo de entrega de interrupes passa a usar um servio de
eventos oferecido pelo hipervisor; o ncleo convidado deve registrar
um vetor de tratadores de excees junto ao hipervisor;
c Carlos Maziero
414
9: User-Mode Linux
as operaes de entrada/sada de dispositivos so feitas atravs de uma

interface simplificada, independente de dispositivo, que usa buffers
circulares de tipo produtor/consumidor;
o ncleo convidado pode consultar diretamente as tabelas de segmentos e pginas da memria usada por ele e por suas aplicaes, mas as
modificaes nas tabelas devem ser solicitadas ao hipervisor;
o ncleo convidado deve executar em um nvel de privilgio inferior
ao do hipervisor;
o ncleo convidado deve implementar uma funo de tratamento das
chamadas de sistema de suas aplicaes, para evitar que elas tenham
de passar pelo hipervisor antes de chegar ao ncleo convidado.
Como o hipervisor deve acessar os dispositivos de hardware, ele deve
dispor dos drivers adequados. J os ncleos convidados no precisam de
drivers especficos, pois eles acessam dispositivos virtuais atravs de uma
interface simplificada. Para evitar o desenvolvimento de drivers especficos
para o hipervisor, o ambiente Xen usa uma abordagem alternativa: a primeira
mquina virtual (chamada VM0 ) pode acessar o hardware diretamente e
prov os drivers necessrios ao hipervisor. As demais mquinas virtuais
(VMi , i > 0) acessam o hardware virtual atravs do hipervisor, que usa os
drivers da mquina VM0 conforme necessrio. Essa abordagem, apresentada
na Figura 9.20, simplifica muito a evoluo do hipervisor, por permitir
utilizar os drivers desenvolvidos para o sistema Linux.
O hipervisor Xen pode ser considerado uma tecnologia madura, sendo
muito utilizado em sistemas de produo. O seu cdigo-fonte est liberado
sob a licena GNU General Public Licence (GPL). Atualmente, o ambiente Xen
suporta os sistemas Windows, Linux e NetBSD. Vrias distribuies Linux
j possuem suporte nativo ao Xen.
9.6.4
User-Mode Linux
O User-Mode Linux foi proposto por Jeff Dike em 2000, como uma alternativa de uso de mquinas virtuais no ambiente Linux [Dike, 2000]. O ncleo
do Linux foi portado de forma a poder executar sobre si mesmo, como um
processo do prprio Linux. O resultado um user space separado e isolado
na forma de uma mquina virtual, que utiliza dispositivos de hardware
c Carlos Maziero
415
9: User-Mode Linux
VM 0 (gerncia)
VM 1
VM n
aplics de
gerncia
aplicaes
convidadas
aplicaes
convidadas
...
Linux convidado
driver
nativo
driver
back-end
SO convidado
SO convidado
driver
front-end
driver
front-end
Hipervisor Xen
hardware x86
Figura 9.20: O hipervisor Xen.

virtualizados a partir dos servios providos pelo sistema hospedeiro. Essa
mquina virtual capaz de executar todos os servios e aplicaes disponveis para o sistema hospedeiro. Alm disso, o custo de processamento e de
memria das mquinas virtuais User-Mode Linux geralmente menor que
aquele imposto por outros hipervisores mais complexos.
O User-Mode Linux hipervisor convidado, ou seja, executa na forma de
um processo no sistema hospedeiro. Os processos em execuo na mquina
virtual no tm acesso direto aos recursos do sistema hospedeiro. A maior
dificuldade na implementao do User-Mode Linux foi encontrar formas de
virtualizar as funcionalidades do hardware para as chamadas de sistema do
Linux, sobretudo a distino entre o modo privilegiado do ncleo e o modo
no-privilegiado de usurio. Um cdigo somente pode estar em modo
privilegiado se confivel o suficiente para ter pleno acesso ao hardware,
como o prprio ncleo do sistema operacional. O User-Mode Linux deve
possuir uma distino de privilgios equivalente para permitir que o seu
ncleo tenha acesso s chamadas de sistema do sistema hospedeiro quando
os seus prprios processos solicitarem este acesso, ao mesmo tempo em que
impede os mesmos de acessar diretamente os recursos reais subjacentes.
No hipervisor, a distino de privilgios foi implementada com o mecanismo de interceptao de chamadas do prprio Linux, fornecido pela
c Carlos Maziero
416
9: QEMU
chamada de sistema ptrace1 . Usando a chamada ptrace, o hipervisor

recebe o controle de todas as chamadas de sistema de entrada/sada geradas
pelas mquinas virtuais. Todos os sinais gerados ou enviados s mquinas
virtuais tambm so interceptados. A chamada ptrace tambm utilizada
para manipular o contexto do sistema convidado.
O User-Mode Linux utiliza o sistema hospedeiro para operaes de
entrada/sada. Como a mquina virtual um processo no sistema hospedeiro,
a troca de contexto entre duas instncias de mquinas virtuais rpida,
assim como a troca entre dois processos do sistema hospedeiro. Entretanto,
modificaes no sistema convidado foram necessrias para a otimizao da
troca de contexto. A virtualizao das chamadas de sistema implementada
pelo uso de uma thread de rastreamento que intercepta e redireciona todas
as chamadas de sistema para o ncleo virtual. Este identifica a chamada
de sistema e os seus argumentos, cancela a chamada e modifica estas
informaes no hospedeiro, onde o processo troca de contexto e executa a
chamada na pilha do ncleo.
O User-Mode Linux est disponvel na verso 2.6 do ncleo Linux, ou seja,
ele foi assimilado rvore oficial de desenvolvimento do ncleo, portanto
melhorias na sua arquitetura devero surgir no futuro, ampliando seu uso
em diversos contextos de aplicao.
9.6.5
QEMU
O QEMU um hipervisor com virtualizao completa [Bellard, 2005].

No requer alteraes ou otimizaes no sistema hospedeiro, pois utiliza
intensivamente a traduo dinmica (Seo 9.4) como tcnica para prover a
virtualizao. um dos poucos hipervisores recursivos, ou seja, possvel
chamar o QEMU a partir do prprio QEMU. O hipervisor QEMU oferece
dois modos de operao:
Emulao total do sistema: emula um sistema completo, incluindo
processador (normalmente um Intel Pentium II) e vrios perifricos.
Neste modo o emulador pode ser utilizado para executar diferentes
sistemas operacionais;
1
Chamada de sistema que permite observar e controlar a execuo de outros processos;

o comando strace do Linux permite ter uma noo de como a chamada de sistema ptrace
funciona.
c Carlos Maziero
417
9: Valgrind
Emulao no modo de usurio: disponvel apenas para o sistema Linux.

Neste modo o emulador pode executar processos Linux compilados
em diferentes plataformas (por exemplo, um programa compilado
para um processador x86 pode ser executado em um processador
PowerPC e vice-versa).
Durante a emulao de um sistema completo, o QEMU implementa uma
MMU (Memory Management Unit) totalmente em software, para garantir
o mximo de portabilidade. Quando em modo usurio, o QEMU simula
uma MMU simplificada atravs da chamada de sistema mmap (que permite
mapear um arquivo em uma regio da memria) do sistema hospedeiro.
Por meio de um mdulo instalado no ncleo do sistema hospedeiro,
denominado KQEMU ou QEMU Accelerator, o hipervisor QEMU consegue
obter um desempenho similar ao de outras mquinas virtuais como VMWare
e User-Mode Linux. Com este mdulo, o QEMU passa a executar as chamadas
de sistema emitidas pelos processos convidados diretamente sobre o sistema
hospedeiro, ao invs de interpretar cada uma. O KQEMU permite associar
os dispositivos de entrada/sada e o endereamento de memria do sistema
convidado aos do sistema hospedeiro. Processos em execuo sobre o ncleo
convidado passam a executar diretamente no modo usurio do sistema
hospedeiro. O modo ncleo do sistema convidado utilizado apenas para
virtualizar o processador e os perifricos.
O VirtualBox [VirtualBox, 2008] um ambiente de mquinas virtuais
construdo sobre o hipervisor QEMU. Ele similar ao VMware Workstation em
muitos aspectos. Atualmente, pode tirar proveito do suporte virtualizao
disponvel nos processadores Intel e AMD. Originalmente desenvolvido
pela empresa Innotek, o VirtualBox foi adquirido pela Sun Microsystems e
liberado para uso pblico sob a licena GPLv2.
9.6.6
Valgrind
O Valgrind [Nethercote and Seward, 2007] uma ferramenta de depurao de uso da memria RAM e problemas correlatos. Ele permite investigar
fugas de memria (memory leaks), acessos a endereos invlidos, padres de
uso dos caches e outras operaes envolvendo o uso da memria RAM. O
Valgrind foi desenvolvido para plataforma x86 Linux, mas existem verses
experimentais para outras plataformas.
Tecnicamente, o Valgrind um hipervisor de aplicao que virtualiza o
processador atravs de tcnicas de traduo dinmica. Ao iniciar a anlise
c Carlos Maziero
418
9: JVM
de um programa, o Valgrind traduz o cdigo executvel do mesmo para um

formato interno independente de plataforma denominado IR (Intermediate
Representation). Aps a converso, o cdigo em IR instrumentado, atravs
da insero de instrues para registrar e verificar as operaes de alocao,
acesso e liberao de memria. A seguir, o programa IR devidamente
instrumentado traduzido no formato binrio a ser executado sobre o
processador virtual. O cdigo final pode ser at 50 vezes mais lento que o
cdigo original, mas essa perda de desempenho normalmente no muito
relevante durante a anlise ou depurao de um programa.
9.6.7
JVM
comum a implementao do suporte de execuo de uma linguagem

de programao usando uma mquina virtual. Um bom exemplo dessa
abordagem ocorre na linguagem Java. Tendo sido originalmente concebida
para o desenvolvimento de pequenos aplicativos e programas de controle
de aparelhos eletroeletrnicos, a linguagem Java mostrou-se ideal para ser
usada na Internet. O que o torna to atraente o fato de programas escritos
em Java poderem ser executados em praticamente qualquer plataforma. A
virtualizao o fator responsvel pela independncia dos programas Java
do hardware e dos sistemas operacionais: um programa escrito em Java,
ao ser compilado, gera um cdigo binrio especfico para uma mquina
abstrata denominada mquina virtual Java (JVM - Java Virtual Machine). A
linguagem de mquina executada pela mquina virtual Java denominada
bytecode Java, e no corresponde a instrues de nenhum processador real.
A mquina virtual deve ento interpretar todas as operaes do bytecode,
utilizando as instrues da mquina real subjacente para execut-las.
A vantagem mais significativa da abordagem adotada por Java a
portabilidade do cdigo executvel: para que uma aplicao Java possa
executar sobre uma determinada plataforma, basta que a mquina virtual
Java esteja disponvel ali (na forma de um suporte de execuo denominado
JRE - Java Runtime Environment). Assim, a portabilidade dos programas
Java depende unicamente da portabilidade da prpria mquina virtual Java.
O suporte de execuo Java pode estar associado a um navegador Web, o
que permite que cdigo Java seja associado a pginas Web, na forma de
pequenas aplicaes denominadas applets, que so trazidas junto com os
demais componentes de pgina Web e executam localmente no navegador.
A Figura 9.21 mostra os principais componentes da plataforma Java.
c Carlos Maziero
419
9: JVM
Cdigo
fonte
Java
.java
aplicao
em
bytecode
compilao
aplicao
em
bytecode
JVM
JVM
carga
Windows
x86
carga
.jar
distribuio
bytecode
distribuio
Solaris
Sparc
Figura 9.21: Mquina virtual Java.

importante ressaltar que a adoo de uma mquina virtual como
suporte de execuo no exclusividade de Java, nem foi inventada por
seus criadores. As primeiras experincias de execuo de aplicaes sobre
mquinas abstratas remontam aos anos 1970, com a linguagem UCSD
Pascal. Hoje, muitas linguagens adotam estratgias similares, como Java,
C#, Python, Perl, Lua e Ruby. Em C#, o cdigo-fonte compilado em um
formato intermedirio denominado CIL (Common Intermediate Language),
que executa sobre uma mquina virtual CLR (Common Language Runtime).
CIL e CLR fazem parte da infraestrutura .NET da Microsoft.
Referncias Bibliogrficas
[Amoroso, 1994] Amoroso, E. (1994). Fundamentals of Computer Security
Technology. Prentice Hall PTR.
[Anderson et al., 2002] Anderson, D., Cobb, J., Korpela, E., Lebofsky, M.,
and Werthimer, D. (2002). SETI@home: An experiment in public-resource
computing. Communications of the ACM, 45(11):5661.
[Anderson et al., 1992] Anderson, T., Bershad, B., Lazowska, E., and Levy,
H. (1992). Scheduler activations: effective kernel support for the userlevel management of parallelism. ACM Transactions on Computer Systems,
10(1):5379.
[Arpaci-Dusseau et al., 2003] Arpaci-Dusseau, A., Arpaci-Dusseau, R., Burnett, N., Denehy, T., Engle, T., Gunawi, H., Nugent, J., and Popovici, F.
(2003). Transforming policies into mechanisms with InfoKernel. In 19th
ACM Symposium on Operating Systems Principles.
[Avizienis et al., 2004] Avizienis, A., Laprie, J.-C., Randell, B., and
Landwehr, C. (2004). Basic Concepts and Taxonomy of Dependable
and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1).
[Bach, 1986] Bach, M. J. (1986). The design of the UNIX operating System.
Prentice-Hall.
[Badger et al., 1995] Badger, L., Sterne, D., Sherman, D., Walker, K., and
Haghighat, S. (1995). Practical Domain and Type Enforcement for UNIX.
In IEEE Symposium on Security and Privacy, pages 6677.
[Bansal and Modha, 2004] Bansal, S. and Modha, D. (2004). CAR: Clock
with adaptive replacement. In USENIX Conference on File and Storage
Technologies.
c Carlos Maziero
421
9: REFERNCIAS BIBLIOGRFICAS
[Barham et al., 2003] Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris,
T., Ho, A., Neugebauer, R., Pratt, I., and Warfield, A. (2003). Xen and the
art of virtualization. In ACM Symposium on Operating Systems Principles,
pages 164177.
[Barney, 2005] Barney, B. (2005).
POSIX threads programming.
http://www.llnl.gov/computing/tutorials/pthreads.
[Bell and LaPadula, 1974] Bell, D. E. and LaPadula, L. J. (1974). Secure
computer systems. mathematical foundations and model. Technical
Report M74-244, MITRE Corporation.
[Bellard, 2005] Bellard, F. (2005). QEMU, a fast and portable dynamic
translator. In USENIX Annual Technical Conference.
[Ben-Ari, 1990] Ben-Ari, M. (1990). Principles of Concurrent and Distributed
Programming. Prentice-Hall.
[Biba, 1977] Biba, K. (1977). Integrity considerations for secure computing
systems. Technical Report MTR-3153, MITRE Corporation.
[Birrell, 2004] Birrell, A. (2004). Implementing condition variables with
semaphores. Computer Systems Theory, Technology, and Applications, pages
2937.
[Black, 1990] Black, D. L. (1990). Scheduling and resource management techniques for multiprocessors. Technical Report CMU-CS-90-152, CarnegieMellon University, Computer Science Dept.
[Blunden, 2002] Blunden, B. (2002). Virtual Machine Design and Implementation in C/C++. Worldware Publishing.
[Boebert and Kain, 1985] Boebert, W. and Kain, R. (1985). A practical alternative to hierarchical integrity policies. In 8th National Conference on
Computer Security, pages 1827.
[Bomberger et al., 1992] Bomberger, A., Frantz, A., Frantz, W., Hardy, A.,
Hardy, N., Landau, C., and Shapiro, J. (1992). The KeyKOS nanokernel
architecture. In USENIX Workshop on Micro-Kernels and Other Kernel
Architectures, pages 95112.
c Carlos Maziero
422
[Bovet and Cesati, 2005] Bovet, D. and Cesati, M. (2005). Understanding the
Linux Kernel, 3rd edition. OReilly Media, Inc.
[Boyd-Wickizer et al., 2009] Boyd-Wickizer, S., Morris, R., and Kaashoek, M.
(2009). Reinventing scheduling for multicore systems. In 12th conference
on Hot topics in operating systems, page 21. USENIX Association.
[Brown, 2000] Brown, K. (2000). Programming Windows Security. AddisonWesley Professional.
[Burns and Wellings, 1997] Burns, A. and Wellings, A. (1997). Real-Time
Systems and Programming Languages, 2nd edition. Addison-Wesley.
[Carr and Hennessy, 1981] Carr, R. and Hennessy, J. (1981). WSclock - a
simple and effective algorithm for virtual memory management. In ACM
symposium on Operating systems principles.
[Chen et al., 1994] Chen, P. M., Lee, E. K., Gibson, G. A., Katz, R. H., and
Patterson, D. A. (1994). RAID: high-performance, reliable secondary
storage. ACM Computing Surveys, 26:145185.
[Clark et al., 2005] Clark, C., Fraser, K., Hand, S., Hansen, J., Jul, E., Limpach,
C., Pratt, I., and Warfield, A. (2005). Live migration of virtual machines.
In Symposium on Networked Systems Design and Implementation.
[Coffman et al., 1971] Coffman, E., Elphick, M., and Shoshani, A. (1971).
System deadlocks. ACM Computing Surveys, 3(2):6778.
[Corbat, 1963] Corbat, F. (1963). The Compatible Time-Sharing System: A
Programmers Guide. MIT Press.
[Corbat et al., 1962] Corbat, F., Daggett, M., and Daley, R. (1962). An
experimental time-sharing system. In Proceedings of the Spring Joint
Computer Conference.
[Corbat and Vyssotsky, 1965] Corbat, F. J. and Vyssotsky, V. A. (1965).
Introduction and overview of the Multics system. In AFIPS Conference
Proceedings, pages 185196.
[Corbet et al., 2005] Corbet, J., Rubini, A., and Kroah-Hartman, G. (2005).
Linux Device Drivers, 3rd Edition. OReilly Media, Inc.
c Carlos Maziero
423
[Cowan et al., 2000] Cowan, C., Beattie, S., Kroah-Hartman, G., Pu, C.,
Wagle, P., and Gligor, V. (2000). SubDomain: Parsimonious server
security. In 14th USENIX Systems Administration Conference.
[Dasgupta et al., 1991] Dasgupta, P., Richard J. LeBlanc, J., Ahamad, M.,
and Ramachandran, U. (1991). The Clouds distributed operating system.
Computer, 24(11):3444.
[Day, 1983] Day, J. (1983). The OSI reference model. Proceedings of the IEEE.
[Denning, 1980] Denning, P. (1980). Working sets past and present. IEEE
Transactions on Software Engineering, 6(1):6484.
[Denning, 2006] Denning, P. J. (2006). The locality principle. In Barria, J.,
editor, Communication Networks and Computer Systems, chapter 4, pages
4367. Imperial College Press.
[di Vimercati et al., 2007] di Vimercati, S., Foresti, S., Jajodia, S., and Samarati, P. (2007). Access control policies and languages in open environments.
In Yu, T. and Jajodia, S., editors, Secure Data Management in Decentralized Systems, volume 33 of Advances in Information Security, pages 2158.
Springer.
[di Vimercati et al., 2005] di Vimercati, S., Samarati, P., and Jajodia, S. (2005).
Policies, Models, and Languages for Access Control. In Workshop on
Databases in Networked Information Systems, volume LNCS 3433, pages
225237. Springer-Verlag.
[Dike, 2000] Dike, J. (2000). A user-mode port of the Linux kernel. In
Proceedings of the 4th Annual Linux Showcase & Conference.
[Dorward et al., 1997] Dorward, S., Pike, R., Presotto, D., Ritchie, D., Trickey,
H., and Winterbottom, P. (1997). The Inferno operating system. Bell Labs
Technical Journal, 2(1):518.
[Downey, 2008] Downey, A. (2008). The Little Book of Semaphores. Green Tea
Press.
[Duesterwald, 2005] Duesterwald, E. (2005). Design and engineering of a
dynamic binary optimizer. Proceedings of the IEEE, 93(2):436448.
c Carlos Maziero
424
[Engeschall, 2005] Engeschall, R. (2005).

http://www.gnu.org/software/pth.
The GNU Portable Threads.
[Evans and Elischer, 2003] Evans, J. and Elischer, J. (2003). Kernelscheduled entities for FreeBSD. http://www.aims.net.au/chris/kse.
[Farines et al., 2000] Farines, J.-M., da Silva Fraga, J., and de Oliveira, R. S.
(2000). Sistemas de Tempo Real 12a Escola de Computao da SBC. Sociedade
Brasileira de Computao.
[Ford and Susarla, 1996] Ford, B. and Susarla, S. (1996). CPU Inheritance
Scheduling. In Usenix Association Second Symposium on Operating Systems
Design and Implementation (OSDI), pages 91105.
[Foundation, 2005] Foundation, W. (2005). Wikipedia online enciclopedia.
http://www.wikipedia.org.
[Freed and Borenstein, 1996] Freed, N. and Borenstein, N. (1996). RFC 2046:
Multipurpose Internet Mail Extensions (MIME) part two: Media types.
[Gallmeister, 1994] Gallmeister, B. (1994). POSIX.4: Programming for the Real
World. OReilly Media, Inc.
[Gnome, 2005] Gnome (2005). Gnome: the free software desktop project.
http://www.gnome.org.
[Goldberg, 1973] Goldberg, R. (1973). Architecture of virtual machines. In
AFIPS National Computer Conference.
[Goldberg and Mager, 1979] Goldberg, R. and Mager, P. (1979). Virtual
machine technology: A bridge from large mainframes to networks of
small computers. IEEE Proceedings Compcon Fall 79, pages 210213.
[Hart, 2004] Hart, J. (2004). Windows System Programming, 3rd edition.
Addison-Wesley Professional.
[Holt, 1972] Holt, R. (1972). Some deadlock properties of computer systems.
ACM Computing Surveys, 4(3):179196.
[IBM, 2007] IBM (2007). Power Instruction Set Architecture Version 2.04.
IBM Corporation.
c Carlos Maziero
425
[Jain et al., 2004] Jain, A., Ross, A., and Prabhakar, S. (2004). An Introduction
to Biometric Recognition. IEEE Transactions on Circuits and Systems for
Video Technology, 14(1).
[Jiang and Zhang, 2002] Jiang, S. and Zhang, X. (2002). LIRS: an efficient
low inter-reference recency set replacement policy to improve buffer
cache performance. In ACM SIGMETRICS Intl Conference on Measurement
and Modeling of Computer Systems, pages 3142.
[Johnstone and Wilson, 1999] Johnstone, M. S. and Wilson, P. R. (1999).
The memory fragmentation problem: solved? ACM SIGPLAN Notices,
34(3):2636.
[Jones, 1997] Jones, M. (1997). What really happened on Mars Rover Pathfinder. ACM Risks-Forum Digest, 19(49).
[Kay and Lauder, 1988] Kay, J. and Lauder, P. (1988). A fair share scheduler.
Communications of the ACM, 31(1):4455.
[KDE, 2005] KDE (2005). KDE desktop project. http://www.kde.org.
[Kernighan and Ritchie, 1989] Kernighan, B. and Ritchie, D. (1989). C: a
Linguagem de Programao - Padro ANSI. Campus/Elsevier.
[King et al., 2003] King, S., Dunlap, G., and Chen, P. (2003). Operating
system support for virtual machines. In Proceedings of the USENIX
Technical Conference.
[Klein et al., 2009] Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock,
D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolanski, R., Norrish, M.,
Sewell, T., Tuch, H., and Winwood, S. (2009). SeL4: Formal verification of
an OS kernel. In 22nd ACM Symposium on Operating Systems Principles,
Big Sky, MT, USA.
[Lamport, 1974] Lamport, L. (1974). A new solution of Dijkstras concurrent
programming problem. Communications of the ACM, 17(8):453455.
[Lampson, 1971] Lampson, B. (1971). Protection. In 5th Princeton Conference
on Information Sciences and Systems. Reprinted in ACM Operating Systems
Rev. 8, 1 (Jan. 1974), pp 18-24.
c Carlos Maziero
426
[Lampson and Redell, 1980] Lampson, B. and Redell, D. (1980). Experience

with processes and monitors in Mesa. Communications of the ACM.
[Levine, 2000] Levine, J. (2000). Linkers and Loaders. Morgan Kaufmann.
[Lichtenstein, 1997] Lichtenstein, S. (1997). A review of information security
principles. Computer Audit Update, 1997(12):924.
[Liedtke, 1996] Liedtke, J. (1996). Toward real microkernels. Communications
of the ACM, 39(9):7077.
[Loscocco and Smalley, 2001] Loscocco, P. and Smalley, S. (2001). Integrating Flexible Support for Security Policies into the Linux Operating
System. In USENIX Annual Technical Conference, pages 2942.
[Love, 2004] Love, R. (2004). Linux Kernel Development. Sams Publishing
Developers Library.
[Mauro and McDougall, 2006] Mauro, J. and McDougall, R. (2006). Solaris
Internals: Solaris 10 and OpenSolaris Kernel Architecture. Prentice-Hall PTR.
[McKusick and Neville-Neil, 2005] McKusick, M. and Neville-Neil, G.
(2005). The Design and Implementation of the FreeBSD Operating System.
Pearson Education.
[Menezes et al., 1996] Menezes, A., Van Oorschot, P., and Vanstone, S. (1996).
Handbook of Applied Cryptography. CRC Press.
[Microsoft, 2007] Microsoft (2007). Security Enhancements in Windows Vista.
Microsoft Corporation.
[Mitnick and Simon, 2002] Mitnick, K. D. and Simon, W. L. (2002). The Art
of Deception: Controlling the Human Element of Security. John Wiley & Sons,
Inc., New York, NY, USA.
[Mollin, 2000] Mollin, R. A. (2000). An Introduction to Cryptography. CRC
Press, Inc., Boca Raton, FL, USA.
[Nanda and Chiueh, 2005] Nanda, S. and Chiueh, T. (2005). A survey on
virtualization technologies. Technical report, University of New York at
Stony Brook.
c Carlos Maziero
427
[Navarro et al., 2002] Navarro, J., Iyer, S., Druschel, P., and Cox, A. (2002).
Practical, transparent operating system support for superpages. In 5th
USENIX Symposium on Operating Systems Design and Implementation, pages
89104.
[Nethercote and Seward, 2007] Nethercote, N. and Seward, J. (2007). Valgrind: A framework for heavyweight dynamic binary instrumentation.
In ACM Conference on Programming Language Design and Implementation,
San Diego - California - USA.
[Neuman and Tso, 1994] Neuman, B. C. and Tso, T. (1994). Kerberos: An
authentication service for computer networks. IEEE Communications
Magazine, 32(9):3338.
[Neuman et al., 2005] Neuman, C., Yu, T., Hartman, S., and Raeburn, K.
(2005). The Kerberos Network Authentication Service (V5). RFC 4120
(Proposed Standard). Updated by RFCs 4537, 5021.
[Newman et al., 2005] Newman, M., Wiberg, C.-M., and Braswell, B.
(2005). Server Consolidation with VMware ESX Server. IBM RedBooks.
http://www.redbooks.ibm.com.
[Nichols et al., 1996] Nichols, B., Buttlar, D., and Farrell, J. (1996). PThreads
Programming. OReilly Media, Inc.
[Nieh and Lam, 1997] Nieh, J. and Lam, M. (1997). The design, implementation and evaluation of SMART: a scheduler for multimedia applications.
In Proceedings of the 16th ACM Symposium on Operating Systems Principles,
pages 184197.
[Patterson and Henessy, 2005] Patterson, D. and Henessy, J. (2005). Organizao e Projeto de Computadores. Campus.
[Patterson et al., 1988] Patterson, D. A., Gibson, G., and Katz, R. H. (1988). A
case for redundant arrays of inexpensive disks (RAID). In ACM SIGMOD
International Conference on Management of Data, pages 109116. ACM.
[Petzold, 1998] Petzold, C. (1998). Programming Windows, 5th edition. Microsoft Press.
[Pfleeger and Pfleeger, 2006] Pfleeger, C. and Pfleeger, S. L. (2006). Security
in Computing, 4th Edition. Prentice Hall PTR.
c Carlos Maziero
428
[Pike et al., 1995] Pike, R., Presotto, D., Dorward, S., Flandrena, B., Thompson, K., Trickey, H., and Winterbottom, P. (1995). Plan 9 from Bell Labs.
Journal of Computing Systems, 8(3):221254.
[Pike et al., 1993] Pike, R., Presotto, D., Thompson, K., Trickey, H., and
Winterbottom, P. (1993). The use of name spaces in Plan 9. Operating
Systems Review, 27(2):7276.
[Popek and Goldberg, 1974] Popek, G. and Goldberg, R. (1974). Formal
requirements for virtualizable third generation architectures. Communications of the ACM, 17(7):412421.
[Price and Tucker, 2004] Price, D. and Tucker, A. (2004). Solaris zones:
Operating system support for consolidating commercial workloads. In
18th USENIX conference on System administration, pages 241254.
[Provos et al., 2003] Provos, N., Friedl, M., and Honeyman, P. (2003). Preventing privilege escalation. In 12th USENIX Security Symposium.
[Rashid et al., 1989] Rashid, R., Julin, D., Orr, D., Sanzi, R., Baron, R., Forin,
A., Golub, D., and Jones, M. B. (1989). Mach: a system software kernel.
In Proceedings of the 1989 IEEE International Conference, COMPCON, pages
176178, San Francisco, CA, USA. IEEE Comput. Soc. Press.
[Raynal, 1986] Raynal, M. (1986). Algorithms for Mutual Exclusion. The MIT
Press.
[Rice, 2000] Rice, L. (2000). Introduction to OpenVMS. Elsevier Science &
Technology Books.
[Robbins and Robbins, 2003] Robbins, K. and Robbins, S. (2003). UNIX
Systems Programming. Prentice-Hall.
[Robin and Irvine, 2000] Robin, J. and Irvine, C. (2000). Analysis of the Intel
Pentiums ability to support a secure virtual machine monitor. In 9th
USENIX Security Symposium.
[Rosenblum, 2004] Rosenblum, M. (2004). The reincarnation of virtual
machines. Queue Focus - ACM Press, pages 3440.
c Carlos Maziero
429
[Rosenblum and Garfinkel, 2005] Rosenblum, M. and Garfinkel, T. (2005).

Virtual machine monitors: Current technology and future trends. IEEE
Computer.
[Rozier et al., 1992] Rozier, M., Abrossimov, V., Armand, F., Boule, I., Gien,
M., Guillemont, M., Herrman, F., Kaiser, C., Langlois, S., Lonard, P., and
Neuhauser, W. (1992). Overview of the Chorus distributed operating
system. In Workshop on Micro-Kernels and Other Kernel Architectures, pages
3970, Seattle WA (USA).
[Russell et al., 2004] Russell, R., Quinlan, D., and Yeoh, C. (2004). Filesystem
Hierarchy Standard.
[Russinovich and Solomon, 2004] Russinovich, M. and Solomon, D. (2004).
Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server 2003,
Windows XP, and Windows 2000. Microsoft Press.
[Saltzer and Schroeder, 1975] Saltzer, J. and Schroeder, M. (1975). The protection of information in computer systems. Proceedings of the IEEE,
63(9):1278 1308.
[Samarati and De Capitani di Vimercati, 2001] Samarati, P. and De Capitani di Vimercati, S. (2001). Access control: Policies, models, and mechanisms. In Focardi, R. and Gorrieri, R., editors, Foundations of Security
Analysis and Design, volume 2171 of LNCS. Springer-Verlag.
[Sandhu et al., 1996] Sandhu, R., Coyne, E., Feinstein, H., and Youman, C.
(1996). Role-based access control models. IEEE Computer, 29(2):3847.
[Sandhu and Samarati, 1996] Sandhu, R. and Samarati, P. (1996). Authentication, access control, and audit. ACM Computing Surveys, 28(1).
[Seward and Nethercote, 2005] Seward, J. and Nethercote, N. (2005). Using
Valgrind to detect undefined value errors with bit-precision. In USENIX
Annual Technical Conference.
[Sha et al., 1990] Sha, L., Rajkumar, R., and Lehoczky, J. (1990). Priority
inheritance protocols: An approach to real-time synchronization. IEEE
Transactions on Computers, 39(9):11751185.
c Carlos Maziero
430
[Shapiro and Hardy, 2002] Shapiro, J. and Hardy, N. (2002). Eros: a

principle-driven operating system from the ground up. Software, IEEE,
19(1):2633.
[Shirey, 2000] Shirey, R. (2000). RFC 2828: Internet security glossary.
[Silberschatz et al., 2001] Silberschatz, A., Galvin, P., and Gagne, G. (2001).
Sistemas Operacionais Conceitos e Aplicaes. Campus.
[Smith and Nair, 2004] Smith, J. and Nair, R. (2004). Virtual Machines: Architectures, Implementations and Applications. Morgan Kaufmann.
[SNIA, 2009] SNIA (2009). Common RAID Disk Data Format Specification.
SNIA Storage Networking Industry Association. Version 2.0 Revision
19.
[Spencer et al., 1999] Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Andersen, D., and Lepreau, J. (1999). The Flask security architecture: System
support for diverse security policies. In 8th USENIX Security Symposium,
pages 123139.
[Stevens, 1998] Stevens, R. (1998). UNIX Network Programming. PrenticeHall.
[Sugerman et al., 2001] Sugerman, J., Venkitachalam, G., and Lim, B. H.
(2001). Virtualizing I/O devices on VMware workstations hosted virtual
machine monitor. In USENIX Annual Technical Conference, pages 114.
[Sun Microsystems, 2000] Sun Microsystems (2000). Trusted Solaris Users
Guide. Sun Microsystems, Inc.
[Tanenbaum, 2003] Tanenbaum, A. (2003). Sistemas Operacionais Modernos,
2a edio. Pearson Prentice-Hall.
[Tanenbaum et al., 1991] Tanenbaum, A., Kaashoek, M., van Renesse, R.,
and Bal, H. (1991). The Amoeba distributed operating system a status
report. Computer Communications, 14:324335.
[Tripwire, 2003] Tripwire (2003).
http://www.tripwire.org.
The Tripwire open source project.
c Carlos Maziero
431
: REFERNCIAS BIBLIOGRFICAS
[Uhlig and Mudge, 1997] Uhlig, R. and Mudge, T. (1997). Trace-driven

memory simulation: a survey. ACM Computing Surveys, 29(2):128170.
[Uhlig et al., 2005] Uhlig, R., Neiger, G., Rodgers, D., Santoni, A., Martins,
F., Anderson, A., Bennett, S., Kgi, A., Leung, F., and Smith, L. (2005).
Intel virtualization technology. IEEE Computer.
[Ung and Cifuentes, 2006] Ung, D. and Cifuentes, C. (2006). Dynamic reengineering of binary code with run-time feedbacks. Science of Computer
Programming, 60(2):189204.
[Vahalia, 1996] Vahalia, U. (1996). UNIX Internals The New Frontiers.
Prentice-Hall.
[VirtualBox, 2008] VirtualBox, I. (2008). The VirtualBox architecture.
http://www.virtualbox.org/wiki/VirtualBox_architecture.
[VMware, 2000] VMware (2000). VMware technical white paper. Technical
report, VMware, Palo Alto, CA - USA.
[Watson, 2001] Watson, R. (2001). TrustedBSD: Adding trusted operating
system features to FreeBSD. In USENIX Technical Conference.
[Whitaker et al., 2002] Whitaker, A., Shaw, M., and Gribble, S. (2002). Denali:
A scalable isolation kernel. In ACM SIGOPS European Workshop.
[Yen, 2007] Yen, C.-H. (2007). Solaris operating system - hardware virtualization product architecture. Technical Report 820-3703-10, Sun
Microsystems.
Apndice A
O Task Control Block do Linux
A estrutura em linguagem C apresentada a seguir constitui o descritor
de tarefas (Task Control Block) do Linux (estudado na Seo 2.4.1). Ela foi
extrada do arquivo include/linux/sched.h do cdigo-fonte do ncleo
Linux 2.6.12 (o arquivo inteiro contm mais de 1.200 linhas de cdigo em C).
1
2
3
4
5
6
struct task_struct {
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
struct thread_info *thread_info;
atomic_t usage;
unsigned long flags; /* per process flags, defined below */
unsigned long ptrace;
7
8
int lock_depth;
/* BKL lock depth */
10
11
12
int prio, static_prio;

struct list_head run_list;
prio_array_t *array;
13
14
15
16
17
unsigned long sleep_avg;

unsigned long long timestamp, last_ran;
unsigned long long sched_time; /* sched_clock time spent running */
int activated;
18
19
20
21
unsigned long policy;

cpumask_t cpus_allowed;
unsigned int time_slice, first_time_slice;
22
23
24
25
#ifdef CONFIG_SCHEDSTATS
struct sched_info sched_info;
#endif
c Carlos Maziero
433
A: O Task Control Block do Linux
26
27
28
29
30
31
32
33
struct list_head tasks;

/*
* ptrace_list/ptrace_children forms the list of my children
* that were stolen by a ptracer.
*/
struct list_head ptrace_children;
struct list_head ptrace_list;
34
35
struct mm_struct *mm, *active_mm;
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
/* task state */
struct linux_binfmt *binfmt;
long exit_state;
int exit_code, exit_signal;
int pdeath_signal; /* The signal sent when the parent dies */
/* ??? */
unsigned long personality;
unsigned did_exec:1;
pid_t pid;
pid_t tgid;
/*
* pointers to (original) parent process, youngest child, younger sibli
* older sibling, respectively. (p->father can be replaced with
* p->parent->pid)
*/
struct task_struct *real_parent; /* real parent process (when being deb
struct task_struct *parent; /* parent process */
/*
* children/sibling forms the list of my children plus the
* tasks Im ptracing.
*/
struct list_head children; /* list of my children */
struct list_head sibling; /* linkage in my parents children list */
struct task_struct *group_leader; /* threadgroup leader */
61
62
63
/* PID/PID hash table linkage. */

struct pid pids[PIDTYPE_MAX];
64
65
66
67
struct completion *vfork_done;

int __user *set_child_tid;
int __user *clear_child_tid;
/* for vfork() */
/* CLONE_CHILD_SETTID */
/* CLONE_CHILD_CLEARTID */
68
69
70
71
unsigned long rt_priority;

cputime_t utime, stime;
unsigned long nvcsw, nivcsw; /* context switch counts */
72
73
74
c Carlos Maziero
434
struct timespec start_time;

/* mm fault and swap info: this can arguably be seen as either mm-specific or
unsigned long min_flt, maj_flt;
75
76
77
78
cputime_t it_prof_expires, it_virt_expires;

unsigned long long it_sched_expires;
struct list_head cpu_timers[3];
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
00
01
02
03
04
05
06
07
08
09
/* process credentials */
uid_t uid,euid,suid,fsuid;
gid_t gid,egid,sgid,fsgid;
struct group_info *group_info;
kernel_cap_t cap_effective, cap_inheritable, cap_permitted;
unsigned keep_capabilities:1;
struct user_struct *user;
#ifdef CONFIG_KEYS
struct key *thread_keyring; /* keyring private to this thread */
#endif
int oomkilladj; /* OOM kill score adjustment (bit shift). */
char comm[TASK_COMM_LEN]; /* executable name excluding path
- access with [gs]et_task_comm (which lock
it with task_lock())
- initialized normally by flush_old_exec */
/* file system info */
int link_count, total_link_count;
/* ipc stuff */
struct sysv_sem sysvsem;
/* CPU-specific state of this task */
struct thread_struct thread;
/* filesystem information */
struct fs_struct *fs;
/* open file information */
struct files_struct *files;
/* namespace */
struct namespace *namespace;
/* signal handlers */
struct signal_struct *signal;
struct sighand_struct *sighand;
10
11
12
sigset_t blocked, real_blocked;

struct sigpending pending;
13
14
15
16
17
unsigned long sas_ss_sp;

size_t sas_ss_size;
int (*notifier)(void *priv);
void *notifier_data;
18
c Carlos Maziero
435
sigset_t *notifier_mask;
19
20
21
22
void *security;
struct audit_context *audit_context;
seccomp_t seccomp;
23
24
25
26
27
28
29
30
31
32
/* Thread group tracking */

u32 parent_exec_id;
u32 self_exec_id;
/* Protection of (de-)allocation: mm, files, fs, tty, keyrings */
spinlock_t alloc_lock;
/* Protection of proc_dentry: nesting proc_lock, dcache_lock, write_lock_irq(&
spinlock_t proc_lock;
/* context-switch lock */
spinlock_t switch_lock;
33
34
35
/* journalling filesystem info */

void *journal_info;
36
37
38
/* VM state */
struct reclaim_state *reclaim_state;
39
40
41
struct dentry *proc_dentry;

struct backing_dev_info *backing_dev_info;
42
43
struct io_context *io_context;
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
unsigned long ptrace_message;

siginfo_t *last_siginfo; /* For ptrace use. */
/*
* current io wait handle: wait queue entry to use for io waits
* If this thread is processing aio, this points at the waitqueue
* inside the currently handled kiocb. It may be NULL (i.e. default
* to a stack based synchronous wait) if its doing sync IO.
*/
wait_queue_t *io_wait;
/* i/o counters(bytes read/written, #syscalls */
u64 rchar, wchar, syscr, syscw;
#if defined(CONFIG_BSD_PROCESS_ACCT)
u64 acct_rss_mem1; /* accumulated rss usage */
u64 acct_vm_mem1;
/* accumulated virtual memory usage */
clock_t acct_stimexpd; /* clock_t-converted stime since last update */
#endif
#ifdef CONFIG_NUMA
struct mempolicy *mempolicy;
short il_next;
64
65
66
67
68
69
70
c Carlos Maziero
436
#endif
#ifdef CONFIG_CPUSETS
struct cpuset *cpuset;
nodemask_t mems_allowed;
int cpuset_mems_generation;
#endif
};

So Livro A5 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

So Livro A5 PDF

Caricato da

Copyright:

Formati disponibili

#include <pthread.

Sistemas Operacionais: Conceitos e Mecanismos

Lucia, Henrique e Daniel, as estrelas mais brilhantes do meu firmamento...

Prof. Carlos Maziero, Dr.

Dedico il Capitolo 8 ai colleghi docenti e ricercatori del Dipartimento di Technologie

Je ddie le Chapitre 9 lquipe ADEPT IRISA/INRIA Rennes - France, au sein de

2.4.2 Trocas de contexto . . . . . . . . . . . . . . . .

Comunicao entre tarefas

8.5.6 Mecanismos de controle de acesso

A O Task Control Block do Linux

Existe uma grande distncia entre os circuitos eletrnicos e dispositivos

programas aplicativos uma forma de acesso homognea aos dispositivos

Figura 1.1: Estrutura de um sistema de computao tpico

Acessar os recursos de hardware de um sistema de computao pode

Tornar os aplicativos independentes do hardware. Ao definir uma interface

Os programas aplicativos usam o hardware para atingir seus objetivos:

1: Tipos de sistemas operacionais

imprimir (print jobs) normalmente atendidos de forma sequencial

Tipos de sistemas operacionais

Os sistemas operacionais podem ser classificados segundo diversos

1: Tipos de sistemas operacionais

ser executado em sequncia, sem interferncia do usurio. Exemplos

1: Tipos de sistemas operacionais

Para cumprir seus objetivos de abstrao e gerncia, o sistema operacional

Distribuir de forma justa, mas no necessariamente igual, pois as aplicaes tm

Gerncia de dispositivos : cada perifrico do computador possui suas

Alm dessas funcionalidades bsicas oferecidas pela maioria dos sistemas

Figura 1.2: Funcionalidades do sistema operacional

1: Estrutura de um sistema operacional

tirar memria de uma aplicao, enviar ou receber um pacote de rede,

Estrutura de um sistema operacional

Um sistema operacional no um bloco nico e fechado de software

As diversas partes do sistema operacional esto relacionadas entre

Figura 1.3: Estrutura de um sistema operacional

teclados. A maioria dos computadores mono-processados atuais segue uma

Figura 1.4: Arquitetura de um computador tpico

O acesso memria geralmente mediado por um controlador especfico

Quando um controlador de perifrico tem uma informao importante a

Ao receber a requisio de interrupo, os circuitos do processador

Figura 1.5: Roteiro tpico de um tratamento de interrupo

4. O processamento desviado do programa em execuo para a rotina

As interrupes recebidas pelo processador tm como origem eventos

Um sistema operacional deve gerenciar os recursos do hardware,

inteiro. Alm disso, aplicaes com acesso pleno ao hardware tornariam

para esse processador s use os nveis extremos (0 para o ncleo e drivers do

O confinamento de cada aplicao em sua rea de memria, imposto

Figura 1.6: Separao entre o ncleo e as aplicaes

em modo usurio atravs de uma biblioteca do sistema (system library), que

1. No nvel usurio, a aplicao invoca a funo read(fd, &buffer, bytes)

1: Arquiteturas de Sistemas Operacionais

Figura 1.7: Roteiro tpico de uma chamada de sistema

Arquiteturas de Sistemas Operacionais

Em um sistema monoltico, todos os componentes do ncleo operam

Figura 1.8: Uma arquitetura monoltica

um componente do ncleo perca o controle devido a algum erro, esse

Uma forma mais elegante de estruturar um sistema operacional faz

Uma outra possibilidade de estruturao consiste em retirar do ncleo

Figura 1.9: Viso geral de uma arquitetura micro-ncleo

Figura 1.10: Uma mquina virtual [Smith and Nair, 2004].

Um ambiente de mquina virtual consiste de trs partes bsicas, que

Mquinas virtuais de sistema : so construdos para suportar sistemas

Figura 1.11: Mquinas virtuais de aplicao e de sistema.

int main (int argc, char argv[], char envp[])