Material de Apoio para o Segundo Seminario de So

2 Seminrio de Avaliao da disciplina de Sistemas Operacionais
(3 Nota de Avaliao)
Critrios para avaliao:
O seminrio ser realizado em duplas escolhidas pelo professor desta disciplina. Ter nota de
avaliao do contedo apresentado e entregue, tambm ser avaliada a postura e clareza
apresentada aos demais colegas de sala. Cada apresentao ser filmada pelo professor
responsvel pela avaliao.
Grupo 01 Viso Geral

Discentes: Fbio e Raquel
Grupo 02 Conceitos de Hardware e Software
Discentes: Ivanete e Renata
Grupo 03 Concorrncia
Discentes: Bruna e Ana
Grupo 04 Estrutura do Sistema Operacional
Discentes: ngela e Laura
Grupo 05 Processos
Discentes: Thbata e Claudinia
Grupo 06 Thead
Discentes: Cleyton e Everton
Grupo 07 Sincronizao e Comunicao entre processos
Discentes: Adriana e Leidiany
Material de apoio para a realizao do Segundo Seminrio

Arquitetura de Sistemas Operacionais
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.
p ro g ra m a d o re s
e a n a li s ta s
u su rio s
p ro g ra m a s,
s is te m a s e
a p l i c a ti v o s
U s u r io s
S is te m a O p e r a c io n a l
m e m r ia
d is c o s
H a rd w a re
fi t a s
U CP
im p r e ss o ra s
m o n i to r e s
Fig. 1.1 - Viso do Sistema Operacional
1.3 Mquina de nveis: Uma mquina, do ponto de vista do hardware, tem pouca utilidade. atravs do
software que esta mquina ganha utilidade (como armazenamento de dados, impresso, etc.) Uma operao efetuada
por software pode ser implementada em hardware, bem como uma funo executada pelo hardware pode ser simulada
via software.
Os primeiros computadores eram programados atravs de fios ligados em painis, criando grandes
dificuldades e exigindo grande conhecimento da mquina.
A soluo veio com o surgimento do SO, tornando a interao com o usurio mais simples, confivel e
eficiente. (Figura 1.2)
u su rio s
S is te m a O p e r a c i o n a l
H a r d w a re
Fig. 1.2 - Viso do computador pelo usurio
O computador pode ser visualizado como uma mquina de nveis ou mquina de camadas. Inicialmente
vemos apenas dois nveis: hardware (nvel 0) e SO (nvel 1). Assim, o usurio pode enxergar a mquina como sendo
apenas o SO, como se o hardware no existisse. Esta viso chamada de mquina virtual.
Na verdade no existem apenas dois nveis, e sim tanto quantos forem necessrios para adequar o usurio s
suas diversas aplicaes. A figura 1.3 representa a estrutura da maioria dos computadores, podendo conter mais ou
menos camadas. A linguagem utilizada em cada um destes nveis diferente, variando da mais elementar (baixo
nvel) mais sofisticada (alto nvel).
A p l ic a ti v o s
U ti li t r i o s
S is te m a O p e r a cio n a l
Lin g u a g e m d e M q u in a
M ic r o p ro g r a m a o
C i r c u i to s E l e tr n ic o s
Fig. 1.3 - Mquina de Nveis
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.
3
T ip o s d e
S is te m a s O p e r a c io n a is
S is te m a s
M o n o p r o g r a m v e is /
M o n o ta r e f a
S is te m a s
M u l ti p r o g r a m v e i s /
M u l ti t a r e f a
S is te m a s
c o m M lti p l o s
P ro ce ssa d o re s
Fig. 1.4 - Tipos de Sistemas Operacionais
1.4.1 SOs monoprogramveis/monotarefa

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

Os SOs multiprogramveis ou multitarefas so uma evoluo do SO monoprogramveis. Neste tipo de SO
os recursos computacionais so compartilhados entre diversos usurios e aplicaes. Aqui vrias aplicaes
compartilham esses mesmos recursos.
Aqui tambm, enquanto um programa espera por uma operao de leitura ou gravao em disco, outros
programas podem estar sendo processados neste intervalo de tempo. Neste exemplo, observamos o compartilhamento
da memria e do processador. O SO se preocupa em gerenciar o acesso concorrente a seus diversos recursos, de
forma ordenada e protegida, entre os diversos programas (Figura 1.6).
p ro g ra m a /
ta r e f a
p ro g ra m a /
ta r e f a
U CP
M e m r ia
P r in c ip a l
D i s p o s itiv o s
d e E/S
p ro g ra m a /
ta r e f a
p ro g ra m a /
ta r e fa
p ro g ra m a /
ta r e f a
Fig. 1.6 Sistemas multiprogramveis / multitarefa
A vantagem deste tipo de SO a reduo do tempo de resposta das aplicaes processadas no ambiente e de
custos, a partir do compartilhamento de recursos do sistema entre diferentes aplicaes. Apesar de mais eficientes, os
SO multiprogramvel tem implementao muito mais complexa.
Baseado no nmero de usurios que interagem com o sistema, o SO multiprogramvel pode ser classificado
como monousurio ou multiusurio. Os sistemas multiprogramveis monousurio so encontrados em computadores
pessoais e estaes de trabalho, onde apenas um usurio interage com o sistema. Por exemplo, um usurio pode
executar um editor de texto, ao mesmo tempo em que acessa a Internet e imprime um documento. Nos sistemas
multiusurios, permite-se que diversos usurios conectarem-se ao sistema simultaneamente. A tabela 1.1 relaciona os
tipos de sistemas em funo do nmero de usurios.
Monoprogramao / Monotarefa
Multiprogramao / Multitarefa
Um usurio
Monousurio
Monousurio
Dois ou mais usurios

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

Os sistemas batch foram os primeiros SOs multiprogramveis implantados na dcada de 60. Os programas,
tambm chamados de jobs, eram executados atravs de cartes perfurados e armazenados em discos ou fitas, onde
aguardavam para serem processados. Posteriormente, em funo da disponibilidade de espao na memria principal,
os jobs eram executados, produzindo uma sada em disco ou fita.
Este tipo de processamento se caracteriza por no exigir a ateno do usurio com a aplicao. Todas entradas e
sadas eram implementadas por algum tipo de memria secundaria, geralmente discos. Clculos numricos,
compilaes, ordenaes e backups so exemplos de aplicaes batch.
Estes sistemas podem ser bastante eficientes, por utilizar melhor o processador, entretanto, podem oferecer
tempos de resposta longos. Atualmente no existem sistemas exclusivamente batch, sendo executados atravs de
simulaes quando necessrio.
1.4.2.2 Sistemas de Tempo compartilhado
Os sistemas de tempo compartilhado (time-sharing), permitem que diversos programas sejam executados a
partir da diviso de tempo do 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, 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.
6
O uso de mltiplos processadores permitiu a criao de sistemas voltados para processamento cientfico (como a
criao do mapa gentico), no desenvolvimento aeroespacial, prospeco de petrleo, simulaes, processamento de
imagens, CAD e previso do tempo. Pode-se afirmar que qualquer aplicao que faca uso intensivo do processador,
ser beneficiada pelo acrscimo de processadores ao sistema. A evoluo destes sistemas se deve em grande parte, ao
elevado custo de desenvolvimento de processadores de alto desempenho. menos custoso interligar diversos
processadores menores do que desenvolver um mais poderoso.
Alm dos mesmos benefcios dos sistemas multiprogramveis, o sistema com mltiplos processadores
apresentam vantagens como:
Escalabilidade: a possibilidade de se aumentar o poder computacional do sistema, adicionando-se novos
processadores.
Disponibilidade: a capacidade de manter o sistema em operao mesmo em caso de falha de uma ou mais
maquinas. No caso de uma falha, as outras mquinas assumem suas funes de maneira transparente ao usurio,
embora com menor poder de computao.
Balanceamento de carga: a possibilidade de distribuir o processamento entre os diversos processadores,
melhorando assim o desempenho do sistema como um todo.
Um fator-chave na criao de SOs com mltiplos processadores a forma de comunicao entre eles e o
grau de compartilhamento da memria e dos dispositivos de entrada e sada. Assim, podemos classificar os sistemas
com mltiplos processadores em fortemente acoplados ou fracamente acoplados (Figura 1.8).
Sistemas
Com Mltiplos
Processadores
Sistemas
Fortemente
Acoplados
Sistemas
Fracamente
Acoplados
Fig. 1.8 Tipos de Sistemas com mltiplos processadores
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).
U CP
M e m r ia
P r in c ip a l
de E/S
U CP
D is p o s itiv o s
de E/S
Fig 1.9 Sistemas fortemente acoplados
Em virtude disso, este tipo de sistema tambm chamado de multiprocessador.

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

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

