Apostila Fundamentos de Sistemas Operacionais

Apostila da disciplina de
Fundamentos de Sistemas
Operacionais
Arquitetura de Sistemas Operacionais
2010
Apostila Fundamentos de Sistemas Operacionais
Captulo
0
A
EVOLUO
DOS
SISTEMAS
OPERACIONAIS ...................................................................... 04
0.1
A
Primeira
Gerao
(1945-1955):
Vlvulas
e
Painis
com
Plugs ........................................................ 04
0.2
A
Segunda
Gerao
(1955
1965):
Transistores
e
Sistemas
Batch .................................................... 05
0.3
A
Terceira
Gerao
(1965
1980):
CIs
e
Multiprogramao .............................................................. 08
0.4
A
Quarta
Gerao
(1980-1990):
Computadores
Pessoais .................................................................. 11
0.5
1990/97:
a
Era
Windows ................................................................................................................ 13
Captulo
1
VISO
GERAL ........................................................................................................................ 19
1.1
Introduo .....................................................................................................................................
19
1.2
Funes
bsicas ............................................................................................................................. 19
1.3
Mquina
de
nveis .......................................................................................................................... 20
1.4
Tipos
de
Sistemas
Operacionais ....................................................................................................... 22
1.4.1
SOs
monoprogramveis/monotarefa ................................................................................ 22
1.4.2
SOs
multiprogramveis
/
multitarefa ................................................................................ 23
1.4.2.1
Sistemas
Batch ............................................................................................... 25
1.4.2.2
Sistemas
de
Tempo
compartilhado ................................................................... 25
1.4.2.3
Sistemas
de
Tempo
Real ................................................................................. 26
1.4.3
Sistemas
com
Mltiplos
Processadores
............................................................................. 26
1.4.3.1
Sistemas
fortemente
acoplados ........................................................................ 27
1.4.3.2
Sistemas
fracamente
acoplados ....................................................................... 28
Captulo 2 - CONCEITOS DE HARDWARE E
SOFTWARE ........................................................................... 31
2.1
Introduo ..................................................................................................................................... 31
2.2
Hardware ....................................................................................................................................... 31
2.2.1
Processador ................................................................................................................... 31
2.2.2
Memria ........................................................................................................................ 32
2.2.3 Memria
Cache .............................................................................................................. 32
2.2.4 Memria Principal e
Secundaria ....................................................................................... 32
2.2.5 Dispositivos e
Entrada/Sada ............................................................................................ 33
2.2.6 Barramentos ou
Bus ........................................................................................................ 33
2.2.7
Pipeline .......................................................................................................................... 35
Captulo 3 CONCORRNCIA .................................................................................................................

... 36
3.1
Introduo ..................................................................................................................................... 36
3.2 Interrupo e
Exceo .................................................................................................................... 38
3.3 Operaes de
Entrada/Sada ........................................................................................................... 40
3.4
Buffering ....................................................................................................................................... 42
3.5
Spooling ........................................................................................................................................ 43
3.6
Reentrncia .................................................................................................................................. 43
3.7 Proteo do
Sistema ....................................................................................................................... 44
Captulo 4 - ESTRUTURA DO SISTEMA
OPERACIONAL ............................................................................ 45
4.1
Introduo .................................................................................................................................... 45
4.2 Principais
Funes ......................................................................................................................... 46
4.3 System
Calls ................................................................................................................................. 47
4.4 Modos de
Acesso .......................................................................................................................... 48
4.5 Arquitetura
Monoltica ................................................................................................................... 51
4.6 Arquitetura de
Camadas ................................................................................................................ 52
4.7 Mquina
Virtual ............................................................................................................................ 53
4.8 Arquitetura
Microkernel ................................................................................................................. 55
4.9 Projeto do
Sistema ...................................................................................................................... 57
Captulo 5 - PROCESSO
.............................................................................................................................
58
5.1
Introduo
..................................................................................................................................... 58
5.2 Estrutura do
Processo ................................................................................................................... 58
5.2.1 Contexto de
hardware .................................................................................................... 59
5.2.2 Contexto de
software .................................................................................................... 60
5.2.3 Espao de
endereamento ............................................................................................. 62
5.2.4 Bloco de controle do
processo ........................................................................................ 62
5.3 Estados do
Processo ....................................................................................................................... 63
5.4 Mudanas de Estado de
Processo ....................................................................................................64
5.5 Criao e Eliminao de
Processos .................................................................................................. 66
5.6 Processos Independentes, Subprocessos e
Threads ......................................................................... 68
5.7 Processos Foreground e
Background ............................................................................................... 70
5.8 Processos do Sistema

Operacional .................................................................................................. 71
5.9 Processos CPU-Bound e I/OBound ................................................................................................ 72
5.10
Sinais ....................................................................................................................................... 73
Captulo 6
THREAD .............................................................................................................................
... 75
6.1
Introduo
..................................................................................................................................... 75
6.2 Ambiente
Monothread .................................................................................................................... 75
6.3 Ambiente
Multithread ..................................................................................................................... 77
6.4 Arquitetura e
Implementao ......................................................................................................... 82
6.4.1 Threads em Modo
Usurio ............................................................................................. 82
Kernel ............................................................................................... 84
Hbrido ............................................................................................. 85
6.4.4 Scheduler
Activations ..................................................................................................... 86
6.5 Modelos de
Programao ................................................................................................................ 87
Captulo
7
Sincronizao
e
Comunicao
entre
processos
.................................................................. 88
7.1
Introduo
..................................................................................................................................... 88
7.2
Aplicaes
Concorrentes
............................................................................................................... 88
7.3 Especificao de Concorrncia em
Programas .................................................................................. 89
7.4 Problemas de Compartilhamento de
Recursos ................................................................................... 91
7.5 Excluso
Mtua ............................................................................................................................. 93
7.5.A Starvation
................................................................................................................... 93
7.5.B Sincronizao condicional
.............................................................................................. 94
7.5.1 Solues de Hardware
................................................................................................... 94
7.5.2 Solues de software
...................................................................................................... 95
7.6
Semforos .................................................................................................................................... 95
7.7 Monitores
...................................................................................................................................... 97
7.8 Troca de mensagens
..................................................................................................................... 98
7.9 Deadlock
....................................................................................................................................... 99
7.9.1 Preveno do Deadlock
................................................................................................ 100
7.9.2 Deteco de Deadlock
................................................................................................... 100
7.9.3 Correo do Deadlock
............................................................................................... 100
Captulo 8 - Gerncia do Processador
................................................................................................... 102
8.1 Funes
................................................................................................................................ 102
8.2 Critrios de escalonamento
...................................................................................................... 102
8.3 Escalonamentos No-Preemptivos e Preemptivos
........................................................................ 103
Captulo 9 - Gerncia de Memria / Memria Virtual
.......................................................................... 107
9.1
Introduo
....................................................................................................................... 107
9.2
Funes
........................................................................................................................... 107
9.3
Alocao Contgua Simples
................................................................................................. 108
9.4
Segmentao de Programas
............................................................................................... 109
9.5
Alocao Particionada Esttica
............................................................................................ 110
9.6
Alocao Particionada Dinmica
........................................................................................... 111
9.7
Estratgias de Alocao de Partio
..................................................................................... 112
9.8
Swapping
......................................................................................................................... 113
9.9
Memria Virtual
................................................................................................................ 113
9.10
Algoritmos de substituio de pginas
.................................................................................. 116
Captulo 10 - Gerncia de Sistemas de Arquivos
.................................................................................. 118
10.1
Estrutura
de
..................................................................................................... 118
10.2
Sistemas
de
alocao
de
...................................................................................... 118
10.3
Gerncia
de
espao
................................................................................................... 119
10.4
Proteo
de
............................................................................................................ 120
Diretrios
arquivos
livre
acesso
Bibliografia ........................................................................................................................
..................... 121
Captulo 0
A EVOLUO DOS SISTEMAS OPERACIONAIS
Os sistemas operacionais tm sido historicamente amarrados
arquitetura dos computadores nos quais iriam rodar. Por isso, veremos como
eles evoluiram nas sucessivas geraes de computadores. Esse mapeamento
entre geraes de computadores e geraes de sistemas operacionais
admissivelmente imaturo, mas tem algum sentido.
O primeiro computador digital verdadeiro foi projetado pelo
matemtico ingls Charles Babbage (1792-1871). Embora Babbage tenha
5
dispendido muito de sua vida e de sua fortuna tentando construir sua

"mquina analtica", ele jamais conseguiu por o seu projeto em
funcionamento porque era simplesmente um modelo matemtico e a
tecnologia da poca no era capaz de produzir rodas, engrenagens, dentes e
outras partes mecnicas para a alta preciso que necessitava. Desnecessrio
se dizer que a mquina analtica no teve um sistema operacional.
0.1 - A Primeira Gerao (1945-1955): Vlvulas e Painis com
Plugs
Aps os esforos sem sucesso de Babbage, pouco progresso se
teve na construo de computadores digitais at a Segunda Guerra Mundial.
Em torno de 1940, Howard Aiken em Harvard, John Von Neumann no Instituto
para Estudos Avanados em Princeton, John Presper Eckert e William
Mauchley na Universidade de Pennsylvania e Konrad Zuse na Alemanha,
entre outros, tiveram sucesso na construo de mquinas calculadoras
usando vlvulas. Essas mquinas eram enormes, ocupando salas completas,
com dezenas de milhares de vlvulas, porm eram muito mais lentas do que
os mais simples computadores pessoais de hoje.
Naqueles dias primitivos, um pequeno grupo de pessoas
construiu, programou, operou e deu manuteno a cada mquina. Toda a
programao era feita em linguagem de mquina, sempre se conectando fios
com plugs em painis para controlar as funes bsicas da mquina. As
linguagens de programao no eram conhecidas (nem a linguagem
Assembly). Nem se ouvia falar em sistemas operacionais. O modo usual de
operao consistia no programador elaborar o programa numa folha e ento
ir sala da mquina, inserir os plugs nos painis do computador e gastar as
prximas horas apelando que nenhuma das 20.000 ou mais vlvulas no se
queimasse durante a execuo do programa. Na verdade, todos os problemas
eram inerentemente sobre clculos numricos tais como geraes de tabelas
de senos e cossenos.
Por volta dos anos 50, essa rotina teve uma pequena evoluo
com a introduo de cartes perfurados. Era possvel, a partir de ento, se
escrever programas em cartes e l-los, em vez do uso de plugs em painis;
no mais, o procedimento era o mesmo.
0.2 - A Segunda Gerao (1955 - 1965): Transistores e Sistemas
Batch
A introduo do transistor em meados dos anos 50 mudou o quadro
radicalmente. Os computadores tornaram-se bastante confiveis para que
pudessem ser produzidos e vendidos comercialmente na expectativa de que
eles continuassem a funcionar por bastante tempo para realizar algumas
6
tarefas usuais. A princpio havia uma clara separao entre projetistas,

construtores, operadores, programadores e o pessoal de manuteno.
Essas mquinas eram alocadas em salas especialmente preparadas
com refrigerao e com apoio de operadores profissionais. Apenas grandes
companhias, agncias governamentais, ou universidades, dispunham de
condies para pagar um preo de multimilhes de dlares por essas
mquinas. Para rodar um job (isto , um programa ou um conjunto de
programas), primeiro o programador escrevia o programa no papel (em
FORTRAN ou linguagem Assembly), e ento perfurava-o em cartes. Da, ele
levava o "deck" de cartes sala de recepo e o entregava a um dos
operadores.
Quando o computador encerrava a execuo de um job, um operador
apanhava a sada na impressora, a conduzia de volta sala de recepo
onde o programador poderia colet-lo posteriormente. Ento ele tomava um
dos decks de cartes que tinha sido trazido da sala de recepo e produzia a
sua leitura. Se o compilador FORTRAN era necessrio, o operador tinha que
peg-lo de uma sala de arquivos e produzir a sua leitura. Muito tempo de
computador era desperdiado enquanto os operadores caminhavam pela sala
da mquina para realizarem essas tarefas.
Devido ao alto custo do equipamento, era de se esperar que as pessoas
tentassem reduzir o tempo desperdiado. A soluo geralmente adotada era
o sistema em "batch". A idia original era colecionar uma bandeja completa
de jobs na sala de recepo e ento l-los para uma fita magntica usando
um computador pequeno e relativamente barato, por exemplo o IBM 1401,
que era muito bom na leitura de cartes, na cpia de fitas e na impresso da
sada, porm no era to bom em clculo numrico. Outros computadores,
mquinas mais caras, tais como o IBM 7094, eram usados para a computao
real. Essa situao mostrada na figura 0.1.

U n id a d e
d e F it a
.
E n tra d a
S is te m a
d a F ita
d e F ita s
S a d a
d e F ita
L e ito r a d e
Im p re sso ra
c a rt e s
1401
(a)
7094
(b)
(c)
(f)
1401
(d)
(e)
Figura 0.1 - Um sistema batch antigo.

( a ) Programadores levam cartes ao 1401.
( b ) 1401 l batch de jobs em fita.
( c ) A operadora acopla fita de entrada no 7094.
( d ) O 7094 faz o processamento.
( e ) A operadora acopla fita de sada no 1401.
( f ) O 1401 imprime a sada.
Aps cerca de uma hora coletando-se um lote de jobs, a fita era
rebobinada e levada para a sala da mquina onde era montada numa
unidade de fita. O operador ento carregava um programa especial (o
antecessor do sistema operacional de hoje), que lia o primeiro job da fita e o
executava. A sada era escrita numa segunda fita, em vez de ser impressa.
Aps o fim da execuo de cada job, o sistema operacional automaticamente
lia o prximo job da fita e comeava a execut-lo. Quando todo o "batch" era
feito, o operador removia as fitas de entrada e de sada, substituia a fita de
entrada pelo prximo "batch" e levava a fita de sada para um 1401 produzir
a impresso "off-line" (isto , no conectada ao computador principal).
A estrutura de um job de entrada tpico mostrada na figura 0.2.
Ele comea com um carto $JOB, especificando o tempo mximo de execuo
em minutos, o nmero da conta e o nome do programador. A seguir vinha um
carto $FORTRAN, avisando ao sistema operacional para carregar o
compilador FORTRAN da fita do sistema. Em seguida vinha um programa a ser
compilado, acompanhado de um carto $LOAD, informando ao sistema
operacional para carregar o programa objeto j compilado. (Programas
compilados eram sempre escritos em fitas selecionadas e tinham
8
de ser carregadas explicitamente). A seguir vinha um carto $RUN,

informando ao sistema operacional para executar o programa com os dados
que vinham a seguir. Finalmente o carto $END marcava o fim do job. Esses
cartes de controle foram os precurssores das linguagens de controle de job
(JCL) modernas e de interpretadores de comandos.
Muitos computadores da segunda gerao foram usados
principalmente para clculos cientficos e de engenharia, tais como em
soluo de equaes diferenciais parciais. Eles foram vastamente
programados em FORTRAN e em linguagem Assembly. Sistemas operacionais
tpicos eram o FMS (Sistema Monitor FORTRAN) e IBSYS (Sistema Operacional
da IBM para o 7094).
$END
Dados para o
Programa
$RUN
$LOAD
Programa Fortran
$FORTRAN
$JOB, 10, 429754, TANENBAUM
Figura 0.2 - Estrutura de um tpico job FMS
0.3 - A Terceira Gerao (1965 - 1980): CIs e Multiprogramao

Nos anos 60, muitos fabricantes de computadores tinham duas
linhas de produto distintas e totalmente incompatveis. Por um lado havia os
computadores cientficos, em grande escala, orientado por palavras, tais
como o 7094, que era usado para clculos numricos em cincia e
engenharia. Por outro lado, havia os computadores comerciais, orientados por
caracter, tais como o 1401, que era vastamente usado para classificao em
fita e impresso, por bancos e companhias de seguros.
O desenvolvimento e a manuteno de duas linhas de produto
completamente diferentes era uma proposta cara para os fabricantes. Alm
do mais, os clientes em potencial para aquisio de novos computadores
necessitavam inicialmente de uma mquina pequena, para mais tarde, com o
crescimento, terem uma mquina maior em que pudessem rodar todos os
seus programas mais rapidamente.
A IBM, no intuito de resolver ambos os problemas de uma s
tacada, introduziu o sistema /360. O 360 era uma srie de mquinas
compatveis por software, variando de tamanho a partir do 1401 at o mais
potente 7094. As mquinas diferiam apenas em preo e performance
(capacidade de memria, velocidade do processador, nmero de perifricos
I/O permitidos, e assim por diante). J que todas as mquinas tinham a
mesma arquitetura e o mesmo conjunto de instrues, pelo menos em teoria,
programas escritos para uma mquina poderiam rodar em todas as outras.
Alm disso, o 360 foi projetado para manusear tanto computao comercial
como computao cientfica. Assim, uma nica famlia de mquinas poderia
satisfazer s necessidades de todos os clientes. Em anos subsequentes, a IBM
apresentou os sucessores compatveis com a linha 360, usando uma
tecnologia mais moderna, conhecidos como sries 370, 4300, 3080 e 3090.
O 360 foi a primeira linha de computadores a usar (em pequena
escala) circuitos integrados (CIs), fornecendo uma maior vantagem em
preo/performance sobre as mquinas da segunda gerao, que eram
construidas de transistores individuais. Isso foi um sucesso imediato e a idia
de uma famlia de computadores compatveis foi logo adotada por todos os
outros fabricantes. Os descendentes dessas mquinas ainda hoje esto em
uso em grandes centros de computao.
A maior fora da idia de "uma famlia" foi simultaneamente a
sua maior durabilidade. A inteno era que todo o software, incluindo o
sistema operacional, deveria trabalhar em todos os modelos. Ele tinha de
rodar em sistemas pequenos que muitas vezes j substituia 1401s para
cpias de cartes em fitas e em sistemas muito grandes, que muitas vezes
substituia 7094s para fazer clculos demorados e outras computaes
pesadas. Ele deveria ser bom em sistemas com poucos perifricos e em
sistemas com muitos perifricos. Ele tinha de trabalhar em ambientes
10
comerciais e em ambientes cientficos. Acima de tudo, ele tinha de ser

eficiente em todos esses usos diferentes.
No havia uma maneira atravs da qual a IBM (ou outra

companhia) pudesse solucionar todas essas exigncias conflitantes. O
resultado foi um sistema operacional enorme e extraordinariamente
complexo, provavelmente de dois ou trs ordens de magnitude maior do que
o FMS. Ele consistia de milhares de linhas de linguagem assembly escritas por
centenas de programadores e continha centenas e centenas de depuraes
que necessitavam de contnuas verses a fim de corrig-los. Cada nova verso
fixava algumas depuraes e introduzia outras novas, tal que o nmero de
depuraes provavelmente permanecia constante com o tempo.
A despeito de seu enorme tamanho e de seus problemas, o
OS/360 e os sistemas operacionais similares da terceira gerao, produzidos
por outros fabricantes, satisfizeram razoavelmente bem a seus clientes. Eles
tambm popularizaram vrias tcnicas ausentes nos sistemas operacionais
da segunda gerao. Provavelmente, a mais importante dessas tcnicas foi a
multiprogramao. No 7094, quando o job que estava sendo executado tinha
uma pausa esperando que uma operao em fita ou em qualquer outro
perifrico I/O fosse completada, a CPU simplesmente ficava ociosa at que a
operao I/O fosse encerrada. Em clculos cientficos pesados, as operaes
de I/O no so frequentes, e essse tempo ocioso insignificante. Em
processamento de dados comerciais, as operaes de I/O consomem
frequentemente entre 80 a 90 porcento do tempo total, exigindo alguma
providncia sobre isso.
A soluo foi particionar a memria em vrias partes, com um job
diferente em cada partio, como mostrado na Fig. 3. Enquanto um job
estava esperando que uma operao I/O fosse concluida, um outro job
poderia usar a CPU. Se vrios jobs pudessem ocupar a memria no mesmo
instante, a CPU estaria sempre ocupada quase que em 100% do tempo. Ter
mltiplos jobs na memria, por sua vez, requer hardware especial para
proteger cada job contra danos e entrelaamento entre eles, e o 360 e outros
sistemas da terceira gerao eram equipados com esse hardware.
Job 3
Job 2
Parties da Memria
Job 1
Sistema
Operacional
11
Figura 0.3 - Um sistema de multiprogramao com trs jobs na

memria
Um outro grande aspecto presente nos sistemas operacionais da

terceira gerao era a habilidade de ler jobs de cartes para o disco assim
que eles eram trazidos sala do computador. Assim, sempre que um job
tinha a sua execuo encerrada, o sistema operacional poderia carregar um
novo job do disco numa nova partio vazia e execut-lo. Essa tcnica
chamada de "spooling" (de "Simultaneous Perifheral Operation On Line") e
tambm era usada para a sada. Com o "spooling", os 1401s no precisavam
ser to grandes e a utilizao da fita diminuiu bastante.
Apesar dos sistemas operacionais da terceira gerao terem sido
bem apropriados para a execuo de programas envolvendo grandes clculos
cientficos e de processamento de dados comerciais compactos, eles eram
ainda, basicamente, sistemas em "batch". Muitos programadores sentiam
saudades dos dias da primeira gerao, quando eles tinham a mquina toda
para eles por poucas horas, mas de tal forma que eles depuravam os seus
programas rapidamente. Com os sistemas da terceira gerao, o tempo entre
a submisso do job e a obteno da sada era frequentemente de vrias
horas, a ponto da ausncia de uma nica vrgula causar uma falha na
compilao e o programador desperdiava quase um dia.
A vontade de ter um tempo de resposta menor abriu espao
para "time-sharing", uma variante da multiprogramao, em que cada
usurio tem um terminal "on-line". Num sistema "time-sharing", se 20
usurios esto conectados e 17 deles esto pensando, falando ou tomando
caf, a CPU pode ser alocada para os trs jobs que querem servio. Como as
pessoas que depuram programas usualmente editam poucos comandos
(como compilar um programa de cinco pginas) em vez de programas longos
(como classificar mil registros em fita), o computador pode fornecer mais
rpido, servio interativo a um nmero maior de usurios e talvez tambm
trabalhar com grandes jobs em "batch" paralelamente, enquanto a CPU est,
por outro lado, ociosa. Embora a primeira srie de sistemas em time-sharing
(CTSS) foi desenvolvido no MIT num IBM 7094 especialmente modificado, ele
no se tornou verdadeiramente popular at que a necessidade de proteo
de hardware ficasse mais difundida durante a terceira gerao.
Aps o sucesso do sistema CTSS, o MIT, o Laboratrio Bell e a
General Electric (ento o maior fabricante de computadores) decidiram
embarcar no desenvolvimento de um "computador utilitrio", uma mquina
que suportasse milhares de usurios em "time-sharing" simultaneamente. O
12
seu modelo era baseado no sistema de distribuio de eletricidade - quando

voce precisa de eletricidade, basta por um plug na tomada da parede e a
quantidade que voce precise, ter. Os projetistas desse sistema, conhecido
como MULTICS (MULTiplexed Information and Computing Service), tinham em
mente uma grande mquina que fornecesse servio de computao para
todos em Boston. A idia de que mquinas to poderosas quanto o GE44
seriam vendidas como computadores pessoais por alguns milhares de dlares
apenas vinte anos mais tarde era, naquela poca, pura fico cientfica. Para
resumir, o MULTICS introduziu muitas idias inovadoras na literatura da
computao, mas a sua construo foi mais difcil do que se esperava. O
Laboratrio Bell saiu do projeto e a General Electric continuou sozinha.
Eventualmente o MULTICS rodava o suficientemente bem para ser usado num
ambiente de produo no MIT e em poucas outros lugares, mas a idia de
um computador utilitrio falhou. Mesmo assim, o MULTICS teve uma enorme
influncia nos sistemas subsequentes.
Outro importante desenvolvimento durante a terceira gerao foi
o crescimento fenomenal de mini-computadores, comeando com o DEC PDP1 em 1961. O PDP-1 tinha apenas 4 K palavras de 18 bits mas a um custo de
120.000 dlares por mquina (menos que 5% do preo de um 7094) eles
vendiam como bolinhos. Para certos tipos de trabalhos no-numricos era
quase to rpido quanto o 7094 e fez surgir uma nova indstria. Foi
rapidamente seguido por uma srie de outros PDPs (que diferentes da famlia
IBM, eram todos incompatveis) culminando com o PDP-11.
Um dos cientistas do Laboratrio Bell que trabalhou no MULTICS,
Ken Thompson, logo depois encontrou um pequeno PDP-7 que ningum usava
e comeou a escrever uma verso simplificada mono-usurio do MULTICS.
Brian Kernighan apelidou esse sistema de UNICS (UNiplexed Information and
Computing Service), mas sua grafia foi mais tarde trocada para UNIX.
Posteriormente foi levado para um PDP-11/20, onde funcionou bem o
bastante para convencer a gerncia do Laboratrio Bell em investir no PDP11/45 para continuar o trabalho.
Outro cientista do Laboratrio Bell, Dennis Ritchie, juntou-se a
Thompson para reescrever o sistema numa linguagem de alto nvel chamada
C, projetada e implementada por Ritchie. O Laboratorio Bell licensiava o UNIX
para Universidades quase de graa e dentro de poucos anos, centenas delas
estavam usando-o. O UNIX logo estendeu-se para o Interdata 7/32, para o
VAX, para o MOTOROLA 68000, e para
muitos outros computadores. O UNIX tinha sido transportado para mais
computadores do que qualquer outro sistema operacional da histria e seu
uso est ainda aumentando rapidamente.
13
0.4 - A Quarta Gerao (1980-1990): Computadores Pessoais

