#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
Conceitos e Mecanismos
while Operacionais:
(__sync_fetch_and_add
(l, 1)) ;
}
Prof. Carlos A. Maziero, Dr.
leave_cs (int
DAINF *l)
UTFPR

void
{
(*l) = 0 ;
}

8 de agosto 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.
Prof. Carlos Maziero, Dr.
Curitiba PR, Outubro de 2011

iii

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 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

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.
2
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.

iv

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

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 . . . . . . . . . . . . . . . . . . . . .
2.4.2 Trocas de contexto . . . . . . . . . . . . . . . .
2.4.3 Processos . . . . . . . . . . . . . . . . . . . . .
2.4.4 Threads . . . . . . . . . . . . . . . . . . . . . .
2.5 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)
v

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

1
1
2
3
4
6
8
10
11
13
15
18
18
19
19
21
25

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

27
27
28
29
30
31
32
33
35
35
36
37
42
47
48
49
50

c Carlos Maziero

2.5.4
2.5.5
2.5.6
2.5.7
3

0: SUMRIO

Escalonamento SJF (Shortest Job First)

Escalonamento por prioridades . . . .
Outros algoritmos de escalonamento .
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 . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

53
54
62
63

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

65
65
66
67
67
68
69
71
72
73
74
74
77
78

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 . . . . . . . . . . . . . . . . . . .
4.6 Semforos . . . . . . . . . . . . . . . . . . . . . . .
4.7 Variveis de condio . . . . . . . . . . . . . . . . .
4.8 Monitores . . . . . . . . . . . . . . . . . . . . . . .
4.9 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 . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

82
82
82
85
86
87
87
88
89
89
91
91
95
97
99
99
101
103
105
107
108
109

vi

c Carlos Maziero

0: SUMRIO

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 . . . . . . . . . . . . . . . . .
Gerncia de arquivos
6.1 Arquivos . . . . . . . . . . . . . . . . .
6.1.1 O conceito de arquivo . . . . .
6.1.2 Atributos . . . . . . . . . . . . .
6.1.3 Operaes . . . . . . . . . . . .
6.1.4 Formatos . . . . . . . . . . . . .
6.1.5 Arquivos especiais . . . . . . .
6.2 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 . . . . . .
6.3 Organizao de volumes . . . . . . . .
6.3.1 Diretrios . . . . . . . . . . . .
6.3.2 Caminhos de acesso . . . . . .
6.3.3 Atalhos . . . . . . . . . . . . . .
6.3.4 Montagem de volumes . . . . .
6.4 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 .

vii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

114
114
116
118
120
121
121
123
124
127
136
136
139
143
145
146
149
150
157
159
160

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

163
163
163
164
165
166
170
171
171
173
174
176
178
180
181
183
186
187
188
189
190
191
203

c Carlos Maziero

6.5
7

0: SUMRIO

Tpicos avanados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

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 . . . . . . . . . .
7.5 Interfaces de rede . . . . . . . . . . . . .
7.6 Dispositivos USB . . . . . . . . . . . . .
7.7 Interfaces de udio . . . . . . . . . . . .
7.8 Interface grfica . . . . . . . . . . . . . .
7.9 Mouse e teclado . . . . . . . . . . . . . .
7.10 Outros tpicos . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Segurana de sistemas
8.1 Introduo . . . . . . . . . . . . . . . . . . . . .
8.2 Conceitos bsicos . . . . . . . . . . . . . . . . .
8.2.1 Propriedades e princpios de segurana
8.2.2 Ameaas . . . . . . . . . . . . . . . . . .
8.2.3 Vulnerabilidades . . . . . . . . . . . . .
8.2.4 Ataques . . . . . . . . . . . . . . . . . .
8.2.5 Malwares . . . . . . . . . . . . . . . . .
8.2.6 Infraestrutura de segurana . . . . . . .
8.3 Fundamentos de criptografia . . . . . . . . . .
8.3.1 Cifragem e decifragem . . . . . . . . . .
8.3.2 Criptografia simtrica e assimtrica . .
8.3.3 Resumo criptogrfico . . . . . . . . . .
8.3.4 Assinatura digital . . . . . . . . . . . . .
8.3.5 Certificado de chave pblica . . . . . .
8.4 Autenticao . . . . . . . . . . . . . . . . . . . .
8.4.1 Usurios e grupos . . . . . . . . . . . .
8.4.2 Tcnicas de autenticao . . . . . . . . .
8.4.3 Senhas . . . . . . . . . . . . . . . . . . .
8.4.4 Senhas descartveis . . . . . . . . . . .
viii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

205
205
207
207
207
209
212
214
218
218
221
229
230
230
231
235
235
241
241
241
241
241
241

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

242
242
243
243
245
245
247
249
251
253
253
254
256
257
258
260
261
262
262
263

c Carlos Maziero

8.5

8.6

0: SUMRIO

8.4.5 Tcnicas biomtricas . . . . . . . . . . . . . . . . . . . .

8.4.6 Desafio-resposta . . . . . . . . . . . . . . . . . . . . . .
8.4.7 Certificados de autenticao . . . . . . . . . . . . . . . .
8.4.8 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.9 Infra-estruturas de autenticao . . . . . . . . . . . . .
Controle de acesso . . . . . . . . . . . . . . . . . . . . . . . . .
8.5.1 Polticas, modelos e mecanismos de controle de acesso
8.5.2 Polticas discricionrias . . . . . . . . . . . . . . . . . .
8.5.3 Polticas obrigatrias . . . . . . . . . . . . . . . . . . . .
8.5.4 Polticas baseadas em domnios e tipos . . . . . . . . .
8.5.5 Polticas baseadas em papis . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . .

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 . . . . . . . . . . . . . .

ix

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

264
265
267
267
270
271
272
273
278
280
282
283
290
293
293
296
297

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

299
299
299
300
301
303
305
307
307
309
312
313
314
317
319
321
321
322
323
324
325
327
329
329
330
331
333

c Carlos Maziero

9.6.5
9.6.6
9.6.7

0: SUMRIO

QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Referncias Bibliogrficas

336

A O Task Control Block do Linux

346

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 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.

c Carlos Maziero

1: Abstrao de recursos

editor de
textos

aplicativos

reprodutor
de mdia

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.

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.

1.1.1

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;
2

c Carlos Maziero

1: Gerncia de recursos

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).
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.

c Carlos Maziero

1: Tipos de sistemas operacionais

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 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 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.

c Carlos Maziero

1: Tipos de sistemas operacionais

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.
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-micro-ondas, 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
5

c Carlos Maziero

1: Funcionalidades

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.

1.3

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

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.
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 inter-dependentes: 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.

c Carlos Maziero

1: Estrutura de um sistema operacional

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 retirar 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:
2

Na verdade essa regra to importante que deveria ser levada em conta na construo de qualquer
sistema computacional complexo.

c Carlos Maziero

1: Estrutura de um sistema operacional

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, test-los 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.
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

c Carlos Maziero

1.5

1: Conceitos de hardware

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 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
10

c Carlos Maziero

1: Interrupes

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.
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).
Ao receber a requisio de interrupo, os circuitos do processador suspendem seu
fluxo de execuo corrente e desviam 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 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.
11

c Carlos Maziero

programa
em execuo

1: Interrupes
Memria
1

rotina de
tratamento de
interrupo

5
6

rede
2

MMU

processador

dados

controladora
de rede

endereos

controle

Figura 1.5: Roteiro tpico de um tratamento de interrupo

A Figura 1.5 representa os principais passos associados ao tratamento de uma
interrupo envolvendo a placa de rede Ethernet, enumerados a seguir:
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;
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
12

c Carlos Maziero

1: Proteo do ncleo

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.
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,
13

c Carlos Maziero

1: Proteo do ncleo

Tabela 1.2: Vetor de Interrupes do processador Pentium [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

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)

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 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 para esse
processador s use os nveis extremos (0 para o ncleo e drivers do sistema operacional

14

c Carlos Maziero

1: Chamadas de sistema

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.

nvel
usurio

aplicao

aplicao

nvel
ncleo

aplicao

aplicao

ncleo

hardware

Figura 1.6: Separao entre o ncleo e as aplicaes

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
15

c Carlos Maziero

1: Chamadas de sistema

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 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
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.

16

c Carlos Maziero

1: Chamadas de sistema

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.
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.

17

c Carlos Maziero

1.6

1: Arquiteturas de Sistemas Operacionais

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 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 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
18

c Carlos Maziero

1: Sistemas em camadas

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.
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
19

c Carlos Maziero

1: Sistemas micro-ncleo

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.
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

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.
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,
20

c Carlos Maziero

1: Mquinas virtuais

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.

1.6.4

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].

21

c Carlos Maziero

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.
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.
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
22

c Carlos Maziero

1: Mquinas virtuais

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.

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 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.
Os trabalhos [Goldberg, 1973, Blunden, 2002] relacionam algumas vantagens para a
utilizao de mquinas virtuais em sistemas de computao:
23

c Carlos Maziero

1: Mquinas virtuais
aplics

OS 1

aplics

aplics

aplics

guest OS

OS 2
host OS

hipervisor

hipervisor

hardware

hardware

hipervisor nativo

hipervisor convidado

Figura 1.12: Arquiteturas de mquinas virtuais de sistema.

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.