multicomputadores. Neste modelo, cada sistema computacional tambm pode ser formado por um ou mais
processadores.
At meados dos anos 80, as aplicaes eram centralizadas em sistemas de grande porte, com um ou mais
processadores. Nesta configurao, os usurios utilizavam terminais no-inteligentes conectados a linhas seriais
dedicadas ou mesmo a linhas telefnicas pblicas para comunicao interativa com estes sistemas. No modelo
centralizado, os terminais no tem poder de processamento. A solicitao de uma tarefa ao sistema feita atravs de
linhas de comunicao.
A evoluo dos computadores pessoais e tambm das telecomunicaes, fez com que um novo modelo de
computao surgisse, chamado de modelo de rede de computadores. Em uma rede existem dois ou mais sistemas
independentes (hosts), interligados atravs de linhas de comunicao, oferecendo algum tipo de servio aos demais.
Assim, a informao deixa de ser centralizada em sistemas de grande porte e passa a ser distribuda pelos diversos
sistemas da rede.
Baseando-se no grau de integrao dos hosts da rede, dividimos os sistemas fracamente acoplados em
sistemas operacionais de rede e sistemas distribudos. A diferena bsica entre eles a capacidade do SO criar uma
imagem nica dos servios disponibilizados pela rede.
Os sistemas operacionais de rede (SORs) permitem que um host compartilhe seus recursos como impressora
ou disco, com os demais hosts da rede. Um exemplo disto so as redes locais.
Nos sistemas distribudos o sistema operacional esconde os detalhes dos hosts individuais e passa a trat-los
como um conjunto nico, como se fosse um sistema fortemente acoplado. Nos sistemas distribudos, uma aplicao
pode ser dividida em partes e cada parte pode ser executada por hosts diferentes da rede de computadores. Para os
usurios e suas aplicaes, como se no existisse a rede de computadores, e sim um nico sistema centralizado.
Outro exemplo de sistema distribudo so os clusters. Em um cluster existem dois ou mais servidores
ligados, atravs de uma conexo de alto desempenho. O usurio no conhece os nomes dos membros do cluster e no
sabe quantos so. Basta solicitar um servio ao cluster para obt-lo. Este tipo de sistema usado atualmente em
sistemas de banco de dados e Web, garantindo alta disponibilidade, escalabilidade e balanceamento de carga
soluo.

Captulo 2
CONCEITOS DE HARDWARE E SOFTWARE
2.1 Introduo:
Neste captulo sero apresentados brevemente, conceitos bsicos de hardware e software, para compreenso
dos captulos seguintes.
2.2 Hardware
Um sistema computacional um conjunto de circuitos eletrnicos interligados, formado por Processador ou
unidade central de processamento, memria principal e dispositivos de entrada/sada.
P ro ce ssa d o r / U C P
U n id a d e L g ic a
e A r i tm t i c a
U n id a d e d e
C o n tr o le
M e m r ia
P r in c ip a l
R e g is tr a d o r e s
D is p o s itiv o s
de E/S
Fig. 2.1 Sistema Computacional
2.2.1 Processador
Um processador composto por unidade de controle, unidade lgica e aritmtica, e registradores. A unidade
de controle (UC) responsvel por gerenciar as atividades de todos os componentes do computador, como a gravao
de dados em discos ou a busca de instrues na memria. A unidade lgica e aritmtica (ULA), como o nome indica,
responsvel pela realizao de operaes lgicas (testes e comparaes) e aritmticas (somas e subtraes).
2.2.2 Memria
A memria composta por unidades de acesso chamadas clulas, sendo cada clula composta por um
determinado nmero de bits. Atualmente, a grande maioria dos computadores utiliza o byte (8 bits) como tamanho de
clula.
Memrias volteis precisam estar sempre energizadas para manter suas informaes, o que no acontece
com as no-volteis.
in s tr u o o u d a d o
e n d e re o s
16
2 -1
c lu la = 8 b its
Fig. 2.2 Memria principal com 64 Kbytes
2.2.3 Memria Cache

A memria cache uma memria voltil de alta velocidade, porm com pequena capacidade de
armazenamento. O tempo de acesso a um dado nela contido muito menor que se o mesmo estivesse na memria
principal. O propsito do uso da memria cache minimizar a disparidade existente entre a velocidade com que o
processador executa instrues e a velocidade com que dados so acessados na memria principal.
2.2.4 Memria Principal e Secundaria
A memria principal um dispositivo de armazenamento, em geral voltil, onde so armazenados instrues
e dados utilizados pelo processador durante a execuo de programas. A memria secundria um dispositivo novoltil com maior capacidade de armazenamento, porm com menor velocidade de acesso aos seus dados
armazenados.
R e g i s tr a d o r e s
M e m r ia C a c h e
m a io r
ca p a cid a d e d e
a r m a z e n a m e n to
M e m r ia P r in c ip a l
m a io r c u s to e
v e lo cid a d e
d e a ce sso
M e m r ia S e c u n d r ia
Fig. 2.3 Relao entre dispositivos de armazenamento
10
2.2.5 Dispositivos e Entrada/Sada

Os dispositivos de entrada e sada podem ser divididos em duas categorias: os que so utilizados como
memria secundria e os que servem para a interface usurio-mquina. Os dispositivos utilizados como memria
secundria (discos e fitas magnticas) caracterizam-se por ter capacidade de armazenamento bastante superior ao da
memria principal. Seu custo relativamente baixo, porm o tempo de acesso memria secundria bem superior
ao da memria principal. Outros dispositivos tm como finalidade a comunicao usurio-mquina, como teclados,
monitores de vdeo, impressoras e plotters.
2.2.6 Barramentos ou Bus
Barramentos o meio fsico de comunicao entre as unidades funcionais de um sistema computacional. Os
barramentos 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.
M e m r ia
P r in c ip a l
U C P
B a r r a m e n to p r o ce s sa d o r - m e m r ia
A d a p ta d o r
B a r r a m e n to d e E / S
A d a p ta d o r
Fig. 2.4 Barramentos processador-memria e de E/S
11
M e m r ia
P r in c ip a l
U CP
B a r r a m e n to p r o c e s s a d o r - m e m r i a
B a r r a m e n to
d e b a ck p la n e
A d a p ta d o r
A d a p ta d o r
A d a p ta d o r
Fig. 2.5 Barramento de Backplane
2.2.7 Pipeline
uma tcnica que permite ao processador executar mltiplas instrues paralelamente em estgios
diferentes.
P1
P2
P3
P4
U n id a d e d e
b u sca d a
in s tr u o
A n a lis a d o r
da
in stru o
U n id a d e d e
b u sca d o s
dados
U n id a d e d e
e xe cu o d a
in stru o
P1
P2
P3
P4
I n s t r. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
I n s t r. 5
I n s t r. 6
I n s t r. 7
I n s t r. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
I n s t r. 5
I n s t r. 6
I n s tr. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
I n s t r. 5
I n s tr. 1 I n s t r. 2
I n s t r. 3
I n s t r. 4
te m p o
Fig. 2.6 Arquitetura pipeline com quatro estgios
12