Com o desenvolvimento de circuitos LSI (Large Scale Integration),
chips contendo milhares de transistores em um centimetro quadrado de
silcio, a era do computador pessoal comeava. Em termos de arquitetura, os
computadores pessoais no eram diferentes de minicomputadores da classe
do PDP-11, mas em termos de preo eles eram certamente bem diferentes.
Enquanto o minicomputador tornou possvel um departamento de uma
companhia ou uma universidade ter o seu prprio computador, o chip
micropocessador tornou possvel um indivduo ter o seu prprio computador.
A grande variedade de capacidade computacional disponvel,
especialmente a capacidade de computao altamente interativa com
excelentes facilidades grficas, fizeram crescer a indstria de produo de
software para computadores pessoais. Muitos desses softwares eram
"amigveis ao usurio", significando que eles foram projetados para usurios
que no tinham conhecimento
algum sobre computadores e alm do mais no tinha outra inteno a no ser
a de orient-los no uso. Essa foi certamente a maior mudana do OS/360,
cujo JCL era to complexo que livros inteiros foram escritos sobre ele.
Dois sistemas operacionais dominaram a utilizao do
computador pessoal: o MS-DOS, escrito pela Microsoft para o IBM PC e para
outras mquinas que usavam a CPU Intel 8088 e seus sucessores, e UNIX,
que predominante em mquinas que usam a CPU da famlia Motorola
68000. Pode parecer irnico que o descendente direto do MULTICS, projetado
para o gigante computador utilitrio, ficou to popular em computadores
pessoais, mas principalmente mostra como foram boas as idias sobre o
MULTICS e o UNIX. Apesar da primeira verso do MS-DOS ser primitiva, em
verses subsequentes foram incluidas diversas facilidades do UNIX, o que no
to surpreendente j que a Microsoft um dos maiores fornecedores do
UNIX, usando o nome comercial XENIX.
Um interessante desenvolvimento que comeou em meados dos
anos 80 foi o crescimento de redes de computadores pessoais rodando
sistemas operacionais para rede e sistemas operacionais distribuidos. Num
sistema operacional para rede, os usurios tm conscincia da existncia de
mltiplos computadores e podem se conectar com mquinas remotas e
copiar arquivos de uma mquina para outra. Cada mquina roda o seu
prprio sistema operacional local e tem o seu prprio usurio (ou usurios).
Um sistema operacional distribuido, em contraste, aparece para
o usurio como um sistema tradicional de um nico processador, mesmo
sendo composto realmente de mltiplos processadores. Num verdadeiro
sistema distribuido, os usurios no tm conscincia de onde os seus
programas esto sendo rodados ou onde seus arquivos esto localizados;
tudo manuseado automtica e eficientemente pelo sistema operacional.
14
Os sistemas operacionais em rede no so fundamentalmente

diferentes dos sistemas operacionais de um nico processador. Eles
obviamente necessitam de um controlador de interface de rede e de algum
software de alto nvel para gerenci-lo, bem como de programas para concluir
com xito uma conexo remota e o acesso a arquivos remotos, mas essas
adies no mudam a estrutura essencial do sistema operacional.
Os sistemas operacionais distribuidos requerem mais do que a
adio de cdigos a um sistema operacional de um processador porque
sistemas distribuidos e centralizados diferem em modos crticos. Sistemas
distribuidos, por exemplo, frequentemente admitem rodar programas em
vrios processadores ao mesmo tempo, e da exigem algortmos de
escalonamento de processadores para otimimizar a quantidade de
paralelismo que deve ser concludo com xito.
O atraso de comunicao em uma rede frequentemente significa
que esses (e outros) algortmos devem rodar com informao incompleta,
desatualizada ou s vezes incorreta. Essa situao radicalmente diferente
de um sistema de um nico processador no qual o sistema operacional tem a
informao completa sobre o estado do sistema.
Tolerncia a falhas uma outra rea em que os sistemas
distribuidos so diferentes. comum para um sistema distribuido ser
projetado com a expectativa de que continuar rodando mesmo que parte do
hardware deixe de funcionar. Desnecessrio se dizer que uma exigncia
adicional ao projeto tem enormes implicaes para o sistema operacional.
0.5 A Era Windows (1990/97)

Se o mundo da computao estava procurando por um novo
padro ou no, ele encontrou um em maio de 1990, quando a Microsoft
finalmente lanou o Windows 3.0.
O Windows 3.0 era executado sobre o DOS e, portanto, oferecia
compatibilidade com os programas DOS. Ele se beneficiava do processador
386, podendo fazer a multitarefa com programas DOS e tambm com
programas Windows. A interface com o usurio foi projetada para se parecer
com o Presentation Manager, trazendo um Gerenciador de Programas
baseado em cones e um Gerenciador de Arquivos em estilo rvore, incluindo
avanos como cones sombreados. Embora o Windows 3.0 tenha exigido
revises mnimas de praticamente todos os programas Windows existentes
na poca, no havia muito a ser revisado. Alm do mais, imediatamente
aps a introduo do Windows 3.0, comearam a aparecer os aplicativos,
liderados pela diviso de aplicativos da prpria Microsoft e seguidos por
praticamente todos os outros grandes desenvolvedores. Mesmo depois do
anncio do Windows 3.0, a Microsoft e a IBM continuavam falando sobre o
15
OS/2 e, especialmente, sobre o OS/2 2.0, a primeira verso 32 bits real que
viria a aparecer, finalmente, em 1992.
Para contundir ainda mais as coisas, enquanto a IBM
posicionava o OS/2 como o futuro sistema operacional para todos os usurios,
a Microsoft posicionava o OS/2 como um topo de linha, apenas para os
aplicativos misso crtica e baseados em servidor. Em vez disto, a Microsoft
comeou a falar sobre o OS/2 3.0 (no confundir com o posterior IBM OS/2
Warp 3.0), que adicionaria segurana e suporte avanados a
multiprocessador, sendo capaz de executar aplicativos Windows e Posix
diretamente. Neste cenrio, o Windows NT era o ncleo sobre o qual se
apoiariam o DOS, o Windows, o OS/2 e o Posix.
As duas companhias finalmente separaram suas estratgias no
incio de 1991, com Jim Cannavino, da IBM, e Bill Gates, da Microsoft,
brigando como um casal durante um divrcio litigioso. O OS/2 conquistou um
forte nicho em algumas grandes aplicaes corporativas, auxiliado por sua
estabilidade e robustez, comparadas ao Windows 3.x. Mais tarde, a IBM faria
uma ltima tentativa de fazer do OS/2 o principal sistema operacional com
seu OS/2 Warp 3.0, mais orientado ao consumidor comum e lanado no final
de 1994. Ele venderia milhes de cpias mas no diminuiria a grande
inclinao da indstria pelo Windows.
A Microsoft viria a transformar seu antigo "OS/2 3.0" no Windows NT 3.
1, que foi lanado em 1993 sem o suporte grfico ao OS/2 e recebido,
inicialmente, como um sistema operacional para servidores de aplicativos,
concorrendo, principalmente, com o OS/2 da IBM.
Para a maioria dos usurios de PCs, a Microsoft ofereceu o Wlndows 3.1
avanado no final de 1991, que adicionava uma melhor integrao de
aplicativos, recursos arrastar-e-soltar e uma maior estabilidade. No incio dos
anos 90, ele se tornou o padro dominante para os aplicativos para PC e a
Microsoft ocupou o papel de lder na definio das especificaes multimdia.
A Microsoft viria a dominar muitas reas mais na computao
por esta mesma poca. Seus produtos Visual Basic e Visual C++ venceram a
grande concorrncia da Borland no domnio de linguagens de programao.
Alm disto, os aplicativos Microsoft - liderados pelo pacote Office, contendo o
Word, o Excel, o PowerPoint e, mais tarde, o Access tomaram grande parte do
mercado de programas aplicativos (o que foi auxiliado, em parte, pelos
atrasos nas verses do Lotus 1-2-3, WordPerfect e DBASE para Windows,
sendo que este ltimo foi adquirido pela Borland).
Neste perodo, o Macintosh, da Apple, continuava a crescer e
expandir-se e encontrou nichos nas artes grficas, na multimdia e na
educao. Mas, na maioria das empresas e rgos governamentais, o
principal sistema comercial era aquele que seguia os padres do PC original.
16
quela poca, o termo compatvel com IBM j tinha sado de moda, para ser
substitudo pelo Processador como a principal pea descritiva de hardware.
A era do 286 j havia terminado no final de 1988, aps a
introduo do 386SX da Intel, um Processador que possua os componentes
internos de 32 bits do 386 e um barramento de dados 16 bits como o 286, o
que o tornava barato.
Este e o 386 original rebatizado como 386DX
dominaram as vendas de computadores durante anos. Em abril de 1989, a
Intel apareceu com seus processadores 486.
Com 1,2 milhes de
transistores, o 486 era, efetivamente, uma verso mais rpida e mais
refinada do 386 somada a um co-processador matemtico que executava
todos os aplicativos escritos para o 386 sem quaisquer problemas.
Desta vez, ningum esperou pela IBM ou pela Compaq.
Dezenas de desenvolvedores se apressaram para tornar disponveis suas
mquinas 486 o mais rpido possvel aps a introduo da Intel, e estas
mquinas tinham uma velocidade de execuo 50 vezes maior que o IBM PC
original.
A Intel introduziu seu Processador Pentium de 60 MHz em
maro de 1993, mas no eram apenas os processadores que continuavam a
avanar. Os discos rgidos ficavam cada vez maiores e mais velozes. E a
tecnologia de exibio grfica progrediu das placas de vdeo de "buffer de
quadro" para as aceleradores grficas, que trabalhavam diretamente com o
Windows a fim de aumentar os tempos de resposta de tela e melhorar os
grficos em geral.
Neste perodo, as redes locais corporativas realmente comearam a
decolar. A IBM promovia, ento, o Office Vision, que deveria ser executado
em todas as plataformas SAA, inclusive sobre o OS/2. E praticamente todos
os gigantes do Desenvolvimento de sistemas tinham suas estratgias
multiplataforma para a automao de escritrios, como o All-In-One da DEC.
Quase todos fracassariam dentro de um espao de tempo relativamente
curto. Quem realmente alcanou o sucesso foram os servidores de PC, que
abrigavam seus prprios dados e podiam fazer ligaes com grandes bases
de dados corporativas. No fronte do hardware, o Compaq Systempro,
introduzido em 1989, liderava os grandes aplicativos que antes viviam em
minicomputadores e outros grandes sistemas. No lado do software, chegava
ao mercado o SQL, e companhias como a Oracle e a Sybase comeavam a ter
como alvos os desenvolvedores para PC. As ferramentas de desenvolvimento
rpido de aplicativos, ou RAD, logo facilitaram a criao de boas interfaces
com o usurio para o acesso a dados corporativos.
O correio eletrnico (email) aceito no dia-a-dia das
corporaes com produtos, como o cc:Mail, mais tarde adquirido pela Lotus, e
mais um punhado de concorrentes menores. Em dezembro de 1989, a Lotus
mudou a frmula com o Lotus Notes, o primeiro aplicativo de "groupware".
17
Em 1994, a Microsoft e a Intel j vestiam o manto da

liderana na indstria do PC, o Windows tinha-se estabelecido como o padro
para aplicativos e as redes estavam definitivamente no mercado comum.
No comeo de 1995, poderamos esperar que novos sistemas
operacionais da Microsoft e novos chips da Intel continuassem sendo o carrochefe da computao ainda por muitos anos, levando-se em conta o histrico
dos anos anteriores. Eles ainda so importantes, mas talvez a mudana mais
importante destes ltimos anos tenha vindo de um grupo de estudantes da
Universidade de Illinois. Foi l que, no incio de 1993, Marc Andreessen, Eric
Bina e outros que trabalhavam para o National Center for Supercomputing
Applications (NCSA) apareceram com o Mosaic, uma ferramenta que seria
utilizada para paginar a Internet.
A Internet, claro, j existia h muitos anos, datando do
incio dos anos 60, quando o rgo de Defesa de Projetos de Pesquisa
Avanada (DARPA) do Pentgono estabeleceu as conexes com muitos
computadores de universidades. Enquanto a Internet crescia, o governo
transferiu seu controle para os sites individuais e comits tcnicos. E, em
1990, Tim Berners-Lee, ento no laboratrio de fsica CERN, em Genebra,
Sua, criou a Linguagem de Marcao de Hipertexto (HTML), uma maneira
simples de ligar informaes entre sites da Internet. Isto, por sua vez, gerou
a World Wide Web (www), que apenas aguardava por um paginador grfico
para comear a crescer.
Aps o lanamento do Mosaic ao pblico, no final de 1993,
repentinamente, a Internet - e, em particular, a Web - podiam ser acessadas
por qualquer pessoa que tivesse um computador pessoal, fato auxiliado, em
parte, nela possibilidade de transferir livremente a verso mais recente de
vrios paginadores
diferentes. E, dentro de pouco tempo, parecia que todo o mundo - e todas as
companhias - estava inaugurando seu site na Web.
Novas verses de paginadores da Web tambm chegaram
rapidamente.
A Netscape Corp. - uma nova companhia formada por
Andreessen e Jim Clark, que havia sido um dos fundadores da Silicon Graphics
- logo comeou a dominar o ramo de paginadores Web. O Netscape
Navigator acrescentou vrios recursos, inclusive o suporte a extenses (o
que, por sua vez, levou a diversas extenses multimdia) e a mquina virtual
Java (que permitia aos desenvolvedores elaborar aplicativos Java que podiam
ser executados dentro do paginador).
A tremenda empolgao ocasionada pela exploso da World
Wide Web chegou perto de eclipsar o maior anncio da Microsoft neste
perodo: o Windows 95. Introduzido em agosto de 1995, a estria do software
foi acompanhada por um entusiasmo maior do que qualquer outro anncio de
computao da era.
18
O Windows 95 era a verso do Windows pela qual muitos

usurios estiveram esperando.
Ele permitia a utilizao de aplicativos
totalmente 32 bits, tinha a multitarefa preemptiva, era compatvel com Plugand-Play, suportava novos padres de e-mail e comunicaes e, logicarnente,
trazia uma nova interface com o usurio. Na verdade, muitos usurios
pensavam que a nova interface, que inclua um menu "Iniciar" e uma rea de
trabalho de programas com pastas e cones, deixaria o Windows muito mais
prximo do projeto Lisa original ou do Macintosh de dez anos atrs.
A Microsoft passou anos prometendo um Windows 32 bits,
chegando a dizer que ele estaria pronto em 1992, e os desenvolvedores
passaram um longo tempo aguardando pelo "Chicago", como era conhecido o
Windows 95 durante o desenvolvimento. Urna vez lanado, o Windows 95
rapidamente tornou-se o padro para a computao de usurio final, fazendo
com que muitos desenvolvedores tivessem suas verses de aplicativos 32
bits prontas no lanamento do SO ou imediatamente aps. A Microsoft fez
seguir ao Windows 95, menos de um ano mais tarde, o Windows NT 4.0, que
incorporava a mesma interface com o usurio e executava a maioria dos
mesmos aplicativos, utilizando interfaces de programao Win32. O Windows
NT agradou rapidamente os gerentes de IT corporativos, devido a seu projeto
mais estvel.
Mas ainda existe um grande espao para avanos nos
sistemas operacionais.
Durante anos, os desenvolvedores de software
falaram sobre as linguagens orientadas a objetos (como o C++) e sobre um
sistema operacional mais orientado a objetos. Num projeto como este, dados
e aplicativos deveriam ser divididos, para que os usurios pudessem
trabalhar com os dados independentemente dos aplicativos individuais. O
ideal seria que os dados pudessem ser disseminados ou distribudos por
diversos computadores.
A Microsoft vem falando sobre este conceito h anos, em
especial na palestra "A Informao nas Pontas de Seus Dedos" de Bill Gates,
realizada em novembro de 1990, que enfatizava o conceito de que todos os
dados de que um usurio pode necessitar poderiam, algum dia, ser
acessados por meio de um computador pessoal,
independente do local onde os dados realmente residem. A idia, disse ele,
iria alm dos aplicativos e consideraria apenas os dados. Este caminho levou
nfase dada pela Microsoft aos documentos compostos, macros que
funcionam atravs dos aplicativos, e a um novo sistema de arquivos. Algumas
peas desta viso - chamada Cairo - fazem parte da interface do windows 95
e do OLE (Object Linking and Embedding). Outras ainda esto na prancheta
de desenhos. claro que os concorrentes da Microsoft continuaram seguindo
seus prprios caminhos. Em 1989, a NEXT Computer de Steve Jobs apareceu
com um SO orientado a objetos, destinado aos clientes corporativos e
recentemente adquirido pela Apple Computer. No incio dos anos 90, a IBM e
a Apple fundiram dois de seus projetos - o SO "Pink" da Apple e o
experimento IBM/Metaphor, chamado de Patriot Partners - para criar o
19
Taligent. Este projeto resultou numa srie um tanto extensa de estruturas,

para uso dos desenvolvedores, na criao de aplicativos baseados em
objetos. Mas, embora as estruturas tenham sido recentemente adicionadas
ao OS/2, os planos para o Taligent como um SO isolado foram arquivados.
Uma outra tecnologia baseada em objetos est em vrios
estgios de desenvolvimento. O OLE, da Microsoft, que permite a criao de
documentos compostos, tem sido aprimorado e hoje faz parte da
especificao ActiveX, da mesma companhia. A Apple, a IBM e outras
companhias surgiam com uma especificao alternativa chamada OpenDoc e
tais componentes so hoje conhecidos como LiveObjects. A IBM definiu um
padro para que os objetos trabalhassem em conjunto ao longo de uma rede
chamada Systems Object Model (SOM, ou Modelo de Objeto de Sistema), que
concorre com o Component Object Model (COM, ou Modelo de Objeto
Componente), da Microsoft.
Mas tudo isto tem sido eclipsado nos ltimos meses pelo Java,
da Sun Microsystems, que comeou sua vida como uma variao do C++
projetada para uso na Internet. No ano passado, ele passou a incluir uma
implementao de mquina virtual que foi incorporada aos paginadores da
Netscape e da Microsoft e tambm mais nova verso do sistema
operacional da IBM, o OS/2 Warp. Muitos desenvolvedores esto atualmente
desenvolvendo applets (pequenos aplicativos) e at mesmo aplicativos
completos dentro do Java, na esperana de que isto venha a livr-los de
terem que se apoiar nos padres Microsoft. Mais recentemente, a Sun, a
Netscape e outras companhias estiveram promovendo a especifieao JavaBeans como um timo mtodo de ligao de objetos.
Na prpria Web, um dos atuais esforos so as tecnologias e
produtos que permitem o fornecimento automtico do contedo sobre a
Internet, para que os usurios no precisem pesquisar informaes
especficas. Apresentada pela primeira vez pela PointCast, que implementou
uma tela de descanso que coleta as informaes da vrias fontes, esta
abordagem est sendo perseguida por diversos concorrentes novos, como a
Castanet e a BackWeb. E tanto a Netscape quanto a Microsoft agora
prometem o fornecimento de contedo Internet em segundo plano, com a
Microsoft sempre falando em fazer disto uma parte da rea de trabalho do
Windows.
Quantas e quais destas iniciativas em equipamentos,

programas e rede tero sucesso? Como sempre, difcil dizer. Mas est claro
que a Internet e a Web sero os principais fatores nos prximos anos, assim
como os inevitveis avanos nas capacidades de hardware e software.
20
Captulo 1
VISO GERAL
1.1 Introduo:
21
Sistema Operacional nada mais do que um conjunto de instrues

executadas pelo processador. Sua funo controlar o funcionamento de um
computador, gerenciando a utilizao e o compartilhamento dos seus
diversos recursos, como processadores, memrias e dispositivos de entrada e
sada.
Sem SO, usurio deveria conhecer profundamente o computador para
poder interagir com ele. Implicaria em trabalho lento e com possibilidade de
erros.
A diferena entre um SO e aplicaes convencionais a maneira como
as rotinas so executadas em funo do tempo. O SO no tem incio, meio e
fim como as aplicaes. Dependem de eventos assncronos. Tambm pode
ser chamado de Programa monitor, Executivo, supervisor ou Controlador.
1.2 Funes bsicas:
- Facilidade de acesso aos recursos do sistema: Usurio no
precisa se preocupar como feita a comunicao com monitores, discos,
impressoras, etc. O SO uma interface entre o usurio e os recursos do
sistema. Este conceito de ambiente simulado pelo SO tambm chamado de
Mquina Virtual (figura 1.1)
Compiladores, linkers, bibliotecas, depuradores e outras ferramentas
so utilitrios que facilitam a interao do usurio com o computador.
- Compartilhamento de recursos de forma organizada e
protegida: Em sistemas onde diversos usurios compartilham recursos,
necessrio controlar o uso concorrente destes recursos. Ex: Impressora, a
impresso de um usurio no deve interferir na do outro. O SO controla estes
acessos concorrentes. O compartilhamento tambm permite reduo de
custos, quando diversos usurios podem compartilhar perifricos como
impressoras, discos, etc.
Dependendo do SO, podemos executar diversas tarefas ao mesmo
tempo, como imprimir um documento e baixar um arquivo da Internet. E o
SO que controla estas atividades concorrentes.
22
u su rio s
p ro g ra m a d o re s
e a n a li s ta s
p ro g ra m a s,
s is te m a s e
a p l i c a ti v o s
U s u r io s
S i s te m a O p e r a c i o n a l
m e m r ia
d is c o s
H a rdw a re
fi t a s
U CP
im p r e ss o ra s
m o n i to r e s
Fig. 1.1 - Viso do Sistema Operacional
1.3 Mquina de nveis:

Uma mquina, do ponto de vista do hardware, tem pouca utilidade. atravs
do software que esta mquina ganha utilidade (como armazenamento de
dados, impresso, etc.) Uma operao efetuada por software pode ser
implementada em hardware, bem como uma funo executada pelo hardware
pode ser simulada via software.
Os primeiros computadores eram programados atravs de fios ligados
em painis, criando grandes dificuldades e exigindo grande conhecimento da
mquina.
A soluo veio com o surgimento do SO, tornando a interao com o
usurio mais simples, confivel e eficiente. (Figura 1.2)
23
u su rio s
S is te m a O p e r a c i o n a l
H a rd w a re
Fig. 1.2 - Viso do computador pelo usurio

O computador pode ser visualizado como uma mquina de nveis ou
mquina de camadas. Inicialmente vemos apenas dois nveis: hardware (nvel
0) e SO (nvel 1). Assim, o usurio pode enxergar a mquina como sendo
apenas o SO, como se o hardware no existisse. Esta viso chamada de
mquina virtual.
Na verdade no existem apenas dois nveis, e sim tanto quantos forem
necessrios para adequar o usurio s suas diversas aplicaes. A figura 1.3
representa a estrutura da maioria dos computadores, podendo conter mais ou
menos camadas. A linguagem utilizada em cada um destes nveis diferente,
variando da mais elementar (baixo nvel) mais sofisticada (alto nvel).
A p l ic a ti v o s
U ti l i t r i o s
S is te m a O p e r a c io n a l
Lin g u a g e m d e M q u in a
M ic r o p ro g r a m a o
C i r c u i to s E l e tr n i c o s
Fig. 1.3 - Mquina de Nveis

24
1.4 Tipos de Sistemas Operacionais:

Os tipos de SOs e sua evoluo esto diretamente relacionados com a
evoluo do hardware e das aplicaes por ele suportadas. A figura 1.4
sintetiza os diversos tipos de SOs, cujas caractersticas, vantagens e
desvantagens sero abordadas em seguida.
T ip o s d e
S is te m a s O p e r a c io n a i s
S is te m a s
M o n o p r o g r a m v e is /
M o n o ta r e fa
S is te m a s
M u l ti p r o g r a m v e i s /
M u l ti t a r e f a
S is te m a s
c o m M l ti p l o s
P ro ce ssa d o re s
Fig. 1.4 - Tipos de Sistemas Operacionais
1.4.1 SOs monoprogramveis/monotarefa:

Os primeiros SOs eram voltados para a execuo de um nico
programa. Qualquer outra aplicao deveria aguardar a aplicao concorrente
terminar, para ser executada. Estes sistemas vieram a ser conhecidos como
sistemas monoprogramveis e se caracterizavam por permitir que o
processador, a memria e os perifricos estejam exclusivamente dedicados
execuo de um nico programa.
Este tipo de SO est relacionado aos primeiros computadores da dcada
de 60. Voltou a ser utilizado na dcada de 70 em estaes de trabalho. Nos
sistemas monotarefas, como tambm so conhecidos, todos recursos do
sistema ficam exclusivamente dedicados a uma nica tarefa.
Neste tipo de SO, o processador fica ocioso, por exemplo, quando
espera a digitao de um dado. A memria sub-utilizada caso no seja
preenchida totalmente, e os perifricos, como discos e impressoras, esto
dedicadas a um nico usurio, nem sempre de forma integral (Figura 1.5).
25
U CP
M e m r ia
P r in c ip a l
p ro g ra m a /
ta r e f a
D is p o s itiv o s
de E/S
Fig. 1.5 - Sistemas monoprogramveis / monotarefa.
1.4.2 SOs multiprogramveis / multitarefa:

Os SOs multiprogramveis ou multitarefas so uma evoluo do SO
monoprogramveis. Neste tipo de SO os recursos computacionais so
compartilhados entre diversos usurios e aplicaes. Aqui vrias aplicaes
compartilham esses mesmos recursos.
Aqui tambm, enquanto um programa espera por uma operao de
leitura ou gravao em disco, outros programas podem estar sendo
processados neste intervalo de tempo. Neste exemplo, observamos o
compartilhamento da memria e do processador. O SO se preocupa em
gerenciar o acesso concorrente a seus diversos recursos, de forma ordenada
e protegida, entre os diversos programas (Figura 1.6).
26
p ro g ra m a /
ta r e f a
p ro g ra m a /
ta r e f a
U CP
M e m r ia
P r in c ip a l
D i s p o s it iv o s
d e E/S
p ro g ra m a /
ta r e f a
p ro g ra m a /
ta r e fa
p ro g ra m a /
ta r e f a
Fig. 1.6 Sistemas multiprogramveis / multitarefa

A vantagem deste tipo de SO a reduo do tempo de resposta das
aplicaes processadas no ambiente e de custos, a partir do
compartilhamento de recursos do sistema entre diferentes aplicaes. Apesar
de mais eficientes, os SO multiprogramvel tem implementao muito mais
complexa.
Baseado no nmero de usurios que interagem com o sistema, o SO
multiprogramvel pode ser classificado como monousurio ou multiusurio.
Os sistemas multiprogramveis monousurio so encontrados em
computadores pessoais e estaes de trabalho, onde apenas um usurio
interage com o sistema. Por exemplo, um usurio pode executar um editor de
texto, ao mesmo tempo em que acessa a Internet e imprime um documento.
Nos sistemas multiusurios, permite-se que diversos usurios conectarem-se
ao sistema simultaneamente. A tabela 1.1 relaciona os tipos de sistemas em
funo do nmero de usurios.
Um usurio
Monoprogramao /
Monotarefa
Monousuri
o
Dois ou mais
usurios
No disponvel
27
Multiprogramao /
Multitarefa
Monousuri
o
Multiusurio
Tabela 1.1 Sistemas x Usurios