24

c Carlos Maziero

1.7

1: Um breve histrico dos sistemas operacionais

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]:
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.
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.
25

c Carlos Maziero

1: Um breve histrico dos sistemas operacionais

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.

26

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.
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
27

c Carlos Maziero

2: O conceito de tarefa

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 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 inter-dependentes
para elaborar a torta (preparar a massa, fazer o recheio, decorar, etc.), um programa
28

c Carlos Maziero

2: A gerncia de tarefas

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:

4
2
1
3
Figura 2.1: Tarefas de um navegador 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;
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.

2.3

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
29

c Carlos Maziero

2: Sistemas mono-tarefa

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.
disco

Memria

dados

tarefa

resultados

processador

control.
de disco
4

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.
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:
30

c Carlos Maziero

2: Sistemas multi-tarefa

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.

2.3.2

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:
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!

31

c Carlos Maziero

nova

2: Sistemas de tempo compartilhado

terminou de
ser carregada
em memria

inicia a
execuo

pronta

dado disponvel ou
evento ocorreu

executando

suspensa

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.

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 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 TimeSharing 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.
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
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].

32

c Carlos Maziero

2: Ciclo de vida das tarefas

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.
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.

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:
33

c Carlos Maziero

2: Ciclo de vida das tarefas

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.
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.
34

c Carlos Maziero

2: Implementao de tarefas

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 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, ...);
35

c Carlos Maziero

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 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).
36

c Carlos Maziero

2: Processos

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

restaura contexto

TCB(t1)

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.

2.4.3

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

37

c Carlos Maziero

2: Processos

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.
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.

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 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
38

c Carlos Maziero

2: Processos

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.
Processo pai

Processo pai

Processo lho

tarefas

memria

tarefas

memria

tarefas

memria

arqs abertos

conexes

arqs abertos

conexes

arqs abertos

conexes

fork

return

ncleo

return

ncleo

Figura 2.9: A chamada de sistema fork: antes (esq) e depois (dir) de sua execuo pelo
ncleo do sistema UNIX.
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 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:

39

c Carlos Maziero

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 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.

40

c Carlos Maziero

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. 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.

41

c Carlos Maziero

2.4.4

2: Threads

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.
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
42

c Carlos Maziero

2: Threads

Processo pb

Processo pa
threads

threads

memria

biblioteca

biblioteca

thread de
ncleo

memria

ncleo

thread de
ncleo

Figura 2.10: O modelo de threads N:1.

ele conhece e gerencia: as threads de ncleo. Assim, 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.
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

43

c Carlos Maziero

2: Threads

Processo pb

Processo pa
threads

threads

memria

memria

ncleo
threads
de ncleo

Figura 2.11: O modelo de threads 1:1.

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

threads

memria

biblioteca

biblioteca

thread de
ncleo

memria

ncleo

threads
de ncleo

Figura 2.12: O modelo de threads N:M.

44

c Carlos Maziero

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 th- read 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.

O modelo N:M implementado pelo Solaris e tambm pelo projeto KSE (KernelScheduled 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. 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.

45

c Carlos Maziero

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

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):

46

c Carlos Maziero

1
2

2: Escalonamento de tarefas

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);
MyThread t2 = new MyThread (2);
MyThread t3 = new MyThread (3);

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 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).
47

c Carlos Maziero

2: Objetivos e mtricas

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.
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).
48

c Carlos Maziero

2: Escalonamento preemptivo e cooperativo

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, 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.
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
49

c Carlos Maziero

2: Escalonamento FCFS (First-Come, First Served)

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.

Escalonamento FCFS (First-Come, First Served)

2.5.3

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).
t4
t3
t2
t1

t
0

11

14

Figura 2.13: Escalonamento FCFS.

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 =

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 =

50

c Carlos Maziero

2: Escalonamento FCFS (First-Come, First Served)

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 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.
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 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 :
51

c Carlos Maziero

t2

t=0

t=2

t=3

t=4

t=5

t=6

t4

t1

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

2: Escalonamento FCFS (First-Come, First Served)

t=8

t=9

t=10

t=11

t2

t=12

t=13

t3

t4

t1

t1

t3

t4

t1

t3

t4

t4

t1

t3

t4

t1

t3

t4

t1

t3

t4

t1

t=14

t4

Figura 2.15: Evoluo da fila de tarefas prontas no escalonamento Round-Robin.

E=

tq
tq + ttc

Por exemplo, um sistema no qual as trocas de contexto duram 1ms e cujo quantum
20
mdio de 20ms ter uma eficincia E = 20+1
= 95, 2%. Caso a durao do quantum
2
seja reduzida para 2ms, a eficincia cair para 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.

52

c Carlos Maziero

2: Escalonamento SJF (Shortest Job First)

Escalonamento SJF (Shortest Job First)

2.5.4

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.
t4
t3
t2
t1

t
0

14

Figura 2.16: Escalonamento SJF.

Calculando o tempo mdio de execuo Tt e o tempo mdio de espera Tw para o
algoritmo SJF, temos:
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

53

c Carlos Maziero

2: Escalonamento por prioridades

tempo, esse algoritmo pode ser de grande valia, sobretudo para tarefas orientadas a
entrada/sada.
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.
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

54

t2
0
2
3

t3
1
4
1

t4
3
3
4

c Carlos Maziero

2: Escalonamento por prioridades

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).

Calculando o tempo mdio de execuo Tt e o tempo mdio de espera 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 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

Figura 2.18: Escalonamento por prioridades (preemptivo).

55

14

c Carlos Maziero

2: Escalonamento por prioridades

Calculando o tempo mdio de execuo Tt e o tempo mdio de espera 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.).
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.
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:
4: baixa ou ociosa
56

c Carlos Maziero

2: Escalonamento por prioridades

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.

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
57

c Carlos Maziero

2: Escalonamento por prioridades

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 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):
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
58

c Carlos Maziero

2: Escalonamento por prioridades

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 .
t3
t2
t1

t
0

Figura 2.21: Escalonamento por prioridades com envelhecimento.

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 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;
59

c Carlos Maziero

2: Escalonamento por prioridades

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.
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).

60

c Carlos Maziero

2: Escalonamento por prioridades

Pa acorda, solicita o recurso

e ca bloqueado esperando
Pb libera o recurso
bloqueado e
perde o processador

Pm recebe o processador

Pa

R
Pm

Pb aloca um
recurso para si

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).
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
61

c Carlos Maziero

2: Outros algoritmos de escalonamento

tarefa
funo
prioridade durao
tg
gerncia da rea de transferncia
alta
curta
tm
coleta de dados meteorolgicos
baixa
curta
comunicao com a Terra
mdia
longa
tc
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.

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
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
multi-processador [Black, 1990] e multi-core [Boyd-Wickizer et al., 2009].

62

c Carlos Maziero

2.5.7

2: Um escalonador real

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.
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
63

c Carlos Maziero

2: Um escalonador real

tarefas, ou seja, a grande maioria das aplicaes e comandos dos usurios, executa na
classe de escalonamento SCHED_OTHER.

64

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 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 interdependentes. Cada mdulo tem suas prprias responsabilidades e coopera com
os demais mdulos quando necessrio. Sistemas de interface grfica, como os

65

c Carlos Maziero

3: Escopo da comunicao

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 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.
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).

66

c Carlos Maziero

3: Caractersticas dos mecanismos de comunicao

Computador 1

Computador 2

Processo pa
tarefa i

Processo pb

tarefa j

send

Processo pc

tarefa k

tarefa l

recv

rea
comum

send

send recv

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 intersistemas (tk tl ).

3.3

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

67

c Carlos Maziero

3: Sincronismo

as tarefas esto associadas: enviar (dados, canal) e receber (dados, canal). A Figura 3.2
ilustra essas duas formas de comunicao.
receptor

emissor

receptor

emissor

canal
dados

enviar

dados

enviar

receber

dados

Figura 3.2: Comunicao direta (esquerda) e indireta (direita).

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 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

dados

enviar

receber

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
68

c Carlos Maziero

3: Formato de envio

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 tornar 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 semi-bloqueantes) 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.
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.
69

c Carlos Maziero

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.

emissor

ab

1234

xyz

enviar

buer

receptor

ab

enviar

1234

enviar

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 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.
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.
70

c Carlos Maziero

3: Capacidade dos canais

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.

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 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.
71

c Carlos Maziero

3: Confiabilidade dos canais

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).
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.

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 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
72

c Carlos Maziero

3: Nmero de participantes

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.

3.3.6

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.

73

c Carlos Maziero

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 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;
74

c Carlos Maziero

3: Filas de mensagens UNIX

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).

75

c Carlos Maziero

1
2

3: Filas de mensagens UNIX

// 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

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

