Apostila de SO

Licenciatura em Informtica:
Sistemas Operacionais
Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul
NDICE
1.
EVOLUO DOS SISTEMAS OPERACIONAIS .................................................................................. 04
a.
b.
c.
d.
A Primeira Gerao (1945-1955): Vlvulas e Painis com Plugs ....................................... 04

A Segunda Gerao (1955 - 1965): Transistores e Sistemas Batch .................................... 05
A Terceira Gerao (1965 - 1980): CIs e Multiprogramao .............................................. 07
A Quarta Gerao (1980-1990): Computadores Pessoais .................................................. 10
2. VISO GERAL................................................................................................................................... 13
a. Introduo ........................................................................................................................ 13
b. Funes bsicas ................................................................................................................. 13
c. Mquina de nveis ............................................................................................................. 14
d. Tipos de Sistemas Operacionais ......................................................................................... 16
3. CONCEITOS DE HARDWARE............................................................................................................ 25
a. Introduo .......................................................................................................................... 25
b. Processador ........................................................................................................................ 25
c. Memria ............................................................................................................................. 25
d. Memria Cache .................................................................................................................. 26
e. Memria Principal e Secundaria ........................................................................................ 26
f. Dispositivos e Entrada/Sada .............................................................................................. 27
g. Barramentos ou Bus ........................................................................................................... 27
h. Pipeline ............................................................................................................................... 29
4. CONCORRNCIA .............................................................................................................................. 30
a. Introduo .......................................................................................................................... 30
b. Interrupo e Exceo ........................................................................................................ 32
c. Operaes de Entrada/Sada .............................................................................................. 34
d. Buffering ............................................................................................................................. 36
e. Spooling .............................................................................................................................. 36
f. Reentrncia ........................................................................................................................ 37
5. ESTRUTURA DO SISTEMA OPERACIONAL ...............................................................................38
a. Principais Funes ............................................................................................................. 39
b. Arquitetura Monoltica ..................................................................................................... 42
c. Arquitetura de Camadas ................................................................................................... 43
d. Mquina Virtual ................................................................................................................ 44
e. Arquitetura Microkernel .................................................................................................. 46
6. PROCESSO ....................................................................................................................................... 49
a. Estrutura do Processo ........................................................................................................ 49
b. Estados do Processo ........................................................................................................... 54
c. Mudanas de Estado de Processo .................................................................................... 55
d. Criao e Eliminao de Processos..................................................................................... 57
7. THREAD ........................................................................................................................................... 59
a. Ambiente Monothread .................................................................................................... 59
b. Ambiente Multithread ..................................................................................................... 61
8. SINCRONIZAO E COMUNICAO ENTRE PROCESSOS .............................................................. 66
a. Aplicaes Concorrentes ................................................................................................. 66
b. Starvation ........................................................................................................................... 71
c. Semforos ......................................................................................................................... 73
d. Monitores ........................................................................................................................... 74
e. Deadlock ............................................................................................................................. 77
Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

9.
GERNCIA DE MEMRIA ................................................................................................................. 80
a. Alocao Contgua Simples ............................................................................................... 80

b. Segmentao de Programas ............................................................................................. 81
c. Swapping .......................................................................................................................... 85
d. Memria Virtual ................................................................................................................ 86
10. GERNCIA DE SISTEMAS DE ARQUIVOS ..................................................................................91
a. Estrutura de Diretrios .................................................................................................... 91
b. Sistemas de alocao de arquivos .................................................................................... 91
c. Gerncia de espao livre ................................................................................................... 92
d. Proteo de acesso ............................................................................................................. 93
11. BIBLIOGRAFIA .......................................................................................................................94
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 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 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.
Unidade
de Fita
Entrada
da Fita
Sistema
Sada
de Fitas
de Fita
Leitora de
Impressora
cartes
1401
(a)
7094
(b)
(c)
(d)
Figura 0.1 - Um sistema batch antigo.
1401
(e)
(f)
5
( 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
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 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
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 "timesharing", uma variante da multiprogramao, em que cada usurio tem um terminal "online". 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 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 PDP-1 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
PDP-11/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.
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
10
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.
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.
11
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.
12
Captulo 1
VISO GERAL
1.1 Introduo:
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.
13
programadores
e analistas
usurios
programas,
sistemas e
aplicativos
Usurios
Sistema
Sistema Operacional
memria
discos
Hardware
fitas
UCP
impressoras
monitores
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)
14
usurios
Sistema Operacional
Hardware
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).
Aplicativos
Utilitrios
Sistema Operacional
Linguagem de Mquina
Microprogramao
Circuitos Eletrnicos
Fig. 1.3 - Mquina de Nveis