Os SO multiprogramveis ou multitarefa, podem ainda ser classificados
pela forma com que suas aplicaes so gerenciadas, podendo ser divididos
em sistemas batch, de tempo compartilhado ou de tempo real. Um SO pode
suportar um ou mais destes tipos de processamento, dependendo de sua
implementao (Figura 1.7).
S is te m a s
M u l ti p r o g r a m v e i s /
M u l tita r e f a
S is te m a s
B a tch
S is te m a s d e
Te m p o C o m p a r tilh a d o
S is te m a s d e
Te m p o R e a l
Fig. 1.7 Tipos de sistemas multiprogramveis / multitarefa.

1.4.2.1 Sistemas Batch:
Os sistemas batch foram os primeiros SOs multiprogramveis implantados
na dcada de 60. Os programas, tambm chamados de jobs, eram
executados atravs de cartes perfurados e armazenados em discos ou fitas,
onde aguardavam para serem processados. Posteriormente, em funo da
disponibilidade de espao na memria principal, os jobs eram executados,
produzindo uma sada em disco ou fita.
Este tipo de processamento se caracteriza por no exigir a ateno do
usurio com a aplicao. Todas entradas e sadas eram implementadas por
algum tipo de memria secundaria, geralmente discos. Clculos numricos,
compilaes, ordenaes e backups so exemplos de aplicaes batch.
Estes sistemas podem ser bastante eficientes, por utilizar melhor o
processador, entretanto, podem oferecer tempos de resposta longos.
Atualmente no existem sistemas exclusivamente batch, sendo executados
atravs de simulaes quando necessrio.
1.4.2.2 Sistemas de Tempo compartilhado:
Os sistemas de tempo compartilhado (time-sharing), permitem que
diversos programas sejam executados a partir da diviso de tempo do
28
processador em pequenos intervalos, chamados de fatia de tempo (timeslice). Caso o tempo disponibilizado no seja suficiente para a concluso do
programa, este interrompido pelo SO e substitudo por um outro, enquanto
fica aguardando por uma nova fatia de tempo. Este ambiente d a impresso
que todo o sistema esta dedicado, exclusivamente, para cada usurio.
Geralmente, nestes sistemas a interao com o usurio se d atravs de

terminais de vdeo, teclado e mouse. Estes sistemas possuem uma linguagem
de controle prpria, permitindo ao usurio comunicar-se diretamente com o
SO atravs de comandos. Assim, possvel por exemplo, a verificar arquivos
armazenados num disco, ou cancelar a execuo de um programa.
Devido a este tipo de interao, os sistemas de tempo compartilhado
tambm so chamados de sistemas on-line.
A maioria das aplicaes comerciais atuais so processadas em sistemas
de tempo compartilhado, pois oferecem tempos baixos de resposta aos
usurios e menores custos, em funo da utilizao compartilhada de
diversos recursos.
1.4.2.3 Sistemas de Tempo Real:
Os sistemas de tempo real (real-time) so implementados de forma
semelhante dos sistemas de tempo compartilhado. A diferena o tempo
de resposta exigido no processamento das aplicaes.
Nos sistemas de tempo compartilhado, o tempo de resposta pode variar
sem comprometer as aplicaes em execuo. Nos de tempo real, os tempos
de resposta devem estar dentro de limites rgidos, que devem ser
obedecidos, caso contrario podero ocorrer srios problemas.
No sistema de tempo real no existe a idia de fatia de tempo. Um
programa utiliza o processador o tempo que necessitar, ou ate que aparea
outro mais prioritrio. A prioridade de execuo definida pela prpria
aplicao e no pelo SO.
Estes sistemas podem ser encontrados em aplicaes de controle de
processos, como no monitoramento de refinarias de petrleo, controle de
trafego areo, de usinas termoeltricas e nucleares, ou qualquer outra onde o
tempo de resposta fator fundamental.
1.4.3 Sistemas com Mltiplos Processadores:
Os sistemas com mltiplos processadores caracterizam-se por possuir
dois ou mais processadores interligados e trabalhando em conjunto. Este tipo
de sistema permite que vrios programas sejam executados ao mesmo
29
tempo, ou que um nico programa seja subdividido em partes para serem

executados simultaneamente em mais de um processador.
O uso de mltiplos processadores permitiu a criao de sistemas voltados
para processamento cientfico (como a criao do mapa gentico), no
desenvolvimento aeroespacial, prospeco de petrleo, simulaes,
processamento de imagens, CAD e previso do tempo. Pode-se afirmar que
qualquer aplicao que faca uso intensivo do processador, ser beneficiada
pelo acrscimo de processadores ao sistema. A evoluo destes sistemas se
deve em grande parte, ao elevado custo de desenvolvimento de
processadores de alto desempenho. menos custoso interligar diversos
processadores menores do que desenvolver um mais poderoso.
Alm dos mesmos benefcios dos sistemas multiprogramveis, o sistema
com mltiplos processadores apresentam vantagens como:
Escalabilidade : a possibilidade de se aumentar o poder computacional
do sistema, adicionando-se novos processadores.
Disponibilidade : a capacidade de manter o sistema em operao
mesmo em caso de falha de uma ou mais maquinas. No caso de uma falha,
as outras mquinas assumem suas funes de maneira transparente ao
usurio, embora com menor poder de computao.
Balanceamento de carga : a possibilidade de distribuir o
processamento entre os diversos processadores, melhorando assim o
desempenho do sistema como um todo.
Um fator-chave na criao de SOs com mltiplos processadores a
forma de comunicao entre eles e o grau de compartilhamento da memria
e dos dispositivos de entrada e sada. Assim, podemos classificar os sistemas
com mltiplos processadores em fortemente acoplados ou fracamente
acoplados (Figura 1.8).
Sistemas
Com Mltiplos
Processadores
Sistemas
Fortemente
Acoplados
Sistemas
Fracamente
Acoplados
Fig. 1.8 Tipos de Sistemas com mltiplos processadores

30
1.4.3.1 Sistemas fortemente acoplados:

Nos sistemas fortemente acoplados (tightly coupled) vrios
processadores compartilham uma nica memria fsica (shared memory) e
dispositivos de entrada e sada, sendo gerenciados por um nico SO (Figura
1.9).
M e m r ia
P r in c ip a l
U CP
D i s p o s itiv o s
de E/S
U CP
D is p o s itiv o s
de E/S
Fig 1.9 Sistemas fortemente acoplados

Em virtude disso, este tipo de sistema tambm chamado de
multiprocessador.
Os sistemas multiprocessadores dividem-se ainda em SMP (Symmetric
MultiProcessor) e NUMA (Non-Uniform Memory Access). Os sistemas SMP
possuem tempo uniforme de acesso memria principal pelos diversos
processadores. Os sistemas NUMA apresentam diversos conjuntos reunindo
processadores e memria principal, sendo que cada conjunto conectado aos
outros atravs de uma rede de interconexo. O tempo de acesso memria
pelos processadores varia em funo da sua localizao fsica.
Nos sistemas SMP e NUMA todos processadores tm as mesmas
funes. Inicialmente, os sistemas multiprocessadores limitavam-se a
sistemas de grande porte. Com a evoluo dos computadores pessoais, os
sistemas multitarefa tambm evoluram para permitir a existncia de vrios
processadores no modelo simtrico. Atualmente, sistemas como Unix, Linux,
Windows 200 e Windows XP implementam esta funcionalidade.
31
1.4.3.2 Sistemas fracamente acoplados:

Os sistemas fracamente acoplados (loosely coupled), caracterizam-se
por possuir dois ou mais sistemas computacionais conectados atravs de
linhas de comunicao. Cada sistema funciona de forma independente,
possuindo seu prprio sistema operacional e gerenciando seus prprios
recursos, como processador, memria e dispositivos de entrada e sada
(Figura 1.10).
lin k d e co m u n ic a o
U CP
M e m r ia
P r in c ip a l
U CP
D is p o s itiv o s
d e E/S
M e m r ia
P r in cip a l
de E/S
Fig. 1.10 Sistemas fracamente acoplados

Em funo destas caractersticas, os sistemas fracamente acoplados
tambm so conhecidos como multicomputadores. Neste modelo, cada
sistema computacional tambm pode ser formado por um ou mais
processadores.
At meados dos anos 80, as aplicaes eram centralizadas em sistemas
de grande porte, com um ou mais processadores. Nesta configurao, os
usurios utilizavam terminais no-inteligentes conectados a linhas seriais
dedicadas ou mesmo a linhas telefnicas pblicas para comunicao
interativa com estes sistemas. No modelo centralizado, os terminais no tem
poder de processamento. A solicitao de uma tarefa ao sistema feita
atravs de linhas de comunicao.
A
evoluo
dos
computadores
pessoais
e
tambm
das
telecomunicaes, fez com que um novo modelo de computao surgisse,
chamado de modelo de rede de computadores. Em uma rede existem dois ou
mais sistemas independentes (hosts), interligados atravs de linhas de
comunicao, oferecendo algum tipo de servio aos demais. Assim, a
32
informao deixa de ser centralizada em sistemas de grande porte e passa a

ser distribuda pelos diversos sistemas da rede.
Baseando-se no grau de integrao dos hosts da rede, dividimos os
sistemas fracamente acoplados em sistemas operacionais de rede e sistemas
distribudos. A diferena bsica entre eles a capacidade do SO criar uma
imagem nica dos servios disponibilizados pela rede.
Os sistemas operacionais de rede (SORs) permitem que um host
compartilhe seus recursos como impressora ou disco, com os demais hosts da
rede. Um exemplo disto so as redes locais.
Nos sistemas distribudos o sistema operacional esconde os detalhes
dos hosts individuais e passa a trat-los como um conjunto nico, como se
fosse um sistema fortemente acoplado. Nos sistemas distribudos, uma
aplicao pode ser dividida em
partes e cada parte pode ser executada por hosts diferentes da rede de
computadores. Para os usurios e suas aplicaes, como se no existisse a
rede de computadores, e sim um nico sistema centralizado.
Outro exemplo de sistema distribudo so os clusters. Em um cluster
existem dois ou mais servidores ligados, atravs de uma conexo de alto
desempenho. O usurio no conhece os nomes dos membros do cluster e no
sabe quantos so. Basta solicitar um servio ao cluster para obt-lo. Este tipo
de sistema usado atualmente em sistemas de banco de dados e Web,
garantindo alta disponibilidade, escalabilidade e balanceamento de carga
soluo.
33
Captulo 2
CONCEITOS DE HARDWARE E SOFTWARE
2.1 Introduo:
Neste captulo sero apresentados brevemente, conceitos bsicos de
hardware e software, para compreenso dos captulos seguintes.
2.2 Hardware:
Um sistema computacional um conjunto de circuitos eletrnicos
interligados, formado por Processador ou unidade central de processamento,
memria principal e dispositivos de entrada/sada.
P ro ce ssa d o r / U C P
U n id a d e L g ic a
e A r i tm t i c a
U n id a d e d e
C o n tr o le
M e m r ia
P r in c ip a l
R e g is tr a d o r e s
de E/S
Fig. 2.1 Sistema Computacional

2.2.1 Processador:
Um processador composto por unidade de controle, unidade lgica e
aritmtica, e registradores. A unidade de controle (UC) responsvel por
gerenciar as atividades de todos os componentes do computador, como a
gravao de dados em discos ou a busca de instrues na memria. A
unidade lgica e aritmtica (ULA), como o nome indica, responsvel pela
realizao de operaes lgicas (testes e comparaes) e aritmticas (somas
e subtraes).
34
2.2.2 Memria:
A memria composta por unidades de acesso chamadas clulas,
sendo cada clula composta por um determinado nmero de bits.
Atualmente, a grande maioria dos computadores utiliza o byte (8 bits) como
tamanho de clula.
Memrias volteis precisam estar sempre energizadas para manter
suas informaes, o que no acontece com as no-volteis.
0
in s tr u o o u d a d o
e n d e re o s
16
2 -1
c lu la = 8 b its
Fig. 2.2 Memria principal com 64 Kbytes

2.2.3 Memria Cache:
A memria cache uma memria voltil de alta velocidade, porm com
pequena capacidade de armazenamento. O tempo de acesso a um dado nela
contido muito menor que se o mesmo estivesse na memria principal. O
propsito do uso da memria cache minimizar a disparidade existente entre
a velocidade com que o processador executa instrues e a velocidade com
que dados so acessados na memria principal.
2.2.4 Memria Principal e Secundaria:
A memria principal um dispositivo de armazenamento, em geral
voltil, onde so armazenados instrues e dados utilizados pelo processador
durante a execuo de programas. A memria secundria um dispositivo
35
no-voltil com maior capacidade de armazenamento, porm com menor

velocidade de acesso aos seus dados armazenados.
R e g i s tr a d o r e s
M e m r ia C a c h e
m a io r
ca p a cid a d e d e
a r m a z e n a m e n to
M e m r ia P r in c ip a l
m a io r c u s to e
v e lo cid a d e
d e a ce sso
M e m r ia S e c u n d r ia
Fig. 2.3 Relao entre dispositivos de armazenamento

2.2.5 Dispositivos e Entrada/Sada:
Os dispositivos de entrada e sada podem ser divididos em duas
categorias: os que so utilizados como memria secundria e os que servem
para a interface usurio-mquina. Os dispositivos utilizados como memria
secundria (discos e fitas magnticas) caracterizam-se por ter capacidade de
armazenamento bastante superior ao da memria principal. Seu custo
relativamente baixo, porm o tempo de acesso memria secundria bem
superior ao da memria principal. Outros dispositivos tm como finalidade a
comunicao usurio-mquina, como teclados, monitores de vdeo,
impressoras e plotters.
2.2.6 Barramentos ou Bus:
Barramentos o meio fsico de comunicao entre as unidades
funcionais de um sistema computacional. Os barramentos processadormemria so de curta extenso e alta velocidade para que seja otimizada a
transferncia de informao entre processadores e memrias. Os
barramentos de E/S possuem maior extenso, so mais lentos e permitem a
conexo de diferentes dispositivos. O barramento de backplane tem a
funo de integrar os dois barramentos anteriores.
36
M e m r ia
P r in c ip a l
U C P
B a r r a m e n to p r o ce s sa d o r - m e m r ia
B a r r a m e n to d e E / S
A d a p ta d o r
A d a p ta d o r
Fig. 2.4 Barramentos processador-memria e de E/S
M e m r ia
P r in c ip a l
U CP
B a r r a m e n to p r o c e s s a d o r - m e m r i a
B a r r a m e n to
d e b a ck p la n e
A d a p ta d o r
A d a p ta d o r
A d a p ta d o r
37
Fig. 2.5 Barramento de Backplane
2.2.7 Pipeline:
uma tcnica que permite ao processador executar mltiplas
instrues paralelamente em estgios diferentes.
P1
P2
P3
P4
U n id a d e d e
b u sca d a
in s tr u o
A n a lis a d o r
da
in stru o
U n id a d e d e
b u sca d o s
dados
U n id a d e d e
e xe cu o d a
in stru o
P1
P2
P3
P4
I n s t r. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
I n s t r. 5
I n s t r. 6
I n s t r. 7
I n s t r. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
I n s t r. 5
I n s t r. 6
I n s tr. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
I n s t r. 5
I n s tr. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
te m p o
Fig. 2.6 Arquitetura pipeline com quatro estgios
38
Captulo 3
CONCORRNCIA
3.1 Introduo:
Os sistemas operacionais podem ser vistos como um conjunto de
rotinas que executam concorrentemente de forma ordenada. A possibilidade
de o processador executar instrues em paralelo com operaes de E/S
permite que diversas tarefas sejam executadas concorrentemente.
Concorrncia o princpio bsico para projeto e implementao dos sistemas
operacionais multiprogramveis.
Os SOs monoprogramveis eram limitados por seus recursos no serem
utilizados de forma eficiente, limitando seu desempenho. Muitos recursos
(alguns de alto custo), permaneciam ociosos por longos perodos de tempo.
O disperdcio dos SOs monoprogramveis pode ser representado na
Figura 3.1a, pois enquanto uma leitura em disco realizada, o processador
permanece ocioso. O tempo de espera relativamente longo, pois as
operaes de E/S so lentas comparadas s operaes dos processadores.
E/S
U CP
E/S
U C P
liv r e
(a ) S i s te m a M o n o p r o g r a m v e l
te m p o
( b ) S i s te m a M u l ti p r o g r a m v e l
te m p o
Fig. 3.1 Sistema monoprogramvel x sistema multiprogramvel

A tabela 3.1 apresenta um exemplo de um programa que l registros de
um arquivo e executa, em mdia, 100 instrues por registro lido. Neste caso,
o processador gasta cerca de 93% do tempo esperando o dispositivo de E/S
concluir sua operao para ento continuar o processamento.
Leitura de um registro
0,0015 s
Execuo
de
100 0,0001 s
instrues
Total
0,0016 s
% utilizao da CPU (0,0001 / 0,0015) = 0,066 =
6,6 %
39
Tabela 3.1 Exemplo de utilizao do sistema

A memria principal tambm subutilizada se o programa no a ocupa
totalmente, deixando reas livres. Nos SOs multiprogramveis, vrios
programas podem estar residentes em memria, concorrendo pela utilizao
do processador. Assim, o processador permanece menos tempo ocioso (Figura
3.1 b) e a memria utilizada de forma mais eficiente, pois vrios programas
se revezam na utilizao do processador.
A utilizao concorrente do processador deve ser implementada de
forma que, quando um programa perde o uso do processador, e depois
retorna sua execuo, dever continu-la na instruo seguinte quela em
que fora interrompido. Para o usurio, parece que nada aconteceu. Em
sistemas de tempo compartilhado, existe a impresso de o sistema est
inteiramente dedicado a ele.
Em sistema monoprogramveis, temos perifricos (como impressoras e
discos) parados por grandes perodos de tempo esperando aes de um nico
usurio.
Na tabela 3.2 temos as vantagens de um sistema multiprogramvel,
com um disco, um terminal e uma impressora. Nesta configurao, so
executados trs programas distintos (Prog1, Prog2 e Prog3).
Pela tabela, percebemos que Prog1 no realiza operaes de E/S, ao
contrrio de Prog2 e Prog3.
Caractersticas
Utilizao
do
processador
Operaes de E/S
Tempo
de
processamento
Memria utilizada
Utilizao de disco
Utilizao de terminal
Utilizao de impressora
Prog1
Alta
Prog2
Baixa
Prog3
Baixa
Poucas
5 min
Muitas
15 min
Muitas
10 min
50 Kb
No
No
No
100 Kb
No
Sim
No
80 Kb
Sim
No
Sim
Tabela 3.2 Caractersticas de execuo do programas

Se fossem realizados num ambiente monoprogramvel, seriam
executados em seqncia, totalizando 30 minutos. Se fossem executados em
ambiente multiprogramvel, os ganhos so considerveis, conforme mostra a
tabela 3.3.
Caractersticas
Utilizao do processador
Utilizao da memria
Monoprogramao
17 %
30 %
Multiprogramao
33 %
67 %
40
Utilizao de disco
Utilizao de impressora
Tempo
total
processamento
Taxa de processamento
33%
33 %
30 min.
67 %
67%
15 min.
6 progr. / hora
12 progr. / hora
de
Tabela 3.3 Comparao entre Mono e multiprogramao

A seguir, ser apresentado tcnicas de implementao da concorrncia,
essencial num sistema multiprogramvel.
3.2 Interrupo e Exceo:
Durante a execuo de um programa, eventos inesperados podem
ocorrer, ocasionando um desvio forcado em seu fluxo de execuo. Estes
tipos de eventos so conhecidos por interrupo ou exceo e podem ser
conseqncia da sinalizao de algum hardware externo ou da execuo de
instrues do prprio programa. A diferena entre interrupo e exceo e
dada pelo tipo de evento ocorrido. Porm, nem sempre feita esta distino.
A interrupo permitiu a implementao da concorrncia nos
computadores. Com este mecanismo, o SO sincroniza a execuo de todas
suas rotinas e dos programas dos usurios, alm de controlar dispositivos.
Uma interrupo gerada por algum evento externo ao programa e
independe da instruo que esta sendo executada. Um exemplo de
interrupo ocorre quando um disco avisa ao processador que uma operao
de leitura ou escrita est completa. Neste caso, o processador interrompe o
programa e trata o trmino da operao.
Ao final da execuo de cada instruo, a unidade de controle verifica a
ocorrncia de algum tipo de interrupo. Neste caso, o programa desviado
para uma rotina de tratamento de interrupo. Para o programa prosseguir
posteriormente, as informaes do programa executado so armazenadas em
registradores no processador (Figura 3.2).
41
Fig. 3.2 Mecanismos de interrupo e exceo

A tabela 3.4 descreve o mecanismo de interrupo, que pode ser
realizado por hardware ou software.
Para cada tipo de interrupo existe uma rotina de tratamento
associada. A identificao do tipo de interrupo fundamental para
determinar o endereo da rotina de tratamento.
Existem dois mtodos utilizados no tratamento das interrupes. O
primeiro utiliza uma estrutura de dados chamada de vetor de interrupo,
que contem o endereo inicial de todas as rotinas de tratamento existentes,
associadas a cada evento. Um segundo mtodo utiliza um registrador de
status que armazena o tipo do evento ocorrido. Neste mtodo, s existe uma
nica rotina de tratamento, que no seu inicio testa o registrador para
identificar o tipo de interrupo e trat-la de maneira adequada.
Via
Hardware
Via Software
1. Um sinal de interrupo gerado para o processador

2. Aps o termino da execuo da instruo corrente, o
processador identifica o pedido de interrupo
3. Os contedos dos registradores apropriados so
salvos
4. O processador identifica qual a rotina de tratamento
que ser executada e carrega um registrador com o
endereo inicial desta rotina
5. A rotina de tratamento salva o contedo dos demais
registradores na pilha de controle de programas
6. A rotina de tratamento executada
7. Aps o termino da execuo da rotina, os
registradores so restaurados, retomando a execuo
42
do programa interrompido
Tabela 3.4 Mecanismo de interrupo
As interrupes so decorrentes de eventos assncronos (no
relacionados instruo do programa). Estes eventos podem ser
imprevisveis e podem ocorrer mltiplas vezes. Isso possibilitaria a ocorrncia
de mltiplas interrupes simultneas. Par evitar esta situao, a rotina de
tratamento inibir as demais interrupes. Assim, as interrupes posteriores
seriam ignoradas durante a execuo da rotina de tratamento, ou seja, no
receberiam tratamento. Interrupes com estas caractersticas so chamadas
de interrupes mascarveis.
Alguns processadores no permitem que interrupes sejam
desabilitadas. Neste caso, o processador precisa saber a ordem em que
ocorreram as interrupes concorrentes. Para isso, as interrupes devem
possuir prioridades, em funo de sua importncia. Normalmente, um
dispositivo denominado controlador db pedidos de interrupo, o
responsvel por avaliar as interrupes geradas e suas prioridades.
Uma exceo semelhante a uma interrupo, sendo a principal

diferena, o motivo pelo qual o evento gerado. A exceo resultado direto
da execuo de uma instruo do prprio programa, como a diviso de um
nmero por zero, ou a ocorrncia de um overflow e operaes aritmticas.
Portanto, a exceo gerada por um evento sncrono. Tais eventos so
portanto previsveis e s podem ocorrer um nico de cada vez. Um programa
com este tipo de evento que seja reexecutado a exceo ocorrera sempre na
mesma instruo.
Assim como a interrupo, o programa interrompido desviado para
uma rotina de tratamento de exceo (Figura 3.2). O mecanismo de
tratamento de excees muitas vezes pode ser escrito pelo prprio
programador. Assim, possvel evitar que um programa seja encerrado de
ocorrer, por exemplo, um overflow.
3.3 Operaes de Entrada/Sada:
Nos primeiros SOs, existiam instrues especiais para controlar
perifricos, denominadas de instrues de entrada/sada. Estas instrues
continham detalhes de cada perifrico, como por exemplo, na gravao de
um bloco de dados em disco, deveria se especificar em qual trilha e setor
ocorreria a gravao. Isto provocava uma forte dependncia entre
processador e os dispositivos de E/S.
O controlador de interface surgiu para permitir que o processador fique
mais independente dos perifricos. Desta forma, o processador no se
43
comunica mais diretamente com os dispositivos de E/S, mas sim atravs do

controlador (Figura 3.3).
M e m r ia
P r in c ip a l
U CP
C o n tr o la d o r
D is p o s itiv o s d e E / S
Fig. 3.3 Controlador de dispositivos de E/S

O controlador simplificou as instrues de E/S, pois o processador no
necessitaria utilizar instrues detalhadas.
Com a utilizao do controlador, existiam duas maneiras bsicas pelas
quais o processador gerenciava as operaes de E/S:
- Na primeira, o processador sincroniza-se com o perifrico para o
inicio da troca de dados entre eles, e depois de iniciada a transferncia, o
sistema ficava permanentemente testando o estado dos perifricos para
saber quando a operao de E/S terminaria. Este tipo de controle, chamado
de E/S controlada por programa, mantinha o processador ocupado at o fim
da operao de E/S (busy wait). Isto provocava um desperdcio de tempo, pois
o processador executa uma instruo muito mais rapidamente que a
realizao de uma operao de E/S.
- Na segunda, h uma evoluo do modo anterior, onde uma vez
iniciada a transferncia de dados, o processador permanece livre para realizar
outras tarefas. Neste caso, em determinados intervalos de tempo, o SO deve
testar os dispositivos para saber do trmino da operao de E/S (polling). Esta
tcnica permitiu um tipo de paralelismo, sendo a base dos sistemas
multiprogramveis. O nico inconveniente desta tcnica, que caso haja
muitos perifricos, o processamento ser interrompido freqentemente.
44
Com o mecanismo de interrupo, as operaes de E/S se tornaram

mais eficientes, uma vez que o controlador interrompe o processador para
avisar o fim de uma operao, ao invs do processador ficar constantemente
verificando as operaes pendentes (E/S controlada por interrupo).
Esta ltima tcnica mais eficiente do que a controlada por programa,
pois elimina a necessidade do processador esperar pelo trmino da operao,
alem de permitir varias operaes de E/S simultneas.
Ainda existe um outro inconveniente neste processo. o caso em que
h uma grande quantidade de dados, onde as muitas intervenes do
processador acabam por reduzir sua eficincia. Uma soluo pensada para
este problema, foi a tcnica de transferncia de dados chamada de DMA
(Direct Memory Address).
A tcnica DMA permite que um bloco de dados seja transferido entre a
memria principal e um dispositivo de E/S, sem a interveno do processador,
exceto no inicio e no fim da transferncia. Quando o sistema deseja ler ou
gravar um bloco de dados, o processador informa ao controlador sua
localizao, o dispositivo de E/S, a posio inicia da memria onde os dados
sero lidos ou gravados e o tamanho do bloco. Com estas informaes, o
controlador realiza a transferncia entre o perifrico e a memria principal, e
o processador ser interrompido somente no final da operao. A rea de
memria utilizada pelo controlador na tcnica de DMA chamada de buffer
de entrada/sada.
Na tcnica de DMA, o controlador assume momentaneamente o