{
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:

76

c Carlos Maziero

1
2

3: Pipes

// 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

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

{
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
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

77

c Carlos Maziero

3: Memria compartilhada

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

grep

pipe

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 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
78

c Carlos Maziero

3: Memria compartilhada

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.
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.
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.

79

c Carlos Maziero

3: Memria compartilhada

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>

9
10
11
12

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

{
int fd, value, *ptr;

13

// 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) ;
}

14
15
16
17
18
19
20

// Passos 1 a 3: ajusta o tamanho da area compartilhada

if (ftruncate(fd, sizeof(value)) == -1) {
perror ("ftruncate");
exit (1) ;
}

21
22
23
24
25
26

// 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);
}

27
28
29
30
31
32
33

for (;;) {
// Passo 5: escreve um valor aleatorio na area compartilhada
value = random () % 1000 ;
(*ptr) = value ;
printf ("Wrote value %i\n", value) ;
sleep (1);

34
35
36
37
38
39
40

// Passo 5: le e imprime o conteudo da area compartilhada

value = (*ptr) ;
printf("Read value %i\n", value);
sleep (1) ;

41
42
43
44

45
46

80

c Carlos Maziero

3: Memria compartilhada

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.

81

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 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.

82

c Carlos Maziero

1
2
3
4
5

4: Condies de disputa

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 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

terminal 1

tarefa 1

tarefa 2
depositar

depositar

conta

depositar
R$1000

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.
83

c Carlos Maziero

4: Condies de disputa

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 monoprocessados, a sobreposio pode acontecer caso ocorram trocas de contexto durante a
execuo do depsito. Em sistemas multi-processados 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 .
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.
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
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.

84

c Carlos Maziero

4: Sees crticas

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.

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
85

c Carlos Maziero

4: Inibio de interrupes

uma tarefa j esteja ocupando a seo crtica csi , as demais tarefas que tentarem 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

typedef struct conta_t

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

// saldo atual da conta

// identificao da conta (seo crtica)
// outras informaes da conta

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.

4.4

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
86

c Carlos Maziero

4: Solues com espera ocupada

inteiro ser bloqueado. Uma tarefa mal-intencionada 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.

4.5.1

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
87

c Carlos Maziero

4: Alternncia de uso

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.
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.

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:
1
2

int turn = 0 ;
int num_tasks ;

3
4
5
6
7

void enter (int task)

{
while (turn != task) ;
}

// task vale 0, 1, ..., num_tasks-1

// a tarefa espera seu turno

8
9
10
11
12
13
14
15

void leave (int task)

{
if (turn < num_tasks-1) // o turno da prxima tarefa
turn ++ ;
else
turn = 0 ;
// volta primeira tarefa
}

88

c Carlos Maziero

4: O algoritmo de Peterson

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.

4.5.3

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:
1
2

int turn = 0 ;
// indica de quem a vez
int wants[2] = {0, 0} ; // indica se a tarefa i quer acessar a seo crtica

3
4
5
6
7
8
9
10

void enter (int task)

// 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
}

11
12
13
14
15

void leave (int task)

{
wants[task] = 0 ;
}

// 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.
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
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.

89

c Carlos Maziero

4: Instrues Test-and-Set

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:
1

int lock ;

// 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
90

c Carlos Maziero

4: Problemas

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 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;

91

c Carlos Maziero

4: Semforos

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 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:
3

Alguns sistemas implementam tambm a chamada TryDown(s), cuja semntica no-bloqueante:

caso o semforo solicitado esteja ocupado, a chamada retorna imediatamente, com um cdigo de erro.

92

c Carlos Maziero

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

1
2
3
4
5
6

4: Semforos

// saldo atual da conta

// semforo associado conta, valor inicial 1
// outras informaes da conta

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
}

8
9
10
11
12
13

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.
4

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.

93

c Carlos Maziero

1

4: Semforos

sem_t vagas = 500 ;

2
3
4
5
6
7

void carro_entra ()
{
down (vagas) ;
...
}

// solicita uma vaga de estacionamento

// demais aes especficas da aplicao

8
9
10
11
12
13

void carro_sai ()
{
up (vagas) ;
...
}

// libera uma vaga de estacionamento

// demais aes especficas da aplicao

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:

94

c Carlos Maziero

4: Variveis de condio

#include <pthread.h>

1
2

// 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);

3
4
5
6

// destri uma varivel do tipo mutex

int pthread_mutex_destroy (pthread_mutex_t *mutex);

7
8
9

// solicita acesso seo crtica protegida pelo mutex;

// se a seo estiver ocupada, bloqueia a tarefa
int pthread_mutex_lock (pthread_mutex_t *mutex);

10
11
12
13

// 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);

14
15
16
17

// libera o acesso seo crtica protegida pelo mutex

int pthread_mutex_unlock (pthread_mutex_t *mutex);

18
19

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.
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:
5

Assim como os operadores sobre semforos, os operadores sobre variveis de condio tambm
devem ser implementados de forma atmica.

95

c Carlos Maziero

1
2
3
4
5

wait (c):
c.queue t
unlock (c.mutex)
suspend (t)
lock (c.mutex)

4: Variveis de condio

//
//
//
//

coloca a tarefa t no fim de c.queue

libera o mutex
pe a tarefa atual para dormir
quando acordar, obtm o mutex imediatamente

6
7
8

notify (c):
awake (first (c.queue)) // acorda a primeira tarefa da fila c.queue

9
10
11

broadcast (c):
awake (c.queue)

// 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.
1
2
3
4
5
6
7
8
9
10

Task A ()
{
...
lock (c.mutex)
while (not condition)
wait (c) ;
...
unlock (c.mutex)
...
}

11
12
13
14
15
16
17
18
19
20

Task B ()
{
...
lock (c.mutex)
condition = true
notify (c)
unlock (c.mutex)
...
}

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.

96

c Carlos Maziero

4.8

4: Monitores

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;
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

97

c Carlos Maziero

4: Monitores

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 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].

98

c Carlos Maziero

4.9

4: Problemas clssicos de coordenao

Problemas clssicos de coordenao

Algumas situaes de coordenao entre atividades ocorrem com muita frequncia

na programao de sistemas complexos. Os problemas clssicos de 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.
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.

99

c Carlos Maziero

4: O problema dos produtores/consumidores

c1
C

p1

buer
L

p2

c2
A

c3
Figura 4.5: O problema dos produtores/consumidores.
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:
1
2
3

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.
100

c Carlos Maziero

4.9.2

4: O problema dos leitores/escritores

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.

l1
M[3]?

e1

M[3]=2

M
3

e2

M?
1

l2

M[1]?

M=[2,1,0,6]

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:

101

c Carlos Maziero

1

sem_t mutex_area ;

4: O problema dos leitores/escritores

// 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) {
sem_down (&mutex_area) ;
...
sem_up (&mutex_area) ;
...
}
}

// requer acesso exclusivo rea

// escreve dados na rea compartilhada
// libera o acesso rea

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:

102

c Carlos Maziero

1
2
3

sem_t mutex_area ;
int conta_leitores = 0 ;
sem_t mutex_conta ;

4: O jantar dos filsofos

// 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_down (&mutex_area) ;
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_area) ;
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) ;
...
}
}

// requer acesso exclusivo rea

// escreve dados na rea compartilhada
// libera o acesso rea

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 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)

103

c Carlos Maziero

4: O jantar dos filsofos

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.

f4
p4

f3

p0

f0

p1
p3
f2

p2

f1

Figura 4.7: O jantar dos filsofos chineses.

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:
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]) ;
}
}

104

// obtem palito i
// obtem palito i+1
// devolve palito i
// devolve palito i+1

c Carlos Maziero

4: Impasses

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
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
f1

p2

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
105

c Carlos Maziero

4: Impasses

a consistncia dos mesmos. Para isso, a cada 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

typedef struct conta_t

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

// saldo atual da conta

// semforo associado conta
// outras informaes da 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, 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.

106

c Carlos Maziero

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.

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]:
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.

107

c Carlos Maziero

4: Grafos de alocao de recursos

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 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,
108

c Carlos Maziero

4: Tcnicas de tratamento de impasses

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.
r1

t1

r3

r4
t2

r2
t3

t4

Figura 4.11: Grafo de alocao com mltiplas instncias de recursos.

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 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
109

c Carlos Maziero

4: Tcnicas de tratamento de impasses

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 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, solicitandoo 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 viceversa), 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, 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
110

c Carlos Maziero

4: Tcnicas de tratamento de impasses

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 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

111

c Carlos Maziero

4: Tcnicas de tratamento de impasses

E0

E1

E2

E3

E4

E5

E6

E7

E20

E8

E21

E16

E22

E17

E9

E14

E10

Estados
inseguros
E23

E18

E15

E12

E13

E19

E11

impasse

Figura 4.12: Grafo de estados do sistema de transferncias com duas tarefas.

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

112

c Carlos Maziero

4: Tcnicas de tratamento de impasses

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 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 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.

113

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, CD-ROMs, DVD-ROMs, fitas magnticas, etc.) tambm podem ser
considerados 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).
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
114

c Carlos Maziero

5: Estruturas de memria

registradores

velocidade,
custo e
consumo
de energia

cache L1

cache L2

memria RAM

voltil
no-voltil

memria Flash
disco rgido

CD-ROM, DVD-ROM, ta magntica

capacidade

Figura 5.1: Hierarquia de memria.

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, 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)

Tabela 5.1:
Tempos de
[Patterson and Henessy, 2005].

acesso

taxas

Taxa de transferncia
1 GB/s (1 ns/byte)
1 GB/s (1 ns/byte)
10 MB/s (100 ns/byte)
80 MB/s (12 ns/byte)

10 MB/s (100 ns/byte)

de

transferncia

tpicas

Neste captulo sero estudados os mecanismos envolvidos na gerncia da memria

principal do computador, que geralmente constituda por um grande espao de
115