15
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.
Tipos de
Sistemas Operacionais
Sistemas
Monoprogramveis/
Monotarefa
Sistemas
Multiprogramveis/
Multitarefa
Sistemas
com Mltiplos
Processadores
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).
16
UCP
Memria
Principal
programa/
tarefa
Dispositivos
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).
17
programa/
tarefa
programa/
tarefa
UCP
Memria
Principal
Dispositivos
de E/ S
programa/
tarefa
programa/
tarefa
programa/
tarefa
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.
Monoprogramao / Monotarefa
Multiprogramao / Multitarefa
Um usurio
Monousurio
Monousurio
Dois ou mais usurios

No disponvel
Multiusurio
Tabela 1.1 Sistemas x Usurios

18
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).
Sistemas
Multiprogramveis/
Multi tarefa
Sistemas
Batch
Sistemas de
Tempo Compartilhado
Sistemas de
Tempo Real
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 processador em pequenos
intervalos, chamados de fatia de tempo (time-slice). 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,
19
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 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
20
processadores de alto desempenho. menos custoso

processadores menores do que desenvolver um mais poderoso.
interligar
diversos
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
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).
21
Memria
Principal
UCP
Dispositivos
de E/ S
UCP
Dispositivos
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.
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).
22
link de comunicao
UCP
Memria
Principal
UCP
Dispositivos
de E/ S
Memria
Principal
Dispositivos
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 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
23
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.
24
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.
Processador / UCP
Unidade Lgica
e Aritmtica
Unidade de
Controle
Memria
Principal
Registradores
Dispositivos
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).
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.
25
Memrias volteis precisam estar sempre energizadas para manter suas

informaes, o que no acontece com as no-volteis.
0
instruo ou dado
endereos
16
2 -1
clula = 8 bits
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 no-voltil com maior capacidade de
armazenamento, porm com menor velocidade de acesso aos seus dados armazenados.
26
Registradores
Memria Cache
maior
capacidade de
armazenamento
Memria Principal
maior custo e
velocidade
de acesso
Memria Secundria
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 usuriomquina. 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 processador-memria 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.
27
Memria
Principal
UCP
Barramento processador-memria
Barramento de E/ S
Adaptador
Barramento de E/ S
Adaptador
Fig. 2.4 Barramentos processador-memria e de E/S
Memria
Principal
UCP
Barramento processador-memria
Barramento
de backplane
Adaptador
Adaptador
Barramento de E/ S
Barramento de E/ S
Adaptador
Fig. 2.5 Barramento de Backplane
28
2.2.7 Pipeline:
uma tcnica que permite ao processador executar mltiplas instrues
paralelamente em estgios diferentes.
P1
P2
P3
P4
Unidade de
busca da
instruo
Analisador
da
instruo
Unidade de
busca dos
dados
Unidade de
execuo da
instruo
P1
Instr.1 Instr.2 Instr.3 Instr.4 Instr.5 Instr.6 Instr.7
P2
Instr.1 Instr.2 Instr.3 Instr.4 Instr.5 Instr.6
P3
Instr.1 Instr.2 Instr.3 Instr.4 Instr.5
P4
Instr.1 Instr.2 Instr.3 Instr.4