controle do barramento. Neste caso, a utilizao do barramento passa ser
exclusiva do perifrico, e o processador suspende temporariamente o acesso
ao barramento. O processador pode nestas horas, realizar tarefas que no
dependa, do barramento, como por exemplo, acesso memria cache.
3.4 Buffering:
A tcnica de buffering consiste na utilizao de uma rea na memria
principal, denominada buffer, para a transferncia de dados entre os
dispositivos de E/S e a memria. Esta tcnica permite que em uma operao
de leitura, o dado seja primeiramente transferido para o buffer, liberando
imediatamente o dispositivo para uma nova leitura. Assim, enquanto o
processador processa o dado localizado no buffer, o perifrico realiza outra
operao de leitura, simultaneamente. O mesmo mecanismo pode ser
aplicado s gravaes (Figura 3.4)
45
.
M e m r ia
P r in c ip a l
g ra v a o
U CP
g ra v a o
C o n tr o la d o r
B u ff e r
l e i tu r a
l e itu r a
Fig. 3.4 Operaes de E/S utilizando buffer

O objetivo desta tcnica manter, na maior parte do tempo,
processador e dispositivos de E/S ocupados, pois minimiza o problema da
disparidade da velocidade de processamento entre o processador e os
dispositivos.
A unidade de transferncia utilizada no buffering o registro, que tem
seu tamanho definido em funo:
- Da natureza do dispositivo. Por exemplo, uma linha gerada por
uma impressora, ou um caractere de um teclado.
- Da aplicao, definido em arquivo.
Logicamente o buffer deve permitir armazenar diversos registros, de
forma que hajam dados lidos e ainda no processados, ou processados mas
ainda no gravados.
Isto torna o processo bastante eficiente, pois possvel compatibilizar a
diferena existente entre o tempo em que o processador executa instrues e
o tempo em que o dispositivo de E/S realiza suas operaes de leitura e
gravao.
3.5 Spooling:
A tcnica de spooling (simultaneous peripheral operation on-line),
introduzida no final dos anos 50, visa aumentar o grau de concorrncia e a
eficincia dos SOs.
Semelhante tcnica de buffering, a tcnica de spooling utiliza uma
rea em disco como se fosse um grande buffer. Neste caso, os dados podem
ser lidos ou gravados em disco, enquanto programas so executados
concorrentemente.
Esta tcnica esta presente na maioria dos SOs, utilizada no
gerenciamento de impresso. No momento em que um comando de
impresso executado, as informaes a serem impressas so gravadas
46
antes em um arquivo em disco, conhecido como arquivo de spool, liberando o

programa para outras atividades. Posteriormente, o SO se encarrega de
direcionar o contedo do arquivo de spool para a impressora (Figura 3.5).
Pro g ra m a
A r q u iv o
de Spoo l
Im p re sso ra
Fig. 3.5 Tcnica de Spooling

Esta tcnica desvincula o programa do dispositivo impressor, impedindo
que um programa reserve a impressora para uso exclusivo. O SO gerencia a
seqncia de impresses solicitadas pelos programas, seguindo critrios de
segurana e de uso eficiente das impressoras.
3.6 Reentrncia:
Em sistemas multiprogramveis, vrios usurios podem utilizar o
mesmo aplicativo simultaneamente. Se cada um deles trouxesse o programa
para uma rea de memria, haveria desperdcio de recursos (espao em
memria).
Chamamos de reentrncia, a capacidade de um cdigo executvel
(cdigo reentrante) ser compartilhado entre vrios usurios, exigindo apenas
uma cpia do programa em memria. Esta tcnica permite que cada usurio
possa estar em um ponto diferente do cdigo reentrante, manipulando dados
prprios e exclusivos de cada usurio (Figura 3.6).
47
u s u r io A
u s u r io C
c d i g o r e e n tr a n te
u s u r io B
u s u r io D
r e a d e d a d o s d o u s u r io A
r e a d e d a d o s d o u su r io B
r e a d e d a d o s d o u s u r io C
r e a d e d a d o s d o u s u r io D
M e m r ia P r in ci p a l
Fig. 3.6 Reentrncia

3.7 Proteo do Sistema:
A complexidade de um sistema multiprogramvel resulta em alguns
problemas de proteo. Considerando que diversos usurios compartilham os
mesmos recursos, como memria e processador, deve existir uma
preocupao com a confiabilidade e integridade dos dados e programas dos
usurios, alem do prprio SO.
Como vrios programas ocupam a memria simultaneamente, cada
usurio possui uma rea reservada onde seus dados e cdigo so
armazenados. O SO deve preservar estas informaes. Caso um programa
tente acessar uma posio de memria fora de sua rea, um erro indicando a
violao deve ocorrer.
Semelhante ao compartilhamento de memria, um disco armazena
arquivos de diferentes usurios. Novamente o SO deve garantir a integridade
e confidencialidade dos dados de cada usurio. O compartilhamento de
arquivos em disco permite que dois ou mais usurios acessem um mesmo
arquivo simultaneamente pelo SO.
No sistema multiprogramvel, diversos programas compartilham o
processador. Portanto, deve ser tarefa do SO tambm, o controle da utilizao
do processador, evitando que algum programa monopolize seu uso.
Assim, o SO deve implementar diversos mecanismos de proteo que
controlem o acesso concorrente aos diversos recursos do sistema. Estes
mecanismos sero abordados em captulos posteriores.
48
Captulo 4
ESTRUTURA DO SISTEMA OPERACIONAL
4.1 Introduo:
O Sistema Operacional formado por um conjunto de rotinas que
oferecem servios aos usurios, s suas aplicaes, e ao prprio sistema. Este
conjunto de rotinas denominado ncleo do sistema ou kernel.
No confundir o ncleo do sistema com aplicaes, utilitrios ou
interpretadores de comando, que acompanham o SO. (Figura 4.1). As
aplicaes so utilizadas pelos usurios e no mostram os detalhes da
interao com o sistema. Os utilitrios, como compiladores e editores de
texto, e os interpretadores de comando, permitem aos usurios,
administradores e desenvolvedores, uma interao amigvel com o sistema.
A p l ic a ti v o s
U ti li t r io s
N c le o d o
H a rd w a re
Fig. 4.1 Sistema Computacional

Uma das dificuldades de se compreender o funcionamento de um SO,
devido ao fato que ele no possui um incio, um meio e um fim, como outras
aplicaes. Suas aes dependem de eventos que no ocorrem em uma
ordem pr-definida. Muitos eventos esto relacionados ao hardware e ao
prprio sistema.
49
4.2 Principais Funes:

As principais funes do ncleo na maioria dos SOs esto listadas a
seguir:
Tratamento
de
interrupes
anteriormente, em detalhes;
Criao e eliminao de processos: funo responsvel por alocar

em memria todos os recursos necessrios execuo do processo.
esta funo que aloca em memria, alm do executvel, o contexto do
processo, o buffer de leitura/gravao (se necessrio), alm de listas e
estruturas de controle utilizadas pelo sistema operacional. Nesta funo
tambm so estabelecidos vnculos fsicos a arquivos em disco, fitas e
outros perifricos que sero usados no processamento. Quando do fim
da execuo do programa, esta funo que desaloca todos os espaos
em memria ocupados pelo processo, liberando-os para futuras
alocaes a outros processos;
Escalonamento e controle de processos: funo responsvel por

organizar a fila de acesso ao processador. Utiliza parmetros do sistema
e do perfil do usurio para estabelecer a ordem em que os processos
permanecero espera pela liberao da CPU, para ento entrarem em
execuo;
Gerncia de memria: funo responsvel por fornecer funo de

criao/eliminao de processos os endereos em memria disponveis
para alocao;
Gerncia de sistemas de arquivos: responsvel pelo gerenciamento

dos arquivos, bem como seu compartilhamento pelos diversos usurios,
implementando mecanismos de controle da segurana e direitos de
acesso s reas utilizadas pelos usurios nos diversos dispositivos;
Gerncia de dispositivos de E/S: responsvel por gerenciar os

dispositivos, prestando auxlio criao/eliminao de processos e
gerncia de sistemas de arquivos no que diz respeito ao
endereamento e associao de arquivos em perifricos;
Suporte a redes e teleprocessamento: esta funo que executa

todos os servios de rede, fazendo o empacotamento das mensagens
vindas dos terminais para a CPU central e vice-versa, alm de controlar
e confirmar o envio e recebimento de todas as mensagens que
trafegam pela rede;
Contabilizao de uso do sistema: responsvel por contabilizar o

uso de todos os recursos do sistema consumidos pelos usurios e suas
excees:
explicados
50
aplicaes. So registrados: tempo de CPU, tempo corrido, quantidade

de rea alocada em memria, em disco, linhas impressas, pginas de
papel, entre outros. Isto se faz necessrio para servir de subsdio para
anlise de performance, estatsticas de
gastos com material de consumo e tambm para definio de custos de
processamento.;
Auditoria e segurana do sistema: funo extremamente

importante, pois detecta e registra (num arquivo especial de LOG) todas
as ocorrncias de erro e violao de direitos de acesso ao sistema, aos
arquivos, memria e a todos os recursos do sistema. O arquivo de
LOG usado pela gerncia de sistemas, com o intuito de verificar e
aperfeioar os mecanismos de segurana e proteo ao sistema.
A forma como o cdigo do sistema organizado e o relacionamento com seus

diversos componentes varia de acordo com o projeto do SO.
4.3 System Calls:
Uma grande preocupao no projeto de um SO, quanto a sua
integridade, ou seja, a proteo do ncleo do sistema contra possveis
acessos no-autorizados.
As system calls (chamadas ao sistema) podem ser entendidas como uma
porta de entrada para o acesso ao ncleo do sistema e seus servios. Quando
um usurio ou aplicao necessitar de algum servio do sistema, feita uma
chamada a uma de suas rotinas atravs de uma system call. O termo system
call tpico de ambientes Unix, no ambiente Windows conhecida como API
(Application Program Inteface).
Para cada servio disponvel existe uma system call associada. Cada SO
tem seu prprio conjunto de chamadas diferentes (Figura 4.2). Isto explica o
fato de uma aplicao desenvolvida para um SO, no pode ser executada em
outro.
S y s te m C a l l
A p lic a o
N c le o d o
B ib li o te c a
H a rd w a re
Fig. 4.2 System call

Algumas tentativas foram feitas para padronizar uma biblioteca de
chamadas. O padro POSIX (Portable Operating System Interface for Unix),
51
por exemplo, foi estabelecido com a inteno de unificar as diversas verses

do Unix existentes.
Atravs de parmetros fornecidos nas system calls, a solicitao
processada e uma resposta retornada aplicao, junto com um status
indicando erro ou no. A ativao e comunicao entre programas e o SO,
semelhante a uma sub-rotina de um programa.
As system calls podem ser divididas em grupos de funes (Tabela 4.1)
Muitos usurios e mesmo programadores no imaginam os detalhes que
envolvem um simples comando de leitura de um arquivo, quando se utiliza
uma linguagem de programao de alto nvel. O compilador converte este
comando de alto nvel para uma system call especfica, que quando
executada, verifica a ocorrncia de erros e retorna os dados ao programa, de
forma transparente ao usurio.
Funes
Gerncia
threads
System Calls
de
processos
Gerncia de memria
Gerncia
arquivos
de
sistema
Gerncia de dispositivos
e Criao e eliminao de processos e

threads
Alterao
das
caractersticas
de
processos e threads
Sincronizao e comunicao entre
processos e threads
Obteno
de
informao
sobre
processos e threads
de
Alocao e desalocao de memria
Criao e eliminao de arquivos e
diretrios
Alterao
das
caractersticas
de
arquivos e diretrios
Abrir e fechar arquivos
Obteno
de
informaes
sobre
arquivos e diretrios
Alocao e desalocao de dispositivos
Operaes
de
entrada/sada
em
dispositivos
Obteno
de
informaes
sobre
dispositivos
Tabela 4.1 Funes das system calls

52
4.4 Modos de Acesso:

Algumas instrues no podem ser colocadas diretamente disposio
das aplicaes, pois sua utilizao indevida poderia ocasionar problemas
integridade do sistema. Por exemplo, uma aplicao que atualize um arquivo
em disco. O programa por si s, no pode especificar diretamente as
instrues que acessam seus dados no disco.
Como o disco um recurso compartilhado, quem gerencia exclusivamente
sua utilizao o SO. Assim se evita que a aplicao acesse qualquer parte
do disco indiscriminadamente, o que poderia comprometer a segurana e
integridade do sistema de arquivos.
Portanto, fica claro que certas instrues s devem ser executadas pelo SO
ou sob sua superviso, impedindo assim riscos de segurana e integridade.
As instrues que possuem o poder de comprometer o sistema so
conhecidas como instrues privilegiadas, enquanto que as no-privilegiadas
no oferecem estes riscos.
Para que uma aplicao no execute uma instruo privilegiada, deve ser
implementado no processador um mecanismo de proteo, conhecido como
modos de acesso. So basicamente dois os modos de acesso implementados
pelo processador. O primeiro o modo usurio, onde a aplicao s poder
executar instrues no-privilegiadas, tendo acesso a um numero reduzido de
instrues. O segundo modo o modo kernel ou supervisor, onde a aplicao
tem acesso ao conjunto total de instrues do processador.
O modo de acesso de uma aplicao determinado por um registrador de
status do processador (chamado de PSW), Dependendo do contedo deste
registrador, o hardware verifica se a instruo pode ou no ser executada
pela aplicao.
Apenas o SO deve ter acesso s instrues privilegiadas. Portanto, se uma
aplicao necessitar executar uma instruo privilegiada, deve solicitar sua
execuo atravs de uma system call. A system call altera o status do PSW
para modo kernel, e ao termino de sua execuo retorna ao modo usurio
(Figura 4.3). Caso uma aplicao tente executar uma instruo privilegiada
em modo usurio, o processador sinaliza um erro, uma exceo ser gerada e
o programa ser interrompido.
No mesmo exemplo do acesso ao disco, para o programa atualizar um
arquivo, a aplicao deve solicitar a operao ao SO por meio de uma system
call, que altera o modo de acesso para kernel. Aps efetuar a atualizao,
retorna-se ao modo usurio.
O mecanismo de modos de acesso tambm uma boa forma de proteger
o prprio ncleo do sistema residente em memria. Por exemplo, se uma
aplicao tivesse acesso rea de memria onde est o SO, um programador
53
mal-intencionado ou um erro de programao poderia ter acessar esta rea e

acabar danificando o sistema. Com os modos de acesso, apenas em modo
kernel poderia se efetuar tal tarefa.
Fig. 4.3 Chamada a uma rotina do sistema
54
4.5 Arquitetura Monoltica:

A arquitetura monoltica pode ser comparada com uma aplicao formada
por vrios mdulos que so compilados separadamente e depois linkados,
formando um grande e nico programa executvel, onde os mdulos podem
interagir livremente. Os primeiros SOs baseavam-se neste modelo, tornando
seu desenvolvimento e sua manuteno bastante difceis. A estrutura
monoltica apresenta simplicidade e bom desempenho, por isso foi usada no
projeto do MS-DOS e nos primeiros sistemas Unix (Figura 4.4).
55
a p li c a o
a p lica o
M o d o u su rio
M o do kern el
S y s te m c a ll
H a rdw a re
Fig. 4.4 Arquitetura monoltica
4.6 Arquitetura de Camadas:

Os sistemas operacionais tornaram-se mais complexos e maiores em
tamanho, por isso, novas tcnicas de programao estruturada e modular
foram incorporadas ao seu projeto. Na arquitetura de camadas, o sistema
dividido em nveis sobrepostos. Cada camada oferece um conjunto de
funes que podem ser utilizadas apenas pelas camadas superiores.
O primeiro SO a usar este conceito, surgiu em 1968 na Holanda e utilizava
seis camadas. Posteriormente, sistemas como MULTICS e OpenVMS tambm
implementaram o conceito de camadas, agora sob forma concntrica (Figura
56
4.5). Neste formato, as camadas mais internas so mais privilegiadas que as

externas.
Fig. 4.5 Arquitetura em camadas do OpenVMS

A vantagem da arquitetura em camadas isolar as funes do SO,
facilitando sua manuteno e depurao, alem de criar uma hierarquia de
nveis de modos de acesso, protegendo as camadas mais internas. Porm,
seu desempenho inferior ao modelo monoltico. Cada nova camada implica
uma mudana no modo de acesso. Por exemplo, no caso do OpenVMS, para
ter acesso aos servios oferecidos pelo kernel preciso passar por trs
camadas ou trs mudanas no modo de acesso.
Atualmente, a maioria dos SOs utiliza o modelo de duas camadas, onde
existem mdulos de acesso usurio (no-privilegiado) e kernel (privilegiado).
A maioria das verses do Unix e do Windows 2000 baseiam-se neste modelo.
4.7 Mquina Virtual:

Um sistema computacional formado por nveis, onde a camada de nvel
mais baixo o hardware. Acima dele, encontramos o SO, que oferece suporte
para as aplicaes, como visto na Figura 4.1. O modelo de mquina virtual, ou
virtual machine (VM), cria um nvel intermedirio entre o hardware e o SO,
denominado gerncia de mquinas virtuais (Figura 4.6). Este nvel cria
diversas maquinas virtuais independentes, onde cada uma oferece uma cpia
virtual do hardware, incluindo os modos de acesso, interrupes, dispositivos
de E/S, etc.
57
Como cada VM independente das demais, possvel que cada uma

tenha seu prprio SO e que seus usurios executem suas aplicaes como se
todo o computador estivesse dedicado a cada um deles, Na dcada de 60, a
IBM implantou este modelo no VM/370, permitindo aplicaes batch,
desenvolvidas em antigos sistemas OS/360 e aplicaes de tempo
compartilhado pudessem conviver na mesma mquina de forma transparente
aos usurios e aplicaes.
VM
VM
VM
Alm de permitir SOs diferentes no mesmo computador, este modelo cria

o isolamento total entre cada VM, oferecendo grande segurana para cada
uma delas. Por exemplo, se uma VM executar uma aplicao que comprometa
o funcionamento de seu SO, as demais VMs no sofrero qualquer problema.
A maior desvantagem desta arquitetura sua complexidade, que necessita
compartilhar e gerenciar os recursos de hardware entre as diversas VMs.
Ap
Ap
Ap
SO
SO
SO
H V
H V
H V
G e r n c i a d e M q u in a s V i r tu a i s
H a rd w a re
Fig. 4.6 Mquina Virtual
Temos outro exemplo desta arquitetura, na linguagem Java, criada pela

Sun Microsystems. Para executar um programa em Java, necessrio uma
mquina virtual Java (ou Java Virtual Machine JVM). Qualquer SO pode
suportar uma aplicao Java, desde que exista uma JVM desenvolvida para
ele. Assim, a aplicao no precisa ser compilada para cada sistema,
tornando-se independente do hardware e SO utilizado (Figura 4.7).
58
A p lic a o
M q u in a V i r tu a l J a v a
S is te m a O p e r a cio n a l
H a rd w a re
Fig. 4.7 Mquina Virtual Java
4.8 Arquitetura Microkernel:

Uma tendncia nos SOs modernos tornar o ncleo do sistema
operacional o menor e mais simples possvel. Para implementar esta idia, os
servios do sistema so disponibilizados atravs de processos, onde cada um
responsvel por oferecer um conjunto especfico de funes, como gerncia
de arquivos, de processos, de memria e escalonamento.
59
Se uma aplicao desejar algum servio, realizada uma solicitao ao

processo responsvel. Neste caso, a aplicao chamada de cliente e o
processo que responde chamado de servidor. A solicitao feita enviandose uma mensagem ao servidor, que responde com outra mensagem. A
principal funo do ncleo realizar esta comunicao entre cliente e
servidor (Figura 4.8).
M o d o u su r io
M o do kernel
M ic r o k e r n e l
H a rd w a re
Fig. 4.8 Arquitetura Microkernel

Este conceito de Arquitetura Microkernel surgiu na dcada de 80, com o
sistema operacional Mach. O ncleo do Mach oferece basicamente quatro
servios: gerncia de processos, gerncia de memria, comunicao por troca
de mensagens e operaes de E/S, todos em modo usurio.
A utilizao deste modelo permite que os servidores executem em

modo usurio, ou seja, no tenham acesso direto a certos componentes do
sistema. Apenas o ncleo do SO, responsvel pela comunicao entre clientes
e servidores, executa no modo kernel. Assim, se um erro ocorrer em um
servidor, este poder parar, mas o sistema no ficar inteiramente
comprometido, aumentando sua disponibilidade (tempo em que est
acessvel).
60
Como os servidores se comunicam atravs de troca de mensagens, no

importa se os clientes e servidores so processados em um sistema com um
processador, com mltiplos processadores (fortemente acoplados) ou ainda
em um ambiente de sistema distribudo (fracamente acoplados). A
implementao de sistemas microkernel em ambientes distribudos permite
que um cliente solicite um servio e a resposta seja processada
remotamente. Isso permite acrescentar novos servidores medida que
aumenta o numero de clientes, conferindo uma grande escalabilidade ao SO.
Outra vantagem que a arquitetura microkernel permite isolar as
funes do sistema operacional por diversos processos servidores pequenos e
dedicados a servios especficos, tornado o ncleo menor, mais fcil de
depurar e, conseqentemente, aumentando sua confiabilidade. Na
arquitetura microkernel, o sistema operacional passa a ser de mais fcil
manuteno, flexvel e de maior portabilidade. Apesar de todas as vantagens
deste modelo, sua implementao, na prtica, muito difcil. Primeiro existe
o problema de desempenho, devido necessidade de mudana de modo de
acesso a cada comunicao entre clientes e servidores. Outro problema que
certas funes do sistema operacional exigem acesso direto ao hardware,
como operaes de E/S.
Na verdade, o que se implanta normalmente a combinao do modelo
de camadas com a arquitetura de microkernel. O ncleo do sistema, alm de
ser responsvel pela comunicao entre cliente e servidor, passa a incorporar
outras funes crticas, como escalonamento, tratamento de interrupes e
gerncia de dispositivos.
4.9 Projeto do Sistema:

O projeto de um SO bastante complexo e deve atender inmeros
requisitos, algumas vezes conflitantes, como confiabilidade, portabilidade e
61
facilidade de manuteno. O projeto ir depender muito da arquitetura do

hardware utilizado e do tipo de sistema que se deseja construir: batch, tempo
compartilhado, mono usurio ou multiusurio, tempo real, etc.
Os primeiros SOs foram desenvolvidos em assembly e seus cdigos
possuam cerca de um milho de instrues (ex.: IBM OS/360). Com a
evoluo dos SOs e conseqentemente o aumento do numero de linhas de
cdigo (cerca de 20 milhes no sistema MULTICS), novas tcnicas de
programao modular foram incorporadas ao projeto, alm do uso de
linguagens de alto nvel, como PL/1 e Algol. Nos SOs atuais, o nmero de
linhas de cdigo chega perto dos 40 milhes (Windows 2000), sendo escrito
grande parte em linguagem C/C++, utilizando em alguns casos, programao
orientada a objetos.
Existe uma srie de vantagens na utilizao de programao por
objetos no projeto e na implementao de sistemas operacionais. Os
principais benefcios so:
-
melhoria na organizao das funes e recursos do sistema;

reduo no tempo de desenvolvimento;
maior facilidade na manuteno e extenso do sistema e
facilidade de implementao do modelo de computao distribuda.
Alm disso, o uso de uma linguagem de alto nvel permite maior

portabilidade, ou seja, o SO pode ser adaptado para outra arquitetura de
hardware. Por outro lado, o uso de linguagens de alto nvel em relao
programao assembly, apresenta perda de desempenho. Por isso, partes
crticas do sistema, como device drivers, o escalonador e as rotinas de
tratamento de interrupes, so ainda desenvolvidas em assembly.
Um princpio fundamental no projeto de SOs a separao no projeto
do sistema das polticas e dos mecanismos. A poltica define o que deve
ser feito, e o mecanismo define como implementar esta poltica.
62
Captulo 5
PROCESSO
5.1 Introduo:
O processo a base para implantao de um SO multiprogramvel. O
processador executa instrues, sem distinguir qual programa se encontra
em execuo. A gerncia de um ambiente multiprogramvel uma funo
exclusiva do SO, que deve controlar a execuo dos diversos programas e o
uso concorrente do processador. Assim, um programa deve estar associado a
um processo.
O termo processo surgiu aps os SOs multiprogramveis, sendo
utilizado no lugar de tarefa ou job, por grande parte da literatura tcnica.
O SO deve controlar os processos. Atravs dos processos, um programa
pode alocar recursos, compartilhar dados, trocar informaes e sincronizar
sua execuo. Nos SOs multiprogramveis, os processos so executados
concorrentemente, compartilhando, entre outros recursos, o uso do
processador, da memria e dos dispositivos de E/S. Em sistemas
multiprocessados, alm da concorrncia de processos pelo uso do
processador, existe tambm a execuo simultnea de processos nos
diferentes processadores.
Aqui abordaremos os principais conceitos relacionados aos processos.
5.2 Estrutura do Processo:
Inicialmente, pode-se entender um processo, como um programa em
execuo, porm, com um conceito mais abrangente. Imaginemos como os
SOs multiprogramveis atendem os diversos usurios e ainda mantm
informaes a respeito dos vrios programas executados ao mesmo tempo.
Em um sistema multiusurio, cada usurio associado a um processo.
Ao executar um programa, o usurio tem a impresso de possuir o
processador e demais recursos exclusivamente para si. Na verdade, o
processador executa o programa de um usurio durante um intervalo de
tempo, e no instante seguinte poder estar executando um outro programa
de outro usurio.
Para que esta troca ocorra sem traumas, necessrio que as
informaes do programa interrompido sejam guardadas, para que no seu
retorno, nada seja perdido. Todas informaes importantes e necessrias
execuo de um programa fazem parte de um processo.
63
Um processo tambm pode ser definido como o ambiente em que o

programa executado. Este ambiente possui informaes sobre a execuo,
de quanto de recursos do sistema cada programa pode utilizar, como espao
de memria, tempo do processador e rea em disco.
A execuo de um mesmo programa pode variar dependendo do
processo no qual ele executado, ou seja, em funo dos recursos
disponveis. A falta de recursos pode impedir um programa de ser executado
com sucesso. Por exemplo, caso um programa precise utilizar uma rea em
disco superior ao seu limite, o SO deve interromper sua execuo por falta de
recursos.
Um processo formado por trs partes, denominadas contexto de
hardware, contexto de software e espao de endereamento, que juntas
mantm todas informaes necessrias execuo de um programa (Figura
5.1).
C o n te x t o d e
S o f tw a r e
C o n te x t o d e
H a rd w a re
Pro g ra m a
E sp a o d e
E n d e r e a m e n to
Fig. 5.1 Estrutura do processo

5.2.1 Contexto de hardware:
O contexto de hardware guarda o contedo dos registradores do
processador. Quando um processo est em execuo, o seu contexto de
hardware est armazenado nos registradores do processador. Quando o
processo perde a utilizao da CPU, o sistema salva as informaes no
contexto de hardware do processo.
64
O
contexto
de
hardware
fundamental
nos
sistemas
multiprogramveis, onde o revezamento da CPU permite que os processos
sejam interrompidos e posteriormente restaurados. A troca de um processo
por outro no processador, executada pelo SO,
chamada de mudana de contexto, e consiste em salvar o contedo dos
registradores do processo que esta saindo e carreg-los com os valores
referentes ao do novo processo que ser executado (Figura 5.2).
5.2.2 Contexto de software:
No contexto de software so especificadas as caractersticas e limites
dos recursos que podem ser alocados pelo processo, como o numero Maximo
de arquivos abertos simultaneamente, prioridade de execuo e tamanho do
buffer dos dispositivos de E/S. Muitas destas caractersticas so determinadas
no momento da criao do processo, enquanto outras podem ser alteradas
posteriormente.
A maior parte das informaes do contexto de software do processo so
provenientes de um arquivo do SO, conhecido como arquivo de contas. Neste
arquivo, gerenciado pelo SO, so especificados os limites dos recursos que
cada processo pode alocar. Outras informaes presentes no contexto de
software so geradas dinamicamente ao longo da execuo dos processos.
65
.
S iste m a O p e r a cio n a l
P ro ce sso A
Pro ce sso B
e x e c u ta n d o
S a lv a r e g is tra d o r e s d o
P ro ce ss o A
C a r r e g a r e g is tr a d o r e s d o
P r o ce ss o B
e x e c u ta n d o
S a lv a r e g is tra d o r e s d o
P r o ce ss o B
C a r r e g a r e g is tr a d o r e s d o
P ro ce ss o A
e x e c u ta n d o
Fig. 5.2 Mudana de contexto

O contexto de software composto por trs grupos de informaes
sobre o respectivo processo: identificao, quotas e privilgios.
Identificao
Cada processo criado pelo sistema recebe uma identificao nica
(chamada de PID Process IDentification), representada por um
nmero e em alguns casos tambm atravs de um nome.
atravs do PID que o SO e outros processos podem fazer
referncia a qualquer processo existente, consultando e at
alterando suas caractersticas.
O processo possui tambm a identificao do usurio ou do
processo que o criou (owner). Cada usurio possui uma
identificao tambm nica no sistema (representada pelo UID
User Identification), que atribuda ao processo no momento de
sua criao. A UID permite implementar modelos de segurana,
onde apenas os objetos (processos, arquivos, reas de memria,
etc) que possuam um UID autorizado, podem ser acessados.
Quotas
66
As quotas so os limites de cada recurso do sistema que um

processo pode alocar. Caso uma quota seja insuficiente, o
processo poder ser executado lentamente, interrompido ou
mesmo no ser executado. Alguns exemplos de quotas presentes
nos SOs modernos:
- nmero mximo de arquivos abertos simultaneamente;
- tamanho mximo de memria principal e secundaria que o
processo pode alocar;
- nmero mximo de operaes de E/S pendentes;
- tamanho mximo do buffer para operaes de E/S;
- numero mximo de processos, subprocessos e threads que
podem ser criados.
Privilgios
Os privilgios ou direitos definem as aes que um processo pode
fazer em ralao a ele mesmo, aos demais processos e ao SO.
Privilgios que afetam o prprio processo permitem que suas
caractersticas possam ser alteradas, como prioridade de
execuo, limites alocados na memria principal e secundaria,
etc. J os privilgios que afetam os demais processos permitem,
alem da alterao de suas prprias caractersticas, alterar as de
outros processos.
Privilgios que afetam o sistema so mais amplos e poderosos,
pois esto relacionados gerncia do ambiente, como a
desativao do sistema, alterao de regras de segurana,
criao de outros processos privilegiados, modificao de
parmetros de configurao do sistema, entre outros. A maioria
dos SOs possui uma conta de acesso com todos privilgios
disponveis, afim de o administrador gerenciar o SO. Nos
sistemas Unix, existe a conta root, no Windows 2000 a conta
administrador e no Open VMS a conta system.
5.2.3 Espao de endereamento:

O espao de endereamento a rea de memria pertencente ao
processo onde as instrues e dados do programa so armazenados para
execuo. Cada processo possui seu prprio espao de endereamento, que
deve ser devidamente protegido do acesso dos demais processos. A Figura
5.3 ilustra as caractersticas da estrutura de um processo.
67
.
nom e
P ID
o w n e r (U ID )
r e g i s tr a d o r e s
g e r a is
p rio r id a d e d e
e xe cu o
d a ta / h o r a
d e cr ia o
r e g i s tr a d o r P C
C o n te x t o d e
S o f tw a r e
C o n te x to d e
H a rd w a re
r e g i s tr a d o r S P
te m p o d e
p ro ce ssa d o r
q u o ta s
Pro gra m a
p r iv il g io s
r e g i s tr a d o r
d e s ta tu s
E sp a o d e
E n d e r e a m e n to
e n d e r e o s d e m e m r ia
p r in c ip a l a lo ca d o s
Fig. 5.3 Caractersticas da estrutura de um processo

5.2.4 Bloco de controle do processo:
O processo implementado pelo SO atravs de uma estrutura de
dados chamada Bloco de controle de processos (Process Control Block PCB).
A partir do PCB, o SO mantm todas as informaes sobre o contexto de
hardware, contexto de software e espao de endereamento de cada
processo (Fig. 5.4).
68
p o n te ir o s
E s ta d o d o p r o c e s s o
N o m e d o p ro ce sso
P r io r id a d e d o p r o c e s s o
R e g i s tr a d o r e s
L i m i te s d e m e m r ia
L i s ta d e a r q u iv o s a b e r to s
..
..
..
..
Fig. 5.4 Bloco de controle do processo (PCB)

5.3 Estados do Processo:
Em um estado multiprogramvel, um processo no deve alocar o
processador com exclusividade, de forma que possa ser compartilhado. Os
processos passam por diferentes estados ao longo de seu processamento, em
funo de eventos gerados pelo SO ou pelo prprio processo. Um processo
ativo pode encontra-se em trs estados diferentes:
Execuo (running) Um processo dito no estado de

execuo quando est sendo processado pela CPU. Em sistemas
com apenas um processador, somente um processo estar sendo
executado em um dado instante. Os processos se alternam na
utilizao do processador, seguindo uma poltica estabelecida
pelo SO. Em sistemas com multi-processadores, existe a
possibilidade de mais de um processo ser executado ao mesmo
tempo, como tambm possvel um mesmo processo ser
executado simultaneamente em mais de um processador
(processamento paralelo).
Pronto (ready) Um processo est no estado de pronto quando

aguarda apenas para ser executado. O SO que determina a ordem
e o critrio pelos quais os processos neste estado devem utilizar o
processador. Este mecanismo conhecido como escalonamento.
Em geral, existem vrios processos no estado de pronto,
organizados em listas encadeadas. Os processos devem estar
ordenados pela sua importncia (Figura 5.5).
69
L i s ta d e
p ro ce sso s
e m e s ta d o
d e p r o n to
.
..
..
..
.
.
..
..
..
.
PCB# 5
PCB# 1
..
..
.
..
.
..
..
.
..
.
L i s ta d e
p ro ce sso s
e m e s ta d o
d e e sp e ra
PCB# 9
PCB# 2
..
..
.
..
.
PCB#4
Fig. 5.5 Lista de PCBs nos estados de pronto e espera.
Espera (wait) Um processo no estado de espera aguarda por

algum evento externo ou por algum recurso para prosseguir seu
processamento. Por exemplo, o trmino de uma operao de E/S
ou a espera de uma data ou hora para continuar sua execuo.
Em alguns SOs, este estado tambm pode ser chamado de
bloqueado (blocked).
O sistema organiza os vrios processos no estado de espera
tambm em listas encadeadas. Em geral os processos so
separados em listas de espera associadas a cada tipo de evento
(Figura 5.5). Neste caso, quando um evento acontece, todos
processos da lista associada ao evento so transferidos para o
estado de pronto.
5.4 Mudanas de Estado de Processo:

Um processo muda de estado durante seu processamento em funo de
eventos originados por ele prprio (eventos voluntrios) ou pelo SO (eventos
involuntrios). Basicamente apenas quatro mudanas de estados podem
ocorrer:
Pronto Execuo Aps a criao de um processo, o sistema

o coloca em uma lista de processos no estado de pronto,
aguardando para ser executado (Figura 5.6 a). Cada SO tem sua
poltica de escalonamento.
Execuo Espera Um processo passa a estado de espera

por eventos gerados pelo prprio processo, como uma operao
de E/S, ou por eventos externos (Figura 5.6 b). Um evento externo
gerado, por exemplo, quando o SO suspende por um perodo de
tempo a execuo de um processo
70
Espera Pronto Ocorre quando uma operao solicitada

atendida ou o recurso esperado concedido. No existe a
mudana de espera para execuo diretamente (Figura 5.6 c).
Execuo Pronto Ocorre atravs de eventos gerados pelo

sistema, como o termino da fatia de tempo que o processo possui
para sua execuo (Figura 5.6 d). Ento, aguarda nova
oportunidade para continuar seu processamento.
Quando no houver espao suficiente para todos os processos na

memria principal, um processo em estado de pronto ou espera pode ser
encontrado na memria secundria. Uma tcnica conhecida como swapping
retira processos da memria principal e os traz de volta segundo seus
prprios critrios. Portanto, os processos em estado de espera e pronto,
podem estar ou no residentes em memria principal (Figura 5.7).
E s ta d o d e E x e c u o
b
a
E s ta d o d e E s p e r a
E s ta d o d e P r o n to
Fig. 5.6 Mudanas de estados do processo
71
E s ta d o d e E x e cu o
r e s i d e n te
n o r e s id e n te
Fig. 5.7 Mudanas de estado do processo (2).
5.5 Criao e Eliminao de Processos:

Processos so criados e eliminados por diversas razes. A criao de
um processo ocorre quando o SO adiciona um novo PCB sua estrutura e
reserva espao na memria para uso. A partir da criao do PCB, o SO j
reconhece a existncia do processo, passando a gerenci-lo e associar
programas ao seu contexto para serem executados. No caso da eliminao de
um processo, todos recursos associados a ele so desalocados e o PCB
eliminado pelo SO.
Alm destes trs processos, a maioria dos SOs estabelece mais dois
estados para os momentos de criao e eliminao de um processo (Figura
5.8).
72
E s ta d o d e E x e c u o
E s ta d o d e T r m i n o
E s ta d o d e C r ia o
Fig. 5.8 Mudanas de estado do processo (3)
Criao (new) Um processo considerado em estado de criao,

quando o SO j criou um novo PCB, porm ainda no pode coloc-lo na
lista de processos do estado de pronto. Alguns SOs limitam o nmero
de processos ativos em funo dos recursos disponveis ou de
desempenho. Esta limitao pode ocasionar que os processos criados
permaneam no estado de criao at que possam passar a ativos.
A criao de processos pode ocorrer por razes como:
- logon interativo: um processo criado atravs do estabelecimento de
uma sesso interativa por um usurio a partir de um terminal.
- criao por um outro processo: um processo j existente pode criar
outros processos, sendo estes novos independentes ou subprocessos.
- criao pelo SO: o SO pode criar novos processos para oferecer algum
servio.
Terminado (exit) Um processo no estado terminado no poder ter

mais nenhum programa executado em seu contexto, porm, o SO ainda
mantm suas informaes de controle na memria. Neste estado, o
processo no mais considerado ativo, mas como o PCB ainda existe, o
SO pode recuperar informaes sobre a contabilizao de uso de
recursos do processo, como o tempo total do processador. Aps a
extrao das informaes, o processo pode deixar de existir.
O trmino de um processo pode ocorrer devido a:
- trmino normal da execuo;
- eliminao por um outro processo;
73
- eliminao forcada por ausncia de recursos disponveis no sistema.
5.6 Processos Independentes, Subprocessos e Threads:

Processos, subprocessos e threads so maneiras diferentes de
implementar a concorrncia dentro de uma aplicao. Neste caso, busca-se
dividir o cdigo em partes para trabalharem de forma cooperativa. Por
exemplo, um banco de dados que recebe consultas constantes e freqentes.
Aqui, a concorrncia na aplicao proporciona um tempo de espera menor
entre consultas, melhorando o desempenho da aplicao e beneficiando os
usurios.
O uso de processos independentes a maneira mais simples de se
implementar a concorrncia em sistemas multiprogramveis. Neste caso, no
existe vnculo entre o processo criado e seu criador. A criao de um processo
independente exige a locao de um PCB, possuindo contextos de hardware,
software e espao de endereamento prprios.
Subprocessos so criados dentro de uma estrutura hierrquica. E neste
caso, o processo criador denominado processo pai e o novo processo
chamado de subprocesso ou processo filho. O subprocesso pode criar outros
subprocessos. Uma caracterstica desta implementao a de criar
dependncia entre processo criador e subprocesso. Se o processo deixar de
existir, tambm os subprocessos o faro. Assim como os processos
independentes, os subprocessos tambm exigem seu prprio PCB. A Figura
5.9 ilustra cinco processos numa estrutura hierrquica, cada qual com seus
contextos e espaos de endereamento. Alm disso, os subprocessos
tambm podem compartilhar quotas com o processo pai. Ou seja, quando o
subprocesso criado, o processo pai cede parte de suas quotas a ele.
O uso de processos independentes e subprocessos demanda consumo
de recursos, uma vez que recursos so alocados toda vez que um processo
criado, e tambm tempo do processador utilizado para este trabalho. Assim
tambm ocorre no seu trmino (desalocao de recursos). Mais ainda, a
comunicao e sincronizao entre processos considerada pouco eficiente,
visto que cada processo possui seu prprio espao de endereamento.
O conceito de thread foi estabelecido com a inteno de reduzir o
tempo gasto na criao, eliminao e troca de contexto de processos nas
aplicaes concorrentes, bem como economizar recursos do sistema como
um todo. Num ambiente multithread, um nico processo pode suportar
mltiplos threads, cada qual associado a uma parte do cdigo da aplicao
(Figura 5.10). Neste caso no necessrio haver diversos processos para
implementao da concorrncia. Threads compartilham o processador da
mesma maneira que um processo, ou seja, enquanto espera por uma
operao de E/S, outro thread pode ser executado.
74
P ro ce sso A
P ro ce sso C
Pro ce sso B
P ro ce sso D
P ro ce sso E
Figura 5.9 Estrutura de Processos e Subprocessos

Cada thread possui seu prprio contexto de hardware, porm
compartilha o mesmo contexto de software e espao de endereamento. O
compartilhamento deste ltimo permite que a comunicao de threads dentro
de um mesmo processo seja feita de forma simples e rpida. Este assunto
ser melhor detalhado no captulo seguinte.
75
C o n te x t o
d e h a rd w a re
C o n te x t o
d e h a rd w a re
Th re a d 1
Th re a d 2
Th rea d 3
C o n te x t o d e
s o f tw a r e
C o n te x to
d e h a rd w a re
E sp a o d e
e n d e r e a m e n to
Fig. 5.10 Processo Multithread

5.7 Processos Foreground e Background:
Um processo possui sempre associado sua estrutura, pelo menos dois
canais de comunicao por onde so realizadas todas as entradas e sadas de
dados ao longo do seu processamento. Os canais de entrada (input) e de
sada (output) de dados podem estar associados a terminais, arquivos,
impressoras e ate mesmo outros processos.
Um processo foreground aquele que permite a comunicao direta do
usurio com o processo durante sua execuo. Assim, ambos os canais esto
associados a um terminal com teclado, mouse e monitor, permitindo
portanto, a interao com o usurio (Figura 5.11a). O processamento
interativo tem com base processos foreground.
Um processo background aquele onde no existe a comunicao com
o usurio durante seu processamento (Figura 5.11b). Aqui, os canais de E/S
no esto associados a nenhum dispositivo de E/S interativo, mas em geral a
arquivos de E/S. O processamento batch, por exemplo, realizado atravs de
processos background.
Quando o canal de sada de um processo estiver associado ao canal de
entrada de outro processo, dizemos que existe um pipe ligando ambos os
processos. Por exemplo, se um processo A gera uma listagem e o processo B
tem como funo orden-la, basta associar o canal de sada do processo A ao
canal de entrada do processo B (Figura 5.12).
76
(a ) P r o c e s s o F o r e g r o u n d
e n tr a d a
s a d a
te r m i n a l
te r m i n a l
(b ) P r o ce s s o B a c k g r o u n d
e n tr a d a
s a d a
a r q u iv o
d e e n tr a d a
a r q u iv o
d e s a d a
Fig. 5.11 Processos foreground e background
s a d a d o
P ro ce sso A
e n tr a d a d o
Pro ce sso A
s a d a d o
Pro ce sso B
e n tr a d a d o
P ro ce sso B
P ro ce sso A
P ro ce ss o B
Figura 5.12 Pipe
5.8 Processos do Sistema Operacional:

O conceito de processo, alm de estar associado a aplicaes de
usurios, podem tambm ser implementados na prpria arquitetura do SO.
Como visto em captulo anterior, a arquitetura microkernel implementa uso
intensivo de processos que disponibilizam servios para processos das
aplicaes e do prprio SO.
77
Quando processos so utilizados para a implementao de servios do

sistema, estamos retirando cdigos de seu ncleo, tornando-o menor e mais
estvel. No caso de um ou mais servios no serem desejados, basta no
ativar os processos responsveis, o que permitir liberar memria para os
processos dos usurios.
Alguns servios que o SO pode implementar atravs de processos so:
auditoria e segurana;
servios de rede;
contabilizao do uso de recursos;
contabilizao de erros;
gerncia de impresso;
gerncia de jobs match;
temporizao;
comunicao de eventos;
interface de comandos.
5.9 Processos CPU-Bound e I/O-Bound:

Os processos podem ser classificados como CPU-Bond ou I/O-Bond, de
acordo com a utilizao do processador e dos dispositivos de E/S.
Um processo definido como CPU-Bound (ligado CPU), quando passa
a maior parte do tempo no estado de execuo, ou seja, utilizando o
processador (Figura 5.13a). Este tipo de processo realiza poucas operaes de
leitura e gravao e encontrado em aplicaes cientficas que efetuam
muitos clculos.
Por outro lado, um processo I/O-Bound (ligado E/S) passa a maior
parte do tempo no estado de espera, pois realiza grande nmero de
operaes de E/S (Figura 5.13b). Aplicaes comerciais, que se baseiam em
leitura, processamento e gravao so exemplos de processos deste tipo,
assim como tambm os processos interativos, pela forma de comunicao
entre o usurio e o sistema, normalmente lenta, devido ao uso de terminais.
78
E/S
E/S
U CP
U CP
(a ) C P U - b o u n d
te m p o
(b ) I/ O - b o u n d
te m p o
Fig. 5.13 Processos CPU-bound x I/O-bound
5.10 Sinais:
Sinais so um mecanismo que permite notificar processos de eventos
gerados pelo sistema operacional ou por outros processos. O uso de sinais
fundamental para a gerncia de processos, alm de possibilitar a
comunicao e sincronizao entre processos.
Por exemplo, ao se teclar simultaneamente as teclas Ctrl e C, para
interromper um programa, o SO gera um sinal ao processo, sinalizando a
ocorrncia do evento. O processo identificando o sinal, uma rotina especial de
tratamento executada (Figura 5.14).
79
in te r r u p o
s in a l
S is te m a O p e r a c i o n a l
[c tr l- C ]
Fig. 5.14 Uso de Sinais
Pro ce sso
Os sinais podem ser usados em conjunto com temporizadores com a

inteno de sinalizar ao processo algum evento associado ao tempo. Por
exemplo, um processo que deve ser avisado periodicamente sobre uma tarefa
a realizar, como monitorar uma fila de pedidos. Aps a realizao da tarefa, o
processo retorna espera do prximo sinal.
A maior parte dos eventos associados a sinais so gerados pelo SO ou
pelo hardware, como as excees, interrupes, limites de quotas excedidos e
alarmes de tempo. Em outros casos, os eventos so gerados a partir de
outros processos com o propsito de sincronizar suas execues.
A gerao de um sinal ocorre quando o SO, a partir da ocorrncia de
eventos sncronos ou assncronos, notifica o processo atravs de bits de
sinalizao localizados no seu PCB. Um processo no responde
instantaneamente a um sinal. Os sinais ficam pendentes at que o processo
seja escalonado, quando ento sero tratados. Por exemplo, na eliminao de
um processo, o sistema ativa o bit associado a este evento. O processo s
ser excludo do sistema quando for selecionado para execuo. Assim,
possvel que o processo demore algum tempo at ser eliminado de fato.
O tratamento de um sinal bem semelhante ao de uma interrupo.
Quando um sinal tratado, o contexto do processo salvo e a execuo
desviada para um cdigo de tratamento de sinal (signal handler), geralmente
no ncleo do SO. Aps a execuo do
tratador de sinais, o programa pode voltar a ser processado do ponto onde foi
interrompido. s vezes, o prprio processo pode tratar o sinal atravs de um
tradutor de sinais definido no cdigo do programa. possvel tambm que
um processo bloqueie temporariamente ou ignore por completo alguns sinais.
Apesar do mecanismo ser parecido com o do tratamento de
interrupes e excees, os propsitos so diferentes. O sinal est para o
processo assim como as interrupes e excees esto para o sistema
operacional (Figura 5.15)
80
P ro ce sso
P ro ce sso
S in a i s
I n te r r u p e s
E xce e s
H a rdw a re
Fig. 5.15 Sinais, interrupes e excees.
81
Captulo 6
THREAD
6.1 Introduo:
At o final dos anos 70, os SOs suportavam processos com apenas um
thread (monothread), ou seja, um processo com apenas um programa
fazendo parte de seu contexto. Em 1979, introduziu-se o conceito de
processos ligthweight (peso leve), onde o espao de endereamento de um
processo era compartilhado por vrios programas. Porm, esta idia no foi
utilizada comercialmente, e apenas na metade da dcada de 80, com o SO
Mach, ficou clara a separao entre os conceitos de processo e thread.
Com o conceito de mltiplos threads (multithread), pode-se projetar
aplicaes concorrentes de forma eficiente, pois um processo pode ter
diferentes partes de seu cdigo sendo executadas em paralelo. Como os
threads de um mesmo processo compartilham o mesmo espao de
endereamento, a comunicao entre threads no envolve mecanismos
lentos de intercomunicao entre processos, aumentando assim o
desempenho da comunicao.
O desenvolvimento de programas que exploram os benefcios da
programao multithread no simples. A presena do paralelismo introduz
um novo conjunto de problemas, como a comunicao e sincronizao de
threads. Existem diferentes modelos para a implementao de threads em
um SO, onde desempenho, flexibilidade e custos devem ser avaliados.
Atualmente, o conceito de multithread pode ser encontrado em
sistemas como Sun Solaris e Windows 2000. A utilizao comercial de
sistemas multithreads tem crescido devido ao aumento de popularidade de
sistemas com multiprocessadores, do modelo cliente-servidor w dos sistemas
distribudos.
6.2 Ambiente Monothread:
Um programa uma seqncia de instrues, compostas de desvios,
repeties e chamadas a procedimentos e funes. Em um ambiente
monothread, um processo suporta apenas um programa em seu espao de
endereamento. Neste ambiente, aplicaes concorrentes so implementadas
apenas com o uso de mltiplos processos independentes ou subprocessos.
O uso de processos independentes e subprocessos permite dividir uma
aplicao em partes que podem trabalhar de forma concorrente. Por exemplo,
um usurio pode estar lendo seus e-mails antigos, ao mesmo tempo em que
estaria enviando e recebendo e-mails atuais. Co o uso de mltiplos processos,
cada funcionalidade do software implicaria na criao de um novo processo
para atend-lo, aumentando o desempenho da aplicao (Figura 6.1).
82
Um problema que o uso de processos no desenvolvimento de

aplicaes concorrentes demanda consumo de diversos recursos do sistema.
Sempre que um novo processo criado, o sistema deve alocar recursos para
cada processo, consumindo tempo de processador neste trabalho. No caso do
trmino do processo, o sistema dispensa tempo para desalocar recursos
previamente alocados.
Outro problema a ser considerado quanto ao compartilhamento do
espao de endereamento. Como cada processo possui seu prprio espao de
endereamento, a comunicao entre processos torna-se difcil e lenta, pois
utiliza mecanismos como pipes, sinais, semforos, memria compartilhada ou
troca de mensagem. Alm disso, o compartilhamento de recursos comuns
aos processos concorrentes, como memria e arquivos abertos, no
simples. Na Figura 6.2 existem trs processos monothread, cada um com seu
prprio contexto de hardware, de software e espao de endereamento.
Su b p ro cesso s
P r o c e s s o s I n d e p e n d e n te s
Fig. 6.1 Concorrncia com subprocessos e processos independentes

So exemplos de sistemas monothread o MS-DOS e as primeiras
verses do Windows. Mesmo em ambientes multiprogramveis e
multiusurios, encontra-se exemplos de implementaes monothread, como
nas verses mais antigas dos sistemas VAX/VMS e Unix.
T h re a d
Th re a d
Th re a d
83
Fig. 6.2 Ambiente monothread

6.3 Ambiente Multithread:
Em um ambiente multithread, ou seja, com mltiplos threads, no
existe a idia de programas associados a processos, mas sim a threads. O
processo, neste ambiente, tem pelo menos um thread em execuo, mas
pode compartilhar o seu espao de endereamento com inmeros outros
threads. Na Figura 6.3 existe apenas um processo com trs threads de
execuo compartilhando o mesmo espao de endereamento.
C o n te x to
d e h a rd w a re
C o n te x t o
d e h a rd w a re
Th re a d 1
Th re a d 2
T h re a d 3
C o n te x to d e
s o f tw a r e
C o n te x to
d e h a rd w a re
Esp a o d e
Fig. 6.3 Ambiente Multithread