c Carlos Maziero

5: Endereos, variveis e funes

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):
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:

116

c Carlos Maziero

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

5: Endereos, variveis e funes

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 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

117

c Carlos Maziero

5: Endereos lgicos e fsicos

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.

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 pelo
processador. Caso o acesso a um determinado endereo solicitado pelo processador no
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 arquivos-objeto; 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].

118

c Carlos Maziero

5: Endereos lgicos e fsicos

edio/
programao

cdigo
fonte

arq.c

lib.c

biblioteca
fonte

compilao

cdigo
objeto

arq.o

biblioteca
esttica

lib.a

ligao

cdigo
executvel

lib.so
lib.dll

arq.exe

biblioteca
dinmica

carga

execuo

processo

Figura 5.2: Momentos de atribuio de endereos.

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
119

c Carlos Maziero

5: Modelo de memria dos processos

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 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.

120

c Carlos Maziero

5: Estratgias de alocao
rea no alocada

max

TEXT

STACK

HEAP

DATA

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 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
121

c Carlos Maziero

5: Parties fixas

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

part 4

max

Figura 5.6: Alocao em parties fixas.

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].
122

c Carlos Maziero

5.3.2

5: Alocao contgua

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.
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
124.257 (endereo fsico)

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.

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 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].
123

c Carlos Maziero

5: Alocao por segmentos

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.

5.3.3

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.S2

P2.S4

P1.S1

P2.S1

P1.S6

P1.S3

P1.S4

P1.S2

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
124

c Carlos Maziero

5: Alocao por segmentos

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.
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 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
125

c Carlos Maziero

5: Alocao por segmentos

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

32.300

8.750

45.000

12.000

87.000

7.600

...

...

offset
6.914

no

o<lim
8.750

1.500

segmento

Erro: violao de
segmento (IRQ)

sim

32.300

MMU
39.214 (endereo fsico)

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.

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 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.

126

c Carlos Maziero

5: Alocao paginada

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.
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
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.

127

c Carlos Maziero

5: Alocao paginada
pginas
processo P1

processo P2

Memria RAM

ncleo
rea no-paginada

quadros

Figura 5.11: Alocao de memria por pginas.

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 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

128

c Carlos Maziero

5: Alocao paginada

Para traduzir um endereo lgico no endereo fsico correspondente, a MMU precisa

efetuar os seguintes passos:
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)
registrador atualizado
na troca de contexto
que ativou P3

PTBR

0000 5E9A (endereo lgico)

PTBR
pgina

offset

0 13

Pginas no-mapeadas

Tabela de pginas
(em memria RAM)

A7

2F

4B

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.

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
129

c Carlos Maziero

5: Alocao paginada

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 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.
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.
130

c Carlos Maziero

5: Alocao paginada

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.

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:

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.
131

c Carlos Maziero

5: Alocao paginada
processo P3

TCB(P3)

registrador atualizado
na troca de contexto
que ativou P3

PTBR

2B

22

31

3 1A 3B

offset
E9A

...

005

6C 21

4 17 13

4E

5 8E A4

2F

19

71 9A

7F

12

16

2C

0002F

quadro

offset

MMU

...
...

...
...

pg2

7
-

1 14

6 10

006

0 5C

0000000110 0000000101 111010011010

pg 1

0180 5E9A (endereo lgico)

PTBR
Tabela de pginas
(em memria RAM)

0002 FE9A (endereo fsico)

Memria RAM

ncleo
rea no-paginada

47

Figura 5.14: Tabela de pgina multi-nvel.

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 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
132

c Carlos Maziero

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).

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 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 resultar nos mesmos quadros de memria fsica. Por isso, consultas
recentes tabela de pginas so armazenadas em um cache dentro da prpria MMU,
3

Esse fenmeno conhecido como localidade de referncias e ser detalhado na Seo 5.4.

133

c Carlos Maziero

5: Alocao paginada

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.
processo P3

TCB(P3)

0000000110 0000000101 111010011010

pg 1
Tabela de pginas
(em memria RAM)
2

0180 5E9A (endereo lgico)

PTBR

registrador atualizado
na troca de contexto
que ativou P3

PTBR

pg2

offset

006

E9A

...

01805

TLB
p1,p2

0 5C

2B

1 14

22

31

3 1A 3B

4E

5 8E A4

2F

19

71 9A

7F

12

16

2C

0002F
0002F

quadro

offset

MMU

...
...

...
...

update

6C 21

4 17 13

6 10

005

0002 FE9A (endereo fsico)

Memria RAM

ncleo
rea no-paginada

47

Figura 5.16: Uso da TLB.

134

c Carlos Maziero

5: Alocao paginada

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

// em caso de acerto
// em caso de erro, consultar as tabelas
// acesso ao quadro desejado

tmdio = 58, 475ns

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 considerando-se 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.
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.
135

c Carlos Maziero

5.3.5

5: Alocao segmentada paginada

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.
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);
136

c Carlos Maziero

5: Localidade de referncias

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
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.

137

c Carlos Maziero

i

5: Localidade de referncias
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.

Figura 5.18: Localidade de referncias nas duas execues.

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 direita detalha os acessos da parte inferior,
que corresponde s reas de cdigo, dados e heap do processo.
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.

138

c Carlos Maziero

5: Fragmentao

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;
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.
139

c Carlos Maziero

5: Fragmentao

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.
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.

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 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.
140

c Carlos Maziero

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.

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 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

P3

P1

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 processos. 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
141

c Carlos Maziero

5: Fragmentao

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

Soluo 2:
aloca 5.000 Kbytes

4.900 Kbytes

5.000 Kbytes

fragmentao externa

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.
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.

142

c Carlos Maziero

5.6

5: Compartilhamento de memria

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. Normalmente, a rea de cdigo no
precisa ter seu contedo modificado durante a execuo, portanto geralmente essa rea
protegida contra escritas (read-only). 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.
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.
143

c Carlos Maziero

5: Compartilhamento de memria

S4

S4

S3

S2

S4
S3

S2

S1
S3

S2

P2
S1

S1

P1

P3

Memria RAM

ncleo

P1.S2

P1.S3

P2.S4

P*.S1

P3.S3

P3.S4

P1.S3

P3.S2

P2.S3

max

P1.S4

Figura 5.25: Compartilhamento de segmentos.

processo P1

processo P2

Memria RAM

ncleo
rea no-paginada

Figura 5.26: Compartilhamento de pginas.

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 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:

144

c Carlos Maziero

5: Memria virtual

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 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
145

c Carlos Maziero

5: Mecanismo bsico

de informaes multimdia (imagens, 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.
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.
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
5

Estes valores so apenas indicativos, variando de acordo com o fabricante e a tecnologia envolvida.

146

c Carlos Maziero

5: Mecanismo bsico
processo P2

processo P1
0

rea de troca
Memria RAM

ncleo
rea no-paginada

Figura 5.27: Memria virtual paginada.

(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.
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

147

c Carlos Maziero

5: Mecanismo bsico

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.

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.

148

c Carlos Maziero

5.7.2

5: Eficincia de uso

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 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).
o comportamento dos processos em relao ao uso da memria: processos que
agrupem seus acessos a poucas pginas em cada momento, respeitando a localidade
149

c Carlos Maziero

5: Algoritmos de substituio de pginas

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.
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
150

c Carlos Maziero

5: Algoritmos de substituio de pginas

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 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.
Apesar de ter uma implementao simples, na prtica este algoritmo no oferece
bons resultados. Seu principal defeito considerar somente a 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

151

c Carlos Maziero

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

5: Algoritmos de substituio de pginas

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 memria)
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.

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 na Seo anterior,
considerando uma memria fsica com 3 quadros, 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.
152

c Carlos Maziero

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

5: Algoritmos de substituio de pginas

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
p0 carregada no quadro vazio q0
p2 carregada em q1
p1 carregada em q2
p3 substitui p0 (no ser mais acessada)
p5 substitui p2 (no ser mais acessada)
p4 substitui p1 (s ser acessada em t = 17)
p6 substitui p5 (s ser acessada em t = 14)
p3 est na memria
p7 substitui p6 (no ser mais acessada)
p4 est na memria
p7 est na memria
p3 est na memria
p3 est na memria
p5 substitui p4 (s ser acessada em t = 23)
p5 est na memria
p3 est na memria
p1 substitui p5 (no ser mais acessada)
p1 est na memria
p1 est na memria
p7 est na memria
p1 est na memria
p3 est na memria
p4 substitui p3 (no ser mais acessada)
p1 est na memria

Tabela 5.3: Aplicao do algoritmo de substituio timo.

A aplicao do algoritmo LRU cadeia de referncias apresentada na Seo anterior,
considerando uma memria fsica com 3 quadros, 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, 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

153

c Carlos Maziero

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

5: Algoritmos de substituio de pginas

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
p0 carregada no quadro vazio q0
p2 carregada em q1
p1 carregada em q2
p3 substitui p0 (h mais tempo sem acessos)
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.

exigiria 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
154

c Carlos Maziero

5: Algoritmos de substituio de pginas

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.

bits de referncia para zero e acabar por escolher a primeira pgina da fila, como faria
o algoritmo FIFO.
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 ajustandoos 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

3
1

12

2
11
26

prxima
vtima

42

18

14

33

11
bits de
referncia

17
0

26

1
1

14

33

Figura 5.30: Algoritmo da segunda chance (ou do relgio).

155

18

nmeros
de pgina

nova
pgina

23

2
0

12

ajustados
para zero

21

17

c Carlos Maziero

5: Algoritmos de substituio de pginas

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.
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
156

c Carlos Maziero

5: Conjunto de trabalho

tm um peso maior que acessos mais antigos, e o contador nunca ultrapassa seu valor
mximo.
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 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
157

c Carlos Maziero

5: Conjunto de trabalho
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.

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.

substituio de pginas: s substituir pginas que no pertenam ao conjunto de

158

c Carlos Maziero

5: A anomalia de Belady

trabalho de nenhum processo 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:
(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,
159

c Carlos Maziero

5: Thrashing

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 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 referncia, esse conjunto pequeno
e varia lentamente. Caso a localidade de referncia seja ruim, o conjunto de trabalho
160

c Carlos Maziero

5: Thrashing

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.
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.

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
161

c Carlos Maziero

5: Thrashing

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 quantum de processador
para cada processo ativo, ou simplesmente abortar os processos com maior alocao de
memria ou com maior atividade de paginao.

162

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.

6.1.1

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
163

c Carlos Maziero

6: Atributos

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.

6.1.2

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;
164

c Carlos Maziero

6: Operaes

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 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;
1

Alguns sistemas operacionais, como o TOPS-20 e o OpenVMS, possuem sistemas de arquivos com
suporte automtico a mltiplas verses do mesmo arquivo.

165

c Carlos Maziero

6: Formatos

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;
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 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.
Nos sistemas operacionais cujo ncleo no suporta arquivos estruturados como registros, essa funcionalidade pode ser facilmente obtida atravs de bibliotecas especficas
166

c Carlos Maziero

6: Formatos

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.

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):
int main()
{
printf("Hello, world\n");
exit(0);
}

1
2
3
4
5

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

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.

167

c Carlos Maziero

6: Formatos

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
8

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]:
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.
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).
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
168

c Carlos Maziero

6: Formatos
ELF header

Sections

Program
header table

Segments

Section
header table

Figura 6.3: Estrutura interna de um arquivo executvel em formato ELF [Levine, 2000].
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
169

c Carlos Maziero

6: Arquivos especiais

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 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 Values)
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:
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).

170

c Carlos Maziero

6: Uso de arquivos

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 dos conceitos aqui expostos
so igualmente aplicveis aos arquivos no-convencionais descritos nesta seo.

6.2

Uso de arquivos

Arquivos so usados por processos para ler e escrever dados de forma no-voltil.
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
171

c Carlos Maziero

6: Abertura de um arquivo

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;
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.
172

c Carlos Maziero

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.
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
173

c Carlos Maziero

6: Controle de acesso

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.

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:

174

c Carlos Maziero

6: Controle de acesso

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)

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
175

c Carlos Maziero

6: Compartilhamento de arquivos

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 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 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

176

c Carlos Maziero

6: Compartilhamento de arquivos

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
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.
177

c Carlos Maziero

6: Exemplo de interface

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 .

71
open

p4

close
read

39

close
read

23

23

close
read

23

39

write

71

open

p2

write

open

p3

p1

12

read

write

39

open

close
read

write

read

t
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

178

c Carlos Maziero

6: Exemplo de interface

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:
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).

179

c Carlos Maziero

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 (CD-ROM, 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).
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

180

c Carlos Maziero

6: Diretrios

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.
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
181

c Carlos Maziero

6: Diretrios

sistema Linux, cuja estrutura definida nas normas Filesystem Hierarchy Standard
[Russell et al., 2004].

bin
etc
home
lib
proc
root
tmp
usr
var

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.

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.
182

c Carlos Maziero

6: Caminhos de acesso

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.
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

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

D
D
D
A
A

X11
.
D
..
D
libX.a A

0101011
110000110
001101011
101110100
110000010
100011111
010110100

Figura 6.9: Implementao de uma estrutura de 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 ento necessrio conhecer sua
localizao completa, ao invs de somente seu nome. A posio de um arquivo dentro
183

c Carlos Maziero

6: Caminhos de acesso

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, 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

184

c Carlos Maziero

6: Caminhos de acesso

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 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.
3

Para simplificar, foram omitidas as verificaes de existncia de entradas, de permisses de acesso e

os tratamentos de erro.

185

c Carlos Maziero

6.3.3

6: Atalhos

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 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.
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 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.
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.

186

c Carlos Maziero

VBR

/
.
..
bin
etc
home
lib
usr

6: Montagem de volumes

D
D
D
D
D
L
D

bin
.
..
cp
ls
rm
shell

0101011
110000110
001101011
101110100
110000010
100011111
010110100

D
D
A
A
A
L

link to:
/usr/bin/sh

link to:
/usr/lib

usr
.
..
bin
lib

D
D
D
D

Volume (disco ou partio)

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.

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 CDROMs, 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
187

c Carlos Maziero

6: Sistemas de arquivos

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 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 informaes de
controle necessrias para localizar e manter seu contedo no disco.
188

c Carlos Maziero

6: Arquitetura geral

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.
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.

189

c Carlos Maziero

6: Blocos fsicos e lgicos

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).
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 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
190

c Carlos Maziero

6: Alocao fsica de arquivos

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 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

191

c Carlos Maziero

6: Alocao fsica de arquivos

foto1.jpg
0

relat.pdf

blocos do dispositivo

instruc.txt
6

sinfonia.mp3
0

7 ...

Figura 6.13: O problema da alocao de arquivos.

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 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, considera-se 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, 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.

192

c Carlos Maziero

6: Alocao fsica de arquivos

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

04
05

08
09

blocos lgicos com 4096 bytes

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.

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): 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

193

c Carlos Maziero

6: Alocao fsica de arquivos

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 )
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 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.
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 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
194

c Carlos Maziero

6: Alocao fsica de arquivos

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

blocos lgicos com 4096 bytes

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.

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
195

c Carlos Maziero

6: Alocao fsica de arquivos

Algoritmo 2 Localizar a posio do i-simo byte do arquivo no disco

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 )
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 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
a formatao do sistema de arquivos, o que limita o nmero mximo de arquivos ou
diretrios que podem ser criados na partio.

196

c Carlos Maziero

6: Alocao fsica de arquivos

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

blocos lgicos com 4096 bytes

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.

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 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:

197

c Carlos Maziero

6: Alocao fsica de arquivos

Tabela de i-nodes

Tabela de diretrio
nome

i-node

foto1.jpg

relat.pdf

instruc.txt

10

sinfonia.mp3

31

10417
...

i-node 5

blocos lgicos com 4096 bytes

meta-dados
13
16
17

bloco em uso

19

bloco livre

ponteiros
de dados

22
10
12
null
null
null

Figura 6.17: Estratgia de alocao indexada simples.

max =
+
+
+
=
max

4096 12
4096 1024
4096 1024 1024
4096 1024 1024 1024
4.402.345.721.856 bytes
4T bytes

198

(ponteiros diretos)
(ponteiro indireto)
(ponteiro indireto duplo)
(ponteiro indireto triplo)

c Carlos Maziero

6: Alocao fsica de arquivos

i-node
12

meta-dados
do arquivo

13

blocos de dados

0
1035

1
2

1036

12 ponteiros
diretos

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, 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,
199

c Carlos Maziero

6: Alocao fsica de arquivos

Algoritmo 3 Localizar a posio do i-simo byte do arquivo no disco

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.
38.
39.
40.
41.

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
// ler bloco de ponteiros de nvel 1
block1 = read_block (ptr[13])
// ler bloco de ponteiros de nvel 2
block2 = read_block (block1 [baux 1024])
// encontrar o endereo do bloco bi
bi = block2 [baux mod 1024]
else // ponteiro indireto triplo
baux = baux (1024 1024)
// ler bloco de ponteiros de nvel 1
block1 = read_block (ptr[14])
// ler bloco de ponteiros de nvel 2
block2 = read_block (block1 [baux (1024 1024)])
// ler bloco de ponteiros de nvel 3
block3 = read_block (block2 [(baux 1024) mod 1024])
// encontrar o endereo do bloco bi
bi = block3 [baux mod 1024]
end if
end if
end if
return (bi , oi )

200

c Carlos Maziero

6: Alocao fsica de arquivos

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.

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.
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

201

c Carlos Maziero

6: Alocao fsica de arquivos

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

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
202

c Carlos Maziero

6: O sistema de arquivos virtual

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.
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.

203

c Carlos Maziero

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

204

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, DVD-ROMs 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 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.
205

c Carlos Maziero

7: Introduo

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 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. 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.

206

c Carlos Maziero

7.2

7: Dispositivos de entrada/sada

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 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
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.

207

c Carlos Maziero

7: Barramentos

CPU
dados

controlador de barramento
01001010

01001010

dados

01101010

buer

01101010

buer
sinal digital

conversor
digitalanalgico

conversor
analgicodigital
sinal analgico

sensor

amplicador

atuador

amplicador

controlador de dispositivo

Figura 7.2: Estrutura bsica da entrada e sada de udio.

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.
O controle dos barramentos em um sistema desktop 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).
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.

208