tempo
Fig. 2.6 Arquitetura pipeline com quatro estgios
29
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
UCP
E/ S
UCP
livre
tempo
(a) Sistema Monoprogramvel
tempo
(b) Sistema Multiprogramvel
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 instrues
0,0001 s
Total
0,0016 s
% utilizao da CPU (0,0001 / 0,0015) = 0,066 = 6,6 %
Tabela 3.1 Exemplo de utilizao do sistema
30
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
Poucas
5 min
50 Kb
No
No
No
Prog2
Baixa
Muitas
15 min
100 Kb
No
Sim
No
Prog3
Baixa
Muitas
10 min
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
Utilizao de disco
Utilizao de impressora
Tempo total de processamento
Taxa de processamento
Monoprogramao
17 %
30 %
33%
33 %
30 min.
6 progr. / hora
Multiprogramao
33 %
67 %
67 %
67%
15 min.
12 progr. / hora
Tabela 3.3 Comparao entre Mono e multiprogramao

31
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).
Fig. 3.2 Mecanismos de interrupo e exceo

32
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 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
33
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 comunica mais
diretamente com os dispositivos de E/S, mas sim atravs do controlador (Figura 3.3).
Memria
Principal
UCP
Controlador
Dispositivos de 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.
34
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.
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
35
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)
Memria
Principal
gravao
UCP
gravao
Controlador
Buffer
leitura
leitura
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.
36
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 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).
Sistema Operacional
Programa
Arquivo
de Spool
Impressora
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.
37
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.
Aplicativos
Utilitrios
Ncleo do
Sistema Operacional
Hardware
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.
38
4.2 Principais Funes:

As principais funes do ncleo na maioria dos SOs esto listadas a seguir:
Tratamento de interrupes e excees: j explicados 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 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
39
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.
Ncleo do
Sistema Operacional
System Call
Aplicao
Biblioteca
Hardware
Fig. 4.2 System call

Algumas tentativas foram feitas para padronizar uma biblioteca de chamadas. O
padro POSIX (Portable Operating System Interface for Unix), 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.
40
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 noprivilegiadas, 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 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.
41
Fig. 4.3 Chamada a uma rotina do sistema

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).
42
aplicao
aplicao
Modo usurio
Modo kernel
System call
Hardware
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 4.5). Neste formato, as
camadas mais internas so mais privilegiadas que as externas.
43
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.
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.
44
VM 1
VM 2
VM n
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 1
Ap2
Apn
SO1
SO2
SOn
HV1
HV2
HVn
Gerncia de Mquinas Virtuais
Hardware
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).
45
Aplicao
Mquina Virtual Java
Sistema Operacional
Hardware
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.
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 enviando-se uma mensagem ao servidor, que
responde com outra mensagem. A principal funo do ncleo realizar esta
comunicao entre cliente e servidor (Figura 4.8).
46
Modo kernel
em
ag
ns
me
Modo usurio
me
ns
ag
em
Microkernel
Hardware
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).
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.
47
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.
48
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.
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.
49
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).
Contexto de
Software
Contexto de
Hardware
Programa
Espao de
Endereamento
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.
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).
50
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
provenientes de um arquivo do SO, conhecido como arquivo de contas.
gerenciado pelo SO, so especificados os limites dos recursos que cada
alocar. Outras informaes presentes no contexto de software
dinamicamente ao longo da execuo dos processos.
processo so
Neste arquivo,
processo pode
so geradas
Sistema Operacional
Processo A
Processo B
executando
Salva registradores do
Processo A
Carrega registradores do
Processo B
executando
Salva registradores do
Processo B
Carrega registradores do
Processo A
executando
51
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
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
52
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.
nome
registradores
gerais
PID
owner (UID)
prioridade de
execuo
data/hora
de criao
registrador PC
Contexto de
Software
Contexto de
Hardware
registrador SP
tempo de
processador
quotas
Programa
privilgios
registrador
de status
Espao de
Endereamento
endereos de memria
principal alocados
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).
53
ponteiros
Estado do processo
Nome do processo
Prioridade do processo
Registradores
Limites de memria
Lista de arquivos abertos
..
..
..
..
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).
54
Lista de
processos
em estado
de pronto
.
..
..
..
.
PCB#5
.
..
..
..
.
PCB#1
Lista de
processos
em estado
de espera
.
..
..
..
.
.
..
..
..
.
.
..
..
..
.
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
55
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).
Estado de Execuo
b
a
Estado de Espera
Estado de Pronto
Fig. 5.6 Mudanas de estados do processo
56
Estado de Execuo
Estado de Espera
Estado de Pronto
Estado de Espera
Estado de Pronto
residente
no residente
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).
57
Estado de Execuo
Estado de Espera
Estado de Trmino
Estado de Pronto
Estado de Criao
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;
- eliminao forcada por ausncia de recursos disponveis no sistema.
58
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).
59
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.
Subprocessos
Processos Independentes
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.
Thread
Thread
Thread
Fig. 6.2 Ambiente monothread