Captulo 3
CONCORRNCIA
3.1 Introduo:
Os sistemas operacionais podem ser vistos como um conjunto de rotinas que executam concorrentemente de
forma ordenada. A possibilidade de o processador executar instrues em paralelo com operaes de E/S permite que
diversas tarefas sejam executadas concorrentemente. Concorrncia o princpio bsico para projeto e implementao
dos sistemas operacionais multiprogramveis.
Os SOs monoprogramveis eram limitados por seus recursos no serem utilizados de forma eficiente,
limitando seu desempenho. Muitos recursos (alguns de alto custo), permaneciam ociosos por longos perodos de
tempo.
O disperdcio dos SOs monoprogramveis pode ser representado na Figura 3.1a, pois enquanto uma leitura
em disco realizada, o processador permanece ocioso. O tempo de espera relativamente longo, pois as operaes de
E/S so lentas comparadas s operaes dos processadores.
E/S
U CP
E/S
U C P
liv r e
(a ) S i s te m a M o n o p r o g r a m v e l
te m p o
( b ) S i s te m a M u l ti p r o g r a m v e l
te m p o
Fig. 3.1 Sistema monoprogramvel x sistema multiprogramvel
A tabela 3.1 apresenta um exemplo de um programa que l registros de um arquivo e executa, em mdia, 100
instrues por registro lido. Neste caso, o processador gasta cerca de 93% do tempo esperando o dispositivo de E/S
concluir sua operao para ento continuar o processamento.
Leitura de um registro
0,0015 s
Execuo de 100 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
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.
13
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
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 programam 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).
14
Fig. 3.2 Mecanismos de interrupo e exceo
A tabela 3.4 descreve o mecanismo de interrupo, que pode ser realizado por hardware ou software.
Para cada tipo de interrupo existe uma rotina de tratamento associada. A identificao do tipo de
interrupo fundamental para determinar o endereo da rotina de tratamento.
Existem dois mtodos utilizados no tratamento das interrupes. O primeiro utiliza uma estrutura de dados
chamada de vetor de interrupo, que contem o endereo inicial de todas as rotinas de tratamento existentes,
associadas a cada evento. Um segundo mtodo utiliza um registrador de status que armazena o tipo do evento
ocorrido. Neste mtodo, s existe uma nica rotina de tratamento, que no seu inicio testa o registrador para identificar
o tipo de interrupo e trat-la de maneira adequada.
Via Hardware
Via Software
1. Um sinal de interrupo gerado para o processador

2. Aps o termino da execuo da instruo corrente, o processador identifica o
pedido de interrupo
3. Os contedos dos registradores apropriados so salvos
4. O processador identifica qual a rotina de tratamento que ser executada e carrega
um registrador com o endereo inicial desta rotina
5. A rotina de tratamento salva o contedo dos demais registradores na pilha de
controle de programas
6. A rotina de tratamento executada
7. Aps o termino da execuo da rotina, os registradores so restaurados, retomando
a execuo do programa interrompido
Tabela 3.4 Mecanismo de interrupo
As interrupes so decorrentes de eventos assncronos (no relacionados instruo do programa). Estes

eventos podem ser imprevisveis e podem ocorrer mltiplas vezes. Isso possibilitaria a ocorrncia de mltiplas
interrupes simultneas. Par evitar esta situao, a rotina de tratamento inibir as demais interrupes. Assim, as
interrupes posteriores seriam ignoradas durante a execuo da rotina de tratamento, ou seja, no receberiam
tratamento. Interrupes com estas caractersticas so chamadas de interrupes mascarveis.
Alguns processadores no permitem que interrupes sejam desabilitadas. Neste caso, o processador precisa
saber a ordem em que ocorreram as interrupes concorrentes. Para isso, as interrupes devem possuir prioridades,
em funo de sua importncia. Normalmente, um dispositivo denominado controlador db pedidos de interrupo,
o responsvel por avaliar as interrupes geradas e suas prioridades.
Uma exceo semelhante a uma interrupo, sendo a principal diferena, o motivo pelo qual o evento
gerado. A exceo resultado direto da execuo de uma instruo do prprio programa, como a diviso de um
nmero por zero, ou a ocorrncia de um overflow e operaes aritmticas. Portanto, a exceo gerada por um
evento sncrono. Tais eventos so portanto previsveis e s podem ocorrer um nico de cada vez. Um programa com
este tipo de evento que seja reexecutado a exceo ocorrera sempre na mesma instruo.
15
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).
M e m r ia
P r in c ip a l
U CP
C o n tr o la d o r
D is p o s itiv o s d e E / S
Fig. 3.3 Controlador de dispositivos de E/S
O controlador simplificou as instrues de E/S, pois o processador no necessitaria utilizar instrues

detalhadas.
Com a utilizao do controlador, existiam duas maneiras bsicas pelas quais o processador gerenciava as
operaes de E/S:
- Na primeira, o processador sincroniza-se com o perifrico para o inicio da troca de dados entre eles, e
depois de iniciada a transferncia, o sistema ficava permanentemente testando o estado dos perifricos para saber
quando a operao de E/S terminaria. Este tipo de controle, chamado de E/S controlada por programa, mantinha o
processador ocupado at o fim da operao de E/S (busy wait). Isto provocava um desperdcio de tempo, pois o
processador executa uma instruo muito mais rapidamente que a realizao de uma operao de E/S.
- Na segunda, h uma evoluo do modo anterior, onde uma vez iniciada a transferncia de dados, o
processador permanece livre para realizar outras tarefas. Neste caso, em determinados intervalos de tempo, o SO deve
testar os dispositivos para saber do trmino da operao de E/S (polling). Esta tcnica permitiu um tipo de
paralelismo, sendo a base dos sistemas multiprogramveis. O nico inconveniente desta tcnica, que caso haja
muitos perifricos, o processamento ser interrompido freqentemente.
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
16
inicia da memria onde os dados sero lidos ou gravados e o tamanho do bloco. Com estas informaes, o
controlador realiza a transferncia entre o perifrico e a memria principal, e o processador ser interrompido
somente no final da operao. A rea de memria utilizada pelo controlador na tcnica de DMA chamada de buffer
de entrada/sada.
Na tcnica de DMA, o controlador assume momentaneamente o controle do barramento. Neste caso, a
utilizao do barramento passa ser exclusiva do perifrico, e o processador suspende temporariamente o acesso ao
barramento. O processador pode nestas horas, realizar tarefas que no dependa, do barramento, como por exemplo,
acesso memria cache.
3.4 Buffering
A tcnica de buffering consiste na utilizao de uma rea na memria principal, denominada buffer, para a
transferncia de dados entre os dispositivos de E/S e a memria. Esta tcnica permite que em uma operao de leitura,
o dado seja primeiramente transferido para o buffer, liberando imediatamente o dispositivo para uma nova leitura.
Assim, enquanto o processador processa o dado localizado no buffer, o perifrico realiza outra operao de leitura,
simultaneamente. O mesmo mecanismo pode ser aplicado s gravaes (Figura 3.4)
M e m r ia
P r in c ip a l
g ra v a o
U CP
g ra v a o
C o n tr o la d o r
B u ff e r
l e i tu r a
l e itu r a
Fig. 3.4 Operaes de E/S utilizando buffer
O objetivo desta tcnica manter, na maior parte do tempo, processador e dispositivos de E/S ocupados, pois
minimiza o problema da disparidade da velocidade de processamento entre o processador e os dispositivos.
A unidade de transferncia utilizada no buffering o registro, que tem seu tamanho definido em funo:
- Da natureza do dispositivo. Por exemplo, uma linha gerada por uma impressora, ou um caractere de um
teclado.
- Da aplicao, definido em arquivo.
Logicamente o buffer deve permitir armazenar diversos registros, de forma que hajam dados lidos e ainda
no processados, ou processados mas ainda no gravados. Isto torna o processo bastante eficiente, pois possvel
compatibilizar a diferena existente entre o tempo em que o processador executa instrues e o tempo em que o
dispositivo de E/S realiza suas operaes de leitura e gravao.
3.5 Spooling
A tcnica de spooling (simultaneous peripheral operation on-line), introduzida no final dos anos 50, visa
aumentar o grau de concorrncia e a eficincia dos SOs.
Semelhante tcnica de buffering, a tcnica de spooling utiliza uma rea em disco como se fosse um grande
buffer. Neste caso, os dados podem ser lidos ou gravados em disco, enquanto programas so executados
concorrentemente.
Esta tcnica esta presente na maioria dos SOs, utilizada no gerenciamento de impresso. No momento em
que um comando de impresso executado, as informaes a serem impressas so gravadas antes em um arquivo em
disco, conhecido como arquivo de spool, liberando o programa para outras atividades. Posteriormente, o SO se
encarrega de direcionar o contedo do arquivo de spool para a impressora (Figura 3.5).
Pro g ra m a
A r q u iv o
de Spoo l
Im p re sso ra
Fig. 3.5 Tcnica de Spooling
17
Esta tcnica desvincula o programa do dispositivo impressor, impedindo que um programa reserve a
impressora para uso exclusivo. O SO gerencia a seqncia de impresses solicitadas pelos programas, seguindo
critrios de segurana e de uso eficiente das impressoras.
3.6 Reentrncia
Em sistemas multiprogramveis, vrios usurios podem utilizar o mesmo aplicativo simultaneamente. Se
cada um deles trouxesse o programa para uma rea de memria, haveria desperdcio de recursos (espao em
memria).
Chamamos de reentrncia, a capacidade de um cdigo executvel (cdigo reentrante) ser compartilhado
entre vrios usurios, exigindo apenas uma cpia do programa em memria. Esta tcnica permite que cada usurio
possa estar em um ponto diferente do cdigo reentrante, manipulando dados prprios e exclusivos de cada usurio
(Figura 3.6).
u s u r io A
u s u r io C
c d i g o r e e n tr a n te
u s u r io B
u s u r io D
r e a d e d a d o s d o u s u r io A
r e a d e d a d o s d o u su r io B
r e a d e d a d o s d o u s u r io C
r e a d e d a d o s d o u s u r io D
M e m r ia P r in ci p a l
Fig. 3.6 Reentrncia
3.7 Proteo do Sistema

A complexidade de um sistema multiprogramvel resulta em alguns problemas de proteo. Considerando
que diversos usurios compartilham os mesmos recursos, como memria e processador, deve existir uma preocupao
com a confiabilidade e integridade dos dados e programas dos usurios, alem do prprio SO.
Como vrios programas ocupam a memria simultaneamente, cada usurio possui uma rea reservada onde
seus dados e cdigo so armazenados. O SO deve preservar estas informaes. Caso um programa tente acessar uma
posio de memria fora de sua rea, um erro indicando a violao deve ocorrer.
Semelhante ao compartilhamento de memria, um disco armazena arquivos de diferentes usurios.
Novamente o SO deve garantir a integridade e confidencialidade dos dados de cada usurio. O compartilhamento de
arquivos em disco permite que dois ou mais usurios acessem um mesmo arquivo simultaneamente pelo SO.
No sistema multiprogramvel, diversos programas compartilham o processador. Portanto, deve ser tarefa do
SO tambm, o controle da utilizao do processador, evitando que algum programa monopolize seu uso.
Assim, o SO deve implementar diversos mecanismos de proteo que controlem o acesso concorrente aos
diversos recursos do sistema. Estes mecanismos sero abordados em captulos posteriores.
18

Captulo 4
ESTRUTURA DO SISTEMA OPERACIONAL
4.1 Introduo:
O Sistema Operacional formado por um conjunto de rotinas que oferecem servios aos usurios, s suas
aplicaes, e ao prprio sistema. Este conjunto de rotinas denominado ncleo do sistema ou kernel.
No confundir o ncleo do sistema com aplicaes, utilitrios ou interpretadores de comando, que
acompanham o SO. (Figura 4.1). As aplicaes so utilizadas pelos usurios e no mostram os detalhes da interao
com o sistema. Os utilitrios, como compiladores e editores de texto, e os interpretadores de comando, permitem aos
usurios, administradores e desenvolvedores, uma interao amigvel com o sistema.
A p l ic a ti v o s
U tilit r io s
N c le o d o
H a rd w a re
Fig. 4.1 Sistema Computacional
Uma das dificuldades de se compreender o funcionamento de um SO, devido ao fato que ele no possui um
incio, um meio e um fim, como outras aplicaes. Suas aes dependem de eventos que no ocorrem em uma ordem
pr-definida. Muitos eventos esto relacionados ao hardware e ao prprio sistema.
As principais funes do ncleo na maioria dos SOs esto listadas a seguir:
Tratamento de interrupes e excees;
Criao e eliminao de processos e threads;
Sincronizao e comunicao entre processos e threads;
Escalonamento e controle dos processos e threads;
Gerncia de memria;
Gerncia do sistema de arquivos;
Gerncia de dispositivos de E/S;
Suporte a redes locais e distribudas;
Contabilizao do uso do sistema;
Auditoria e segurana do 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.2 System Calls
19
Uma grande preocupao no projeto de um SO, quanto a sua integridade, ou seja, a proteo do ncleo do
sistema contra possveis acessos no-autorizados.
As system calls (chamadas ao sistema) podem ser entendidas como uma porta de entrada para o acesso ao ncleo
do sistema e seus servios. Quando um usurio ou aplicao necessitar de algum servio do sistema, feita uma
chamada a uma de suas rotinas atravs de uma system call. O termo system call tpico de ambientes Unix, no
ambiente Windows conhecida como API (Application Program Inteface).
Para cada servio disponvel existe uma system call associada. Cada SO tem seu prprio conjunto de chamadas
diferentes (Figura 4.2). Isto explica o fato de uma aplicao desenvolvida para um SO, no pode ser executada em
outro.
S y s te m C a l l
A p lic a o
N c le o d o
B ib li o te c a
H a rd w a re
Fig. 4.2 System call
Algumas tentativas foram feitas para padronizar uma biblioteca de chamadas. O padro POSIX (Portable
Operating System Interface for Unix), por exemplo, foi estabelecido com a inteno de unificar as diversas verses
do Unix existentes.
Atravs de parmetros fornecidos nas system calls, a solicitao processada e uma resposta retornada
aplicao, junto com um status indicando erro ou no. A ativao e comunicao entre programas e o SO,
semelhante a uma sub-rotina de um programa.
As system calls podem ser divididas em grupos de funes (Tabela 4.1)
Muitos usurios e mesmo programadores no imaginam os detalhes que envolvem um simples comando de
leitura de um arquivo, quando se utiliza uma linguagem de programao de alto nvel. O compilador converte este
comando de alto nvel para uma system call especfica, que quando executada, verifica a ocorrncia de erros e retorna
os dados ao programa, de forma transparente ao usurio.
Funes
System Calls
Gerncia de processos e threads
Criao e eliminao de processos e threads

Alterao das caractersticas de processos e threads
Sincronizao e comunicao entre processos e threads
Obteno de informao sobre processos e threads
Gerncia de memria
Alocao e desalocao de memria
Gerncia de sistema de arquivos
Criao e eliminao de arquivos e diretrios

Alterao das caractersticas de arquivos e diretrios
Abrir e fechar arquivos
Obteno de informaes sobre arquivos e diretrios
Gerncia de dispositivos
Alocao e desalocao de dispositivos

Operaes de entrada/sada em dispositivos
Obteno de informaes sobre dispositivos
Tabela 4.1 Funes das system calls
4.3 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.
20
Portanto, fica claro que certas instrues s devem ser executadas pelo SO ou sob sua superviso, impedindo
assim riscos de segurana e integridade. As instrues que possuem o poder de comprometer o sistema so
conhecidas como instrues privilegiadas, enquanto que as no-privilegiadas no oferecem estes riscos.
Para que uma aplicao no execute uma instruo privilegiada, deve ser implementado no processador um
mecanismo de proteo, conhecido como modos de acesso. So basicamente dois os modos de acesso implementados
pelo processador. O primeiro o modo usurio, onde a aplicao s poder executar instrues no-privilegiadas,
tendo acesso a um numero reduzido de instrues. O segundo modo o modo kernel ou supervisor, onde a aplicao
tem acesso ao conjunto total de instrues do processador.
O modo de acesso de uma aplicao determinado por um registrador de status do processador (chamado de
PSW), Dependendo do contedo deste registrador, o hardware verifica se a instruo pode ou no ser executada pela
aplicao.
Apenas o SO deve ter acesso s instrues privilegiadas. Portanto, se uma aplicao necessitar executar uma
instruo privilegiada, deve solicitar sua execuo atravs de uma system call. A system call altera o status do PSW
para modo kernel, e ao termino de sua execuo retorna ao modo usurio (Figura 4.3). Caso uma aplicao tente
executar uma instruo privilegiada em modo usurio, o processador sinaliza um erro, uma exceo ser gerada e o
programa ser interrompido.
No mesmo exemplo do acesso ao disco, para o programa atualizar um arquivo, a aplicao deve solicitar a
operao ao SO por meio de uma system call, que altera o modo de acesso para kernel. Aps efetuar a atualizao,
retorna-se ao modo usurio.
O mecanismo de modos de acesso tambm uma boa forma de proteger o prprio ncleo do sistema residente
em memria. Por exemplo, se uma aplicao tivesse acesso rea de memria onde est o SO, um programador malintencionado ou um erro de programao poderia ter acessar esta rea e acabar danificando o sistema. Com os modos
de acesso, apenas em modo kernel poderia se efetuar tal tarefa.
Fig. 4.3 Chamada a uma rotina do sistema
4.4 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).
21
a p li c a o
a p lica o
M o d o u su rio
M o d o kern el
S y s te m c a l l
H a rdw a re
Fig. 4.4 Arquitetura monoltica
4.5 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.
22
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.6 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.
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.
23
VM
VM
VM
Ap
Ap
Ap
SO
SO
SO
H V
H V
H V
G e r n c i a d e M q u in a s V i r tu a i s
H a rd w a re
Fig. 4.6 Mquina Virtual
Temos outro exemplo desta arquitetura, na linguagem Java, criada pela Sun Microsystems. Para executar um
programa em Java, necessrio uma mquina virtual Java (ou Java Virtual Machine JVM). Qualquer SO pode
suportar uma aplicao Java, desde que exista uma JVM desenvolvida para ele. Assim, a aplicao no precisa ser
compilada para cada sistema, tornando-se independente do hardware e SO utilizado (Figura 4.7).
A p lic a o
M q u in a V ir tu a l J a v a
H a rd w a re
Fig. 4.7 Mquina Virtual Java
4.7 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).
24
M o d o u s u rio
M o do kernel
M ic r o k e r n e l
H a rd w a re
Fig. 4.8 Arquitetura Microkernel
Este conceito de Arquitetura Microkernel surgiu na dcada de 80, com o sistema operacional Mach. O ncleo
do Mach oferece basicamente quatro servios: gerncia de processos, gerncia de memria, comunicao por troca de
mensagens e operaes de E/S, todos em modo usurio.
A utilizao deste modelo permite que os servidores executem em modo usurio, ou seja, no tenham acesso
direto a certos componentes do sistema. Apenas o ncleo do SO, responsvel pela comunicao entre clientes e
servidores, executa no modo kernel. Assim, se um erro ocorrer em um servidor, este poder parar, mas o sistema no
ficar inteiramente comprometido, aumentando sua disponibilidade (tempo em que est acessvel).
Como os servidores se comunicam atravs de troca de mensagens, no importa se os clientes e servidores
so processados em um sistema com um processador, com mltiplos processadores (fortemente acoplados) ou ainda
em um ambiente de sistema distribudo (fracamente acoplados). A implementao de sistemas microkernel em
ambientes distribudos permite que um cliente solicite um servio e a resposta seja processada remotamente. Isso
permite acrescentar novos servidores medida que aumenta o numero de clientes, conferindo uma grande
escalabilidade ao SO.
Outra vantagem que a arquitetura microkernel permite isolar as funes do sistema operacional por
diversos processos servidores pequenos e dedicados a servios especficos, tornado o ncleo menor, mais fcil de
depurar e, conseqentemente, aumentando sua confiabilidade. Na arquitetura microkernel, o sistema operacional
passa a ser de mais fcil manuteno, flexvel e de maior portabilidade. Apesar de todas as vantagens deste modelo,
sua implementao, na prtica, muito difcil. Primeiro existe o problema de desempenho, devido necessidade de
mudana de modo de acesso a cada comunicao entre clientes e servidores. Outro problema que certas funes do
sistema operacional exigem acesso direto ao hardware, como operaes de E/S.
Na verdade, o que se implanta normalmente a combinao do modelo de camadas com a arquitetura de
microkernel. O ncleo do sistema, alm de ser responsvel pela comunicao entre cliente e servidor, passa a
incorporar outras funes crticas, como escalonamento, tratamento de interrupes e gerncia de dispositivos.
4.8 Projeto do Sistema
O projeto de um SO bastante complexo e deve atender inmeros requisitos, algumas vezes conflitantes,
como confiabilidade, portabilidade e facilidade de manuteno. O projeto ir depender muito da arquitetura do
hardware utilizado e do tipo de sistema que se deseja construir: batch, tempo compartilhado, mono usurio ou
multiusurio, tempo real, etc.
Os primeiros SOs foram desenvolvidos em assembly e seus cdigos possuam cerca de um milho de
instrues (ex.: IBM OS/360). Com a evoluo dos SOs e conseqentemente o aumento do numero de linhas de
25
cdigo (cerca de 20 milhes no sistema MULTICS), novas tcnicas de programao modular foram incorporadas ao
projeto, alm do uso de linguagens de alto nvel, como PL/1 e Algol. Nos SOs atuais, o nmero de linhas de cdigo
chega perto dos 40 milhes (Windows 2000), sendo escrito grande parte em linguagem C/C++, utilizando em alguns
casos, programao orientada a objetos.
Existe uma srie de vantagens na utilizao de programao por objetos no projeto e na implementao de
sistemas operacionais. Os principais benefcios so:
- melhoria na organizao das funes e recursos do sistema;
- reduo no tempo de desenvolvimento;
- maior facilidade na manuteno e extenso do sistema e
- facilidade de implementao do modelo de computao distribuda.
Alm disso, o uso de uma linguagem de alto nvel permite maior portabilidade, ou seja, o SO pode ser
adaptado para outra arquitetura de hardware. Por outro lado, o uso de linguagens de alto nvel em relao
programao assembly, apresenta perda de desempenho. Por isso, partes crticas do sistema, como device drivers, o
escalonador e as rotinas de tratamento de interrupes, so ainda desenvolvidas em assembly.
Um princpio fundamental no projeto de SOs a separao no projeto do sistema das polticas e dos
mecanismos. A poltica define o que deve ser feito, e o mecanismo define como implementar esta poltica.
26

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.
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).
27
C o n te x t o d e
S o f tw a r e
C o n te x t o d e
H a rd w a re
Pro g ra m a
E sp a o d e
E n d e r e a m e n to
Fig. 5.1 Estrutura do processo
5.2.1 Contexto de hardware

O contexto de hardware guarda o contedo dos registradores do processador. Quando um processo est em
execuo, o seu contexto de hardware est armazenado nos registradores do processador. Quando o processo perde a
utilizao da CPU, o sistema salva as informaes no contexto de hardware do processo.
O contexto de hardware fundamental nos sistemas multiprogramveis, onde o revezamento da CPU
permite que os processos sejam interrompidos e posteriormente restaurados. A troca de um processo por outro no
processador, executada pelo SO, chamada de mudana de contexto, e consiste em salvar o contedo dos
registradores do processo que esta saindo e carreg-los com os valores referentes ao do novo processo que ser
executado (Figura 5.2).
5.2.2 Contexto de software
No contexto de software so especificadas as caractersticas e limites dos recursos que podem ser alocados
pelo processo, como o numero Maximo de arquivos abertos simultaneamente, prioridade de execuo e tamanho do
buffer dos dispositivos de E/S. Muitas destas caractersticas so determinadas no momento da criao do processo,
enquanto outras podem ser alteradas posteriormente.
A maior parte das informaes do contexto de software do processo so provenientes de um arquivo do SO,
conhecido como arquivo de contas. Neste arquivo, gerenciado pelo SO, so especificados os limites dos recursos que
cada processo pode alocar. Outras informaes presentes no contexto de software so geradas dinamicamente ao
longo da execuo dos processos.
28
S iste m a O p e r a cio n a l
P ro ce sso A
Pro ce sso B
e x e c u ta n d o
S a lv a r e g is tra d o r e s d o
P ro ce ss o A
C a r r e g a r e g is tr a d o r e s d o
P r o ce ss o B
e x e c u ta n d o
S a lv a r e g is tra d o r e s d o
P r o ce ss o B
C a r r e g a r e g is tr a d o r e s d o
P ro ce ss o A
e x e c u ta n d o
Fig. 5.2 Mudana de contexto
O contexto de software composto por trs grupos de informaes sobre o respectivo processo:
identificao, quotas e privilgios.
Identificao
Cada processo criado pelo sistema recebe uma identificao nica (chamada de PID Process
IDentification), representada por um nmero e em alguns casos tambm atravs de um nome.
atravs do PID que o SO e outros processos podem fazer referncia a qualquer processo existente,
consultando e at alterando suas caractersticas.
O processo possui tambm a identificao do usurio ou do processo que o criou (owner). Cada
usurio possui uma identificao tambm nica no sistema (representada pelo UID User
Identification), que atribuda ao processo no momento de sua criao. A UID permite implementar
modelos de segurana, onde apenas os objetos (processos, arquivos, reas de memria, etc) que
possuam um UID autorizado, podem ser acessados.
Quotas
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.
29
Privilgios que afetam o prprio processo permitem que suas caractersticas possam ser alteradas,
como prioridade de execuo, limites alocados na memria principal e secundaria, etc. J os
privilgios que afetam os demais processos permitem, alem da alterao de suas prprias
caractersticas, alterar as de outros processos.
Privilgios que afetam o sistema so mais amplos e poderosos, pois esto relacionados gerncia do
ambiente, como a desativao do sistema, alterao de regras de segurana, criao de outros
processos privilegiados, modificao de parmetros de configurao do sistema, entre outros. A
maioria dos SOs possui uma conta de acesso com todos privilgios disponveis, afim de o
administrador gerenciar o SO. Nos sistemas Unix, existe a conta root, no Windows 2000 a conta
administrador e no Open VMS a conta system.
5.2.3 Espao de endereamento
O espao de endereamento a rea de memria pertencente ao processo onde as instrues e dados do
programa so armazenados para execuo. Cada processo possui seu prprio espao de endereamento, que deve ser
devidamente protegido do acesso dos demais processos. A Figura 5.3 ilustra as caractersticas da estrutura de um
processo.
nom e
P ID
o w n e r (U ID )
r e g i s tr a d o r e s
g e r a is
p rio r id a d e d e
e xe cu o
d a ta / h o r a
d e cr ia o
r e g i s tr a d o r P C
C o n te x t o d e
S o f tw a r e
C o n te x to d e
H a rd w a re
r e g i s tr a d o r S P
te m p o d e
p ro ce ssa d o r
q u o ta s
Pro gra m a
p r iv il g io s
r e g i s tr a d o r
d e s ta tu s
E sp a o d e
E n d e r e a m e n to
e n d e r e o s d e m e m r ia
p r in c ip a l a lo ca d o s
Fig. 5.3 Caractersticas da estrutura de um processo
5.2.4 Bloco de controle do processo

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

Em um estado multiprogramvel, um processo no deve alocar o processador com exclusividade, de forma
que possa ser compartilhado. Os processos passam por diferentes estados ao longo de seu processamento, em funo
de eventos gerados pelo SO ou pelo prprio processo. Um processo ativo pode encontra-se em trs estados diferentes:
Execuo (running) Um processo dito no estado de execuo quando est sendo processado
pela CPU. Em sistemas com apenas um processador, somente um processo estar sendo executado
em um dado instante. Os processos se alternam na utilizao do processador, seguindo uma poltica
estabelecida pelo SO. Em sistemas com multi-processadores, existe a possibilidade de mais de um
processo ser executado ao mesmo tempo, como tambm possvel um mesmo processo ser
executado simultaneamente em mais de um processador (processamento paralelo).
Pronto (ready) Um processo est no estado de pronto quando aguarda apenas para ser executado.
O SO que determina a ordem e o critrio pelos quais os processos neste estado devem utilizar o
processador. Este mecanismo conhecido como escalonamento.
Em geral, existem vrios processos no estado de pronto, organizados em listas encadeadas. Os
processos devem estar ordenados pela sua importncia (Figura 5.5).
L i s ta d e
p ro ce sso s
e m e s ta d o
d e p r o n to
..
..
..
..
..
..
..
..
PCB# 5
PCB# 1
..
..
..
..
..
..
..
..
L i s ta d e
p ro ce sso s
e m e s ta d o
d e e sp e ra
PCB# 9
PCB# 2
..
..
..
..
PCB#4
Fig. 5.5 Lista de PCBs nos estados de pronto e espera.
31
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
Espera Pronto Ocorre quando uma operao solicitada atendida ou o recurso esperado
concedido. No existe a mudana de espera para execuo diretamente (Figura 5.6 c).
Execuo Pronto Ocorre atravs de eventos gerados pelo sistema, como o termino da fatia de
tempo que o processo possui para sua execuo (Figura 5.6 d). Ento, aguarda nova oportunidade
para continuar seu processamento.
Quando no houver espao suficiente para todos os processos na memria principal, um processo em estado
de pronto ou espera pode ser encontrado na memria secundria. Uma tcnica conhecida como swapping retira
processos da memria principal e os traz de volta segundo seus prprios critrios. Portanto, os processos em estado de
espera e pronto, podem estar ou no residentes em memria principal (Figura 5.7).
E s ta d o d e E x e c u o
b
a
E s ta d o d e E s p e r a
E s ta d o d e P r o n to
Fig. 5.6 Mudanas de estados do processo
32
E s ta d o d e E x e cu o
r e s i d e n te
n o r e s id e n te
Fig. 5.7 Mudanas de estado do processo (2).
5.5 Criao e Eliminao de Processos

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

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

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

O conceito de processo, alm de estar associado a aplicaes de usurios, podem tambm ser implementados
na prpria arquitetura do SO. Como visto em captulo anterior, a arquitetura microkernel implementa uso intensivo de
processos que disponibilizam servios para processos das aplicaes e do prprio SO.
Quando processos so utilizados para a implementao de servios do sistema, estamos retirando cdigos de
seu ncleo, tornando-o menor e mais estvel. No caso de um ou mais servios no serem desejados, basta no ativar
os processos responsveis, o que permitir liberar memria para os processos dos usurios.
Alguns servios que o SO pode implementar atravs de processos so:
auditoria e segurana;
servios de rede;
36
contabilizao do uso de recursos;

contabilizao de erros;
gerncia de impresso;
gerncia de jobs match;
temporizao;
comunicao de eventos;
interface de comandos.
5.9 Processos CPU-Bound e I/O-Bound

Os processos podem ser classificados como CPU-Bond ou I/O-Bond, de acordo dom a utilizao do
processador e dos dispositivos de E/S.
Um processo definido como CPU-Bound (ligado CPU), quando passa a maior parte do tempo no estado
de execuo, ou seja, utilizando o processador (Figura 5.13a). Este tipo de processo realiza poucas operaes de
leitura e gravao e encontrado em aplicaes cientficas que efetuam muitos clculos.
Por outro lado, um processo I/O-Bound (ligado E/S) passa a maior parte do tempo no estado de espera, pois
realiza grande nmero de operaes de E/S (Figura 5.13b). Aplicaes comerciais, que se baseiam em leitura,
processamento e gravao so exemplos de processos deste tipo, assim como tambm os processos interativos, pela
forma de comunicao entre o usurio e o sistema, normalmente lenta, devido ao uso de terminais.
E/S
E/S
U CP
U C P
(a ) C P U - b o u n d
te m p o
(b ) I / O - b o u n d
te m p o
Fig. 5.13 Processos CPU-bound x I/O-bound

5.10 Sinais
Sinais so um mecanismo que permite notificar processos de eventos gerados pelo sistema operacional ou
por outros processos. O uso de sinais fundamental para a gerncia de processos, alm de possibilitar a comunicao
e sincronizao entre processos.
Por exemplo, ao se teclar simultaneamente as teclas Ctrl e C, para interromper um programa, o SO gera um
sinal ao processo, sinalizando a ocorrncia do evento. O processo identificando o sinal, uma rotina especial de
tratamento executada (Figura 5.14).
in te r r u p o
s in a l
[c tr l- C ]
Fig. 5.14 Uso de Sinais
Pro ce sso
Os sinais podem ser usados em conjunto com temporizadores com a inteno de sinalizar ao processo algum
evento associado ao tempo. Por exemplo, um processo que deve ser avisado periodicamente sobre uma tarefa a
realizar, como monitorar uma fila de pedidos. Aps a realizao da tarefa, o processo retorna espera do prximo
sinal.
37
A maior parte dos eventos associados a sinais so gerados pelo SO ou pelo hardware, como as excees,
interrupes, limites de quotas excedidos e alarmes de tempo. Em outros casos, os eventos so gerados a partir de
outros processos com o propsito de sincronizar suas execues.
A gerao de um sinal ocorre quando o SO, a partir da ocorrncia de eventos sncronos ou assncronos,
notifica o processo atravs de bits de sinalizao localizados no seu PCB. Um processo no responde
instantaneamente a um sinal. Os sinais ficam pendentes at que o processo seja escalonado, quando ento sero
tratados. Por exemplo, na eliminao de um processo, o sistema ativa o bit associado a este evento. O processo s
ser excludo do sistema quando for selecionado para execuo. Assim, possvel que o processo demore algum
tempo at ser eliminado de fato.
O tratamento de um sinal bem semelhante ao de uma interrupo. Quando um sinal tratado, o contexto do
processo salvo e a execuo desviada para um cdigo de tratamento de sinal (signal handler), geralmente no ncleo
do SO. Aps a execuo do tratador de sinais, o programa pode voltar a ser processado do ponto onde foi
interrompido. s vezes, o prprio processo pode tratar o sinal atravs de um tradutor de sinais definido no cdigo do
programa. possvel tambm que um processo bloqueie temporariamente ou ignore por completo alguns sinais.
Apesar do mecanismo ser parecido com o do tratamento de interrupes e excees, os propsitos so
diferentes. O sinal est para o processo assim como as interrupes e excees esto para o sistema operacional
(Figura 5.15)
P r o ce ss o
P ro ce ss o
S in a i s
I n te r r u p e s
E xce e s
H a rdw are
Fig. 5.15 Sinais, interrupes e excees.
38

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).
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.
39
S u b p ro ce sso s
P r o c e s s o s I n d e p e n d e n te s
Fig. 6.1 Concorrncia com subprocessos e processos independentes

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

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

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

Dentro de um mesmo processo, threads compartilham o mesmo contexto de software e espao de
endereamento com os demais threads, porm cada thread possui seu contexto de hardware individual. Threads so
implementados internamente atravs de uma estrutura de dados denominada bloco de controle do thread (Thread
41
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
Processo
Processo Lightweight
Thread
Tempo de criao (s)

1700
350
52
Tempo de sincronizao (s)

200
390
66
Tabela 6.1 Latncia de Processos e Threads

A utilizao do processador, dos discos e outros perifricos pode ser feita de forma concorrente pelos
diversos threads, significando melhor utilizao dos recursos computacionais disponveis. Em algumas aplicaes, a
utilizao de threads pode melhorar o desempenho da aplicao apenas executando tarefas em background enquanto
operaes E/S esto sendo processadas (Figura 6.5). Aplicaes como editores de texto, planilhas, 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).
42
T h re a d d e
e n tr a d a
B u ff e r
T h re a d d e
e xi b i o
T h re a d d e
g ra v a o
Fig. 6.5 Aplicao Multithread (b)

P ro ce sso se rvid o r
S o l ic i ta e s
Th re a d
Th re a d
Th re a d
P r o c e s s o c lie n te
P r o c e s s o c lie n te
P r o ce s s o c lie n te
Fig. 6.6 Aplicao multithread (c)
43
No apenas aplicaes tradicionais podem fazer uso dos benefcios do multithreading. O ncleo do SO
tambm pode ser implementado com o uso desta tcnica de forma vantajosa, como na arquitetura microkernel,
apresentada em captulo anterior.
6.4 Arquitetura e Implementao
O conjunto de rotinas disponveis para que uma aplicao utilize as facilidades dos threads chamado de
pacote de threads. Existem diferentes abordagens na implementao deste pacote em um SO, o que influenciar no
desempenho, na concorrncia e na modularidade das aplicaes multithread.
Threads podem ser oferecidos por uma biblioteca de rotinas fora do ncleo do SO (modo usurio), pelo
prprio ncleo do sistema (modo kernel), por uma combinao de ambos (modo hbrido) ou por um modelo
conhecido como scheduler activations. A Tabela 6.2 resume as diversas arquiteturas para diferentes ambientes
operacionais.
Ambientes
Arquitetura
Distributed Computing Environment (DCE)
Modo Usurio
Compaq Open VMS verso 6
Modo Usurio
MS Windows 2000
Modo Kernel
Compaq Unix
Modo Kernel
Compaq Open VMS verso 7
Modo Kernel
Sun Solaris verso 2
Modo Hbrido
University of Washington FastThreads
Scheduler Activations
Tabela 6.2 Arquitetura de threads para diversos ambientes operacionais
Uma das grandes dificuldades para a utilizao de threads foi a ausncia de um padro. Em 1995, o padro
POSIX P1003.1c foi aprovado e posteriormente atualizado para a verso POSIX 1003.4 a. Com este padro, tambm
conhecido como Pthreads, aplicaes comerciais multithreading tornaram-se mais simples e de fcil implementao.
O padro Pthreads largamente utilizado em ambientes Unix, como o Sun Solaris Pthreads e o DECthreads para
Digital OSF/1.
6.4.1 Threads em Modo Usurio
Threads em modo usurio (TMU) so implementados pela aplicao e no pelo SO. Para isso, deve existir
uma biblioteca de rotinas que possibilite a aplicao realizar tarefas como criao/eliminao de threads, troca de
mensagens entre threads e uma poltica de escalonamento. Neste modo, o SO no sabe da existncia de mltiplos
threads, sendo responsabilidade exclusiva da aplicao gerenciar e sincronizar os diversos threads existentes.
A vantagem deste modelo a possibilidade de implementar aplicaes multithreads mesmo em SOs que no
suportem threads. Utilizando biblioteca, mltiplos threads podem ser criados, compartilhando o mesmo espao de
endereamento do processo, alm de outros recursos (Figura 6.7). TMU so rpidos e eficientes por dispensarem
acessos ao kernel do SO, evitando assim a mudana de modo de acesso (usurio-kernel-usurio).
Os TMU possuem uma grande limitao, pois o SO gerencia cada processo como se existisse apenas um
thread. Quando o thread chama uma rotina do sistema que o coloca em estado de espera (rotina bloqueante), todo o
processo colocado no estado de espera, mesmo havendo outros threads prontos para execuo. Para contornar esta
limitao, a biblioteca tem que possuir rotinas que substituam as rotinas bloqueantes por outras que no possam
causar o bloqueio de um thread (rotinas no-bloqueantes). Todo este controle transparente para o usurio e para o
SO.
44
Th rea d 4
Th rea d 3
Th re a d 2
Th re a d 1
Th rea d 0
M odo
u su rio
B ib lio te c a
M odo
k ern el
K ern el
Figura 6.7 Threads em modo usurio

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

Threads em Modo Kernel (TMK) so implementados diretamente pelo ncleo do SO, atravs de chamadas a
rotinas do sistema que oferecem todas as funes de gerenciamento e sincronizao (Fig. 6.8). O S.O. sabe da
existncia de cada thread e pode escalon-los individualmente. No caso de mltiplos processadores, os threads de um
mesmo processo podem ser executados simultaneamente.
O grande problema para pacotes em modo kernel o seu baixo desempenho. Enquanto nos pacotes em modo
usurio todo tratamento feito sem ajuda do SO, ou seja, sem a mudana do modo de acesso (usurio-kernelusurio), pacotes em modo kernel utilizam chamadas a rotinas do sistema e, conseqentemente, vrias mudanas no
modo de acesso. A Tabela 6.3 compara o desempenho de duas operaes distintas envolvendo a criao,
escalonamento, execuo e eliminao de um processo/thread.
M odo
u su rio
B ib lio te c a
K ernel
M odo
kernel
Figura 6.8 Threads em Modo Kernel
45
Implementao
Subprocessos
Threads em Modo Kernel
Threads em Modo Usurio
Operao 1 (s)
11.300
948
34
Operao 2 (s)
1.840
441
37
Tabela 6.3 Comparao entre tempos de latncia
TM U 5
TM U 4
TM U 3
TM U 2
TM U 1
TM U 0
6.4.3 Threads em Modo Hbrido

A arquitetura de threads em modo hbrido combina as vantagens de threads implementados em modo usurio
(TMU) e threads em modo kernel (TMK). Um processo pode ter vrios TMKs, e por sua vez, um TMK pode ter
vrios TMUs. O ncleo do SO reconhece os TMKs e pode escalon-los individualmente. Um TMU pode ser
executado em um TMK, em um determinado momento, e no instante seguinte ser executado em outro.
O programador desenvolve a aplicao em termos de TMU e especifica quantos TMK esto associados ao
processo. Os TMUs so mapeados em TMK enquanto o processo est sendo executado. O programador pode utilizar
apenas TMK, TMU ou uma combinao de ambos (Figura 6.9).
O modo hbrido, apesar de maior flexibilidade, apresenta problemas herdados de ambas as implementaes.
Por exemplo, quando um TMK realiza uma chamada bloqueante, todos os TMUs so colocados no estado de espera.
TMUs que desejam utilizar vrios processos deve utilizar diferentes TMKs, o que influenciar no desempenho.
M odo
u su rio
B ib li o te c a
TM K 0
TM K 1
TM K 2
TM K 3
M odo
k ern el
K ern el
Figura 6.9 Threads em modo hbrido

6.4.4 Scheduler Activations
Os problemas apresentados no pacote de threads em modo hbrido existem devido falta de comunicao
entre threads em modo usurio e em modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em modo
kernel com o desempenho e flexibilidade do modo usurio.
Introduzido no incio dos anos 90, este pacote combina o melhor das duas arquiteturas, mas em vez de
dividir os threads em modo usurio entre os de modo kernel, o ncleo do sistema troca informaes com a biblioteca
de threads utilizando uma estrutura de dados chamada scheduler activations (Figura 6.10).
A maneira de alcanar um melhor desempenho evitar as mudanas de modos de acesso desnecessrias
(usurio-kernel-usurio). Caso um thread utilize uma chamada ao sistema que o coloque no estado de espera, no
necessrio que o kernel seja ativado, bastando que a prpria biblioteca em modo usurio escalone outro thread. Isto
possvel porque a biblioteca em modo usurio e o kernel se comunicam e trabalham de forma cooperativa. Cada
camada implementa seu escalonamento de forma independente, porem trocando informaes quando necessrio.
46
Thread 4
Thread 3
Th rea d 2
T h re a d 1
Thread 0
M odo
u su rio
B ib li o te c a
K e rn el
M odo
kern el
Figura 6.10 Scheduler activations

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