c Carlos Maziero

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
14 KB/s
Interface infravermelho (IrDA-SIR)
125 KB/s
Interface paralela padro
Interface de udio digital S/PDIF
384 KB/s
11.6 MB/s
Interface de rede Fast Ethernet
Chave ou disco USB 2.0
60 MB/s
116 MB/s
Interface de rede Gigabit Ethernet
Disco rgido SATA 2
300 MB/s
4.2 GB/s
Interface grfica high-end

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 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 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 entrada/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;

209

c Carlos Maziero

7: Interface de acesso

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.

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.
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 mais antigas. 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;
210

c Carlos Maziero

7: Interface de acesso

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.

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);
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.
211

c Carlos Maziero

7: Endereamento

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.

aguarda um
novo dado

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.enable_IRQ?

ack

gera IRQ

0
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
212

c Carlos Maziero

7: Endereamento

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 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
barramento IDE primrio
0170h a 0177h
barramento IDE secundrio
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 037Fh
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].
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
213

c Carlos Maziero

7: Interrupes

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.
Dispositivo
Interrupo
teclado
1
mouse PS/2
12
barramento IDE primrio
14
barramento IDE secundrio
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.
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:
1. O processador est executando um programa qualquer;
2. O usurio pressiona uma tecla no teclado;

214

c Carlos Maziero

7: Interrupes
1: excuo
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

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
215

c Carlos Maziero

7: Interrupes

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 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.
216

c Carlos Maziero

7: Interrupes

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. 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

USB
controller

IRQ

registers

touchscreen
controller

IRQ

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.

217

c Carlos Maziero

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 cdigo de tratamento de cada interrupo
tambm em dois nveis: o bottom-half, 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,

218

c Carlos Maziero

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.

fitas magnticas e outros dispositivos de armazenamento so exemplos tpicos desta
categoria.
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.

219

c Carlos Maziero

sentido dos fluxos:
granularidade

exemplos:

acesso

exemplos:
persistncia:

exemplos:

7: Classes de dispositivos
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 dis- positivo 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)
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)
220

c Carlos Maziero

7.3.2

7: Estratgias de interao

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.
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 :

221

c Carlos Maziero

1
2
3
4

// portas da
#define P0
#define P1
#define P2

7: Estratgias de interao

interface paralela LPT1 (endereo inicial em 0378h)

0x0378
# porta de dados
0x0379
# porta de status
0x037A
# porta de controle

5
6
7
8
9

// 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)

10
11
12

// buffer de bytes a enviar

unsigned char buffer[BUFSIZE] ;

13
14
15
16
17
18
19

polling_output ()
{
for (i = 0 ; i < BUFSIZE ; i++)
{
// espera o controlador ficar livre (bit BUSY deve ser zero).
while (in (P1) & BUSY) ;

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

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.
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
3
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.

222

c Carlos Maziero

7: Estratgias de interao

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.

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 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
223

c Carlos Maziero

7: Estratgias de interao

a rotina de tratamento de interrupo (subentende-se as constantes e variveis definidas

na listagem anterior):
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

// escreve o byte a enviar na porta P0.

out (P0, buffer[i]) ;

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
{
// escreve o byte a enviar na porta P0.
out (P0, buffer[i]) ;

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 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
224

c Carlos Maziero

7: Estratgias de interao

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.
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).

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

225

c Carlos Maziero

7: Estratgias de interao

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).
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 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

226

c Carlos Maziero

7: Estratgias de interao

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;
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).
A dinmica dessas operaes ilustrada de forma simplificada na Figura 7.11. Uma
vez efetuado o passo 1, o processador fica livre para outras 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.
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].

227

c Carlos Maziero

7: Estratgias de interao

processador

memria RAM

5: interrupt request

barramento
1: DMA request

2: transfer request

3: data transfer

controlador
de disco rgido

controlador
de DMA

hardware do dispositivo

Figura 7.11: Funcionamento do acesso direto memria.

1
2
3
4
5
6

// 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) ;

// suspende o processo solicitante, liberando o processador.

schedule () ;

8
9
10

11
12
13
14
15
16

// rotina de tratamento da interrupo do controlador de DMA

interrupt_handle ()
{
// informa o controlador de interrupes que a IRQ foi tratada.
acknowledge_irq () ;

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

228

c Carlos Maziero

7: Discos rgidos

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.
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).
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.

229

c Carlos Maziero

7.4.1

7: Estrutura fsica

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. 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:
230

c Carlos Maziero

7: Escalonamento de acessos

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.
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,
considera-se 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
231

c Carlos Maziero

7: Escalonamento de acessos

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.

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.

SSTF (Shortest Seek Time First Menor Tempo de Busca Primeiro): esta estratgia de
escalonamento de disco consiste em sempre atender o 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.
232

c Carlos Maziero

7: Escalonamento de acessos

255

914

659
588

Percurso total = 1320 blocos

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 parabrisas 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].

255
135

914

659

524
453

71
90

161

117

278

Percurso total = 1272 blocos

57

335

112

200

bloco

53

447

500

400

600

800

Figura 7.15: Escalonamento de disco com o algoritmo do elevador.

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
233

c Carlos Maziero

7: Escalonamento de acessos

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.

524

135

659

255

914

843

Percurso total = 1662 blocos

71
90

161

117

278

57

335

112

200

bloco

53

447

500

400

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 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.
234

c Carlos Maziero

7: Caching de blocos

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; 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.
235

c Carlos Maziero

7: Sistemas RAID
read-behind
t1

read-ahead
t2

cache

t2

cache

cache

cache

t1

dispositivo

dispositivo

write-through
t1

write-back
t1

t2

cache

cache

cache

cache
t2

dispositivo

dispositivo

Figura 7.17: Estratgias de caching de blocos (t1 e t2 indicam dois instantes de tempo).
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, 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.
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).

236

c Carlos Maziero

7: Sistemas RAID

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 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.
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].
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.
237

c Carlos Maziero

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

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)

disco fsico 1 (dados)

disco fsico 2 (dados)

Figura 7.18: RAID nvel 0 (striping).

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

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

disco fsico 0 (dados)

disco fsico 1 (dados)

disco fsico 2 (dados)

Figura 7.19: RAID nvel 0 (linear).

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, 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.
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

238

c Carlos Maziero

bloco 0

7: Sistemas RAID

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

disco fsico 0 (dados)

disco fsico 1 (dados)

Figura 7.20: RAID nvel 1 (mirroring).

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 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 0 (dados)

disco fsico 1 (dados)

disco fsico 2 (dados)

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.
RAID 5 : assim como a anterior, esta abordagem tambm armazena informaes de
paridade para tolerar falhas em discos. Todavia, essas informaes no ficam
concentradas em um nico disco fsico, mas so distribudas uniformemente entre
239

c Carlos Maziero

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

bloco 14

bloco 15

bloco 16

bloco 17

bloco 18

bloco 19

bloco 20

bloco 21

bloco 22

bloco 23

Controladora RAID

disco lgico

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 0 (dados)

disco fsico 1 (dados)

disco fsico 2 (dados)

disco fsico 3 (paridade)

Figura 7.22: RAID nvel 4.

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

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 18

bloco 19

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 26

bloco 27

bloco 24

bloco 25

par (24,28,32) par (25,29,33)

bloco 28

bloco 29

bloco 32

bloco 33

bloco 28

bloco 29

bloco 26

bloco 27

par (26,30,34) par (27,31,35)

bloco 30

bloco 31

bloco 34

bloco 35

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

Figura 7.23: RAID nvel 5.

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
240

c Carlos Maziero

7: Interfaces de rede

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].

7.5

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, ...

241

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
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
242

c Carlos Maziero

8: Conceitos bsicos

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;
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
243

c Carlos Maziero

8: Propriedades e princpios de segurana

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.
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.
244

c Carlos Maziero

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 no-observao 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.
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:

245

c Carlos Maziero

8: Vulnerabilidades

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.
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:
1
2

#include <stdio.h>
#include <stdlib.h>

3
4

int i, j, buffer[20], k; // declara buffer[0] a buffer[19]

5
6
7
8

int main()
{
i = j = k = 0 ;

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:

246

c Carlos Maziero

1
2
3
4
5

8: Ataques

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 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;
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.

247

c Carlos Maziero

8: Ataques

Fabricao : consiste em produzir informaes falsas ou introduzir mdulos ou componentes maliciosos no sistema; um ataque autenticidade.
interceptao

interrupo

fonte

fonte

destino
atacante

atacante

fabricao

modificao

fonte

destino

fonte

destino

destino
atacante

atacante

Figura 8.1: Tipos bsicos de ataques (inspirado em [Pfleeger and Pfleeger, 2006]).
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 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
248

c Carlos Maziero

8: Malwares

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.

8.2.5

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
2

De forma anloga, um vrus biolgico precisa de uma clula hospedeira, pois usa o material celular
como suporte para sua existncia e replicao.

249

c Carlos Maziero

8: Malwares

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].
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.
250

c Carlos Maziero

8: Infraestrutura de segurana

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.

8.2.6

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.

251

c Carlos Maziero

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

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

arquivos

outros
sujeitos
ou
sistemas

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

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.
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
252

c Carlos Maziero

8: Fundamentos de criptografia

(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:
mensagem aberta:
mensagem cifrada com k = 1:
mensagem cifrada com k = 2:
mensagem cifrada com k = 3:

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
253

c Carlos Maziero

8: Criptografia simtrica e assimtrica

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:
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)

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

Figura 8.3: Criptografia simtrica.

254

decifrar

chave secreta

c Carlos Maziero

8: Criptografia simtrica e assimtrica

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:
{ { 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

Ille nihil dubitat qui

nullam scientiam habet
(Nada duvida quem nada sabe)

Ille nihil dubitat qui

nullam scientiam habet
(Nada duvida quem nada sabe)

texto cifrado

cifrar

6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
ca974d8cc5d986b6c48fba534eab
2eb4d39273910b72c869c54521c1
c5df85cb3a37d2aaa6f19b560ead
a9eb92c5e8e95

chave pblica

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 em um chaveiro pblico (que
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.

255

c Carlos Maziero

8: Resumo criptogrfico

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
Ille nihil dubitat qui
nullam scientiam habet
(Nada duvida quem nada sabe)

texto aberto

3: cifrar

6d034072696a6e6461656c2d31
3238002000636263006d63727970
742d7368613100157290d14234f6
fce39f0908827c54cdf58890687f
7368613100ff56dfb2015aae6f33
86a6acbd051a33562699a2d97623
ca974d8cc5d986b6c48fba534eab
2eb4d39273910b72c869c54521c1
c5df85cb3a37d2aaa6f19b560ead
a9eb92c5e8e95

4: envio do texto cifrado

Beto
Ille nihil dubitat qui
nullam scientiam habet
(Nada duvida quem nada sabe)

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 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
256

c Carlos Maziero

8: Assinatura digital

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 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,
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.

257

c Carlos Maziero

8: Certificado de chave pblica

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
kp(u)
0
00
forem iguais (r = r ), 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:
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
258

c Carlos Maziero

8: Certificado de chave pblica

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

r'=r'' ?

r'

sim

assinatura
vlida

s'
6fce39f0908827
ca54cdf5889068
7f734aef674d2a

r''

cifrar
Alice

decifrar

Chaveiro pblico

chave
privada
chave
pblica

6fce39f0908827
ca54cdf5889068
7f734aef674d2a

documento
assinado
por Alice

resumo

chave pblica de Alice

Alice

Beto Carol Davi

Figura 8.6: Assinatura e verificao de uma assinatura digital.

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;
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.

259

c Carlos Maziero

8: Autenticao

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

dfh kds
ks

d sk

f dsjh
dfh kds
ks

lsd jsfhd

lsd jsfhd

d sk

f dsjh

d sk

f dsjh

dfh kds
ks

d s lj k l s
d

lk

29-05-2009
d sk

dfh kds
ks

lsd jsfhd

d s lj k l s

29-05-2009

lsd jsfhd

29-05-2009

lk

d s lj k l s
d

lk

lsd jsfhd

d sk

f dsjh

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.

8.4

Autenticao

O objetivo da autenticao consiste em identificar as diversas entidades de um

sistema computacional. Atravs da autenticao, o usurio interessado em acessar o

260

c Carlos Maziero

8: Usurios e grupos

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 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.

261

c Carlos Maziero

8.4.2

8: Tcnicas de autenticao

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.
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.

262

c Carlos Maziero

8: Senhas descartveis

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 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 ) com o valor de sn previamente informado: se
forem iguais, o cliente est autenticado e ambos podem descartar sn . O servidor
263

c Carlos Maziero

8: Tcnicas biomtricas

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 pr-definida 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 identificlo 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;
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.
264

c Carlos Maziero

8: Desafio-resposta

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 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.

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.

265

c Carlos Maziero

dados
biomtricos

8: Desafio-resposta

dados
biomtricos

sensor

sistema biomtrico
extrator de
caractersticas

coleta/registro

caractersticas
relevantes

humanos
senha
carto
etc.

autenticador

identidade

usurios
cadastrados

comparador

base de
dados

resultado (identificao ou autenticao)

Figura 8.10: Um sistema biomtrico tpico.

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 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.

266

c Carlos Maziero

8: Certificados de autenticao

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
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
267

c Carlos Maziero

8: Kerberos

da rede. Os tickets so cifrados usando criptografia simtrica DES e tm validade

limitada, para aumentar sua segurana.
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:
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
268

c Carlos Maziero

8: Kerberos

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

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 ]

269

c Carlos Maziero

8: Infra-estruturas de autenticao

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.
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 infraestruturas 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;
270

c Carlos Maziero

8: Controle de acesso

SSPI (Security Support Provider Interface): variante proprietria da GSSAPI, especfica

para plataformas Windows.

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 objetos
podem ser organizados em grupos e hierarquias, para facilitar a gerncia da segurana.

271

c Carlos Maziero

8.5.1

8: Polticas, modelos e mecanismos de controle de acesso

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].
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

272

c Carlos Maziero

8: Polticas discricionrias

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.

8.5.2

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 .
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].

273

c Carlos Maziero

8: Polticas discricionrias

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

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:
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 , socket1 } 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.
274

c Carlos Maziero

8: Polticas discricionrias

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 no-vazias 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:
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) }
275

c Carlos Maziero

8: Polticas discricionrias

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

276

c Carlos Maziero

8: Polticas discricionrias

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),
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
277

c Carlos Maziero

8: Polticas obrigatrias

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):
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 multi-nvel (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.

278

c Carlos Maziero

8: Polticas obrigatrias

Modelo de Bell-LaPadula
Um modelo de controle de acesso que permite formalizar polticas multi-nvel 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), 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, preservandoos 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 seu, para no correr o
risco de ler informao duvidosa. Por exemplo, um sujeito com integridade alta (A)
279

c Carlos Maziero

8: Polticas baseadas em domnios e tipos

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].

8.5.4

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
280

c Carlos Maziero

8: Polticas baseadas em domnios e tipos

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

/* type definitions
type unix_t,
/*
specs_t,
/*
budget_t,
/*
rates_t;
/*

*/
normal UNIX files, programs, etc. */
engineering specifications */
budget projections */
labor rates */

6
7

#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;

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, [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
281

c Carlos Maziero

8: Polticas baseadas em papis

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.

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.
282

c Carlos Maziero

8: Mecanismos de controle de acesso

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.

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.

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 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).

283

c Carlos Maziero

8: Mecanismos de controle de acesso

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 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
284

c Carlos Maziero

8: Mecanismos de controle de acesso

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.

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.
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 apresentlo 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
285

c Carlos Maziero

8: Mecanismos de controle de acesso

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.

do arquivo. Esse padro parcialmente implementado em vrios sistemas operacionais,
como o Linux e o FreeBSD. No Linux, os comandos getfacl e setfacl permitem
manipular essas ACLs, como mostra o exemplo a seguir:

286

c Carlos Maziero

1
2

8: Mecanismos de controle de acesso

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 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.

287

c Carlos Maziero

8: Mecanismos de controle de acesso

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.
usurio

recurso

sujeito
logon

Local
Security
Authority
Subsystem

processo
ou
thread

solicitao
de acesso

Security
Reference
Monitor

acesso
autorizado

AT
eventos

registros
de
auditoria

Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi

SD
eventos

access
token
Token ID
Owner SID
Group1 SID
Group2 SID
...
Flags
Privileges
...

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
288

c Carlos Maziero

8: Mecanismos de controle de acesso

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 multi-polticas, 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 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 microncleo 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.
289

c Carlos Maziero

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, 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

290

c Carlos Maziero

8: Mudana de privilgios

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 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.
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 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
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.

291

c Carlos Maziero

processo pai

8: Mudana de privilgios
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

flag setuid habilitado

Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi

flag setgid habilitado

Illenihild
ubitatquin
ullamscientiam
habet(Nadaduvi
daquemnadasabe
)Illenihildubi
tatquinullamsc
ientiamhabet(N
adaduvidaquemn
adasabe)Illeni
hildubitatquin
ullamscientiam
habet(Nadaduvi

Figura 8.19: Funcionamento dos flags setuid e setgid do UNIX.

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)
292

c Carlos Maziero

8: Auditoria

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 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 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,
8

A anlise de violaes j ocorridas comumente conhecida como anlise post-mortem.

293

c Carlos Maziero

8: Coleta de dados

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:
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

sudo: e89602174 : user NOT in sudoers ; TTY=pts/1 ; USER=root ; COMMAND=/bin/su

userhelper[20480]: running /sbin/halt with user_u:system_r:hotplug_t context
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 context
gdm[12199]: pam_unix(gdm:session): session opened for user rafael3 by (uid=0)
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 (uid=0)
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
9

Processo que executa em segundo plano, sem estar associado a uma interface com o usurio, como
um terminal ou janela.

294

c Carlos Maziero

8: Coleta de dados

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.
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.

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 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
295

c Carlos Maziero

8: Anlise de dados

podem vasculhar o sistema de arquivos em busca de arquivos com contedo malicioso,

ou varrer as portas de rede para procurar servios suspeitos.

8.6.2

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 anti-vrus
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.
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
296

c Carlos Maziero

8: Auditoria preventiva

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 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
297

c Carlos Maziero

8: Auditoria preventiva

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.

298

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.

9.1.1

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
299

c Carlos Maziero

9: Interfaces de sistema

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.

9.1.2

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
300

c Carlos Maziero

9: Compatibilidade entre interfaces