60
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.
Contexto
de hardware
Contexto
de hardware
Thread 1
Thread 2
Thread 3
Contexto de
software
Contexto
de hardware
Espao de
endereamento
Fig. 6.3 Ambiente Multithread

De forma simplificada, um thread pode ser definido como uma sub-rotina 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 subrotinas 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 Thread_1 e Thread_2, e executados
independentemente do programa principal. Neste processo, os trs threads so
executados concorrentemente.
61
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.
Processo
Variveis
Programa Principal
Thread_1
PC
SP
Contexto de
Hardware
...
Espao de
endereamento
Call Sub_1
Thread_2
Sub_1
Ret
PC
SP
Thread_3
Sub_2
PC
SP
Contexto de
Hardware
Fim
Contexto de
Hardware
Call Sub_2
...
Ret
Fig. 6.4 Aplicao Multithread (a)
62
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 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
Tempo de criao (s)
Tempo de sincronizao
(s)
Processo
1700
200
Processo Lightweight
350
390
Thread
52
66
Tabela 6.1 Latncia de Processos e Threads
63
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, aplicativos grficos e processadores de imagem so especialmente
beneficiados quando desenvolvidos com base em threads.
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).
Thread de
entrada
Buffer
Thread de
exibio
Thread de
gravao
Fig. 6.5 Aplicao Multithread (b)
64
Processo servidor
Solicitaes
Thread
Thread
Thread
Processo cliente
Processo cliente
Processo cliente
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.
65
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 comuniquemse 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.
Sincronizao
gr
Processo
gravador
av
a
o
i tu
le
ra
Processo
leitor
dado
Buffer
66
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.
67
Processo
principal
PARBEGIN
Comando_1;
Comando_2;
.
.
Comando_n;
PAREND
Processo 1
Processo 2
Processo n
Processo
principal
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;
68
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
69
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).
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).
70
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.
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...
71
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. 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.
72
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:
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
73
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.
0)
D
O
=
(S
W
N
N
W
(S
>
DO
0)
Processo deseja entrar

na regio crtica
UP (S) - processo sai

da regio crtica
Libera processo
da fila de espera
Processo acessa
a regio crtica
Fila de espera
de processos
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.
74
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.
Declarao de
variveis globais
Procedimentos
Monitor
Proc. 1
Proc. 2
Fila de entrada
Proc. n
Inicializao
de variveis
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
75
dever enviar ao processo transmissor uma mensagem 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.
Processo A
Processo B
Fig. 7.5 Comunicao direta

Processo A
Processo B
Mailbox
ou Port
Fig. 7.6 Comunicao indireta
76
7.9 Deadlock:
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).
Processo A
Processo A
solicita o
Recurso 2
Recurso 1
alocado ao
Processo A
Recurso 2
Recurso 1
Processo B
Recurso 2
alocado ao
Processo B
Processo B
solicita o
Recurso 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
77
tarefas do Windows que detecta o 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.
78
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.
79
Captulo 8
Gerncia de Memria / Memria Virtual
8.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.
8.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 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.
8.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
80
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
Sub-utilizao da memria principal
8.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.
81
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
Sistema
2 KB
Operacional
3 KB
4 KB
Cadastramento
Mdulo Principal
4 KB
rea de
Overlay
Impresso
2 KB
1 KB
rea livre
2 KB
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.
8.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 subutilizada. Os sistemas multiprogramveis j so muito mais eficientes no uso do
82
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.
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.
83
Memria Principal
Sistema
Operacional
Programa C
1 KB
Programa A
3 KB
Fragmentao
interna
Programa E
5 KB
Alocao particionada esttica com fragmentao interna