De forma simplificada, um thread pode ser definido como uma subrotina de um programa que pode ser executada de forma assncrona, ou seja,
executada paralelamente ao programa chamador. O programador deve
especificar os threads, associando-os s sub-rotinas assncronas. Assim, um
ambiente multithread possibilita a execuo concorrente de sub-rotinas
dentro de um mesmo processo.
Na Figura 6.4 existe um programa principal que realiza a chamada de
suas sub-rotinas assncronas (Sub_1 e Sub_2). Inicialmente, o processo
criado apenas com o Thread_0 para a execuo do programa principal.
Quando o programa principal chama as duas sub-rotinas, so criados os
84
Thread_1 e Thread_2, e executados independentemente do programa

principal. Neste processo, os trs threads so executados concorrentemente.
No ambiente multithread, cada processo pode responder a varias

solicitaes concorrentemente ou mesmo simultaneamente, caso haja mais
de um processador. A grande vantagem no uso de threads a possibilidade
de minimizar a alocao de recursos do sistema, alem de diminuir o overhead
na criao, troca e eliminao de processos.
Threads compartilham o processador da mesma maneira que processos
e passam pelas mesmas mudanas de estado (execuo, espera e pronto).
Por exemplo, enquanto um thread espera por uma operao de E/S, outro
thread pode ser executado. Para permitir a troca de contexto entre os
diversos threads, cada um possui seu prprio contexto de hardware, com o
contedo dos registradores gerais, PC e SP. Quando um thread est sendo
executado, seu contexto hardware est armazenado nos registradores do
processador. No momento em que o thread perde a utilizao do processador,
as informaes so atualizadas no seu contexto de hardware.
85
.
P r o ce ss o
V a r i v e is
P r o g r a m a P r in c ip a l
T h re a d _ 1
PC
SP
C a ll Su b _ 1
C o n te x to d e
H a rd w a re
...
E sp a o d e
T h re a d _ 2
Sub_1
Ret
PC
SP
T h re a d _ 3
Sub_2
PC
SP
C o n te x to d e
H a rd w a re
F im
C o n te x to d e
H a rd w a re
C a ll Su b _ 2
...
Ret
Fig. 6.4 Aplicao Multithread (a)

Dentro de um mesmo processo, threads compartilham o mesmo
contexto de software e espao de endereamento com os demais threads,
porm cada thread possui seu contexto de hardware individual. Threads so
implementados internamente atravs de uma estrutura de dados
denominada bloco de controle do thread (Thread Control Block TCB). O TCB
armazena, alm do contexto de hardware, mais algumas informaes
relacionadas exclusivamente ao thread, como prioridade, estado de execuo
e bits de estado.
Em ambientes monothread, o processo ao mesmo tempo a unidade
de alocao de recursos e a unidade de escalonamento. A independncia
entre os conceitos de processo e thread permite separar a unidade de
alocao de recursos da unidade de escalonamento, que em ambientes
monothread esto fortemente relacionadas. Em um ambiente multithread, a
unidade de alocao de recursos o processo, onde todos os seus threads
compartilham o espao de endereamento, descritores de arquivos de
86
dispositivos de E/S. Por outro lado, cada thread representa uma unidade de
escalonamento independente. Neste caso, o sistema no seleciona um
processo para a execuo, mas sim um de seus threads.
A grande diferena entre aplicaes mono e multithread est no uso do
espao de endereamento. Processos independentes e subprocessos
possuem espaos de endereamento individuais e protegidos, enquanto
threads compartilham o espao dentro de um mesmo processo. Isso permite
que o compartilhamento de dados entre threads de um mesmo processo seja
mais simples e rpido, se comparado a ambientes monothreads.
Como threads de um mesmo processo compartilham o mesmo espao
de endereamento, no existe qualquer proteo no acesso memria,
permitindo que um thread possa alterar facilmente dados de outros. Para que
os threads trabalhem de forma cooperativa, fundamental que a aplicao
implemente mecanismos de comunicao e sincronizao entre threads, a
fim de garantir o acesso seguro aos dados compartilhados na memria.
O uso de multithreads proporciona uma serie de benefcios. Programas
concorrentes com mltiplos threads so mais rpidos do que programas
concorrentes implementados com mltiplos processos, pois operaes de
criao, troca de contexto e eliminao dos threads geram menor overhead
(Tabela 6.1). Como os threads dentro de um processo dividem o mesmo
espao de endereamento, a comunicao entre eles pode ser realizada de
forma rpida e eficiente. Alm disso, threads em um mesmo processo podem
compartilhar facilmente outros recursos, como descritores de arquivos,
temporizadores, sinais, atributos de segurana, etc.
Implementao
Processo
Processo
Lightweight
Thread
Tempo de criao
(s)
1700
350
Tempo de sincronizao
(s)
200
390
52
66
Tabela 6.1 Latncia de Processos e Threads

A utilizao do processador, dos discos e outros perifricos pode ser
feita de forma concorrente pelos diversos threads, significando melhor
utilizao dos recursos computacionais disponveis. Em algumas aplicaes, a
utilizao de threads pode melhorar o desempenho da aplicao apenas
executando tarefas em background enquanto operaes E/S esto sendo
processadas (Figura 6.5). Aplicaes como editores de texto, planilhas,
87
aplicativos grficos e processadores de imagem so

beneficiados quando desenvolvidos com base em threads.
especialmente
Em ambientes cliente-servidor, threads so essenciais para solicitao

de servios remotos. Em um ambiente monothread, se uma aplicao solicita
um servio remoto, ela pode ficar esperando indefinidamente, enquanto
aguarda pelo resultado. Em um ambiente multithread, um thread pode
solicitar o servio remoto, enquanto a aplicao pode continuar realizando
outras atividades. J para o processo que atende a solicitao, mltiplos
threads permitem que diversos pedidos sejam atendidos simultaneamente
(Figura 6.6).
Th re a d d e
e n tr a d a
B u ff e r
T h re a d d e
e xib i o
T h re a d d e
g ra v a o
Fig. 6.5 Aplicao Multithread (b)
88
P r o ce ss o se rvid o r
S o l i c i ta e s
Th re a d
T h re a d
Th re a d
P r o ce s s o c lie n te
P r o c e s s o c lie n te
P r o c e s s o c lie n te
Fig. 6.6 Aplicao multithread (c)

No apenas aplicaes tradicionais podem fazer uso dos benefcios do
multithreading. O ncleo do SO tambm pode ser implementado com o uso
desta tcnica de forma vantajosa, como na arquitetura microkernel,
apresentada em captulo anterior.
6.4 Arquitetura e Implementao:

89
O conjunto de rotinas disponveis para que uma aplicao utilize as

facilidades dos threads chamado de pacote de threads. Existem diferentes
abordagens na implementao deste pacote em um SO, o que influenciar no
desempenho, na concorrncia e na modularidade das aplicaes multithread.
Threads podem ser oferecidos por uma biblioteca de rotinas fora do
ncleo do SO (modo usurio), pelo prprio ncleo do sistema (modo kernel),
por uma combinao de ambos (modo hbrido) ou por um modelo conhecido
como scheduler activations. A Tabela 6.2 resume as diversas arquiteturas
para diferentes ambientes operacionais.
Ambientes
Distributed Computing Environment
(DCE)
Compaq Open VMS verso 6
MS Windows 2000
Compaq Unix
Compaq Open VMS verso 7
Sun Solaris verso 2
University of Washington FastThreads
Arquitetura
Modo Usurio
Modo Usurio
Modo Kernel
Modo Kernel
Modo Kernel
Modo Hbrido
Scheduler Activations
Tabela 6.2 Arquitetura de threads para diversos ambientes operacionais

Uma das grandes dificuldades para a utilizao de threads foi a
ausncia de um padro. Em 1995, o padro POSIX P1003.1c foi aprovado e
posteriormente atualizado para a verso POSIX 1003.4 a. Com este padro,
tambm conhecido como Pthreads, aplicaes comerciais multithreading
tornaram-se mais simples e de fcil implementao. O padro Pthreads
largamente utilizado em ambientes Unix, como o Sun Solaris Pthreads e o
DECthreads para Digital OSF/1.
6.4.1 Threads em Modo Usurio:
Threads em modo usurio (TMU) so implementados pela aplicao e
no pelo SO. Para isso, deve existir uma biblioteca de rotinas que possibilite a
aplicao realizar tarefas como criao/eliminao de threads, troca de
mensagens entre threads e uma poltica de escalonamento. Neste modo, o
SO no sabe da existncia de mltiplos threads, sendo responsabilidade
exclusiva da aplicao gerenciar e sincronizar os diversos threads existentes.
A vantagem deste modelo a possibilidade de implementar aplicaes
multithreads mesmo em SOs que no suportem threads. Utilizando biblioteca,
mltiplos threads podem ser criados, compartilhando o mesmo espao de
endereamento do processo, alm de outros recursos (Figura 6.7). TMU so
rpidos e eficientes por dispensarem acessos ao kernel do SO, evitando assim
a mudana de modo de acesso (usurio-kernel-usurio).
90
Th re a d 4
Th re a d 3
Th re a d 2
Th rea d 1
Th re a d 0
Os TMU possuem uma grande limitao, pois o SO gerencia cada

processo como se existisse apenas um thread. Quando o thread chama uma
rotina do sistema que o coloca em estado de espera (rotina bloqueante), todo
o processo colocado no estado de espera, mesmo havendo outros threads
prontos para execuo. Para contornar esta limitao, a biblioteca tem que
possuir rotinas que substituam as rotinas bloqueantes por outras que no
possam causar o bloqueio de um thread (rotinas no-bloqueantes). Todo este
controle transparente para o usurio e para o SO.
M odo
u su rio
B ib lio te c a
K ern el
M odo
k ern el
Figura 6.7 Threads em modo usurio

Talvez um dos maiores problemas na implementao de TMU seja o
tratamento individual de sinais. Como o sistema reconhece apenas processos
e no threads, os sinais enviados para um processo devem ser reconhecidos
e encaminhados a cada thread para tratamento. No caso do recebimento de
interrupes de clock, fundamental para implementao do tempo
compartilhado, esta limitao crtica. Neste caso, os sinais de temporizao
devem ser interceptados, para que se possa interromper o thread em
execuo e realizar a troca de contexto.
Em relao ao escalonamento em ambientes com mltiplos
processadores, no possvel que mltiplos threads de um processo possam
ser executados em diferentes processadores simultaneamente, pois o sistema
seleciona apenas processos para execuo e no threads. Esta restrio
limita drasticamente o grau de paralelismo da aplicao, j que os threads de
um mesmo processo podem ser executados em somente um processador de
cada vez.
91
6.4.2 Threads em Modo Kernel:

Threads em Modo Kernel (TMK) so implementados diretamente pelo
ncleo do SO, atravs de chamadas a rotinas do sistema que oferecem todas
as funes de gerenciamento e sincronizao (Fig. 6.8). O S.O. sabe da
existncia de cada thread e pode escalon-los individualmente. No caso de
mltiplos processadores, os threads de um mesmo processo podem ser
executados simultaneamente.
Th re a d 4
Th re a d 3
Th re a d 2
Th rea d 1
Th re a d 0
O grande problema para pacotes em modo kernel o seu baixo

desempenho. Enquanto nos pacotes em modo usurio todo tratamento feito
sem ajuda do SO, ou seja, sem a mudana do modo de acesso (usuriokernel-usurio), pacotes em modo kernel utilizam chamadas a rotinas do
sistema e, conseqentemente, vrias mudanas no modo de acesso. A Tabela
6.3 compara o desempenho de duas operaes distintas envolvendo a
criao, escalonamento, execuo e eliminao de um processo/thread.
M odo
u su rio
B ib lio te c a
M odo
k ern el
K ern el
Figura 6.8 Threads em Modo Kernel
Implementao
Subprocessos
Threads em Modo
Kernel
Threads em Modo
Usurio
Operao 1 (s)
11.300
948
Operao 2 (s)
1.840
441
34
37
Tabela 6.3 Comparao entre tempos de latncia

92
6.4.3 Threads em Modo Hbrido:

A arquitetura de threads em modo hbrido combina as vantagens de
threads implementados em modo usurio (TMU) e threads em modo kernel
(TMK). Um processo pode ter vrios TMKs, e por sua vez, um TMK pode ter
vrios TMUs. O ncleo do SO reconhece os TMKs e pode escalon-los
individualmente. Um TMU pode ser executado em um TMK, em um
determinado momento, e no instante seguinte ser executado em outro.
O programador desenvolve a aplicao em termos de TMU e especifica
quantos TMK esto associados ao processo. Os TMUs so mapeados em TMK
enquanto o processo est sendo executado. O programador pode utilizar
apenas TMK, TMU ou uma combinao de ambos (Figura 6.9).
TM U 5
TM U 4
TM U 3
TM U 2
TM U 1
TM U 0
O modo hbrido, apesar de maior flexibilidade, apresenta problemas

herdados de ambas as implementaes. Por exemplo, quando um TMK realiza
uma chamada bloqueante, todos os TMUs so colocados no estado de espera.
TMUs que desejam utilizar vrios processos deve utilizar diferentes TMKs, o
que influenciar no desempenho.
M odo
u su rio
B ib lio te ca
TM K 0
TM K 1
TM K 2
TM K 3
M odo
k ern el
K ern el
Figura 6.9 Threads em modo hbrido

93
6.4.4 Scheduler Activations:

Os problemas apresentados no pacote de threads em modo hbrido
existem devido falta de comunicao entre threads em modo usurio e em
modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em
modo kernel com o desempenho e flexibilidade do modo usurio.
Introduzido no incio dos anos 90, este pacote combina o melhor das
duas arquiteturas, mas em vez de dividir os threads em modo usurio entre
os de modo kernel, o ncleo do sistema troca informaes com a biblioteca
de threads utilizando uma estrutura de dados chamada scheduler activations
(Figura 6.10).
Thread 4
Thread 3
Th re a d 2
Th re a d 1
Thread 0
A maneira de alcanar um melhor desempenho evitar as mudanas

de modos de acesso desnecessrias (usurio-kernel-usurio). Caso um thread
utilize uma chamada ao sistema que o coloque no estado de espera, no
necessrio que o kernel seja ativado, bastando que a prpria biblioteca em
modo usurio escalone outro thread. Isto possvel porque a biblioteca em
modo usurio e o kernel se comunicam e trabalham de forma cooperativa.
Cada camada implementa seu escalonamento de forma independente, porem
trocando informaes quando necessrio.
M odo
u su rio
B ib lio te c a
K e rn el
M odo
k ern el
Figura 6.10 Scheduler activations

94
6.5 Modelos de Programao:

O desenvolvimento de aplicaes multithread no simples, pois exige
que a comunicao e o compartilhamento de recursos entre os diversos
threads seja feito de forma sincronizada para evitar problemas de
inconsistncias
e
deadlock.
Alm
das
dificuldades
naturais
no
desenvolvimento de aplicaes concorrentes, o procedimento de depurao
bastante complexo.
Um fator importante em aplicaes multithread o numero total de
threads e a forma como so criados e eliminados. Se uma aplicao cria um
numero excessivo de threads, poder ocorrer um overhead no sistema,
ocasionando uma queda de desempenho.
Dependendo da implementao, a definio do numero de threads pode
ser dinmica ou esttica. Quando a criao/eliminao dinmica, os threads
so criados/eliminados conforme a demanda da aplicao, oferecendo grande
flexibilidade. J em ambientes estticos, o nmero de threads definido na
criao do processo onde a aplicao ser executada.
Para obter os benefcios do uso de threads, uma aplicao deve permitir
que partes diferentes de seu cdigo sejam executadas em paralelo de forma
independente. Se um aplicativo realiza vrias operaes de E/S e trata
eventos assncronos, a programao multithread aumenta seu desempenho
at mesmo em ambientes com um fraco processador. Sistemas gerenciadores
de banco de dados (SGBDs), servidores de arquivo ou impresso so
exemplos onde o uso de mltiplos threads proporciona grandes vantagens e
benefcios.
95
Captulo 7
Sincronizao e Comunicao entre processos
7.1 Introduo:
Com o surgimento dos SOs multiprogramveis, tornou-se possvel
estruturar aplicaes de maneira que partes diferentes do cdigo do
programa pudessem ser executadas concorrentemente. Este tipo de
aplicao foi denominada de aplicao concorrente.
Em sistemas com um nico processador, os processos alternam sua
execuo segundo escalonamento estabelecido pelo SO e mesmo assim
aplicaes concorrentes obtm melhoras em seu desempenho. Em sistemas
com mltiplos processadores, estendem-se estas vantagens com a
possibilidade do paralelismo na execuo de instrues.
Os processos de uma aplicao concorrente podem compartilhar
recursos, como arquivos registros, dispositivos de E/S e reas de memria.
Este compartilhamento pode gerar situaes indesejveis, capazes de
comprometer a execuo das aplicaes. Para evitar este tipo de problema,
os processos devem ter suas aes sincronizadas, atravs de mecanismos
oferecidos pelo SO.
7.2 Aplicaes Concorrentes:
Em aplicaes concorrentes, pode ser necessrio que os processos
comuniquem-se entre si. Esta comunicao pode ser implementada atravs
de variveis compartilhadas na memria principal ou trocas de mensagens.
Mais uma vez, necessrio que haja sincronizao entre a execuo dos
processos concorrentes.
A figura 7.1 apresenta um exemplo onde dois processos concorrentes
compartilham um buffer para troca de informaes. Aqui, um processo s
poder gravar dados no buffer se ele estiver vazio, e s poder ler um dado
do buffer caso haja um dado a ser lido. Em ambos os casos, os processos
devero esperar at que o buffer esteja pronto para as operaes de
gravao e leitura.
S in c r o n iz a o
P ro ce sso
g ra va d o r
P ro ce ss o
l e i to r
dado
B u ff e r
96
Figura 7.1 Sincronizao e Comunicao entre processos

Os mecanismos que realizam a comunicao entre processos
concorrentes e o acesso a recursos compartilhados so chamados de
mecanismos de sincronizao. Em SOs multiprogramveis estes mecanismos
so fundamentais para garantir a integridade e confiabilidade na execuo de
aplicaes concorrentes.
7.3 Especificao de Concorrncia em Programas:
Existem varias notaes para especificar quais partes de um programa
que devem ser executadas concorrentemente. Tcnicas mais recentes tentam
expressar a concorrncia no cdigo dos programas de uma forma mais clara e
estruturada.
As primeiras notaes para especificar uma concorrncia em um
programa foram os comandos FORK e JOIN. O exemplo abaixo exemplifica de
forma simplificada este uso.
PROGRAMA A;
.
.
FORK B;
.
.
JOIN B;
.
.
END.
PROGRAMA B;
.
.
.
.
.
END.
O Programa A comea a ser executado e, ao encontrar o comando

FORK, faz com que seja criado um outro processo para execuo do Programa
B, concorrentemente ao Programa A. O comando JOIN faz com que o
Programa A sincronize-se com o B, ou seja, o Programa A s continuar a ser
executado aps o trmino da execuo de B. Os comandos FORK e JOIN so
poderosos e prticos, sendo utilizados de forma semelhante no Sistema Unix.
Outra forma mais clara e simples de expressar concorrncia em um
programa com o uso dos comandos PARBEGIN e PAREND (1965), que
posteriormente foram chamados de COBEGIN e COEND. Aqui continuaremos a
utilizar os comandos PARBEGIN e PAREND.
A figura 7.2 demonstra o uso dos comandos PARBEGIN e PAREND.
97
P ro ce sso
p rin cip a l
PARBEGIN
Comando_1;
Comando_2;
.
.
Comando_n;
PAREND
Pro ce sso 1
P ro ce sso 2
P ro ce ss o n
P ro ce sso
p rin cip a l
Figura 7.2 Concorrncia em programas

Para exemplificar o uso destes comandos, o programa chamado
EXPRESSAO realiza um clculo do valor da expresso descrita a seguir:
X := SQRT (1024) + (35.4 * 0.23) (302 / 7)
Os comandos situados entre PARBEGIN e PAREND so executados
concorrentemente. O clculo final de X s poder ser realizado quando todas
as variveis dentro da estrutura estiverem sido calculadas.
PROGRAM Expressao;
VAR X, Temp1, Temp2, Temp3 : REAL;
BEGIN
PARBEGIN
Temp1 := SQRT (1024);
Temp2 := 35.4 * 0.23;
Temp3 := 302 / 7;
PAREND;
X := Temp1 + Temp2 - Temp3;
98
WRITELN ('x = ', X);

END.
7.4 Problemas de Compartilhamento de Recursos:
Para melhor compreenso da importncia da sincronizao entre
processos concorrentes, so apresentados alguns exemplos-problema de
compartilhamento de recursos.
O primeiro problema analisado a partir do programa Conta_Corrente,
que atualiza o saldo bancrio de um cliente aps o lanamento de dbito ou
crdito no arquivo de contas-correntes Arq_Contas. Neste arquivo so
armazenados os saldos de todos os correntistas do banco. O programa l o
registro do cliente no arquivo (Reg_Cliente), l o valor a ser depositado ou
retirado (Valor_Dep_Ret) e, em seguida atualiza o saldo no arquivo de contas.
PROGRAM Conta_Corrente;
.
.
READ (Arq_Contas, Reg_Cliente);
READLN (Valor_Dep_Ret);
Reg_Cliente.Saldo :=
Reg_Cliente.Saldo + Valor_Dep_Ret;
WRITE (Arq_Contas, Reg_Cliente);
.
.
END.
Considerando processos concorrentes pertencentes a dois funcionrios
do banco que atualizam o saldo de um mesmo cliente simultaneamente, a
situao de compartilhamento do recurso pode ser analisada. O processo do
primeiro funcionrio (Caixa 1) l o registro do cliente e soma ao campo Saldo
o valor do lanamento de dbito. Antes de gravar o novo saldo no arquivo, o
processo do segundo funcionrio (Caixa 2) l o registro do mesmo cliente,
que est sendo atualizado, para realizar outro lanamento, desta vez de
crdito. Independente de qual processo atualize primeiro o saldo no arquivo,
o dado gravado estar inconsistente. Acompanhe:
Caixa
1
1
1
2
2
2
1
2
Comando
READ
READLN
:=
READ
READLN
:=
WRITE
WRITE
Saldo Arquivo
1.000
1.000
1.000
1.000
1.000
1.000
800
1.300
Valor Dep/Ret
*
-200
-200
*
+300
+300
-200
+300
Saldo Memria
1.000
1.000
800
1.000
1.000
1.300
800
1.300
99
Outro exemplo simples a situao onde dois processos (A e B)

executam um comando de atribuio. O processo A soma 1 varivel X e o
processo B subtrai 1 da mesma varivel. Suponha que inicialmente a varivel
X possua o valor 2.
Processo A
X: = X + 1 ;
Processo B
X: = X 1;
Seria razovel pensar que no final das operaes a varivel continuasse

valendo 2, porem nem sempre isso ser verdade. Decompondo em operaes
mais elementares, usando uma linguagem de alto nvel, temos:
Processo A
Load x, Ra
Add 1,Ra
Store Ra,x
Processo B
Load x, Rb
Sub 1,Rb
Store Rb,x
Considere que o Processo A carregue o valor de X no Registrador Ra,

some 1, e no momento em que vai armazenar o novo valor de X, seja
interrompido. Neste instante, inicia-se o Processo B, que carrega o valor de X
em Rb e subtrai o valor 1. Agora o Processo B interrompido e o A volta a ser
executado, atribuindo o valor 3 varivel X e finalizando sua execuo. O
Processo B retorna sua execuo, atribui o valor 1 a X e sobrepe o valor
anteriormente gravado pelo Processo O resultado final ser inconsistente.
Resumindo:
Processo
A
A
B
B
A
B
Comando
Load X,Ra
Add 1,Ra
Load X,Rb
Sub 1,Rb
Store Ra,X
Store Rb,X
X
2
2
2
2
3
1
Ra
2
3
*
*
3
*
Rb
*
*
2
1
*
1
Atravs destes exemplos, conclui-se que quando dois ou mais processos

compartilham um mesmo recurso, alguns mecanismos devem evitar que este
tipo de problema ocorra (conhecidos como race conditions condies de
corrida).
100
7.5 Excluso Mtua:

Para que sejam evitados problemas desta natureza, onde dois
processos manipulem o mesmo arquivo ou a mesma varivel de memria
simultaneamente, enquanto um processo estiver acessando determinado
recurso, todos os outros que queiram acessar esse mesmo recurso devero
esperar. Isso se chama EXCLUSO MUTUA (Mutual Exclusion).
A excluso mtua dever agir apenas sobre os processos que esto
concorrendo em um determinado recurso. Quando desenvolvemos um
programa, que faa tratamento de excluso mtua, este dever ter uma
seo chamada REGIO CRTICA (Critical Region). Nesta regio existe uma
srie de procedimentos e protocolos que o programa dever fazer para que o
sistema operacional libere o recurso para o mesmo. Toda vez que um
processo desejar executar instrues de sua regio crtica, obrigatoriamente
devera executar antes um protocolo de entrada nessa regio. Da mesma
forma, ao sair da regio crtica um protocolo de sada dever ser executado. A
regio critica deve ser sempre usada quando seu programa for fazer uso de
recursos que so passiveis de compartilhamento com algum outro suposto
programa na memria. nela tambm que os processos encontram-se em
um momento mais critico, pois qualquer erro ocorrido ali dentro pode fazer
com que dois ou mais processos colidam gerando falhas e derrubando o
sistema.
Assim, para garantir a implementao da excluso mtua, os processos
envolvidos devem fazer acesso aos recursos de forma sincronizada. Diversas
solues foram criadas com este propsito; porm, ainda existem duas
situaes que devem ser evitadas.
7.5.A
Starvation:
A primeira situao indesejada conhecida como starvation (ou

espera indefinida).
Quem determina as prioridades dos processos o sistema operacional.
Neste caso existem duas formas do sistema operacional determinar qual ser
a vez de quem. Ou por escolha aleatria ou por prioridades. Quando a
escolha aleatria, existir a probabilidade de um processo nunca ser
escolhido. Quando for uma escolha por prioridades, um processo de menor
prioridade nunca receber o acesso ao recurso, e ai este processo nunca
executar sua rotina.
Uma soluo bastante simples a criao de filas de pedidos de
alocao para cada recurso, utilizando o esquema FIFO (First In First Out).
Sempre que um processo solicita um recurso, o pedido colocado no final da
fila associada ao recurso. Quando o recurso liberado, o sistema seleciona o
primeiro processo da fila.
101
7.5.B
Sincronizao condicional:
Sincronizao Condicional uma situao onde o acesso a um recurso

compartilhado exige a sincronizao de processos vinculada a uma condio
de acesso.
Quando um recurso no est pronto para ser utilizado, o processo que
vai acessar o recurso ficar em estado de espera at que o mesmo esteja
pronto. Existe o risco deste recurso nunca ficar pronto por j estar com
problemas. Ai todo o sistema fica esperando o recurso resolver sua vida. Um
exemplo disto o caso do uso de Buffers para leitura e gravao de dados
feita pelos processos. Uma possvel falha na memria que impea o acesso
aos buffers e todo o sistema estar parado...
Diversas solues foram propostas para garantir a excluso mtua de
processos concorrentes. A seguir, algumas solues de hardware e software
sero apresentadas, com comentrios sobre suas vantagens e desvantagens.
7.5.1 Solues de Hardware:
Desabilitao de interrupes
Faz com que o processo, antes de entrar em sua regio crtica desabilite
todas as interrupes externas e a reabilite aps deixar a regio critica. Como
a mudana de contexto de processos s pode ser realizada atravs de
interrupes, o processo que as desabilitou ter acesso exclusivo garantido.
Apesar de simples, esta soluo apresenta limitaes. Primeiramente, a
multiprogramao fica comprometida, uma vez a concorrncia entre
processos entre processos tem como base o uso da interrupo. Um caso
mais grave poderia ocorrer caso um processo desabilitasse as interrupes e
no tornasse a habilit-las. Neste caso, o sistema provavelmente teria seu
funcionamento comprometido.
Em sistemas com mltiplos processadores esta soluo torna-se
ineficiente devido ao tempo de propagao quando um processador sinaliza
aos demais que as interrupes devem ser habilitadas ou desabilitadas.
Ainda, o mecanismo de clock do sistema implementado atravs de
interrupes, portanto esta soluo deve ser implementada com muito
critrio.
Apesar destas limitaes, esta soluo pode ser til quando se deseja
que a execuo de parte do ncleo do SO ocorra sem que haja interrupo.
102
Desta forma, o sistema pode garantir que no ocorrero problemas de

inconsistncia em suas estruturas de dados durante a execuo de algumas
rotinas.
Instruo test-and-set
Muitos processadores possuem uma instruo especial onde um
processo apenas l o contedo de uma varivel, e armazena seu valor em
outra rea podendo neste caso fazer todas as manipulaes necessrias e
devidas sem precisar de prioridades ou esperar que a varivel original seja
liberada. Esta instruo chamada de test-and-set e
tem como caracterstica ser executada sem interrupo, ou seja, trata-se de
uma instruo invisvel. Assim garante-se que dois processos no manipulem
uma varivel compartilhada ao mesmo tempo, possibilitando a
implementao da excluso mtua.
O uso desta instruo especial oferece vantagens, como a simplicidade
de implementao da excluso mtua em mltiplas regies crticas e o uso da
soluo em arquiteturas com mltiplos processadores. A principal
desvantagem a possibilidade do starvation, pois a seleo do processo para
o acesso ao recurso arbitrria.
7.5.2 Solues de software:
Diversos algoritmos foram propostos na tentativa de implementar a
excluso mtua atravs de solues de software. As primeiras solues
tratavam apenas da excluso mtua para dois processos e, inicialmente,
apresentavam alguns problemas. A evoluo ocorreu at uma soluo
definitiva para a excluso mtua para N processos.
Alm da excluso mtua, que soluciona os problemas de
compartilhamento de recursos, existem outros fatores fundamentais para a
soluo de problemas de sincronizao:
- O nmero de processadores e o tempo de execuo dos processos.
- Um processo fora de sua regio crtica no pode impedir que outros
processos entrem em suas prprias regies crticas.
- Um processo no pode permanecer indefinidamente esperando para entrar
em sua regio crtica.
Todas as solues que foram apresentadas para contornar estes
inconvenientes apresentavam problemas da ESPERA OCUPADA, Na espera
ocupada, todas vezes que um processo tenta entrar em sua regio crtica ele
so impedidas por j existir um outro processo usando o recurso, fazendo o
sistema ficar parado esperando que o mesmo tenha acesso a este respectivo
recurso.
7.6 Semforos:
103
O conceito de semforos foi proposto em 1965, sendo apresentado

como um mecanismo de sincronizao que permitia implementar, de forma
simples, a excluso mtua sincronizao condicional entre processos.
O semforo uma varivel que fica associada a um recurso
compartilhado, indicando quando este est sendo acessado por um outro
processo. Ela ter seu valor alterado quando o processo entra e quando sai
da regio crtica de forma que se um outro processo entrar em sua regio
critica ele possa checar antes este valor para saber se o recurso esta ou no
disponvel. Quando o processo tiver seu acesso impedido, ele ser colocado
em uma fila de espera associada ao semforo aguardando sua vez de utilizar
o recurso. Todos os processos da fila tero acesso ao recurso na ordem de
chegada. O semforo pode ser usado tambm para implementar
sincronizaes condicionais. Isto consiste em um processo que necessita ser
notificado sobre a ocorrncia de um evento. Pode-se usar o semforo para
notificar este processo sobre a ocorrncia deste evento.
Outro tipo de semforo usado SEMFORO CONSUMIDOR onde ele
pode informar ao processo se o buffer est cheio ou est vazio.
SEMFORO CONTADOR aquele que notifica os processos sobre o uso
dos recursos. Sempre que um processo usa um recurso qualquer, este
semforo incrementado sempre que um processo liberar um recurso ele
ser decrementado. Este semforo til para evitar que um processo na
regio crtica sem que haja recursos disponveis no sistema.
O uso de semforos exige do programador muito cuidado, pois qualquer
engano pode gerar bugs em seu programa que o levem a falhas de
sincronizao ocasionando quedas e travamento geral do sistema.
104
P r o c e s s o d e s e j a e n tr a r
n a r e g i o c r ti c a
U P (S ) - p r o c e s s o s a i
d a r e g i o c r ti c a
L ib e ra p r o ce s s o
d a fi l a d e e s p e r a
Pro ce sso a ce ssa
a r e g i o c r tic a
F ila d e e s p e r a
d e p ro ce sso s
Fig. 7.3 Utilizao do semforo binrio na excluso mtua
7.7 Monitores:
Monitores so mecanismos de sincronizao de alto nvel que tornam
mais simples o desenvolvimento de aplicaes concorrentes. Este conceito foi
proposto em 1972.
Basicamente, so mecanismos de sincronizao compostos de um
conjunto de procedimentos, variveis e estrutura de dados definidos dentro
de um mdulo cuja finalidade a implementao automtica da excluso
mtua entre seus procedimentos. Somente um processo pode estar
executando um dos procedimentos do monitor em um determinado instante.
Toda vez que um processo chamar um destes procedimentos, o monitor
verifica se j existe outro processo executando algum procedimento do
monitor. Caso exista, o processo fica aguardando a sua vez ate que tenha
permisso para execut-lo.
105
A implementao da excluso mtua nos monitores realizada pelo

compilador do programa e no mais pelo programador. Para isto ele ir
colocar todas as regies crticas do programa em forma de procedimentos no
monitor e o compilador se encarregar de garantir a excluso mtua destes
procedimentos. A comunicao do processo com o monitor passa a ser feita
atravs de chamadas a seus procedimentos e dos parmetros passados para
eles.
Outra caracterstica do monitor que os processos, quando no
puderem acessar estes procedimentos, ficaro aguardando em uma fila de
espera e enquanto isto, eles podero executar outros procedimentos.
Como ele escrito em uma linguagem de programao, o compilador
das outras demais linguagens devero ser capazes de reconhec-la e
implement-la. So raras as linguagens que permitem tal implementao
criando uma limitao para o uso deste recurso.
D e c la r a o d e
v a r i v e is g lo b a is
P r o c e d im e n to s
M o n i to r
P ro c. 1
P r o c. 2
F ila d e e n tra d a
P r o c. n
I n i c ia li z a o
d e v a r i v e is
Fig. 7.4 Estrutura do monitor

7.8 Troca de mensagens:
A troca de mensagens um mecanismo de comunicao e
sincronizao entre os processos, implementado pelo sistema operacional
atravs de duas rotinas do sistema SEND e RECEIVE. A rotina SEND a
responsvel pelo envio de uma mensagem para o processo receptor
enquanto a rotina RECEIVE por receber a mensagem do processo transmissor.
Tais procedimentos mesmo no sendo mutuamente exclusivos permitem a
comunicao entre os processos e a sincronizao entre eles, pois uma
mensagem somente poder ser lida depois de ter sido enviada e ela somente
ser envidada aps a ocorrncia de um evento.
No sistema de troca de mensagens, existe a possibilidade da
mensagem se perder. Para isto foi implementado o recurso de que o processo
receptor ao receb-la dever enviar ao processo transmissor uma mensagem
106
de recebimento. Caso o transmissor no receber esta mensagem em um

certo espao de tempo ele ir retransmitir esta mensagem.
A comunicao entre processos pode ser feita diretamente. Bastando
que o processo que deseja enviar uma mensagem enderece explicitamente o
nome do receptor. Esta caracterstica chama-se ENDEREAMENTO DIRETO e
s permitida comunicao entre dois processos.
Existe tambm o ENDEREAMENTO INDIRETO que um mecanismo que
consiste no uso de uma rea compartilhada, onde as mensagens podem ser
colocadas pelo processo transmissor e retiradas por qualquer processo.
Existem duas formas de comunicao entre os processos:
COMUNICAO SINCRONA e COMUNICAO ASSINCRONA. Uma comunicao
dita Sncrona, quando um processo envia uma mensagem e fica esperando
at que o processo receptor leia a mensagem e mande a notificao de
recebimento. Uma comunicao assncrona aquela em que o processo que
envia a mensagem no espera notificao de recebimento.
P ro ce sso A
P ro ce ss o A
P ro ce ss o B
Fig. 7.5 Comunicao direta
P ro ce sso B
M a ilb o x
o u P o rt
Fig. 7.6 Comunicao indireta

7.9 Deadlock:
107
O Deadlock existe em qualquer sistema multiprogramvel. Dizemos que

um processo est em Deadlock quando este para de responder porque est
esperando por um evento que nunca ocorrer. Esta situao conseqncia
do problema da excluso mtua. Existem as condies onde o Deadlock ir
ocorrer:
- Cada recurso s pode estar alocado a um nico processo em um
determinado instante. (Excluso mtua)
- Um processo alm dos recursos j alocados, pode estar esperando por
outros recursos.
- Um recurso no pode ser liberado de um processo porque outros processos
desejam o mesmo recurso (No-preempo)
- Um processo pode ter de esperar por um recurso alocado a outro processo e
vice-versa (Espera circular).
P ro ce sso A
P ro ce sso A
s o li c ita o
R e cu rso 2
R e cu rso 1
a lo ca d o a o
Pro ce sso A
R e cu rso 2
R e cu rso 1
P r o ce ss o B
R e cu rso 2
a lo ca d o a o
P ro ce sso B
Pro ce sso B
s o licita o
R e cu rso 1
Fig. 7.7 Espera circular

7.9.1 Preveno do Deadlock:
Para prevenir o Deadlock preciso garantir que uma das quatro
condies acima citada nunca ocorra, dentre as diversas situaes j citadas
pode ser feito um minucioso trabalho de determinar muito bem que recursos,
quais recursos e quando estes recursos devero ser disponibilizados aos
processos.
7.9.2 Deteco de Deadlock:
Em sistemas que no possuam mecanismos que previnam a ocorrncia
de deadlocks, necessrio um esquema de deteco e correo do problema.
A Deteco do Deadlock um mecanismo que determina a existncia deste e
identifica os recursos envolvidos no problema. Um exemplo deste tipo de
detector o prprio Gerenciador de tarefas do Windows que detecta o
108
aplicativo que parou de responder ao sistema causado, possivelmente, por

um deadlock, como podemos ver logo abaixo:
Fig. 7.8 Exemplo de Deadlock

7.9.3 Correo do Deadlock:
Geralmente o problema resolvido eliminando os processos envolvidos
e desalojando os recursos para ele j garantidos. aquele processo em que
voc d um Alt+Ctrl+Del no Windows e aparece uma janela informando o
aplicativo que no responde. Este aplicativo pode estar em um processo de
Deadlock, neste caso voc manda finalizar o aplicativo e tudo voltar ao
normal. Muitas vezes este mecanismo no resolve e pelo contrrio gera novos
problemas. Se voc finalizar um processo que esteja
intimamente envolvido com o sistema operacional ou que esteja usando
recursos de baixo nvel do mesmo, voc poder vir a deix-lo instvel ou
travado.
Abaixo vemos a caixa de dialogo do Windows que tentar fechar o
processo que pode estar parado por falta de comunicao com o sistema.
109
Fig. 7.9 Correo do Deadlock

O problema do Deadlock um problema que tende a tornar-se mais
critico medida que os sistemas operacionais evoluem no sentido de
implementar o paralelismo e permitir a alocao dinmica de um numero
maior de recursos e a execuo de um numero maior de processos
simultaneamente. Os usurios sentem muita saudade dos computadores que
rodavam o DOS nos bons tempos quando quase no davam problemas. Mas
bom lembrar que o DOS era um sistema operacional monotarefa e
monousurio onde praticamente tnhamos apenas um nico processo
rodando de cada vez. Neste caso no existiam os problemas que um
ambiente multitarefa e multiusurio tem hoje. Todos os recursos do sistema
estavam exclusivamente disponveis para aquele processo e, portanto ele
tinha total e plena liberdade de fazer com estes o que bem entendia.
Hoje os sistemas operacionais so mais complexos rodando em
maquinas mais crticas devido velocidade de processamento tendo um
maior numero de aplicaes que rodam simultaneamente e demandando
praticamente todos os recursos do sistema ao mesmo tempo. Muitos destes
programas trabalham no s com um, mas com vrios processos
simultaneamente o que aumentam as chances de colises entre eles ou com
os recursos do sistema.
Captulo 8
Gerncia do Processador
8.1 Funes:
110
Com o surgimento dos sistemas multiprogramveis, onde mltiplos

processos poderiam permanecer na memria e disputar o uso de um nico
processador, a gerncia do processador tornou-se uma das atividades mais
importantes em um sistema operacional.
A partir do momento em que vrios processos podem estar no estado
de pronto, devem ser estabelecidos critrios para definir qual processo ser
escolhido para fazer uso do processador. Tais critrios compem a poltica de
escalonamento, que a base da gerncia do processador e da
multiprogramao em um sistema operacional.
Dentre as funes da gerncia do processador, podemos citar: manter o
processador ocupado a maior parte do tempo. balancear o uso da CPU entre
processos, privilegiar a execuo de aplicaes crticas, maximizar o
throughput e oferecer tempos de resposta razoveis aos usurios interativos.
Cada sistema operacional possui sua poltica de escalonamento
adequada ao seu propsito e s suas caractersticas. Sistemas de tempo
compartilhado, por exemplo, possuem requisitos de escalonamento distintos
dos sistemas de tempo real.
8.2
Critrios de escalonamento:
Utilizao do processador: corresponde a uma taxa de utilizao,

que na maioria dos sistemas varia entre 30 e 90%. Uma utilizao
abaixo dos 30% indicaria um sistema ocioso, com carga de
processamento baixa, enquanto uma taxa de utilizao acima dos 90%
pode indicar um sistema bastante carregado, prximo da sua
capacidade mxima (em alguns casos tal situao pode levar a um
crash travamento do sistema).
Throughput: o nmero de processos executados em um

determinado intervalo de tempo. Quanto maior o throughput, maior o
nmero de tarefas executadas em funo do tempo. A maximizao do
throughput desejada na maioria dos sistemas.
Tempo de Processador: o tempo que um processo leva no estado

de execuo, durante seu processamento. As polticas de
escalonamento no interferem neste parmetro, sendo este tempo
funo apenas do cdigo executvel e da entrada/sada de dados.
Tempo de Espera (pela CPU): todo o tempo que o processo

permanece na fila de pronto, aguardando a liberao da CPU para ser
executado. A reduo deste tempo de espera desejada pela maioria
das polticas de escalonamento.
111
Tempo de Turnaround: o tempo total que o processo permaneceu

no sistema, desde sua criao at o momento em que encerrado. So
contados os tempos de alocao de memria, espera na fila de pronto e
interrupo (E/S).
Tempo de Resposta: o tempo decorrido entre uma requisio ao

sistema e o instante em que a resposta comea a ser exibida. Em
sistemas interativos, como aplicaes on-line ou acesso Web, os
tempos de resposta devem ser da ordem de apenas poucos segundos.
8.3
Escalonamentos No-Preemptivos e Preemptivos:
Escalonamentos do tipo no-preemptivos so aqueles onde o sistema

operacional no pode interromper o processo em execuo para retir-lo da
CPU. Assim sendo, se nenhum evento externo ocorresse durante a execuo
do processo, este permanecia na CPU at terminar ou ento alguma instruo
do prprio programa o desviasse para o estado de espera (operao de E/S).
J os escalonamentos preemptivos so caracterizados pela possibilidade
de o sistema operacional interromper o processo em execuo para retir-lo
da CPU e dar lugar a outro. Neste caso o processo retirado da CPU volta ao
estado de pronto, onde permanece aguardando nova oportunidade de ocupar
a CPU. Com o uso da preempo, possvel ao sistema priorizar a execuo
de processos, como no caso de aplicaes em tempo real. Outro benefcio
a possibilidade de implementar polticas de escalonamento que compartilhem
o processador de uma maneira mais uniforme, balanceando o uso da CPU
entre os processos.
So escalonamentos no-preemptivos:
-
FIFO: o processo que chegar primeiro fila de pronto selecionado

para execuo, e permanece utilizando o processador at terminar sua
execuo ou ser interrompido por E/S. Neste caso, o prximo processo
da fila de pronto selecionado para execuo. Todo processo que chega
fila de pronto entra no final desta fila, conservando a ordem de
chegada na fila, at ser escalonado novamente. Apesar de simples,
este escalonamento apresenta algumas deficincias, principalmente no
que diz respeito dificuldade de se prever o incio da execuo de um
processo, j que a ordem de chegada fila de pronto deve ser
observada risca. Outro problema quanto aos tipos de processo,
onde os CPU-bound levam vantagem no uso do processador em relao
aos do tipo I/O-bound, pois o sistema no trata este tipo de diferena. O
escalonamento FIFO foi inicialmente implementado em sistemas
monoprogramveis, sendo ineficiente se aplicado em sistemas
interativos de tempo compartilhado.
112
Abaixo, um exemplo de escalonamento utilizando o mtodo FIFO: a

ordem de chegada dos processos (A, B, C) na fila de pronto foi obedecida,
e, no tendo sido interrompidos por E/S, os processos executaram
inteiramente at terminar, de acordo com seus tempos necessrios para
execuo.
0
10
Processo A
10 u.t.
-
18
Processo B
8 u.t.
27
Processo C
9 u.t.
SJF (Shortest Job First): este escalonamento seleciona o processo

que tiver o menor tempo de processador ainda por executar. Desta
forma, o processo que estiver na fila de pronto com menor necessidade
de tempo de CPU para terminar o seu processamento ser o escolhido
para ocupar a CPU. Funciona com um parmetro passado ao sistema
via contexto de software, onde o tempo estimado para o processo
informado baseando-se em estatsticas de execues anteriores.
Como exemplo, vamos utilizar os mesmos processos executados
no escalonamento FIFO acima, com seus respectivos tempos de
execuo em u.t. (unidades de tempo): processo A com 10 u.t.,
processo B com 8 u.t, e o processo C com 9 u.t. Como neste
escalonamento o que importa o tempo de execuo, a nova ordem
de escalonamento para utilizao da CPU ser B, C e A, como segue:
0
Processo B Processo C
-
17
27
Processo A
Cooperativo: este escalonamento busca aumentar o grau de

concorrncia no processador. Neste caso, um processo em execuo
pode voluntariamente liberar o processador retornando fila de pronto,
possibilitando que um novo processo seja escalonado, permitindo
melhor distribuio do tempo do processador. A liberao da CPU
uma tarefa exclusiva do programa em execuo, que de maneira
cooperativa libera o processador para um outro processo. Neste
mecanismo, o processo em execuo verifica periodicamente uma fila
de mensagens para saber se existem outros processos na fila de pronto.
Porm, como a interrupo do processo no depende do sistema
operacional, situaes indesejveis podem ocorrer, como por exemplo,
se um programa em execuo no verificar a fila de mensagens, os
demais programas no tero chance de executar enquanto a CPU no
113
for liberada. As primeiras verses do Windows chegaram a utilizar este

tipo de escalonamento.
So escalonamentos preemptivos:
Circular: um tipo de escalonamento projetado especialmente para
sistemas em tempo compartilhado. muito semelhante ao FIFO
(obedece a ordem de chegada fila de PRONTO), mas quando um
processo passa para o estado de execuo h um limite de tempo para
o uso contnuo do processador, chamado fatia de tempo (time-slice) ou
quantum. Assim, toda vez que um processo selecionado para
execuo uma nova fatia de tempo lhe concedida. Caso esta fatia de
tempo expire, o sistema operacional interrompe o processo, salva seu
contexto e o direciona para a fila de PRONTO. Este mecanismo
conhecido como preempo por tempo. A principal vantagem deste
escalonamento no permitir que um processo monopolize a CPU.
Outrossim, uma desvantagem que os processos CPU-bound so
beneficiados no uso do processador em relao aos processos I/Obound, pois tendem a utilizar totalmente a fatia de tempo recebida. A
figura a seguir mostra o escalonamento circular com 3 processos, onde
a fatia de tempo igual a 2 u.t. No exemplo no esto sendo levados
em considerao tempos de troca de contexto entre os processos, nem
o tempo perdido em operaes de E/S. Os processos A, B e C, gastam
10 u.t, 6 u.t e 3 u.t., respectivamente.
A
B
C
10
1
1
1
7
u.t.
Por Prioridades: funciona com base num valor associado a cada

processo, denominado prioridade de execuo. O processo com maior
prioridade na fila de PRONTO sempre o escolhido para ocupar o
processador, sendo os processos com prioridades iguais escalonados
pelo critrio FIFO. Neste escalonamento o conceito da fatia de tempo
no existe. Como conseqncia disto, um processo em execuo no
pode sofrer preempo por tempo. Neste escalonamento a perda do
uso do processador somente ocorrer no caso de uma mudana
114
voluntria para o estado de espera (interrupo por E/S), ou quando um

outro processo de prioridade maior passa (ou chega) para o estado de
pronto. Neste caso o sistema operacional interrompe o processo em
execuo, salva seu contexto e o coloca na fila de pronto, dando lugar
na CPU ao processo prioritrio. Este mecanismo chamado de
preempo por prioridade. A figura a seguir mostra a execuo dos
processos A, B e C, com tempos de execuo de 10, 4 e 3 u.t.
respectivamente, e
valores de prioridades de 2, 1 e 3, tambm respectivamente. Na
maioria dos sistemas, valores menores correspondem MAIOR
prioridade. Assim, a ordem de execuo ser invertida para B, A e C.
A
B
C
4
14
17 u.t.
A prioridade de execuo faz parte do contexto de software do

processo, e pode ser esttica (quando no pode ser alterada durante a
existncia do processo) ou dinmica (quando pode ser alterada durante
a existncia do processo). Este escalonamento muito usado em
sistemas de tempo real, com aplicaes de controle de processos,
controle de trfego (sinais de trnsito, de trens/metr, areo), robtica,
entre outros.
-
Escalonamento Circular com Prioridades: implementa o conceito

de fatia de tempo e de prioridade de execuo associada a cada
processo. Neste escalonamento, um processo permanece no estado de
execuo at que termine seu processamento, ou voluntariamente
passe para o estado de espera (interrupo por E/S), ou sofra uma
preempo por tempo ou prioridade. A principal vantagem deste
escalonamento permitir um melhor balanceamento no uso do
processador, com a possibilidade de diferenciar o grau de importncia
dos processos atravs da prioridade (o Windows utiliza este
escalonamento).
Por Mltiplas Filas: Este escalonamento implementa vrias filas de

pronto, cada uma com prioridade especfica. Os processos so
associados s filas de acordo com caractersticas prprias, como
importncia da aplicao, tipo de processamento ou rea de memria
necessria. Assim, no o processo que detm a prioridade, mas sim a
fila. O processo em execuo sofre preempo caso um outro processo
entre em uma fila de maior prioridade. O sistema operacional s pode
115
escalonar processos de uma fila quando todas as outras filas de maior

prioridade estejam vazias. Os processos sempre voltam para a mesma
fila de onde saram.
-
Por Mltiplas Filas com Realimentao: semelhante ao anterior, porm

permitindo ao processo voltar para uma outra fila de maior ou menor
prioridade, de acordo com seu comportamento durante o processamento. O
sistema operacional identifica dinamicamente o comportamento de cada
processo e o redireciona para a fila mais conveniente ao longo de seu
processamento. um algoritmo generalista, podendo ser implementado na
maioria dos sistemas operacionais.
Captulo 9
Gerncia de Memria / Memria Virtual
9.1
Introduo:
Historicamente, a memria principal sempre foi vista como um recurso

escasso e caro. Uma das maiores preocupaes dos projetistas foi
desenvolver sistemas operacionais que no ocupassem muito espao de
memria e, ao mesmo tempo, otimizassem a utilizao dos recursos
computacionais. Mesmo atualmente, com a reduo do custo e o aumento
considervel da capacidade da memria principal, seu gerenciamento dos
fatores mais importantes no projeto e implementao dos sistemas
operacionais.
Enquanto nos sistemas monoprogramveis a gerncia de memria no
muito complexa, nos sistemas multiprogramveis essa gerncia se torna
crtica, devido necessidade de se maximizar o nmero de usurios e
aplicaes utilizando eficientemente o espao da memria principal.
9.2
Funes:
Geralmente, os programas so armazenados em memrias secundrias,

de uso permanente e no volteis, como discos ou fitas. Como o processador
somente executa o que est na memria principal, o sistema operacional
deve sempre transferir programas da memria secundria para a principal
antes de serem executados.Como o tempo de acesso s memrias
secundrias muito superior ao tempo de acesso memria principal, o
sistema operacional deve buscar reduzir o nmero de operaes de E/S
(acessos memria secundria) a fim de no comprometer o desempenho do
sistema.
A gerncia de memria deve tentar manter na memria principal o
maior nmero de processos residentes, permitindo maximizar o
compartilhamento do processador e demais recursos computacionais. Mesmo
no havendo espao livre, o sistema deve permitir que novos processos
116
sejam aceitos e executados. Outra preocupao na gerncia de memria

permitir a execuo de programas maiores do que a memria fsica
disponvel.
Em um ambiente de multiprogramao o sistema operacional deve
proteger as reas de memria ocupadas por cada processo, alm da rea
onde reside o prprio sistema. Caso um programa tente realizar algum acesso
indevido memria, o sistema deve, de alguma forma, impedir o acesso.
9.3
Alocao Contgua Simples:
Este tipo de alocao foi implementado nos primeiros sistemas

operacionais, embora ainda nos dias de hoje esteja presente em alguns
sistemas monoprogramveis. Nesse modelo, a memria principal dividida
em duas partes, uma para o sistema operacional e a outra para o programa
do usurio. Dessa forma, o programador deve desenvolver suas aplicaes
preocupado apenas em no ultrapassar o espao de memria disponvel.
Neste esquema o usurio tem total controle sobre toda a memria,
exceto naquela rea onde reside o sistema operacional, cujo endereamento
protegido por um registrador, impedindo acesso indevido pelo usurio.
Sistema
Operacional
X
registrador
rea para
programas
Proteo na alocao contgua simples

Apesar de simples implementao e cdigo reduzido, a alocao
contgua simples no permite a utilizao eficiente dos recursos do sistema,
pois apenas um usurio pode dispor destes recursos. H inclusive um
desperdcio de espao de memria, caso o programa no venha a ocupar
toda a rea reservada para ele.
Sistema
Operacional
Programa do
Usurio
117
Sub-utilizao da memria principal
9.4
Segmentao de Programas:
Na alocao contgua simples todos os programas esto limitados ao

tamanho da memria principal disponvel para o usurio. Uma soluo
encontrada para o problema dividir o programa em mdulos, de modo que
seja possvel a execuo independente de cada mdulo, utilizando a mesma
rea de memria. A esta tcnica d-se o nome de segmentao ou overlay.
Consideremos um programa que tenha trs mdulos: um principal, um
de cadastramento e outro de impresso, sendo os mdulos de cadastramento
e impresso independentes. A independncia significa que quando um
mdulo estiver na memria para execuo, o outro no necessariamente
precisa estar presente.O mdulo principal comum aos outros dois, logo,
precisa estar na memria durante todo o tempo da execuo do programa.
Na figura a seguir, a memria insuficiente para armazenar todo o
programa, que totaliza 9 KB. A tcnica de overlay utiliza uma rea de
memria comum para armazenar o mdulo principal do programa e uma
outra rea na mesma memria, chamada rea de overlay, que ser
compartilhada entre os mdulos de cadastramento e impresso. Assim,
sempre que um dos mdulos for referenciado no mdulo principal, o sistema
o carregar da memria secundria para a rea de overlay, sobrepondo o
mdulo antigo na memria.
Memria Principal
2 KB
3 KB
4 KB
Sistema
Operacional
Mdulo Principal
rea de
Overlay
Cadastramento
4 KB
Impresso
2 KB
1 KB
2 KB
118
rea livre
Tcnica de Overlay
A definio das reas de overlay funo do programador, atravs de
comandos especficos da linguagem de programao utilizada.
A grande vantagem da utilizao desta tcnica consiste em se poder
executar programas maiores do que a memria fsica disponvel.
9.5
Alocao Particionada Esttica:
Os sistemas operacionais evoluram no sentido de proporcionar melhor

aproveitamento dos recursos disponveis. Nos sistemas monoprogramveis o
processador permanece grande parte do tempo ocioso e a memria principal
sub-utilizada. Os sistemas multiprogramveis j so muito mais eficientes
no uso do processador, necessitando que vrios processos estejam na
memria principal ao mesmo tempo e que novas formas de gerncia de
memria sejam implementadas.
Nos primeiros sistemas multiprogramveis a memria era dividida em
blocos de tamanho fixo, chamados parties.O tamanho dessas parties,
estabelecido em tempo de inicializao do sistema, era definido em funo do
tamanho dos programas que executariam no ambiente.Sempre que fosse
necessria a alterao do tamanho de uma partio, o sistema deveria ser
inicializado novamente com uma nova configurao.
Sistema
Operacional
Partio 1
2 KB
Partio 2
5 KB
Partio 3
8 KB
Inicialmente, os programas s podiam ser carregados e executados em

apenas uma partio especfica, mesmo que as outras estivessem
disponveis. Esta limitao se devia aos compiladores e linkeditores, que
geravam apenas cdigo absoluto. No cdigo absoluto, todas as referncias a
endereos no programa so posies fsicas na memria, ou seja, o programa
s poderia ser carregado a partir do endereo de memria especificado no
seu prprio cdigo. A esse tipo de alocao de memria chamou-se
alocao particionada esttica absoluta.
119
Coma evoluo dos compiladores, linkeditores, montadores e loaders, o

cdigo gerado deixou de ser absoluto e passou a ser relocvel . No cdigo
relocvel, todas as referncias a endereos no programa so relativas ao
incio do cdigo e no a endereos fixos na memria. Desta forma, os
programas puderam ser alocados em qualquer partio livre, independente
do endereo inicial e da partio para a qual o cdigo foi criado. A esse tipo
de alocao deu-se o nome de alocao particionada esttica relocvel.
Tanto nos sistemas de alocao absoluta como nos de alocao
relocvel, os programas, normalmente, no ocupam totalmente as parties
onde so alocados, deixando algum espao livre dentro das parties. Este
tipo de problema, decorrente do esquema de alocao fixa de parties,
chamado fragmentao interna.
A figura a seguir mostra um grfico representando o particionamento
esttico de uma memria e sua fragmentao interna.
Memria Principal
Sistema
Operacional
Programa C
1 KB
Programa A
3 KB
Fragmentao
interna
Programa E
5 KB
Alocao particionada esttica com fragmentao interna

9.6
Alocao Particionada Dinmica:
A alocao particionada esttica deixou clara a necessidade de uma

nova forma de gerncia de memria principal, onde o problema da
fragmentao interna fosse reduzido e, conseqentemente, o grau de
compartilhamento da memria aumentado.
Na alocao particionada dinmica, foi eliminado o conceito de
parties de tamanho fixo. Nesse esquema, cada programa, ao ser carregado,
utilizaria o espao necessrio sua execuo, tornando esse espao a sua
partio. Assim, como os programas utilizam apenas o espao de que
120
necessitam, no esquema de alocao particionada dinmica o problema da

fragmentao interna deixa de existir.
Porm, com o trmino de alguns programas e o incio de outros, passam
a existir na memria blocos cada vez menores na memria, no permitindo o
ingresso de novos programas. A este tipo de problema d-se o nome de
fragmentao externa.
Para resolver o problema da fragmentao externa, os fabricantes
tentaram duas solues:
- reunio de todos os blocos livres adjacentes, formando uma grande
rea livre, que se transforma em uma nova partio;
-
realocao de todas as parties ainda ocupadas para a parte inicial

da memria, eliminando os blocos livres entre elas, formando uma
grande rea
livre no final da memria, que podia ser distribuda entre os
processos ainda por executar. A este tipo de compactao de
espaos livres foi dado o nome de alocao particionada
dinmica com realocao.
Estas solues ajudaram a diminuir os problemas da fragmentao (tanto

interna como externa), mas, devido complexidade dos algoritmos, nem
todos os sistemas operacionais as utilizaram.
9.7
Estratgias de Alocao de Partio:
Os sistemas operacionais implementam basicamente trs estratgias

para determinar em qual rea livre um programa ser alocado para execuo.
Essas estratgias tentam evitar ou diminuir o problema da fragmentao.
A melhor estratgia a ser adotada por um sistema depende de uma
srie de fatores, sendo o mais importante o tamanho dos programas
executados no ambiente.
Independentemente do algoritmo utilizado, o sistema possui uma lista
das reas livres, com endereo e tamanho de cada rea.
So estratgias de alocao:
-
Best-fit: escolhida a melhor partio, ou seja, aquela que deixa o

menor espao sem utilizao. Uma grande desvantagem desta
estratgia que, como so alocados primeiramente as parties
121
menores, deixando pequenos blocos, a fragmentao aparece mais

rapidamente.
-
Worst-fit: aloca o programa na pior partio, ou seja, aquela que

deixa o maior espao livre. Esta tcnica, apesar de aproveitar
primeiro as parties maiores, acaba deixando espaos livres
grandes o suficiente para que outros programas utilizem esses
espaos, permitindo que um nmero maior de processos se utilizem
da memria, diminuindo ou retardando a fragmentao.
First-fit: esta estratgia aloca o programa na primeira partio que

o couber, independente do espao livre que vai deixar. Das trs
estratgias, esta a mais rpida, consumindo menos recursos do
sistema.
9.8
Swapping:
uma tcnica aplicada gerncia de memria que visa dar maior taxa
de utilizao memria principal, melhorando seu compartilhamento. Visa
tambm resolver o problema da falta de memria principal num sistema.
Toda vez que um programa precisa ser alocado para execuo e no h
espao na memria principal, o sistema operacional escolhe entre os
processos alocados que
no tem previso de utilizar a CPU nos prximos instantes (quase sempre
entre aqueles que esto em interrupo de E/S ou no final da fila de pronto),
e descarrega este processo da memria para uma rea especial em disco,
chamada arquivo de swap, onde o processo fica armazenado
temporariamente. Durante o tempo em que o processo fica em swap, o outro
que necessitava de memria entra em execuo ocupando o espao deixado
pelo que saiu. Pouco antes de chegar a vez do processo armazenado em
swap utilizar a CPU, o sistema escolhe um outro processo para descarregar
para swap e devolve o anterior da rea de swap para a memria principal,
para que este possa ser executado novamente. E vai trabalhando assim at
que os processos vo terminando. O problema dessa tcnica que pode
provocar um nmero excessivo de acesso memria secundria (disco),
levando o sistema a uma queda de desempenho.
9.9
Memria Virtual:
122
Anteriormente foram apresentadas diversas tcnicas de gerenciamento

de memria que evoluram no sentido de maximizar o nmero de processos
residentes na memria principal e reduzir o problema da fragmentao,
porm os esquemas vistos se mostraram muitas vezes ineficientes. Alm
disso, o tamanho dos programas e de suas estruturas de dados estava
limitado ao tamanho da memria disponvel. Como vimos, a utilizao da
tcnica de overlay para contornar este problema de difcil implementao
na prtica e nem sempre uma soluo garantida e eficiente.
Memria virtual uma tcnica sofisticada e poderosa de gerncia de
memria onde as memrias principal e secundria so combinadas, dando ao
usurio a impresso de que existe muito mais memria do que a capacidade
real de memria principal.
O conceito de memria virtual baseia-se em no vincular o
endereamento feito pelo programa aos endereos fsicos da memria
principal. Desta forma, o programa e suas estruturas de dados deixam de
estar limitados ao tamanho da memria fsica disponvel, pois podem possuir
endereos vinculados memria secundria, que funciona como uma
extenso da memria principal.
Outra vantagem desta tcnica permitir um nmero maior de
processos compartilhando a memria principal, j que apenas partes de cada
processo estaro residentes. Isto leva a uma utilizao mais eficiente do
processador, alm de minimizar (ou quase eliminar) o problema da
fragmentao.
A seguir, os conceitos que envolvem a gerncia de memria virtual,
incluindo a paginao:
-
espao de endereamento virtual: o conjunto de endereos

virtuais que um processo pode enderear.
Espao de endereamento real: analogamente, o conjunto de

endereos reais que um processo pode enderear.
Mapeamento: como o espao de endereamento virtual no tem

nenhuma relao com o espao de endereamento real, um
programa pode fazer referncia a um endereo virtual que esteja
fora dos limites da memria principal (real), ou seja, os programas e
suas estruturas de dados no esto mais limitados ao tamanho da
memria fsica disponvel. Quando um programa executado,
apenas uma parte do seu cdigo fica residente na memria principal,
permanecendo o restante na memria virtual at o momento de ser
referenciado. Este esquema de endereamento virtual ignorado
pelo programador no desenvolvimento das aplicaes. Cabe ao
compilador e ao linkeditor gerar cdigos executveis em funo do
endereamento virtual, e o sistema operacional se incumbe de
123
administrar os detalhes durante a sua execuo. O processador

apenas executa instrues e referencia dados residentes no espao
de endereamento real. Portanto, deve existir um mecanismo que
transforme os endereos virtuais em endereos reais. Este
mecanismo o que chamamos de mapeamento, e consiste em
permitir a traduo do endereo virtual em endereo real. Como
conseqncia, um programa no mais precisa estar necessariamente
em endereos contguos na memria real para ser executado.
-
Tabela de endereamento de pginas: estrutura mantida pelo

sistema para armazenar, entre outras informaes, o mapeamento.
nica e exclusiva para cada processo, relacionando os endereos
virtuais do processo s suas posies na memria real.
Memria virtual por paginao: a tcnica de gerncia de

memria onde o espao de endereamento virtual e o espao de
endereamento real so divididos em blocos do mesmo tamanho
chamados pginas. As pginas do espao virtual so chamadas
pginas virtuais, enquanto as pginas do espao real so chamadas
pginas reais ou frames.
Page fault: a falha de pgina. Sempre que o processo referencia

um endereo virtual, o sistema verifica se a pgina correspondente
j est carregada na memria real. Se no estiver, acontece o page
fault. Neste caso, o sistema deve transferir a pgina virtual para um
endereo na memria real. Esta transferncia chamada de
paginao. O nmero de page faults gerados por um processo em
um determinado intervalo de tempo chamado de taxa de
paginao do processo. Se esta taxa atingir valores elevados, pode
haver um comprometimento do desempenho do sistema. Um page
fault provoca
uma interrupo no processo, pois h a necessidade de acessar
operaes de E/S. Assim, sempre que acontece a paginao, uma
interrupo de E/S far com que o processo em execuo seja
interrompido e colocado em estado de espera at que sua
interveno de E/S seja realizada, quando ento o processo voltar
fila de pronto e entrar em execuo de acordo com o
escalonamento normal. Enquanto o sistema trata a interrupo deste
processo, um outro ocupar a CPU.
Working-set: o conjunto de pginas de um processo, em memria

real, em um determinado instante. Este conceito surgiu com o
objetivo de reduzir o problema do thrashing e est relacionado ao
princpio da localidade. Existem dois tipos de localidade que so
observados durante a execuo da maioria dos programas. A
localidade espacial a tendncia de que, aps uma referncia a um
endereo de memria, sejam realizadas novas referncias a
endereos prximos ou adjacentes. A localidade espacial a
124
tendncia de que, aps a referncia a uma posio de memria, esta

mesma posio seja referenciada novamente num curto intervalo de
tempo. A partir desse princpio de localidade, o processador tender
a concentrar suas referncias a um conjunto de pginas do processo
durante um determinado perodo de tempo. Imagine um loop
principal de um programa que ocupe trs pginas. A tendncia que
estas trs pginas tenham um alto ndice de referncias durante a
execuo do programa.
-
Thrashing: o efeito causado pelo excesso de page faults durante

a execuo de um processo. Pode acontecer a nvel de programa ou
de sistema. A nvel de programa, pode ser provocado por um
programa mal escrito, com desvios incondicionais espalhados por
seu cdigo (desobedecendo portanto aos princpios da localidade),
ou por um limite de working-set muito pequeno (que no comporte o
loop principal do programa, por exemplo). A soluo para estes casos
reescrever o programa ou aumentar o limite do working-set. No
caso de thrashing de sistema, significa que h mais pginas sendo
requeridas na memria real do que ela pode realmente suportar. A
soluo aumentar o tamanho da memria fsica.
Tamanho da pgina: deve estar entre 512 bytes e 128KB,

aproximadamente.
Pginas
menores
promovem
maior
compartilhamento da memria, permitindo que mais programas
possam ser executados. Pginas maiores diminuem o grau de
compartilhamento da memria, com menos programas disputando o
processador. Assim conclui-se que quanto menor o tamanho da
pgina, MAIOR o grau de compartilhamento da memria e da CPU.
Polticas de busca de pginas: definem como as pginas sero

carregadas da memria virtual para a memria real. A poltica por
demanda estabelece que uma pgina somente ser carregada
quando for referenciada. Este mecanismo conveniente, pois leva
para a memria real somente as pginas realmente necessrias
execuo do programa, ficando as outras na memria
virtual. A outra poltica, chamada paginao antecipada, funciona
carregando antecipadamente vrias pginas da memria virtual para
a principal, na tentativa de economizar tempo de E/S. Nem sempre o
sistema acerta na antecipao, mas o ndice de acertos quase
sempre maior que o de erros.
Polticas de alocao de pginas: determinam quantos frames

cada processo pode manter na memria real. A poltica de alocao
fixa
determina um limite de working-set igual para todos os
processos, e pode ser vista como uma poltica injusta, na medida em
que processos maiores normalmente necessitam de um working-set
maior. A outra poltica a varivel, que define um limite de workingset diferente e varivel para cada processo, em funo de seu
125
tamanho, taxa de paginao ou at mesmo da taxa de ocupao da

memria principal.
-
Polticas de substituio de pginas: definem onde sero

trocadas as pginas, quando se fizer necessria uma substituio. Na
poltica local, somente as pginas do processo que gerou o page
fault so candidatas a serem substitudas.J na poltica global, todas
as pginas alocadas na memria principal so candidatas
substituio, independente do processo que gerou o page fault.
Como uma pgina de qualquer processo pode ser escolhida, pode
ser que este processo sofra um aumento temporrio da taxa de
paginao em funo da diminuio das suas pginas alocadas em
memria.
9.10 Algoritmos de substituio de pginas:

O maior problema na gerncia de memria virtual por paginao no
decidir quais pginas carregar para a memria real, mas sim quais pginas
liberar. Quando h a necessidade de carregar uma pgina, o sistema deve
selecionar entre as diversas pginas alocadas na memria qual delas dever
ser liberada pelo processo.
Os algoritmos de substituio de pginas tm o objetivo de selecionar
os frames que tenham as menores chances de serem referenciados num
futuro prximo. Caso contrrio, o frame poderia retornar diversas vezes para
a memria real, provocando excesso de page faults.
So algoritmos de substituio de pginas:
-
algoritmo timo: impossvel de ser implementado, pois o

processador no consegue prever com segurana qual frame no
ser mais referenciado durante a execuo do programa. Tal fato
deve-se lgica do programa e aos dados que ele manipula,
desconhecidos pelo processador.
Algoritmo aleatrio: escolhe qualquer pgina, entre as alocadas

na memria, para fazer a substituio. Em funo de sua baixa
eficincia, este algoritmo no muito utilizado, embora consuma
poucos recursos do sistema.
Algoritmo FIFO (first in, first out): escolhe a pgina que est h
mais tempo na memria principal para fazer a troca. um algoritmo
de simples implementao, mas corre o risco de retirar uma pgina
que, embora tenha sido carregada h mais tempo, esteja sendo
muito utilizada. Por essa razo no muito usado.
126
Algoritmo LFU (least frequently used): elege a pgina menos

freqentemente usada para efetuar a troca. Atravs de um contador,
armazenado na tabela de endereamento de pginas, mo sistema
identifica quantas referncias cada pgina teve e utiliza esta
informao para escolher a pgina.
Algoritmo LRU (least recently used): elege a pgina menos

recentemente usada para fazer a troca. O sistema mantm na tabela
de endereamento de pginas um campo onde so armazenadas a
data e a hora da ltima referncia de cada pgina, e com base
nestas informaes faz a seleo.
Algoritmo NRU (not recently used): elege a pgina menos

recentemente usada para efetuar a troca. O sistema exclui da
deciso a pgina mais recente e escolhe entre as outras, pelo
mtodo FIFO, qual pgina deve sair.
127
Captulo 10
Gerncia de Sistemas de Arquivos
10.1 Estrutura de Diretrios:
como o Sistema organiza logicamente os arquivos. Contm entradas
associadas aos arquivos, com as informaes de localizao, nome,
organizao e outros atributos:
Nvel nico: a implementao mais simples de uma estrutura de

diretrios, onde existe um nico diretrio contendo todos os arquivos do
disco. muito limitado, no permitindo a criao de arquivos com o
mesmo nome.
Diretrio pessoal: Evoluo do modelo anterior, permite a cada

usurio ter ser diretrio particular, sem a preocupao de conhecer os
outros arquivos do disco. Neste modelo h um diretrio master que
indexa todos os diretrios particulares dos usurios, provendo o acesso
a cada um.
Mltiplos nveis (RVORE): o modelo utilizado hoje em dia em

quase todos os Sistemas Operacionais. Nesta modalidade cada usurio
pode criar vrios nveis de diretrios (ou sub-diretrios), sendo que
cada diretrio pode conter arquivos e sub-diretrios. O nmero de
nveis possveis depende do Sistema Operacional.
10.2 Sistemas de alocao de arquivos:
FAT: sistema criado no MS-DOS e depois utilizado no Windows. Usa

listas encadeadas, tem um limite de rea utilizvel em parties de 2
GB, caracteriza-se por um baixo desempenho no acesso e
armazenamento.
FAT32: igual ao FAT no que diz respeito a organizao e desempenho,

mas pode trabalhar com parties de at 2TB.
NTFS: NT File System, original da plataforma Windows NT/2000/XP.

Opera com uma estrutura em rvore binria, oferecendo alto grau de
segurana e desempenho:
-
nomes de arquivo com at 255 caracteres, podendo conter

maisculas, minsculas e espaos em branco;
dispensa ferramentas de recuperao de erros;
bom sistema de proteo de arquivos;
criptografia;
suporta discos de at 264 bytes.
128
UNIX: Usa diretrio hierrquico, com um raiz e outros diretrios

subordinados. Neste Sistema Operacional todos os arquivos so
considerados apenas como uma seqncia de bytes, sem significado
para o Sistema. responsabilidade da
aplicao controlar os mtodos de acesso aos arquivos. O UNIX utiliza
tambm alguns diretrios padronizados, de exclusividade do Sistema.
10.3 Gerncia de espao livre:
So trs as formas de se implementar estruturas de espaos livres. Uma

delas atravs de uma tabela denominada mapa de bits, onde cada entrada
da tabela associada a um bloco do disco representado por um bit, que
estando com valor 0 indica que o espao est livre, e com valor 1 representa
um espao ocupado. Gasta muita memria, pois para cada bloco do disco h
uma entrada na tabela.
A segunda forma utilizando uma lista encadeada dos blocos livres do
disco. Desse modo, cada bloco possui uma rea reservada para armazenar o
endereo do prximo bloco livre. Apresenta problemas de lentido no acesso,
devido s constantes buscas seqenciais na lista.
A terceira forma a tabela de blocos livres. Nesta, leva em
considerao
que
blocos
contguos
de
dados
geralmente
so
alocados/liberados simultaneamente. Desta forma, pode-se enxergar o disco
como um conjunto de segmentos de blocos livres. Assim, pode-se manter
uma tabela com o endereo do primeiro bloco de cada segmento e o nmero
de blocos contguos que se seguem.
-
Alocao
contgua: armazena o arquivo em blocos
seqencialmente dispostos no disco. O arquivo localizado
atravs do endereo do primeiro bloco de sua extenso em
blocos. O principal problema neste tipo de alocao a existncia
de espao livre para novos arquivos, que deve ser contgua.
Utiliza as estratgias best-fit, worst-fit e first-fit (j conhecidas)
para definir onde o arquivo ser alocado. Causa alto ndice de
fragmentao no disco.
Alocao encadeada: nesta modalidade o arquivo organizado

como um conjunto de blocos ligados logicamente no disco,
independente de sua localizao fsica, onde cada bloco possui
um ponteiro para o bloco seguinte. A fragmentao no
representa problemas na alocao encadeada, pois os blocos
livres para alocao do arquivo no necessariamente precisam
estar contguos. O que acontece a quebra do arquivo em vrios
pedaos, o que aumenta o tempo de acesso. Neste tipo de
alocao s se permite acesso seqencial aos blocos do arquivo,
sendo esta uma das principais desvantagens da tcnica. Outra
129
desvantagem a perda de
armazenamento dos ponteiros.
-
espao
nos
blocos
com
Alocao indexada: esta tcnica soluciona a limitao da

alocao encadeada, no que diz respeito ao acesso, pois permite
acesso direto aos blocos do arquivo.
Isso conseguido
mantendo-se os ponteiros de todos os blocos do arquivo em uma
nica estrutura chamada bloco de ndice. Este tipo de alocao,
alm de permitir acesso direto aos blocos, no utiliza informaes
de controle nos blocos de dados.
10.4 Proteo de acesso:

Considerando-se que os meios de armazenamento so compartilhados
por vrios usurios, fundamental que mecanismos de proteo sejam
implementados para garantir a integridade e proteo individual dos arquivos
e diretrios:
-
Senha de acesso: mecanismo de simples implementao, mas

apresenta duas desvantagens: no possvel determinar quais os
tipos de operao podem ser efetuadas no arquivo, e, se este for
compartilhado, todos os usurios que o utilizam devem conhecer
a senha de acesso.
Grupos de usurio: muito utilizada em muitos Sistemas

Operacionais. Consiste em associar cada usurio a um grupo. Os
grupos so organizados logicamente com o objetivo de
compartilhar arquivos e diretrios no disco. Este mecanismo
implementa trs nveis de proteo: OWNER (dono), GROUP
(grupo) e ALL (todos). Na criao do arquivo o usurio especifica
se o arquivo pode ser acessado somente pelo seu criador, pelo
grupo ou por todos os usurios, alm de definir que tipos de
acesso podem ser realizados (leitura, escrita, execuo e
eliminao)
Lista de controle de acesso: uma lista associada ao arquivo

onde so especificados quais os usurios e os tipos de acesso
permitidos. O tamanho dessa estrutura pode ser bastante extenso
se considerarmos que um arquivo pode ser compartilhado por
vrios usurios. Alm deste problema, h o inconveniente de se
fazer acesso seqencial lista toda vez que um acesso
solicitado. Em determinados sistemas de arquivos pode-se utilizar
uma combinao de proteo por grupos de usurios ou por listas
de acesso, oferecendo assim maior flexibilidade ao mecanismo de
proteo de arquivos e diretrios.
130
BIBLIOGRAFIA
Arquitetura de Sistemas Operacionais
Francis B. Machado
Ed. LTC
Sistemas Operacionais: Conceitos e Aplicaes
Abraham Silberschatz
Ed. Campus
Sistemas Operacionais Modernos
A.S. Tanenbaum
Operating Systems: Design And Implementation
Andrew S. Tanenbaum - Editora Prentice Hall
131

Apostila Fundamentos de Sistemas Operacionais

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Apostila Fundamentos de Sistemas Operacionais

Încărcat de

Drepturi de autor:

Formate disponibile

Apostila da disciplina de

Arquitetura de Sistemas Operacionais