Para exemplificar o uso destes comandos, o programa chamado EXPRESSAO realiza um clculo do valor da
expresso descrita a seguir:
X := SQRT (1024) + (35.4 * 0.23) (302 / 7)
Os comandos situados entre PARBEGIN e PAREND so executados concorrentemente. O clculo final de X
s poder ser realizado quando todas as variveis dentro da estrutura estiverem sido calculadas.
PROGRAM Expressao;
VAR X, Temp1, Temp2, Temp3 : REAL;
BEGIN
PARBEGIN
Temp1 := SQRT (1024);
Temp2 := 35.4 * 0.23;
Temp3 := 302 / 7;
PAREND;
X := Temp1 + Temp2 - Temp3;
WRITELN ('x = ', X);
END.
49
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
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:
50
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).
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...
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.
51
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.
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.7 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 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.
52
P r o c e s s o d e s e ja e n tr a r
n a r e g i o c r ti c a
U P (S ) - p r o c e s s o s a i
d a r e g i o c r ti c a
L ib e ra p r o ce ss o
d a fi l a d e e s p e r a
Pro ce sso a ce ssa
a r e g i o c r tic a
F ila d e e s p e r a
d e p ro ce sso s
Fig. 7.3 Utilizao do semforo binrio na excluso mtua

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

A troca de mensagens um mecanismo de comunicao e sincronizao entre os processos, implementado
pelo sistema operacional atravs de duas rotinas do sistema SEND e RECEIVE. A rotina SEND a responsvel pelo
envio de uma mensagem para o processo receptor enquanto a rotina RECEIVE por receber a mensagem do processo
transmissor. Tais procedimentos mesmo no sendo mutuamente exclusivos permitem a comunicao entre os
processos e a sincronizao entre eles, pois uma mensagem somente poder ser lida depois de ter sido enviada e ela
somente ser envidada aps a ocorrncia de um evento.
No sistema de troca de mensagens, existe a possibilidade da mensagem se perder. Para isto foi implementado
o recurso de que o processo receptor ao receb-la dever enviar ao processo transmissor uma mensagem de
recebimento. Caso o transmissor no receber esta mensagem em um certo espao de tempo ele ir retransmitir esta
mensagem.
A comunicao entre processos pode ser feita diretamente. Bastando que o processo que deseja enviar uma
mensagem enderece explicitamente o nome do receptor. Esta caracterstica chama-se ENDEREAMENTO DIRETO
e s permitida comunicao entre dois processos.
Existe tambm o ENDEREAMENTO INDIRETO que um mecanismo que consiste no uso de uma rea
compartilhada, onde as mensagens podem ser colocadas pelo processo transmissor e retiradas por qualquer processo.
Existem duas formas de comunicao entre os processos: COMUNICAO SINCRONA e
COMUNICAO ASSINCRONA. Uma comunicao dita Sncrona, quando um processo envia uma mensagem e
fica esperando at que o processo receptor leia a mensagem e mande a notificao de recebimento. Uma comunicao
assncrona aquela em que o processo que envia a mensagem no espera notificao de recebimento.
P ro ce sso A
P ro ce sso A
P ro ce ss o B
Fig. 7.5 Comunicao direta
Pro cesso B
M a ilb o x
o u Po rt
Fig. 7.6 Comunicao indireta

7.10 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 (Nopreempo)
- Um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa (Espera circular).
54
P ro ce ss o A
P ro ce sso A
s o li c ita o
R e cu rso 2
R e cu rso 1
a lo ca d o a o
Pro ce sso A
R e cu rso 2
R e cu rso 1
P ro ce ss o B
R e cu rso 2
a lo ca d o a o
Pro ce sso B
P ro ce sso B
s o licita o
R e cu rso 1
Fig. 7.7 Espera circular

7.10.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.10.2 Deteco de Deadlock
Em sistemas que no possuam mecanismos que previnam a ocorrncia de deadlocks, necessrio um
esquema de deteco e correo do problema. A Deteco do Deadlock um mecanismo que determina a existncia
deste e identifica os recursos envolvidos no problema. Um exemplo deste tipo de detector o prprio Gerenciador de
tarefas do Windows que detecta o aplicativo que parou de responder ao sistema causado, possivelmente, por um
deadlock, como podemos ver logo abaixo:
Fig. 7.8 Exemplo de Deadlock

7.10.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.
55
Abaixo vemos a caixa de dialogo do Windows que tentar fechar o processo que pode estar parado por falta
de comunicao com o sistema.
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.
56

Material de Apoio para o Segundo Seminario de So

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Material de Apoio para o Segundo Seminario de So

Diunggah oleh

Hak Cipta:

Format Tersedia

2 Seminrio de Avaliao da disciplina de Sistemas Operacionais

Grupo 01 Viso Geral

Material de apoio para a realizao do Segundo Seminrio

1.2 Funes bsicas:

Fig. 1.1 - Viso do Sistema Operacional

Fig. 1.3 - Mquina de Nveis

1.4 Tipos de Sistemas Operacionais

Fig. 1.4 - Tipos de Sistemas Operacionais

1.4.1 SOs monoprogramveis/monotarefa

Fig. 1.5 - Sistemas monoprogramveis / monotarefa.

1.4.2 SOs multiprogramveis / multitarefa

Fig. 1.6 Sistemas multiprogramveis / multitarefa

Dois ou mais usurios

Tabela 1.1 Sistemas x Usurios

Fig. 1.7 Tipos de sistemas multiprogramveis / multitarefa.

1.4.2.1 Sistemas Batch

Fig. 1.8 Tipos de Sistemas com mltiplos processadores

1.4.3.1 Sistemas fortemente acoplados

Em virtude disso, este tipo de sistema tambm chamado de multiprocessador.

1.4.3.2 Sistemas fracamente acoplados

Fig. 1.10 Sistemas fracamente acoplados

Em funo destas caractersticas, os sistemas fracamente acoplados tambm so conhecidos como

Material de apoio para a realizao do Segundo Seminrio

Fig. 2.2 Memria principal com 64 Kbytes

2.2.3 Memria Cache

Fig. 2.3 Relao entre dispositivos de armazenamento

2.2.5 Dispositivos e Entrada/Sada

Fig. 2.4 Barramentos processador-memria e de E/S

Fig. 2.5 Barramento de Backplane

Fig. 2.6 Arquitetura pipeline com quatro estgios

Material de apoio para a realizao do Segundo Seminrio

Fig. 3.1 Sistema monoprogramvel x sistema multiprogramvel

Tabela 3.2 Caractersticas de execuo do programas

Se fossem realizados num ambiente monoprogramvel, seriam executados em seqncia, totalizando 30

Tabela 3.3 Comparao entre Mono e multiprogramao

A seguir, ser apresentado tcnicas de implementao da concorrncia, essencial num sistema

Fig. 3.2 Mecanismos de interrupo e exceo

1. Um sinal de interrupo gerado para o processador

As interrupes so decorrentes de eventos assncronos (no relacionados instruo do programa). Estes

Fig. 3.3 Controlador de dispositivos de E/S

O controlador simplificou as instrues de E/S, pois o processador no necessitaria utilizar instrues

Fig. 3.4 Operaes de E/S utilizando buffer

Fig. 3.5 Tcnica de Spooling

3.7 Proteo do Sistema

Material de apoio para a realizao do Segundo Seminrio

Fig. 4.1 Sistema Computacional

Fig. 4.2 System call

Gerncia de processos e threads

Criao e eliminao de processos e threads

Alocao e desalocao de memria

Gerncia de sistema de arquivos

Criao e eliminao de arquivos e diretrios

Alocao e desalocao de dispositivos

4.3 Modos de Acesso

Fig. 4.3 Chamada a uma rotina do sistema

4.4 Arquitetura Monoltica

Fig. 4.4 Arquitetura monoltica

4.5 Arquitetura de Camadas

Fig. 4.5 Arquitetura em camadas do OpenVMS

Fig. 4.6 Mquina Virtual

Fig. 4.7 Mquina Virtual Java

4.7 Arquitetura Microkernel

Material de apoio para a realizao do Segundo Seminrio