(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;
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

chamadas de biblioteca
chamadas de sistema

bibliotecas

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
301

c Carlos Maziero

9: Compatibilidade entre interfaces

Interface). 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]:
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.

302

c Carlos Maziero

9: Virtualizao de interfaces

Aplics Solaris

Aplics Windows

Aplics Linux

Solaris

Windows

Linux

Sparc

x86

Aplics Windows
Windows

x86

Aplics Windows

Problemas!
Linux

Sparc

x86

Figura 9.3: Problemas de compatibilidade entre interfaces [Smith and Nair, 2004].
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.

9.1.4

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
303

c Carlos Maziero

9: Virtualizao de interfaces

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).
sistema
convidado

monitor
sistema
hospedeiro

Aplics Windows

Aplics Windows

Windows

Windows

camada de
virtualizao

Sparc

x86

Mquina
Virtual

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

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 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.

304

c Carlos Maziero

9: Virtualizao versus abstrao

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.
Aplicaes
SO

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 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.
305

c Carlos Maziero

9: Virtualizao versus abstrao

aplicao

open
write
close
read

abstrao
de arquivo

API do sist. arquivos

diretrios,
permisses

Sist. arquivos lgico

Alocao de arquivos

estratgias de
alocao de arquivos

Sist. arquivos bsico

buering, caching,
escalonamento de disco
Operaes de E/S
tratamento de interrupes

Controle de E/S

dispositivos fsicos
e controladores

Figura 9.6: Nveis de abstrao em um sub-sistema de disco.

dispositivos
virtuais

i386

camada de virtualizao

disco''

camada de virtualizao

dispositivos
reais

sparc

disco'

disco real

Figura 9.7: Virtualizao de recursos do hardware.

aplicaes

SO convid

SO convid

arquivos
discos
virtuais
Sist Operacional

Hipervisor

disco

disco real

Figura 9.8: Abstrao versus virtualizao de um disco rgido.

306

c Carlos Maziero

9.2

9: A construo de mquinas virtuais

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.

9.2.1

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.
307

c Carlos Maziero

9: Definio formal

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 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:
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.
308

c Carlos Maziero

9: Suporte de hardware

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, interpretla), 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.

9.2.2

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.

309

c Carlos Maziero

9: Suporte de hardware

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.
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 non-root), as instrues sensveis
e as interrupes podem provocar a transio VM exit, devolvendo o processador ao

310

c Carlos Maziero

9: Suporte de hardware

hipervisor em modo root. As instrues 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 - Virtual-Machine 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

ncleo convidado
modo non-root

modo 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 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].
311

c Carlos Maziero

9.2.3

9: Formas de virtualizao

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 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
312

c Carlos Maziero

9: Tipos de mquinas virtuais

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 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
313

c Carlos Maziero

9: Mquinas virtuais de processo

convidados com aplicaes convidadas executando sobre eles. Como exemplos

desta categoria de mquinas virtuais temos os ambientes VMware e VirtualBox.

Aplics Solaris

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 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,
314

c Carlos Maziero

9: Mquinas virtuais de processo

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 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
315

c Carlos Maziero

9: Mquinas virtuais de processo

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).
Aplicao
Windows
Chamadas de
sistema Windows

Wine
Chamadas de
sistema UNIX

Linux
Instrues Intel

PC Intel

Figura 9.12: Funcionamento do emulador Wine.

Entretanto, muitas vezes a interface ISA utilizada pela aplicao no corresponde a
nenhum hardware existente, mas a uma mquina abstrata. 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 Just-in-Time (JIT), na qual blocos de instrues repetidos
frequentemente so traduzidos e mantidos em cache pelo hipervisor, permitem obter
ganhos de desempenho significativos.

316

c Carlos Maziero

9.3.2

9: Mquinas virtuais de sistema operacional

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 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.
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

317

c Carlos Maziero

9: Mquinas virtuais de sistema operacional

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.
/

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").

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
318

c Carlos Maziero

9: Mquinas virtuais de sistema

diretrios visveis aos processos 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 noassociados 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.
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
319

c Carlos Maziero

9: Mquinas virtuais de sistema

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 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
320

c Carlos Maziero

9: Tcnicas de virtualizao
aplics

OS 1

aplics

aplics

aplics

guest OS

OS 2
host OS

hipervisor

hipervisor

hardware

hardware

hipervisor nativo

hipervisor convidado

Figura 9.15: Arquiteturas de mquinas virtuais de sistema.

operacionais previamente instalados, e podem ser 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
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.

321

c Carlos Maziero

9: Virtualizao da interface de sistema

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

cache

hardware

ISA de
alto nvel

ISA de
baixo nvel

Figura 9.16: Hipervisor embutido no hardware.

9.4.2

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.

322

c Carlos Maziero

9: Traduo dinmica

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 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.
323

c Carlos Maziero

9: Paravirtualizao

Esse processo pode ser simplificado caso as instrues de mquina do cdigo

convidado sejam as mesmas do processador real subjacente, o que 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.

aplicaes

aplicaes
Sistema
operacional
modicado

Sistema
operacional
standard

hypercalls
hipervisor

hipervisor

hardware

hardware
hardware

virtualizao
clssica

paravirtualizao

Figura 9.17: Paravirtualizao.

324

c Carlos Maziero

9: Aspectos de desempenho

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 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. 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):

325

c Carlos Maziero

9: Aspectos de desempenho

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].
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.

326

c Carlos Maziero

9: Aplicaes da virtualizao

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.

9.5

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
327

c Carlos Maziero

9: Aplicaes da virtualizao

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.
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. Pode-se 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 um estado salvo anteriormente, em caso de
falhas ou incidentes de segurana.

328

c Carlos Maziero

9: Ambientes de mquinas virtuais

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.

9.6

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
329

c Carlos Maziero

9: FreeBSD Jails

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.
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
330

c Carlos Maziero

9: Xen

(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;
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;
331

c Carlos Maziero

9: Xen

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.
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.

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.

332

c Carlos Maziero

9.6.4

9: User-Mode Linux

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 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 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.
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.

333

c Carlos Maziero

9.6.5

9: QEMU

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;
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 de um programa, o
334

c Carlos Maziero

9: JVM

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.
Cdigo
fonte
Java

.java

aplicao
em
bytecode

compilao

aplicao
em
bytecode

JVM

JVM
carga

Windows
x86

carga

.jar
distribuio

bytecode

distribuio

Figura 9.21: Mquina virtual Java.

335

Solaris
Sparc

c Carlos Maziero

9: JVM

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.

336

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 user-level 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.
[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
http://www.llnl.gov/computing/tutorials/pthreads.

threads

programming.

[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.
337

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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, Carnegie-Mellon 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.
[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. Addison-Wesley
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.
338

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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.
[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.
339

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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). Kernel-scheduled 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,
http://www.wikipedia.org.

W. (2005).

Wikipedia online enciclopedia.

[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).
http://www.gnome.org.

Gnome:

the free software desktop project.

[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.
[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 interreference recency set replacement policy to improve buffer cache performance. In
ACM SIGMETRICS Intl Conference on Measurement and Modeling of Computer Systems,
pages 3142.

340

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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.
[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.

341

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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.
[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.
342

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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.
[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):412
421.
[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.
[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).

343

c Carlos Maziero

9: REFERNCIAS BIBLIOGRFICAS

[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.
[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. Prentice-Hall.

344

c Carlos Maziero

: REFERNCIAS BIBLIOGRFICAS

[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.

[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 re-engineering 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
http://www.virtualbox.org/wiki/VirtualBox_architecture.

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.

345

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 */

9
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

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

346

c Carlos Maziero

35

A: O Task Control Block do Linux

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 sibling,
* older sibling, respectively. (p->father can be replaced with
* p->parent->pid)
*/
struct task_struct *real_parent; /* real parent process (when being debugged) */
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
72
73
74

unsigned long rt_priority;

cputime_t utime, stime;
unsigned long nvcsw, nivcsw; /* context switch counts */
struct timespec start_time;
/* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
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

/* 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

347

c Carlos Maziero

90
91
92
93
94
95

/*

96
97

/*

98
99

/*

100
101

/*

102
103

/*

104
105

/*

106
107
108
109

/*

A: O Task Control Block do Linux

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;

110
111
112

sigset_t blocked, real_blocked;

struct sigpending pending;

113
114
115
116
117
118

unsigned long sas_ss_sp;

size_t sas_ss_size;
int (*notifier)(void *priv);
void *notifier_data;
sigset_t *notifier_mask;

119
120
121
122

void *security;
struct audit_context *audit_context;
seccomp_t seccomp;

123
124
125
126
127
128
129
130
131
132

/* 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(&tasklist_lock); */
spinlock_t proc_lock;
/* context-switch lock */
spinlock_t switch_lock;

133
134
135

/* journalling filesystem info */

void *journal_info;

136
137
138

/* VM state */
struct reclaim_state *reclaim_state;

139
140
141

struct dentry *proc_dentry;

struct backing_dev_info *backing_dev_info;

142
143

struct io_context *io_context;

144

348

c Carlos Maziero

145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170

A: O Task Control Block do Linux

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;
#endif
#ifdef CONFIG_CPUSETS
struct cpuset *cpuset;
nodemask_t mems_allowed;
int cpuset_mems_generation;
#endif
};

349