8.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 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
84
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.
8.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 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.
8.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
85
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.
8.9
Memria Virtual:
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
86
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 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
87
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 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 workingset. 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
88
necessitam de um working-set maior. A outra poltica a varivel, que define

um limite de working-set diferente e varivel para cada processo, em funo
de seu 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.
8.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.
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
89
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.
90
Captulo 9
Gerncia de Sistemas de Arquivos
9.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.
9.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.
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
91
aplicao controlar os mtodos de acesso aos arquivos. O UNIX utiliza tambm

alguns diretrios padronizados, de exclusividade do Sistema.
9.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 desvantagem a
perda de espao nos blocos com o armazenamento dos ponteiros.
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.
92
Este tipo de alocao, alm de permitir acesso direto aos blocos, no utiliza
informaes de controle nos blocos de dados.
9.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.
93
BIBLIOGRAFIA
DEITEL, Harvey M., DEITEL, Paul J. Sistemas Operacionais. ed. 3. So Paulo: Pearson
Education - Br, 2005.
MAIA, Luiz Paulo; MACHADO, Francis Berenger.
Operacionais. ed. 4. Rio de Janeiro: LTC, 2007.
Arquitetura
de
Sistemas
TANENBAUM, A. S. Sistemas operacionais modernos. ed. 3. So Paulo: Pearson

Prentice Hall, 2010.
94

Apostila de SO

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila de SO

Caricato da

Copyright:

Formati disponibili

Licenciatura em Informtica:

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

EVOLUO DOS SISTEMAS OPERACIONAIS .................................................................................. 04

A Primeira Gerao (1945-1955): Vlvulas e Painis com Plugs ....................................... 04

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

GERNCIA DE MEMRIA ................................................................................................................. 80

a. Alocao Contgua Simples ............................................................................................... 80

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

0.2 - A Segunda Gerao (1955 - 1965): Transistores e Sistemas Batch

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

( a ) Programadores levam cartes ao 1401.

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Figura 0.2 - Estrutura de um tpico job FMS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

cientfica. Assim, uma nica famlia de mquinas poderia satisfazer s necessidades de

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Figura 0.3 - Um sistema de multiprogramao com trs jobs na memria

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Aps o sucesso do sistema CTSS, o MIT, o Laboratrio Bell e a General

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

computador pessoal comeava. Em termos de arquitetura, os computadores pessoais

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Os sistemas operacionais distribuidos requerem mais do que a adio de

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Fig. 1.1 - Viso do Sistema Operacional

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Fig. 1.2 - Viso do computador pelo usurio

Fig. 1.3 - Mquina de Nveis

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

1.4 Tipos de Sistemas Operacionais:

Fig. 1.4 - Tipos de Sistemas Operacionais

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Fig. 1.5 - Sistemas monoprogramveis / monotarefa.

1.4.2 SOs multiprogramveis / multitarefa:

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Fig. 1.6 Sistemas multiprogramveis / multitarefa

Dois ou mais usurios

Tabela 1.1 Sistemas x Usurios

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

Os SO multiprogramveis ou multitarefa, podem ainda ser classificados pela forma

Fig. 1.7 Tipos de sistemas multiprogramveis / multitarefa.

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

permitindo ao usurio comunicar-se diretamente com o SO atravs de comandos. Assim,

Adaptada por: Prof. Me. Jefferson Silva - IFPI - CTZS

Apostila de Sistemas Operacionais - PARFOR - IFPI - Campus Teresina Zona Sul

processadores de alto desempenho. menos custoso

Alm dos mesmos benefcios dos sistemas multiprogramveis, o sistema com

Escalabilidade : a possibilidade de se aumentar o poder computacional do

Disponibilidade : a capacidade de manter o sistema em operao mesmo em

Fig. 1.8 Tipos de Sistemas com mltiplos processadores

1.4.3.1 Sistemas fortemente acoplados: