Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
1 INTRODUO E HISTRICO..........................................................................................................................4
1.1 HISTRICO..........................................................................................................................................................7
1.1.1 O Monitor Residente.................................................................................................................................9
1.1.2 Operao Off-Line..................................................................................................................................12
1.1.3 Buferizao.............................................................................................................................................14
1.1.4 Spooling..................................................................................................................................................15
1.1.5 Multiprogramao..................................................................................................................................15
1.1.6 Tempo Compartilhado.............................................................................................................................16
1.2 OS CONCEITOS DE INTERRUPO E TRAP..............................................................................................................19
2 PROCESSOS.......................................................................................................................................................22
2.1 O NCLEO DO SISTEMA OPERACIONAL.................................................................................................................27
2.1.1 Um Resumo das Funes do Ncleo.......................................................................................................28
2.2 ESCALONAMENTO DE PROCESSOS..........................................................................................................................28
2.2.1 Escalonamento FCFS ou FIFO..............................................................................................................30
2.2.2 Escalonamento Round Robin (RR)..........................................................................................................30
2.2.3 Escalonamento com Prioridades............................................................................................................32
2.2.4 Multilevel Feedback Queues...................................................................................................................33
2.2.5 Escalonamento com Prazos....................................................................................................................36
2.2.6 Escalonamento Shortest-Job-First (SJF)................................................................................................36
2.3 COMUNICAO ENTRE PROCESSOS (IPC).............................................................................................................38
2.3.1 Processamento Paralelo.........................................................................................................................38
2.3.1.1 Comandos PARBEGIN e PAREND (Dijkstra)......................................................................................................39
2.3.1.2 Comandos FORK e JOIN (Conway e Dennis)......................................................................................................40
2.3.8 Monitores................................................................................................................................................51
2.3.9 Passagem de Mensagens.........................................................................................................................57
2.4 DEADLOCKS E ADIAMENTO INDEFINIDO.................................................................................................................57
2.4.1 Exemplos de Deadlocks..........................................................................................................................57
2.4.2 Um Deadlock de Trfego........................................................................................................................57
2.4.3 Um Deadlock Simples de Recursos.........................................................................................................58
2.4.4 Deadlock em Sistemas de Spooling.........................................................................................................58
2.4.5 Adiamento Indefinido .............................................................................................................................59
2.4.6 Conceitos de Recursos............................................................................................................................60
2.4.7 Quatro Condies Necessrias para Deadlock.......................................................................................61
2.4.8 Mtodos para Lidar com Deadlocks.......................................................................................................62
2.4.9 Preveno de Deadlocks.........................................................................................................................63
2.4.9.1 Negando a Condio Mutual Exclusion................................................................................................
.............63
2.4.9.2 Negando a Condio Hold and Wait...................................................................................................................
64
2.4.9.3 Negando a Condio No Preemption...............................................................................................
..................64
2.4.9.4 Negando a Condio Circular Wait.....................................................................................................
...............64
3 GERENCIAMENTO DE MEMRIA...............................................................................................................66
3.1 CONCEITOS BSICOS..........................................................................................................................................66
3.1.1 Ligao de Endereos (Address Binding)...............................................................................................67
3.1.2 Carregamento Dinmico (Dynamic Loading).........................................................................................69
3.1.3 Ligao Dinmica..................................................................................................................................70
3.1.4 Overlays..................................................................................................................................................71
3.2 ENDEREAMENTO LGICO E ENDEREAMENTO FSICO .............................................................................................72
3.3 SWAPPING.........................................................................................................................................................74
3.4 ALOCAO CONTGUA DE MEMRIA....................................................................................................................77
3.4.1 Alocao com Partio nica................................................................................................................78
3.5 MEMRIA VIRTUAL............................................................................................................................................82
3.5.1 Paginao...............................................................................................................................................82
3.5.2 Algoritmos de Paginao........................................................................................................................82
3.5.3 Segmentao...........................................................................................................................................82
PREFCIO
O texto existente nesta apostila no de minha autoria. Na verdade, trata-se de uma
sntese de vrios autores renomados na rea de sistemas operacionais, como Tannenbaum,
Deitel, Silberschatz, entre outros.
Entretanto, alguns exemplos e analogias foram adicionados aos textos originais para
facilitar a compreenso do assunto. Este material tambm no se prope a substituir a riqueza
presente nos livros publicados pelos autores mencionados, mas sim, servir como apoio s aulas
da disciplina de Sistemas Operacionais do Curso de Cincia da Computao desta
Universidade.
Dada a grande quantidade de trechos extrados praticamente na ntegra de alguns
livros, fica impraticvel referenciar todos eles. Em compensao, os livros citados na
bibliografia, ao final desta apostila, constituem as fontes principais do texto que a partir daqui
se inicia.
Espero que realmente este grande resumo possa ser til para que os alunos da
disciplina compreendam os aspectos mais importantes dos Sistemas Operacionais.
1INTRODUO E HISTRICO
Podemos dizer sem receio que um computador sem software no passa de peso para
papel. Talvez a prova mais evidente nos dias atuais o sucesso nos sistemas operacionais da
Microsoft Corp. O grande motivo deste sucesso, apesar de muitas pessoas de renome afirmarem
que os sistemas operacionais da Microsoft no so tecnicamente bons, deve-se enorme
quantidade de software disponvel para estes sistemas operacionais.
Mas afinal, se importante para as pessoas a existncia de bons softwares que
ajudem nos seus trabalhos, como pode o sistema operacional influenciar na qualidade e na
disponibilidade de tais softwares?
Para responder esta pergunta, precisamos definir o que um sistema operacional.
Ele nada mais do que um programa de computador, que aps o processo de inicializao
(boot) da mquina, o primeiro a ser carregado, e que possui duas tarefas bsicas:
prover funes bsicas para que programas de computador possam ser escritos com
maior facilidade, de modo que os programas no precisem conhecer detalhes da
mquina para poderem funcionar.
justamente neste segundo item que os sistemas operacionais podem ser bem
sucedidos ou no, em despertar interesse para que a indstria de software e os programadores
independentes construam programas para determinados sistemas operacionais. Isto justifica
parte do sucesso do Microsoft Windows, pois, ao mesmo tempo que ele prov uma interface
bastante amigvel com o usurio, para o programador, no to difcil criar um programa com
janelas, botes, listas, etc, como seria num sistema operacional como o MS-DOS. Alm disso,
os sistemas operacionais da Microsoft rodam no hardware mais popular hoje em dia: os
computadores baseados em IBM PC.
Computadores modernos possuem um ou mais processadores, memria principal,
dispositivos de entrada e sada como discos, fitas, teclado, mouse, monitor, interface de rede,
entre outros. Escrever programas que utilizem um computador com esta complexidade de forma
eficiente muito difcil e trabalhoso. exatamente neste ponto que entram as funes do
sistema operacional: abstrair as particularidades do hardware dos programas, fornecendo a eles
facilidades para sua operao, tais como: rotinas de acesso a dispositivos diversos; funes de
armazenamento de dados como criao de arquivos, leitura e escrita de dados; e rotinas de
acesso aos dispositivos de interao com a mquina, como teclado, mouse, monitor, etc.
Dada a existncia de softwares como o sistema operacional, os programas
normalmente so classificados como software bsico (que inclui o sistema operacional), e
softwares de aplicao, que so voltados a resolver problemas dos usurios.
Podemos visualizar atravs de um diagrama a integrao entre hardware, software
bsico, e softwares aplicativos, como mostra a figura 1.1.
Figura 1.1 Integrao entre hardware, software bsico e software aplicativo
Sistema Bancrio
Controle de
Estoques
Jogos
Compiladores
Editores
Interpretador de
comandos (shell)
Sistema Operacional
Programas de
Aplicao
Programas de Sistema
(software bsico)
Linguagem de Mquina
Microprogramao
Dispositivos Fsicos
Hardware
1.1Histrico
Inicialmente, existiu somente o hardware do computador. Os primeiros
computadores eram mquinas fisicamente muito grandes que funcionavam a partir de um
console, que consiste em um perifrico ou terminal que pode ser usado para controlar a mquina
por mtodos manuais, corrigir erros, determinar o estado dos circuitos internos e dos
registradores e contadores, e examinar o contedo da memria. O console o meio de
comunicao entre o homem e a mquina, ou seja, o meio por onde o operador fornece as
entradas e por onde recebe as sadas. O console das primeiras mquinas consistia em chaves
pelas quais o operador inseria informaes, e por luzes indicativas das sadas, que podiam ser
impressas ou perfuradas em uma fita de papel.
Com o passar do tempo, o uso de teclados para entrada de dados se tornou comum,
e a sada passou a ser inicialmente impressa em papel. Posteriormente o console assumiu a
forma de um terminal com teclado e vdeo.
Nesta poca, os programadores que quisessem executar um programa, deveriam
carreg-lo para a memria manualmente atravs de chaves no painel de controle, ou atravs de
fita de papel ou cartes perfurados. Em seguida, botes especiais eram apertados para iniciar a
execuo do programa. Enquanto o programa rodava, o programador/operador podia monitorar
a sua execuo pelas luzes do console. Se erros eram descobertos, o programa precisava ser
interrompido, e o programador podia examinar os contedos da memria e registradores,
depurando-o diretamente do console. A sada era impressa diretamente, ou ainda perfurada em
fita ou carto para impresso posterior.
As dificuldades nesta poca eram evidentes. O programador era tambm o operador
do sistema de computao. Devido escassez de recursos, a maioria dos sistemas usava um
esquema de reserva para alocao de tempo da mquina. Se voc quisesse usar o computador,
deveria reservar um horrio em uma planilha.
Alm disso, este mtodo no era eficiente na utilizao de recursos. Supondo que
voc tivesse reservado 1 hora de tempo de computador para executar um programa em
desenvolvimento. Se voc tivesse alguns erros desagradveis voc provavelmente no
terminaria dentro de 1 hora, e deveria juntar seus resultados e liberar a mquina para a prxima
pessoa da fila. Por outro lado, se o seu programa rodasse sem problemas, voc poderia terminar
tudo em 35 minutos, e a mquina ficaria ociosa at a prxima reserva de horrio.
Como as mquinas nesta poca custavam muito dinheiro, pensou-se em algumas
solues para agilizar a tarefa de programao. Leitoras de cartes, impressoras de linha e fitas
magnticas tornaram-se equipamentos comuns. Montadores (assemblers), carregadores
(loaders) e ligadores (linkers) foram projetados. Bibliotecas de funes comuns foram criadas
para serem copiadas dentro de um novo programa sem a necessidade de serem reescritas.
Um bom exemplo do uso das bibliotecas de funes sobre as rotinas que
executavam operaes de entrada e sada (E/S). Cada novo dispositivo tinha suas prprias
caractersticas, necessitando de cuidadosa programao. Uma subrotina especial foi escrita para
cada tipo de dispositivo de E/S. Essas subrotinas so chamadas de device drivers (controladores
de dispositivos), e sabem como conversar com o dispositivo para o qual foram escritas. Uma
tarefa simples como ler um caractere de um disco pode envolver seqncias complexas de
operaes especficas do dispositivo. Ao invs de escrever cdigo a cada momento o device
driver simplesmente utilizado a partir de uma biblioteca.
Mais tarde, compiladores para linguagens de alto nvel, como FORTRAN e
COBOL, surgiram, facilitando muito a tarefa de programao, que antes era feita diretamente
na linguagem da mquina. Entretanto a operao do computador para executar um programa em
uma linguagem de alto nvel era bem mais complexa.
Por exemplo, para executar um programa FORTRAN, o programador deveria
Se ele os executasse nessa ordem, ele teria que preparar o job FORTRAN (carregar fitas de
compilador, etc.), ento o COBOL, e novamente o FORTRAN. Se ele executasse os dois jobs
FORTRAN como um grupo ele prepararia o ambiente FORTRAN apenas uma vez
economizando tempo de preparao.
Esta abordagem marcou uma poca, onde o processamento em batch (lotes)
definiu uma forma de utilizao do computador: os usurios preparavam seus programas e
dados, entregavam-nos ao operador do computador, que os agrupava segundo suas necessidades
e os executava, produzindo as sadas para serem devolvidas aos respectivos programadores.
Mesmo assim, quando um job parava, o operador teria que notar o fato observando
no console, determinar porque o programa parou (trmino normal ou anormal), listar contedos
de memria se necessrio e ento carregar a leitora de cartes ou de fita de papel com o
prximo job e inicializar o computador novamente. Durante a transio entre os jobs,
novamente a UCP ficava ociosa.
Para resolver este problema, foi desenvolvido um seqenciador automtico de jobs,
que consistia em um primeiro sistema operacional rudimentar. Sua funo era controlar a
transferncia automtica de um job para outro. Este programa foi implementado sob a forma de
um monitor residente, sempre presente na memria da mquina para este fim.
Assim que o computador era ligado, o monitor residente era chamado, e transferia o
controle para um programa. Quando o programa terminava, ele retornava o controle para o
monitor residente, que ia para o prximo programa. Assim, o monitor residente fornecia uma
seqncia automtica entre programas e jobs.
Para que o monitor residente pudesse saber qual programa deveria ser executado e
de que forma, cartes de controle foram introduzidos, de maneira muito semelhante s
instrues que os operadores recebiam dos programadores para execuo de seus programas.
Assim, alm do programas e dos dados para um job, cartes especiais de controle eram
introduzidos entre os cartes de programa e dados do job a executar, como por exemplo:
$JOB - Primeiro carto, indicando o incio de um job;
$FTN - Executar o compilador FORTRAN;
$LOAD - Carregar o programa compilado;
$RUN - Executar o programa carregado;
$END - Fim do job.
Os cartes de incio e fim de job eram geralmente utilizados para contabilizar o
tempo de uso da mquina, para que seu tempo de processamento pudesse ser cobrado do
usurio. Por isso, s vezes incluam parmetros indicando o usurio do job, nome do job, etc.
Para distinguir cartes de controle dos demais cartes era necessrio identific-los
com um caractere ou um padro especial no carto. Em nosso exemplo, o smbolo do dlar ($)
foi utilizado para este fim. A linguagem JCL (Job Control Language) da IBM usava duas barras
(//) nas primeiras duas colunas. A figura 1.1 ilustra este cenrio.
$END
dados do programa
$RUN
$LOAD
pgm. a ser compilado
$FTN
$JOB
Monitor
Residente
Carregador
Seqenciador automtico de jobs
Interpretador dos cartes de controle
rea do programa do usurio
1.1.2Operao Off-Line
O uso de sistemas batch com seqenciamento automtico de jobs aumentou a
performance do sistema. Entretanto, ainda assim a UCP ficava freqentemente ociosa, devido
baixssima velocidade dos dispositivos mecnicos em relao aos eletrnicos.
Os dispositivos de E/S mais lentos podem significar que a UCP fica freqentemente
esperando por E/S. Como um exemplo, um montador ou compilador pode ser capaz de
processar 300 ou mais cartes por segundo. Uma leitora de cartes mais rpida, por outro lado,
pode ser capaz de ler apenas 1200 cartes por minuto (20 cartes por segundo). Isto significa
que montar um programa com 1200 cartes precisa de apenas 4 segundos de UCP, mas 60
segundos para ser lido. Dessa forma, a UCP fica ociosa por 56 dos 60 segundos, ou 93.3% do
tempo. A utilizao de UCP resultante de apenas 6.7%. O processo similar para operaes de
sada. O problema que, enquanto uma operao de E/S est acontecendo, a UCP est ociosa,
esperando que o E/S termine; enquanto a UCP est executando, os dispositivos de E/S esto
ociosos.
Uma soluo simples era substituir as lentas leitoras de carto (dispositivos de
entrada) e impressoras de linha (dispositivos de sada) por unidades de fita magntica. A
maioria dos sistemas no final dos anos 50 e comeo dos anos 60 eram sistemas batch cujos jobs
eram lidos de leitoras de carto e escritos em impressoras de linha ou perfuradoras de cartes.
Ao invs de a UCP ler diretamente os cartes, os cartes eram primeiro copiados para uma fita
magntica. Quando a fita estava suficientemente cheia ela era transportada para o computador.
Duas abordagens para esta soluo (operao off-line) foram usadas. Dispositivos
especficos (leitoras de carto, impressoras de linha) foram desenvolvidos para provocar sada
ou entrada direta de fitas magnticas. A outra abordagem foi dedicar um pequeno computador
para a tarefa de copiar de e para a fita. O pequeno computador foi um satlite do computador
1.1.3Buferizao
Processamento off-line permite a sobreposio de operaes de UCP e E/S pela
execuo dessas duas aes em duas mquinas independentes. Se desejamos atingir tal
sobreposio em uma nica mquina, comandos devem ser colocados entre os dispositivos e a
UCP para permitir uma separao similar de execuo. Tambm, uma arquitetura adequada
deve ser desenvolvida para permitir buferizao.
Buferizao o mtodo de sobrepor E/S de um job com sua prpria computao. A
idia muito simples. Depois de os dados terem sido lidos e a UCP estar pronta para iniciar a
operao nos mesmos, o dispositivo de entrada instrudo para iniciar a prxima entrada
imediatamente. Dessa forma, a UCP e o dispositivo de entrada de dados ficam ambos ocupados.
Com sorte, no instante em que a UCP est pronta para o prximo item de dado (registro), o
dispositivo de entrada ter terminado de l-lo. A UCP pode ento comear o processamento dos
novos dados lidos, enquanto o dispositivo de entrada comea a ler os dados seguintes. De forma
semelhante isto pode ser feito para a sada. Nesse caso, a UCP cria dados que so colocados em
um buffer at que o dispositivo de sada possa receb-lo.
Na prtica, raro UCP e dispositivos de E/S estarem ocupados o tempo todo, j que
ou a UCP ou o dispositivo de E/S termina primeiro. Se a UCP termina primeiro, ela deve
esperar at que o prximo registro seja lido para a memria. importante observar que a UCP
no fica o tempo todo ociosa, no mximo o tempo que ficaria se no estivesse sendo utilizada
buferizao.
Por outro lado, se o dispositivo de entrada de dados termina primeiro, ele pode tanto
esperar como continuar com a leitura do prximo registro. Neste caso ele s dever parar
quando os buffers estiverem cheios. Para que o dispositivo de entrada continue sempre
trabalhando, normalmente os buffers costumam ter tamanho suficiente para mant-lo sempre
ocupado.
A buferizao geralmente uma funo do sistema operacional. O monitor
residente ou os drivers de dispositivo incluem buffers do sistema de E/S para cada dispositivo
de E/S. Assim, chamadas ao driver de dispositivo pelos programas de aplicao normalmente
causam apenas uma transferncia do buffer para o sistema.
Apesar da buferizao ser de alguma ajuda, ela raramente suficiente para manter a
UCP sempre ocupada, j que os dispositivos de E/S costumam ser muito lentos em relao
UCP.
1.1.4Spooling
Com o passar do tempo, dispositivos baseados em discos tornaram-se comuns e
facilitaram muito a operao off-line dos sistemas. A vantagem que em um disco era possvel
escrever e ler a qualquer momento, enquanto que uma fita precisava ser escrita at o fim para
ento ser rebobinada e lida.
Em um sistema de disco, cartes so diretamente lidos da leitora de cartes para o
disco. Quando um job executado, o sistema operacional satisfaz seus pedidos por entrada da
leitora de cartes pela leitura do disco. Da mesma forma, quando um job pede a impresso de
uma linha para a impressora, esta copiada em um buffer do sistema que escrito para o disco.
Quando a impressora fica disponvel, a sada realmente impressa.
Esta forma de processamento chamada de spooling (spool = Simultaneous
Peripheral Operation On-Line). Spooling utiliza um disco como um buffer muito grande para
ler tanto quanto possa dos dispositivos de entrada e para armazenar arquivos de sada at que os
dispositivos de sada estejam aptos para receb-los. Esta tcnica tambm muito utilizada para
comunicao com dispositivos remotos. A UCP envia os dados atravs dos canais de
comunicao para uma impressora remota (ou aceita um job completo de entrada de uma leitora
de cartes remota). O processamento remoto feito em sua prpria velocidade sem a
interveno da UCP. A UCP apenas precisa ser notificada quando o processamento termina,
para que possa passar para o prximo conjunto de dados do spool.
A diferena entre buferizao e spooling que enquanto a buferizao sobrepe o
processamento de um job com seu prprio E/S, o spooling sobrepe o E/S de um job com o
processamento de outros jobs. Assim, a tcnica spooling mais vantajosa do que a buferizao.
O nico efeito colateral a necessidade de algum espao em disco para o spool, alm de
algumas tabelas em memria.
Outra vantagem do spooling vem do fato de que a tcnica fornece uma estrutura de
dados muito importante, que a lista de jobs. A performance pode ser aumentada, pois os vrios
jobs armazenados no disco podem ser processados em qualquer ordem que o sistema
operacional decidir, buscando o aumento de utilizao da UCP (escalonamento de jobs).
Quando jobs so lidos diretamente de cartes ou fita magntica, no possvel executar os jobs
fora de ordem.
1.1.5Multiprogramao
O aspecto mais importante do escalonamento de jobs a habilidade de
1.1.6Tempo Compartilhado
O conceito de sistemas de tempo compartilhado, tambm chamados de
multitarefa, uma extenso lgica de multiprogramao. Neste ambiente, mltiplos jobs so
executados simultaneamente, sendo que a UCP atende cada job por um pequeno tempo, um a
um em seqncia. Os tempos dedicados para cada job so pequenos o suficiente para que os
usurios consigam interagir com cada programa sem que percebam que existem outros
programas rodando. Quando muitos programas esto sendo executados, a impresso que o
usurio tem de que o computador est lento, pois a UCP tem mais jobs para atender, e
portanto aumenta o tempo entre os sucessivos atendimentos para um determinado job.
fcil de entender como funcionam sistemas de tempo compartilhado quando
comparados com sistemas batch. Neste tipo de sistema operacional, um fluxo de jobs separados
lido (de uma leitora de cartes, por exemplo), incluindo seus cartes de controle que
predefinem o que faz o job. Quando o job termina, seu resultado normalmente impresso, e o
prximo job posto em execuo.
A principal caracterstica (e desvantagem) deste sistema a falta de interao entre
o usurio e o programa em execuo no job. O usurio precisa entregar ao operador o programa
que ele deseja executar, incluindo seus dados de entrada. Algum tempo depois (podendo
demorar minutos, horas ou mesmo dias), a sada do job retornada. Este tempo entre a
submisso do job e seu trmino, chamado de tempo de turnaround, vai depender da quantidade
de processamento necessria, tempo de preparao necessrio, e da quantidade de jobs que
estavam na fila antes dele ser submetido ao processamento.
Existem algumas dificuldades com o sistema batch do ponto de vista do
programador ou do usurio. J que o usurio no pode interagir com o job que est executando,
o usurio deve indicar os cartes de controle para manipularem todos os resultados possveis.
Em um job de mltiplos passos, passos subseqentes podem depender do resultado dos
anteriores. A execuo de um programa, por exemplo, pode depender do sucesso da
compilao. Pode ser difcil definir completamente o que fazer em todos os casos.
Outra dificuldade em um sistema batch que programas devem ser depurados
estaticamente, a partir de uma listagem. Um programador no pode modificar um programa
quando ele est sendo executado para estudar o seu comportamento, como hoje possvel na
maioria dos ambientes de programao.
Um sistema de computao interativo (chamado de hands-on), fornece
comunicao on-line entre o usurio e o sistema. O usurio d instrues ao sistema operacional
ou para um programa diretamente, e recebe uma resposta imediata. Usualmente, um teclado
usado para a entrada de dados e uma impressora ou monitor de vdeo para a sada de dados.
Este tipo de terminal s apareceu algum tempo depois, com o barateamento de componentes
eletrnicos neles utilizados. Quanto o sistema operacional termina a execuo de um comando,
ele passa a aceitar outros comandos do teclado do usurio, e no mais de uma leitora de cartes.
Assim o usurio fornece o comando, espera pela resposta e decide o prximo comandos,
baseado no resultado do comando anterior. O usurio pode fazer experimentos com facilidade e
pode ver resultados imediatamente.
Sistemas batch so bastante apropriados para executar jobs grandes que precisam
de pouca interao. O usurio pode submeter jobs e retornar mais tarde para buscar os
resultados; no necessrio esperar seu processamento. Por outro lado, jobs interativos
costumam ser compostos por vrias aes pequenas, onde os resultados de cada ao podem ser
imprevisveis. O usurio submete o comando e espera pelos resultados. O tempo de resposta
deve ser pequeno da ordem de segundos no mximo. Um sistema interativo usado quando
necessrio um tempo de resposta pequeno.
Conforme j vimos, no incio dos tempos da computao, apesar de primitivos, os
sistemas eram interativos. Um novo processamento s comeava aps o operador analisar os
resultados do job anterior e decidir que ao tomar. Para aumentar o uso de UCP, sistemas
batch foram introduzidos, o que realmente fez com que os computadores ficassem menos tempo
ociosos. Entretanto, no havia interatividade nenhuma do usurio ou programador com o
sistema.
Sistemas de tempo compartilhado foram desenvolvidos para fornecer o uso
interativo de um sistema de computao a custos razoveis. Um sistema operacional de tempo
compartilhado (time-sharing) usa escalonamento de UCP e multiprogramao para fornecer
a cada usurio uma pequena poro de tempo de computador.
Um sistema operacional de tempo compartilhado permite que muitos usurios
compartilhem o computador simultaneamente. J que cada ao ou comando em um sistema
de tempo compartilhado tende a ser pequena, apenas uma pequena quantidade de tempo de UCP
necessria para cada usurio. Conforme o sistema troca de um usurio para outro, cada
usurio tem a impresso de ter seu prprio computador, enquanto na realidade um computador
est sendo compartilhado entre muitos usurios.
A idia de tempo compartilhado foi demonstrada no incio de 1960, mas j que
sistemas de tempo compartilhado so mais difceis e custosos para construir (devido aos
numerosos dispositivos de E/S necessrios), eles somente tornaram-se comuns at o incio dos
anos 70. Conforme a popularidade destes sistemas cresceu, pesquisadores tentaram combinar os
recursos de sistemas batch e de tempo compartilhado em um nico sistema operacional. Muitos
sistemas que foram inicialmente projetados como sistemas batch foram modificados para criar
um subsistema de tempo compartilhado. Por exemplo, o sistema batch OS/360 da IBM foi
modificado para suportar a opo de tempo compartilhado (Time Sharing Option - TSO). Ao
mesmo tempo, maioria dos sistemas de tempo compartilhado foi adicionado um subsistema
batch. Hoje em dia, a maioria dos sistemas fornecem ambos processamento batch e de tempo
compartilhado, embora seu projeto bsico e uso sejam de um ou de outro tipo.
Sistemas operacionais de tempo compartilhado so sofisticados. Eles fornecem um
mecanismo para execuo concorrente. Como na multiprogramao, vrios jobs deve ser
mantidos simultaneamente na memria, o que requer alguma forma de gerenciamento de
2PROCESSOS
O conceito de processo , certamente, o conceito mais importante no estudo de
sistemas operacionais. Para facilitar o entendimento deste conceito, considere-se um
computador
funcionando
em
multiprogramao
(isto
tendo
vrios
programas
computaes paralelas, pois de seus programas origina um nico processo durante a sua
execuo. Tais linguagens so denominadas seqenciais. Linguagens que permitem a
construo de programas que originam vrios processos para serem executados em paralelo so
denominadas linguagens de programao concorrente. Exemplos deste tipo de linguagem
so: Pascal Concorrente, Modula 2, Ada e outras.
A programao concorrente, alm de ser intelectualmente atraente e ser essencial ao
projeto de sistemas operacionais, tambm tem aplicaes na construo de diversos outros tipos
de sistema importantes. Qualquer sistema que deva atender a requisies de servio que possam
ocorrer de forma imprevisvel pode ser organizado, convenientemente, para permitir que cada
tipo de servio seja realizado por um dos processos do sistema. Dessa maneira, diversos
servios podero ser executados simultaneamente e a utilizao dos recursos computacionais
ser, certamente, mais econmica e eficiente. Exemplos de aplicaes deste tipo so sistemas
para controle on-line de informaes (contas bancrias, estoques, etc) e controle de processos
externos (processos industriais, processos qumicos, rotas de foguetes, etc).
Os processos durante suas execues requerem operaes de E/S que so
executadas em dispositivos muito lentos que a UCP, pois os dispositivos perifricos possuem
componentes mecnicos, que funcionam a velocidades muito inferiores dos dispositivos
eletrnicos que funcionam velocidade da luz.
Durante o tempo em que um processo deve ficar esperando a realizao de uma
operao de E/S, a UCP pode ser entregue a outro processo. Dessa forma, a utilizao dos
recursos ser mais completa e, portanto, mais econmica e mais eficiente. Se um processo passa
a maior parte do tempo esperando por dispositivos de E/S, diz-se que o processo limitado por
E/S (I/O-bound). Se, ao contrrio, o processo gasta a maior parte do seu tempo usando a UCP
ele dito limitado por computao (compute-bound ou UCP-bound). Obviamente, processos
I/O-bound devem ter prioridade sobre processos UCP-bound.
Alm de uma melhor utilizao dos recursos, a multiprogramao permite que as
requisies de servio dos usurios sejam atendidas com menores tempos de resposta. Por
exemplo, na situao de um job pequeno e prioritrio ser submetido aps um job demorado j
ter iniciado a execuo, a multiprogramao far com que o job pequeno seja executado em
paralelo e termine muito antes do trmino do job longo.
Os sistemas operacionais acionam os dispositivos de E/S atravs de instrues do
tipo Start I/O (Iniciar E/S). Se o dispositivo uma unidade de disco, por exemplo, a instruo
faz com que um bloco de setores do disco seja lido para a memria principal. Quando o
dispositivo termina a operao, ele manda um sinal de interrupo para a UCP, indicando que
est livre para realizar outra operao. Este sinal faz com que o controle da execuo v para o
sistema operacional, o qual pode acionar o dispositivo para executar outra operao, antes de
devolver a UCP para um processo de usurio.
Durante suas execues os processos dos usurios, ocasionalmente, atravs de
traps, fazem requisies ao sistema operacional (para gravar um setor de disco, por exemplo).
Recebendo a requisio, o sistema operacional bloqueia o processo (deixa de dar tempo de UCP
a ele) at que a operao requerida seja completada. Quando isto acontece o processo
desbloqueado e volta a competir pela UCP com os demais processos.
Quando um processo est realmente usando a UCP, diz-se que o mesmo est no
estado executando (running). Quando est esperando pelo trmino de um servio que requereu,
diz-se que est no estado bloqueado (blocked). Quando o processo tem todas as condies para
ser executado e s no est em execuo porque a UCP est alocada para outro processo, diz-se
que o mesmo est no estado pronto (ready). O sistema operacional mantm uma lista (fila) dos
processos que esto prontos, a chamada lista de processos prontos (ready list ou ready queue).
O diagrama da figura 2.1 mostra como os estados de um processo podem mudar durante a
execuo.
executando
trap
escalonador
interrupo
pronto
bloqueado
interrupo
(concluso do servio)
ready list, conforme os processos anteriores a ele forem sendo usados pela UCP.
Quando o processo alcana a cabea da lista, e quando a UCP torna-se disponvel, o
processo dado UCP e diz-se que foi feito uma transio do estado ready para o estado
running. A transferncia da UCP para o primeiro processo da ready list chamada dispatching,
e executada pelo dispatcher (ou escalonador). Este transio de estado pode ser ilustrada da
seguinte forma:
Dispatch(processname): ready
running
running
ready
Dispatch(processname):
ready
running
running
blocked
Quando terminada a operao que fez com que o estado fique bloqueado, este
passa para o estado pronto. A transio que faz tal operao definida como:
WakeUp(processname): blocked
ready
Dispatch(processname):
ready
running
TimerRunOut(processname):
running
ready
Block(processname):
running
blocked
WakeUp(processname):
blocked
ready
Manipulao de interrupes;
Desacatamento de processos;
Sincronizao de processos;
Manipulao de PCBs;
2.2Escalonamento de Processos
At agora vimos situaes onde tnhamos dois ou mais processos que poderiam
estar executando a qualquer momento. Estes processos poderiam estar executando, bloqueados,
ou prontos para serem executados. Uma situao adicional, que vimos mais tarde, foi o estado
suspenso.
Quando um ou mais processos esto prontos para serem executados, o sistema
operacional deve decidir qual deles vai ser executado primeiro. A parte do sistema operacional
responsvel por essa deciso chamada escalonador, e o algoritmo usado para tal chamado
Processo
corrente
Processo
corrente
Prximo processo
(a)
Prximo processo
(b)
Assim, o algoritmo round robin semelhante ao FIFO, mas com a diferena de que
preemptivo: os processos no executam at o seu final, mas sim durante um certo tempo, um
por vez. Executando sucessivamente em intervalos de tempo o job acaba por terminar sua
execuo em algum momento.
O nico aspecto interessante sobre o algoritmo round robin a durao do
quantum. Mudar de um processo para outro requer um certo tempo para a administrao
salvar e carregar registradores e mapas de memria, atualizar tabelas e listas do SO, etc.
Suponha esta troca de processos ou troca de contexto, como s vezes chamada, dure 5 ms.
Suponha tambm que o quantum est ajustado em 20 ms. Com esses parmetros, aps fazer 20
ms de trabalho til, a CPU ter que gastar 5 ms com troca de contexto. Assim, 20% do tempo de
CPU gasto com o overhead administrativo.
Para melhorar a eficincia da CPU, poderamos ajustar o quantum para digamos,
500 ms. Agora o tempo gasto com troca de contexto menos do que 1 %. Mas considere o que
aconteceria se dez usurios apertassem a tecla <ENTER> exatamente ao mesmo tempo,
disparando cada um processo. Dez processos sero colocados na lista de processo aptos a
executar. Se a CPU estiver ociosa, o primeiro comear imediatamente, o segundo no
comear antes de segundo depois, e assim por diante. O azarado do ltimo processo somente
comear a executar 5 segundos depois do usurio ter apertado <ENTER>, isto se todos os
outros processos tiverem utilizado todo o seu quantum. Muitos usurios vo achar que o tempo
de resposta de 5 segundos para um comando simples muita coisa.
Concluso: ajustar um quantum muito pequeno causa muitas trocas de contexto e
diminui a eficincia da CPU, mas ajust-lo para um valor muito alto causa um tempo de
resposta inaceitvel para pequenas tarefas interativas. Um quantum em torno de 100 ms
freqentemente um valor razovel.
somente 2 ms do seu quantum de 100 ms ganharia uma prioridade 50, enquanto um processo
que executou durante 50 ms antes de bloquear ganharia prioridade 2, e um processo que utilizou
todo o quantum ganharia uma prioridade 1.
freqentemente conveniente agrupar processos em classes de prioridade e utilizar
escalonamento com prioridades entre as classes, mas round robin dentro de cada classe. Por
exemplo, em um sistema com quatro classes de prioridade, o escalonador executa os processos
na classe 4 segundo a poltica round robin at que no haja mais processos na classe 4. Ento
ele passa a executar os processos de classe 3 tambm segundo a poltica round robin, enquanto
houverem processos nesta classe. Ento executa processos da classe 2 e assim por diante. Se as
prioridades no forem ajustadas de tempos em tempos, os processos nas classes de prioridades
mais baixas podem sofrer o fenmeno que chamamos starvation (o processo nunca recebe o
processador, pois sua vez nunca chega).
favorecer jobs limitados por E/S para atingir uma boa utilizao dos dispositivos de
E/S; e
Multilevel feedback queues (filas multi-nvel com retorno) fornecem uma estrutura
que atinge esses objetivos. O esquema ilustrado na figura 2.3:
Nvel 1
(FIFO)
Usa a
CPU
Trmino
Usa a
CPU
Trmino
Usa a
CPU
Trmino
Preempo
Nvel 2
(FIFO)
Preempo
Nvel n
(round robin)
Preempo
Figura 2.3 - Filas Multinvel com Retorno
Um novo processo entra na rede de filas ao final da fila do topo. Ele se move
atravs desta fila segundo uma poltica FIFO at que ganhe a CPU. Se o job termina ou desiste
da CPU para esperar um trmino de E/S ou outro evento, ele deixa a rede de filas. Se o
quantum expira antes do processo voluntariamente desistir da CPU, o processo colocado de
volta no final da fila um nvel abaixo. O processo avana nesta fila, e em algum momento
atinge a cabea da fila. No momento em que no houverem processos na primeira fila, ele
ganha a CPU novamente. Se ele ainda utiliza todo o quantum, ele vai descendo para as filas de
nveis inferiores. Normalmente, a fila de nvel mais baixo possui uma poltica round robin para
que todos os processos terminem de executar de uma maneira ou outra.
Em muitos sistemas de filas multi-nvel, o quantum dado ao processo conforme ele
se move para as filas de nveis inferiores aumentado. Assim, quanto mais um processo
permanece no sistema de filas, maior o seu quantum. Entretanto ele passa a no ganhar a CPU
com tanta freqncia, porque as filas superiores possuem prioridade maior. Um processo em
uma dada fila no pode executar at que as filas superiores estejam vazias. Um processo em
execuo suspenso em favor de um processo que chegue em uma fila superior.
Considere como tal mecanismo responde a diferentes tipos de processos. O
mecanismo deveria favorecer processos limitados por E/S para atingir boa utilizao dos
dispositivos e bons tempos de resposta aos usurios interativos. Realmente isso funciona porque
um processo limitado por E/S vai entrar na primeira fila e rapidamente ganhar a CPU. O
quantum da primeira fila ajustado para que a maioria dos jobs limitados por E/S tenham
tempo de fazer sua requisio de E/S. Quando o processo faz a requisio de E/S, ele deixa a
rede de filas, tendo recebido o tratamento desejado.
Agora considere um processo limitado por CPU que necessita de um grande tempo
de CPU. Ele entra a rede de filas no nvel mais alto, recebendo rapidamente seu primeiro
quantum de CPU, mas quando ele expira, o processo movido para a fila inferior. Agora o
processo tem prioridade inferior aos da fila superior, mas eventualmente ele recebe a CPU,
ganhando um quantum maior do que o anterior. Conforme o processo ainda precise de CPU, ele
vai caminhando pelas filas, at chegar fila de mais baixo nvel, onde ele circula por uma fila
round robin at que tenha terminado.
Filas Multi-nvel com retorno so ideais para separar processos em categorias
baseadas na sua necessidade por CPU. Em um sistema de tempo compartilhado, cada vez que o
processo deixe a rede de filas, ele pode ser marcado com a identificao do nvel da fila onde
ele esteve pela ltima vez. Quando o processo reentra no sistema de filas, ele pode ser enviado
diretamente para a fila onde ele anteriormente completou sua execuo, de forma que um
processo retornando para as filas no interfira no desempenho dos processos das filas de nveis
mais altos.
Se processos so sempre colocados de volta na rede de filas no nvel mais alto que
eles ocuparam da ltima vez que estiveram no sistema de filas, ser impossvel para o sistema
responder a mudanas no processo, como por exemplo, deixando de ser limitado por CPU para
ser limitado por E/S. Este problema pode ser resolvido marcando tambm o processo com o seu
tempo de permanncia na rede de filas na ltima vez em que l esteve. Assim, quando o
processo reentra no sistema de filas, ele pode ser colocado no lugar correto. Dessa forma, se o
processo est entrando em uma nova fase na qual ela deixa de ser limitado por CPU para ser
limitado por E/S, inicialmente ele vai sofrer uma penalidade pelo sistema, mas da prxima vez
o algoritmo perceber a mudana de comportamento do processo. Uma outra maneira de
responder a mudanas no comportamento de um processo coloc-lo em um nvel de filas cima
do qual esteve se ele voluntariamente desistir da CPU antes do trmino do seu quantum.
O mecanismo de filas multi-nvel com retorno um bom exemplo de um
mecanismo adaptativo, que responde a mudanas de comportamento do sistema que ele
controla. Mecanismos adaptativos normalmente requerem um maior overhead do que os no
adaptativos, mas a sensibilidade a mudanas torna o sistema mais gil e justifica o overhead
adicional.
Uma variao comum deste algoritmo ter os processos circulando em vrias filas
round robin. O processo circula pela primeira fila um certo nmero de vezes, depois desce um
nvel, circulando um nmero maior de vezes, e assim por diante.
O sistema deve rodar o job com prazo sem degradar o servio para os outros
usurios;
job na fila de espera com o menor tempo total estimado de processamento executado em
seguida. SJF reduz o tempo mdio de espera sobre o algoritmo FIFO. Entretanto, os tempos de
espera tem uma varincia muito grande (so mais imprevisveis) do que no algoritmo FIFO,
especialmente para grandes jobs.
SJF favorece jobs pequenos em prejuzo dos jobs maiores. Muitos projetistas
acreditam que quanto mais curto o job, melhor servio ele deveria receber. No h um consenso
universal quanto a isso, especialmente quando prioridades de jobs devem ser consideradas.
SJF seleciona jobs para servio de uma maneira que garante que o prximo job ir
completar e deixar o sistema o mais cedo possvel. Isto tende a reduzir o nmero de jobs
esperando, e tambm reduz o nmero de jobs esperando atrs de grandes jobs. Como resultado,
SJF pode minimizar o tempo mdio de espera conforme eles passam pelo sistema.
O problema bvio com SJF que ele requer um conhecimento preciso de quanto
tempo um job demorar para executar, e esta informao no est usualmente disponvel. O
melhor que SJF pode fazer se basear na estimativa do usurio de tempo de execuo. Em
ambientes de produo onde os mesmos jobs rodam regularmente, pode ser possvel prover
estimativas razoveis. Mas em ambientes de desenvolvimento, os usurios raramente sabem
durante quanto tempo seus programasvo executar.
Basear-se nas estimativas dos usurios possui uma ramificao interessante. Se os
usurios sabem que o sistema est projetado para favorecer jobs com tempos estimados de
execuo pequenos, eles podem fornecer estimativas com valores menores que os reais. O
escalonador pode ser projetado, entretanto, para remover esta tentao. O usurio pode ser
avisado previamente que se o job executar por um tempo maior do que o estimado, ele ser
abortado e o usurio ter que ser cobrado pelo trabalho. Uma segunda opo rodar o job pelo
tempo estimado mais uma pequena percentagem extra, e ento salv-lo no seu estado corrente
de forma que possa ser continuado mais tarde. O usurio, claro, teria que pagar por este
servio, e ainda sofreria um atraso na completude de seu job. Outra soluo rodar o job
durante o tempo estimado a taxas de servios normais, e ento cobrar uma taxa diferenciada
(mais cara) durante o tempo que executar alm do previsto. Dessa forma, o usurio que fornecer
tempos de execuo sub-estimados pode pagar um preo alto por isso.
SJF, assim como FIFO, no preemptivo e portanto no til para sistemas de
tempo compartilhado nos quais tempos razoveis deresposta devem ser garantidos.
2.3.1Processamento Paralelo
Conforme o hardware continua a cair em preos e tamanho, cada vez tornam-se
mais evidentes as tendncias para multiprocessamento, processamento distribudo e mquinas
massivamente paralelas. Se certas operaes podem ser logicamente executadas em paralelo, os
computadores paralelos iro fisicamente execut-las em paralelo, mesmo que o nvel de
paralelismo seja da ordem de milhares ou talvez milhes de atividades concorrentes. Isto pode
resultar em um aumento significativo de performance sobre os computadores seqenciais (com
um nico processador).
O processamento paralelo um assunto interessante e ao mesmo tempo complexo
por vrias razes. As pessoas parecem melhor focalizar sua ateno para uma atividade por vez
do que pensar em paralelo. Um exemplo disso tentar fazer uma pessoa ler dois livros ao
mesmo tempo: uma linha de um, uma linha do outro, e assim por diante.
difcil e denota tempo determinar quais atividades podem e quais no podem ser
executadas em paralelo. Programas paralelos so muito mais difceis de depurar do que
programas seqenciais depois de supostamente consertar um bug, praticamente impossvel
reproduzir a seqncia exata de eventos que fez com que o erro aparecesse, dessa forma ento
impossibilitando certificar, com certeza, de que o erro foi corretamente removido.
Processos assncronos podem ocasionalmente interagir um com o outro, e essas
interaes podem ser complexas.
Finalmente, muito mais difcil provas que programas paralelos esto corretos, do
b ** 2
4 * a
(4 * a) * c
(b ** 2) - (4 * a * c)
(b ** 2 - 4 * a *c) ** .5
-b
2 * a
(-b + (b ** 2 - 4 * a * c) ** .5) / (2 * a)
parbegin
temp1 := -b;
temp2 := b ** 2;
temp3 := 4 * a;
temp4 := 2 * a
parend;
temp5 := temp3 * c;
x := temp5 / temp4
program B;
...
...
...
end.
2.3.2Excluso Mtua
Considere um sistema com muitos terminais em tempo compartilhado. Assuma que
os usurios terminam cada linha de texto que eles digitam com a tecla <ENTER>. Suponha que
seja desejvel monitorar continuamente o nmero total de linhas que os usurios entraram no
sistema desde o incio do dia. Assuma que cada terminal de usurio seja monitorado por um
processo diferente. Toda vez que um destes processos recebe uma linha do terminal, ele
incrementa de 1 uma varivel global compartilhada do sistema, chamada LINHAS. Considere o
que aconteceria se dois processos tentassem incrementar LINHAS simultaneamente. Assuma
que cada processo possui sua prpria cpia do seguinte cdigo:
LOAD
ADD
STORE
LINHAS
1
LINHAS
Suponhamos que LINHAS tenha o valor atual 21687. Agora suponhamos que o
primeiro processo execute as instrues LOAD e ADD, deixando ento o valor 21688 no
acumulador. Ento o processo perde o processador (aps o trmino de seu quantum) para o
segundo processo. O segundo processo ento executa as trs instrues, fazendo com que a
varivel linhas tenha o valor 21688. Ele ento perde o processador para o primeiro processo que
continua executando de onde tinha parado, e portanto executando a instruo STORE, e
armazenando 21688 na varivel LINHAS. Devido falta de comunicao entre os processos, o
sistema deixou de contar uma linha o valor correto seria 21689.
O problema est em dois ou mais processos escreverem em uma varivel
compartilhada. Vrias processos poderiam estar lendo uma varivel compartilhada sem
problemas. Entretanto, quando um processo l uma varivel que outro processo est
escrevendo, ou quando um processo tenta escrever em uma varivel que outro processo tambm
esteja escrevendo, resultados inesperados podem acontecer.
O problema pode ser resolvido dando a cada processo acesso exclusivo varivel
2.3.3Regies Crticas
A excluso mtua somente precisa estar presente nos instantes em que os processos
acessam dados compartilhados modificveis quando os processos esto executando
operaes que no conflitam um com o outro, eles deveriam ser liberados para processarem
concorrentemente. Quando um processo est acessando dados compartilhados modificveis,
dito que o processo est em sua regio crtica ou seo crtica.
Fica claro, que para evitarmos problemas como o mostrando acima, necessrio
garantir que quando um processo est em sua regio crtica, todos os outros processos (pelo
menos aqueles que acessam a mesma varivel compartilhada modificvel) sejam excludos de
suas respectivas regies crticas.
Enquanto um processo est em sua regio crtica, outros processos podem
certamente continuar sua execuo fora de suas regies crticas. Quando um processo deixa sua
regio crtica, um dos processos esperando para entrar em sua prpria regio crtica pode
prosseguir. Garantir a excluso mtua um dos principais problemas em programao
concorrente. Muitas solues foram propostas: algumas baseadas em software e outras baseadas
em hardware; algumas em baixo nvel, outras em alto nvel; algumas requerendo cooperao
voluntria entre processos, outras exigindo uma rgida aderncia a protocolos estritos.
Um processo dentro de uma regio crtica est em um estado muito especial. O
processo possui acesso exclusivo aos dados compartilhados modificveis, e todos os outros
processos desejando acess-los devem esperar. Assim, regies crticas devem executar o mais
rpido possvel, um processo no deve passar para o estado bloqueado dentro da regio crtica,
e regies crticas devem ser cuidadosamente codificadas (para evitar, por exemplo, loops
infinitos).
entermutex, ento somente liberado para prosseguir, enquanto o outro permanece esperando.
Por enquanto, vamos assumir que o vencedor escolhido aleatoriamente pelo sistema
operacional.
Cada instruo da mquina executada indivisivelmente, isto , uma vez que uma
instruo comea a ser executada, ela termina sem nenhuma interrupo.
Nenhuma suposio deve ser feita sobre as velocidades relativas dos processos
concorrentes assncronos.
Processos operando fora de suas regies crticas no podem evitar que outros
processos entrem em suas prprias regies crticas.
Processos no devem ter sua vez de entrar em sua regio crtica indefinidamente
adiada.
Uma implementao elegante em software de excluso mtua foi pela primeira vez
apresentada pelo matemtico alemo Dekker. Esta soluo implementa excluso mtua com
espera ocupada (busy wait), pois os processos ficam em um loop infinito fazendo testes at
conseguirem entrar nas suas regies crticas. O algoritmo de Dekker foi analisado e apresentado
por diversos autores da rea de sistemas operacionais. Um deles, G. L. Peterson, apresentou
mais tarde um algoritmo mais simplificado do algoritmo original de Dekker.
Entretanto, a soluo de Dekker somente funciona para excluso mtua entre dois
processos. Outras solues foram inventadas, e contam com algum suporte do sistema
operacional, o que facilita a vida do programador. Vejamos a seguir estas solues.
2.3.7Semforos
Dijkstra conseguiu abstrair as principais noes de excluso mtua em seu conceito
de semforos. Um semforo uma varivel protegida cujo valor somente pode ser acessado e
alterado pelas operaes P e V, e por uma operao de inicializao que chamaremos
inicializa_semforo. Semforos binrios podem assumir somente os valores 0 ou 1.
Semforos contadores (tambm chamados de semforos genricos) podem assumir somente
valores inteiros no negativos.
Ns podemos assumir que existe uma poltica de enfileiramento FIFO (first-infirst-out o primeiro a entrar o primeiro a sair) para os processos esperando para uma
operao P(S) completar.
Assim como testandset, as operaes P e V so indivisveis. A excluso mtua no
semforo S garantida pelas operaes P(S) e V(S). Se vrios processos tentam executar P(S)
simultaneamente, somente um deles poder prosseguir. Os outros ficaro esperando, mas a
implementao de P e V garante que os processos no sofreroadiamento indefinido.
Semforos e operaes com semforos podem ser implementados tanto em
software quanto em hardware. Eles so comumente implementados no ncleo do sistema
operacional, onde a mudana de estado dos processos controlada. O exemplo a seguir ilustra o
uso de semforos para implementar excluso mtua. Neste exemplo, P(ativo) equivalente a
entermutex e V(ativo) equivalente a exitmutex.
program exemplo_semforo;
var ativo: semaphore;
procedure processo_um;
begin
while true do
begin
algumas_funcoes_um;
P(ativo);
regiao_critica_um;
V(ativo);
outras_funcoes_um;
end
end;
procedure processo_dois;
begin
while true do
begin
algumas_funcoes_dois;
P(ativo);
regiao_critica_dois;
V(ativo);
outras_funcoes_dois;
end
end;
begin
inicializa_semaforo(ativo, 1);
parbegin
processo_um;
processo_dois
parend
end.
begin
inicializa_semaforo(evento_de_interesse, 0);
parbegin
processo_um;
processo_dois
parend
end.
processo_um
executa
algumas_funcoes_um
ento
executa
2.3.7.3Semforos Contadores
Semforos contadores so particularmente teis quando um recurso deve ser
alocado a partir de um pool (agrupamento) de recursos idnticos. O semforo inicializado com
o nmero de recursos no agrupamento. Cada operao P decrementa o semforo de 1, indicando
que um recurso foi removido do agrupamento e est em uso por um processo. Cada operao V
incrementa o semforo de 1, indicando que um processo retornou um recurso ao agrupamento, e
o recurso pode ser realocado para outro processo. Se uma operao P executada quando o
semforo possui o valor zero, ento o processo deve esperar at que um recurso seja liberado
com uma operao V.
2.3.7.4Implementando Semforos, P e V
Dado o algoritmo de Dekker e a disponibilidade de uma instruo de mquina
testandset, praticamente direto implementar P e V utilizando busy waiting. Mas esta tcnica
pode no ser boa porque desperdia recursos de CPU.
J vimos em sees anteriores os mecanismos de troca de estados de processos
implementados no ncleo do sistema operacional. Observamos que um processo requisitando
uma operao de E/S voluntariamente se bloqueia esperando que a operao de E/S seja
completada. O processo bloqueado no espera de forma ocupada (busy wait), isto , no fica
processando continuamente um loop de teste para verificar se a operao de E/S j terminou. Ao
contrrio, ele libera o processador, e o ncleo do sistema operacional o coloca (coloca seu PCB)
na lista de processos bloqueados. O processo permanece dormindo at que ele seja
acordado pelo ncleo do sistema operacional quando sua operao de E/S estiver completa,
tirando-o da lista de processos bloqueados e colocando-o na lista de processos prontos para
execuo.
Operaes com semforos tambm podem ser implementadas no ncleo do sistema
operacional para evitar a espera ocupada (busy waiting). Um semforo implementado como
uma varivel protegida e uma fila na qual processos podem esperar por operaes V. Quando
um processo tenta executar uma operao P em um semforo cujo valor corrente seja zero, o
processo libera o processador e se bloqueia para esperar uma operao V no semforo. O ncleo
do SO coloca o PCB do processo na fila de processos esperando naquele semforo. Note que
alguns sistemas implementam uma fila de espera do tipo FIFO, enquanto outros utilizam filas
com prioridades ou mesmo outras disciplinas. Em seguida, o ncleo do SO ento realoca o
processador para o prximo processo pronto paraexecuo.
Em algum momento, nosso processo na fila do semforo vai chegar primeira
posio da fila. A prximo operao V vai remover o processo da fila do semforo e coloc-lo
na lista de processos prontos. claro que processos tentando simultaneamente executar
operaes P e V em um semforo ganharo acesso exclusivo ao semforo pelo ncleo do SO.
Vale notar o caso especial de que em sistemas com um nico processador, a
indivisibilidade de P e V pode ser garantida simplesmente desabilitando interrupes enquanto
operaes P e V esto manipulando o semforo. Isto previne que o processador seja roubado
at que a manipulao do semforo esteja completa. Neste momento as interrupes podero ser
novamente habilitadas.
No ncleo de um sistema multiprocessado, a um dos processadores pode ser dada a
tarefa de controlar a lista de processos prontos e determinar que processadores executam quais
processos. Uma outra abordagem para implementar o ncleo para um sistema multiprocessado
controlar o acesso (via busy waiting) a uma lista de pronto compartilhada. Um ncleo de um
sistema distribudo poderia ter um processador controlando a lista de pronto, mas normalmente
cada processador gerenciaria sua prpria lista de pronto. Portanto, cada processador
essencialmente possui seu prprio ncleo. Conforme um processo migra entre os vrios
processadores em um sistema distribudo, o controle daquele processo passado de um ncleo
para outro.
2.3.8Monitores
A comunicao interprocessos utilizando semforos e contadores de eventos parece
ser a soluo definitiva. Entretanto, se analisarmos mais diretamente estas tcnicas, veremos
que elas possuem alguns problemas:
o mau uso dessas primitivas, tanto de forma acidental como maliciosa, poderia
corromper a operao do sistema concorrente.
uma vez que a operao P usada e o processo fica nela bloqueado, ele no pode
desistir e tomar um curso de ao alternativo enquanto o semforo estiver em uso;
.
end;
end monitor;
Monitores possuem uma importante propriedade que os torna til para atingir
excluso mtua: somente um processo pode estar ativo em um monitor em qualquer momento.
Monitores so uma construo da prpria linguagem de programao utilizada, de forma que o
compilador sabe que eles so especiais, e pode manipular chamadas a procedimentos dos
monitores de forma diferente da qual manipula outras chamadas de procedimentos.
Tipicamente, quando um processo chama um procedimento de um monitor, as primeiras
instrues do procedimento iro checar se algum outro processo est ativo dentro do monitor.
Se isto acontecer, o processo que chamou o procedimento ser suspenso at que outro processo
tenha deixado o monitor. Se nenhum outro processo estiver usando o monitor, o processo que
chamou o procedimento poder entrar.
Fica a cargo do compilador implementar a excluso mtua nas entradas do monitor,
mas comum utilizar semforos binrios. Uma vez que o compilador, e no o programador,
quem faz os arranjos para a excluso mtua, muito menos provvel que alguma coisa d
errado. Em qualquer situao, a pessoa escrevendo o monitor no precisa saber como o
compilador faz os arranjos para excluso mtua. suficiente saber que ao transformar todas as
regies crticas em procedimentos de monitor, dois processos jamais executaro suas regies
crticas simultaneamente.
Apesar de monitores proverem uma maneira fcil de se conseguir excluso mtua,
como acabamos de dizer, isto no suficiente. necessrio tambm que se tenha um meio de
fazer os processos bloquearem quando eles no podem prosseguir. Considere o seguinte
exemplo da relao produtor-consumidor:
program produtor_consumidor;
const N = 100;
var cont: integer;
procedure produtor;
begin
while true do begin
produz_item;
{ produz um item de dado }
if (cont = N) then
suspend;
{ se o buffer esta cheio, entra em suspensao }
entra_item;
{ coloca o item produzido no buffer }
cont := cont + 1;
if (cont = 1) then
resume (consumidor); { se o buffer estava vazio, acorda o consumidor}
end;
end;
procedure consumidor;
begin
while true do begin
if (cont = 0) then
suspend;
{ se o buffer esta vazio, entra em suspensao }
remove_item;
{ remove o item do buffer }
cont := cont - 1;
if (cont = N - 1) then
resume (produtor); { se o buffer estava cheio, acorda o produtor }
consome_item;
{ imprime o item }
end;
end;
begin
cont := 0;
parbegin
produtor;
consumidor;
parend;
end.
que ele no pode continuar (por exemplo, o produtor encontra o buffer cheio), ele executa um
wait em alguma varivel de condio, digamos, cheio. Esta ao faz com que o processo que
chamou o procedimento bloqueie. Isto tambm permite que outro processo que tenha sido
anteriormente proibido de entrar no monitor possa agora entrar.
Este outro processo, por exemplo, o consumidor, pode acordar seu parceiro
suspenso executando um signal na varivel de condio na qual seu parceiro est esperando.
Para evitar que dois processos estejam ativos no monitor ao mesmo tempo, preciso uma regra
que diga o que acontece aps um signal. Hoare props deixar o processo recm-acordado
prosseguir, suspendendo o outro. Brinch Hansen props que o processo que chame signal deve
deixar o monitor imediatamente. Em outras palavras, uma chamada a signal deve aparecer
somente como o ltimo comando em um procedimento de monitor. Utilizaremos a proposta de
Brinch Hansen por ser conceitualmente mais simples e tambm mais fcil de implementar. Se
um comando signal executado em uma varivel na qual vrios processos esto esperando,
somente um deles, determinado pelo escalonador do sistema, acordado.
Um esqueleto do problema produtor-consumidor utilizando monitores
apresentado a seguir:
monitor ProdutorConsumidor;
var cheio, vazio: condition; { variveis de condio }
cont: integer;
procedure colocar;
begin
if cont = N then
wait(cheio);
entra_item;
cont := cont + 1;
if cont = 1 then
signal(vazio);
end;
procedure remover;
begin
if cont = 0 then
wait(vazio);
remove_item;
cont := cont - 1;
if cont = N - 1 then
signal(cheio);
end;
count := 0;
end monitor;
procedure produtor;
begin
while true do begin
produz_item;
ProdutorConsumidor.colocar;
end
end;
procedure consumidor;
begin
while true do begin
ProdutorConsumidor.remover;
consome_item;
end
end;
aplicados.
2.3.9Passagem de Mensagens
(ver notas de aula e texto em ingls do Silberschatz na pgina)
2.4.1Exemplos de Deadlocks
Deadlocks podem desenvolver-se de vrias maneiras. Se um processo recebe a
tarefa de esperar pela ocorrncia de um determinado evento, e o sistema no inclui proviso
para sinalizar aquele evento, ento temos um deadlock de um processo. Deadlocks desta
natureza so extremamente difceis de detectar, pois esto intimamente associados ao cdigo do
processo, provavelmente com erros, neste caso.
A maioria dos deadlocks em sistemas reais geralmente envolve mltiplos processos
competindo por mltiplos recursos. Vejamos alguns exemplos comuns.
cidades. Um certo nmero de automveis esto tentando atravessar uma parte da cidade
bastante movimentada, mas o trfego ficou completamente paralisado. O trfego chegou numa
situao onde somente a polcia pode resolver a questo, fazendo com que alguns carros recuem
na rea congestionada. Eventualmente o trfego volta a fluir normalmente, mas a essa altura os
motoristas j se aborreceram e perderam tempo considervel.
de imprimir. Vrios jobs de impresso podem ser enfileirados e sero gerenciados pelo sistema
de spooling.
Em alguns sistemas de spool, todo o job de impresso deve ser gerado antes do
incio da impresso. Isto pode gerar uma situao de deadlock, uma vez que o espao disponvel
em disco para a rea de spooling limitado. Se vrios processos comearem a gerar seus dados
para o spool, possvel que o espao disponvel para o spool fique cheio antes mesmo de um
dos jobs de impresso tiver terminado de ser gerado. Neste caso, todos os processos ficaro
esperando pela liberao de espao em disco, o que jamais vai acontecer, e portanto gerando
uma situao de deadlock. A soluo neste caso seria o operador do sistema cancelar um dos
jobs parcialmente gerados.
Para resolver o problema sem a interveno do operador, o SO poderia alocar uma
rea maior de spooling, ou a rea de spooling poderia ser varivel dinamicamente. Alguns
sistemas, como o do Windows 3.x/95, utilizam todo o espao em disco disponvel Entretanto,
pode acontecer de o disco possuir pouco espao e o problema ocorrer da mesma forma.
A soluo definitiva seria implementar um sistema de spooling que comeasse a
imprimir assim que algum dado estivesse disponvel, sem a necessidade de se esperar por todo o
job. Isso faria com que o espao fosse sendo liberado gradualmente, na velocidade em que a
impressora conseguisse consumir os dados. Este um problema tpico de uma relao produtorconsumidor.
Nos sistemas operacionais mais populares, como o Windows 95, o sistema de spool
pode ser configurado para comear a imprimir assim que uma pgina estiver disponvel em
disco (isto porque algumas impressoras so orientadas a pgina, como as impressoras laser). No
Windows 3.x, o spool s iniciava a impresso aps todo o job de impresso ter sido gerado.
2.4.5Adiamento Indefinido
Em sistemas onde processos ficam esperando pela alocao de recursos ou pelas
decises de escalonamento, possvel que ocorra adiamento indefinido tambm chamado de
bloqueamento indefinido ou starvation).
Adiamento indefinido pode ocorrer devido s polticas de escalonamento de
recursos do sistema. Quando recursos so alocados segundo um esquema de prioridades,
possvel que um determinado processo espere indefinidamente por um recurso conforme
processos com prioridades mais altas venham chegando. Os sistemas operacionais devem ser
justos com processos em espera, bem como devem considerar a eficincia de todo o sistema.
Em alguns sistemas, o adiamento indefinido pode ser evitado permitindo que a prioridade de
um processo em espera cresa conforme ele espera por um recurso. Isto chamado de aging
(envelhecimento).
2.4.6Conceitos de Recursos
Um sistema operacional pode ser visto de forma mais ampla como um gerenciador
de recursos. Ele responsvel pela alocao de vrios recursos de diversos tipos. A riqueza dos
tipos de recursos que faz o assunto Sistemas Operacionais ser interessante de ser estudado.
Alguns recursos so preemptveis. O maior exemplo a CPU. Memria tambm
pode ser preemptvel (veremos memria virtual).
Certos recursos so no-preemptveis, e no podem ser tomados de processos aos
quais foram alocados. Ex. unidades de fita. Contra-ex. disco.
Alguns recursos so compartilhados entre vrios processos. Unidades de disco so
compartilhadas em geral. Memria principal e CPU so compartilhadas; apesar de que em um
instante a CPU pertence a um nico processo, mas sua multiplexao entre os vrios processos
transmite a idia de que est sendo compartilhada.
Dados e programas so certamente os recursos que mais precisam ser controlados e
alocados. Em sistemas multiprogramados, vrios usurios podem querer simultaneamente usar
um programa editor. Seria desperdcio de memria ter-se uma cpia do editor para cada
programa executando. Ao contrrio, uma nica cpia do cdigo trazida para a memria e
vrias cpias dos dados so feitas, uma para cada usurio. Uma vez que o cdigo est em uso
por vrios usurios simultaneamente, ele no pode mudar. Cdigo que no pode ser mudado
enquanto est em uso dito reentrante. Cdigo que pode ser mudado mas que reinicializada
cada vez que usado dito serialmente reusvel. Cdigo reentrante pode ser compartilhado
entre vrios processos, enquanto cdigo serialmente reusvel s pode ser alocado a um processo
por vez.
Quando chamamos recursos compartilhados particulares, devemos ser cuidadosos
para determinar se eles podem ser usados por vrios processos simultaneamente, ou se podem
ser usados por vrios processos, mas um de cada vez. Estes ltimos so os recursos que tendem
estar envolvidos em deadlocks.
Um sistema possui um nmero finito de recursos para serem distribudos entre
processos concorrentes. Os recursos so classificados segundo vrios tipos, sendo que cada tipo
pode consistir de uma quantidade de instncias idnticas. Por exemplo, se considerarmos o tipo
de recurso CPU, em uma mquina com dois processadores, temos duas instncias do recurso
CPU.
Se um processo requisita uma instncia de um tipo de recurso, a alocao de
qualquer instncia daquele tipo ir satisfazer a requisio. Se em um determinado sistema esta
satisfao no ocorrer, isto significa que as instncias no so idnticas, e que as classes de tipos
de recursos no esto definidas corretamente. Como exemplo (Silberschatz, 1994), suponha que
um sistema possui duas impressoras. Elas poderiam ser definidas como instncias de um mesmo
tipo de recurso. Entretanto se uma estivesse instalada no andar trreo do prdio, e a outra no 9
andar, os usurios do andar trreo podem no enxergar as duas impressoras como sendo
equivalentes. Neste caso, classes de recursos separadas precisariam ser definidas para cada
impressora.
Um processo pode requisitar um recurso antes de us-lo, e deve liber-lo depois de
seu uso. Um processo pode requisitar quantos recursos precisar para desempenhar a tarefa para
a qual foi projetado. Obviamente, o nmero de recursos requisitados no pode exceder o
nmero total de recursos disponveis no sistema. Em outras palavras, o processo no pode
requisitar trs impressoras se o sistema somente possui duas.
Em uma situao de operao normal, um processo pode utilizar um recurso
somente nesta seqncia:
1. Requisitar: se a requisio no pode ser atendida imediatamente (por exemplo, o
recurso est em uso por outro processo), ento o processo requisitante deve esperar
at obter o recurso;
2. Usar: O processo pode operar sobre o recurso (por exemplo, se o recurso uma
impressora, ele pode imprimir);
3. Liberar: O processo libera o recurso.
Para garantir que deadlocks nunca ocorrem, o sistema pode tanto usar um esquema
de prevenir deadlocks, ou evitar deadlocks. A preveno de deadlocks um conjunto de
regras de requisio de recursos que garantem que pelo menos uma das condies necessrias
para a ocorrncia de deadlocks no esteja em efeito. Evitar deadlocks, por outro lado, requer
que seja fornecida ao sistema operacional informao adicional sobre quais recursos um
processo ir requisitar e usar durante sua execuo. Com o conhecimento dessa informao,
possvel decidir, a cada requisio, se o processo pode prosseguir ou se deve esperar. Cada
requisio requer que o sistema operacional considere os recursos atualmente disponveis, os
recursos alocados a cada processo, e as futuras requisies e liberaes de cada processo, para
que possa decidir se a requisio corrente pode ser satisfeita ou deve ser adiada.
Se no so usadas estratgias de preveno ou para evitar deadlocks, existe a
possibilidade de ocorrncia destes. Neste ambiente, o sistema operacional pode possuir um
2.4.9Preveno de Deadlocks
Como vimos, para que um deadlock ocorra, todas as condies necessrias para
ocorrncia de deadlocks, que listamos anteriormente, devem estar em efeito. Isto quer dizer que
se garantirmos que somente uma delas no possa ocorrer, estaremos prevenindo a ocorrncia
de deadlocks em um determinado sistema. Examinemos as quatro condies separadamente:
O problema que nem todos os recursos podem ser alocados via spooling. Alm
disso, o prprio sistema de spooling pode levar a situaes de deadlock, conforme j
discutimos.
em um dado momento. Se ele precisa de um segundo recurso, deve liberar o primeiro. Para um
processo que necessita copiar um arquivo bastante grande para uma impressora (o processo de
spooling, por exemplo), isto inaceitvel.
Uma estratgia melhor seria utilizar a terceira estratgia de Havender, que
determina que todos os recursos devem ser numerados em ordem crescente. Assim, processos
podem requisitar recursos sempre que quiserem, mas todas as requisies devem ser em ordem
crescente de numerao. Tomando a figura 10.3 como exemplo, um processo poderia requisitar
o recurso R1 e em seguida o recurso R3, mas no o inverso. O grafo de alocao mostrado na
figura 2.7 jamais possuir ciclos, evitando assim a condio circular wait.
R10
P3
R9
P2
R8
P1
P2
R7
P1
R6
R5
P1
R4
P1
P2
R3
R2
R1
3GERENCIAMENTO DE MEMRIA
Memria um importante recurso que deve ser cuidadosamente gerenciado. Apesar
de um computador domstico atual possuir dezenas ou at mesmo centenas de vezes mais
memria que um computador IBM 7094 (o maior computador existente no incio dos anos 60),
o tamanho dos programas de computador tem crescido em uma escala to grande quanto da
quantidade de memria dos computadores.
A memria sempre foi vista como um recurso caro e por isso merece cuidados para
o seu gerenciamento correto. Apesar da queda vertiginosa do preo da memria real, esta ainda
muitas vezes mais cara do que a memria secundria (discos, fitas,etc.).
O componente do sistema operacional responsvel pela administrao da memria
chamado de gerenciador de memria. Seu papel consiste em saber quais partes da memria
esto ou no em uso, alocar memria para os processos quando dela necessitam e desalocar
quando deixam de us-la ou terminam, e gerenciar as trocas entre a memria principal e o disco
quando a memria principal no grande o suficiente para conter todos os processos.
Este captulo visa abordar alguns esquemas de gerenciamento de memria, desde
alguns simples at os mais complexos. Sistemas de gerenciamento de memria podem ser
divididos em dois grupos: aqueles que movem processos entre memria e disco durante sua
execuo (paginao e swapping), e aqueles que no o fazem. Cada abordagem possui
vantagens e desvantagens. A escolha do melhor esquema de gerenciamento de memria
depende de vrios fatores, especialmente do projeto do hardware do sistema. Como veremos
mais adiante, vrios algoritmos para gerenciamento de memria requerem algum suporte do
hardware.
3.1Conceitos Bsicos
Como vimos no incio do curso, memria um componente essencial para a
operao de sistemas de computao modernos. A memria um grande vetor de palavras ou
bytes (o tamanho de um palavra depende de cada mquina), cada qual com seu prprio
endereo. A CPU busca instrues do programa em memria de acordo com o valor do
registrador contador de programas (program counter, que no caso dos microprocesadores Intel
O procedimento normal selecionar um dos processos da fila de entrada e carreglo na memria. Conforme o processo executa, ele acesa instrues e dados da memria.
Eventualmente o processo termina, e seu espao de memria declarado como disponvel.
Programa
fonte
Co mpilador ou
assembler
Tempo de
compilaao
Mdulo
objeto
Outros
mdulos
objeto
Link editor
(ligador)
Biblioteca
de sistema
Mdulo
carregvel
Tempo de
carregamento
Carregador
(loader)
Biblioteca de
sistema
carregada
dinamicamente
Imagem em
mem ria do
programa
binrio
Tempo de
execuo
de usurio passar por vrias etapas antes de ser executado, conforme a figura 3.1. Endereos
podem ser representados de diferentes formas nestes passos. Endereos no programa fonte
normalmente so simblicos (por exemplo, a varivel cont). Um compilador ir tipicamente
ligar esses endereos simblicos a endereos relocveis (como por exemplo, 14 bytes a
partir do incio do bloco desse programa). O link editor ou carregador (loader) por sua vez
ligar esses endereos relocveis a endereos absolutos (tal como 74014). Cada uma das
ligaes um mapeamento de um espao de endereamento para outro.
Classicamente, a ligao de instrues e dados para endereos de memria pode ser
feita em qualquer um dos passos citados:
3.1.3Ligao Dinmica
A figura 3.1 tambm ilustra bibliotecas ligadas dinamicamente. Muitos sistemas
operacionais suportam somente ligaes estticas de bibliotecas de funes, na qual as
bibliotecas de sistema so tratadas como qualquer outro mdulo objeto e so combinadas pelo
carregador dentro da imagem binria do programa em memria. O conceito de ligao dinmica
similar ao de carregamento dinmico. Ao invs da carga de rotinas ser adiada at o momento
da execuo do programa, a ligao de rotinas adiada at o tempo de execuo. Esta
caracterstica normalmente usada com bibliotecas de sistema, tais como bibliotecas de
subrotinas da linguagem em uso, como por exemplo, a biblioteca stdio da linguagem C. Sem
essa facilidade, todos os programas em um sistema precisam possuir sua prpria cpia da
biblioteca bsica (ou pelo menos das funes referenciadas pelo programa) includa na imagem
executvel. Este esquema desperdia ambos espao em disco e espao em memria principal.
Com ligao dinmica, um stub includo na imagem para cada referncia a uma rotina de
biblioteca. Este stub um pequeno cdigo que indica como localizar a rotina de biblioteca
3.1.4Overlays
Em algumas situaes pode ser que a memria fsica no seja suficiente para conter
todo o programa do usurio. Uma forma de resolver esse problema o uso de overlays. As
sees do programa no necessrias em um determinado momento podem ser substitudas por
uma outra poro de cdigo trazida do disco para execuo, conforme ilustra a figura 3.2. O
overlay manual requer planejamento cuidadoso e demorado. Um programa com uma estrutura
de overlays sofisticada pode ser difcil de modificar. Alguns compiladores (Turbo Pascal)
podem gerenciar overlays automaticamente, mas sem eficincia muito grande. Como veremos
adiante, os sistemas de memria virtual eliminaram o trabalho do programador com a definio
de overlays.
c
fase de
inicializao
rea de
Overlay
Poro mnima
do programa do
usurio que deve
permanecer em
memria at o
final da execuo
Sistema
Operacional
fase de
processamento
fase de
gerao
de
resultado
b
b
b
feito pela unidade de gerenciamento de memria (MMU Memory Management Unit), que
um dispositivo de hardware. Existem diversas maneiras de fazer este mapeamento, conforme
discutiremos mais adiante. Vejamos um esquema de MMU simples (figura 3.3).
Registrador de
relocao
Endereo
lgico
CPU
346
14000
+
Endereo
fsico
14346
Memria
MMU
3.3Swapping
Um processo precisa estar em memria para executar. Um processo, entretanto,
pode ser temporariamente ser retirado (swapped) da memria para uma rea de armazenamento
de trocas (rea de swapping), de forma que mais tarde seja trazido de volta para a memria para
que continue executando. Por exemplo, suponha um ambiente multiprogramado com um
algoritmo de escalonamento de CPU round-robin. Quanto o quantum de determinado processo
expira, o gerenciador de memria do SO comear a retirar (swap out) o processo recm
interrompido, e recolocar (swap in) outro processo no espao de memria que foi liberado.
Enquanto isso, o escalonador de CPU ir alocar uma fatia de tempo para outro processo em
memria. Conforme cada processo tem seu quantum expirado, ele ser trocado (swapped) por
outro processo que estava na rea de swapping. Em uma situao ideal, o gerenciador de
memria conseguir trocar processos em uma velocidade tal que sempre haja processos em
memria, prontos para executar, sempre que o escalonador de CPU decidir colocar outro
processo em execuo. O quantum dos processos devem tambm ser suficientemente grande
para que os processos consigam processar por um tempo razovel antes de serem retirados
(swapped out) da memria.
Uma variao desta poltica de swapping poderia ser usada para algoritmos de
escalonamento baseados em prioridades. Se um processo com maior prioridade chega no
sistema e deseja CPU, ento o gerenciador de memria poderia retirar um ou mais processos
com prioridades mais baixas de forma que ele possa carregar e executar o processo de
prioridade mais alta. Quando este processo de alta prioridade terminasse, os processos de baixa
prioridade poderiam ser trazidos de volta para a memria e continuarem executando. Esta
variante de swapping s vezes chamada de roll out, roll in.
Normalmente, um processo que foi retirado da memria ser trazido de volta no
mesmo espao de memria que ocupava anteriormente. Esta restrio pode existir ou no
conforme o mtodo de ligao de endereos de memria. Se a ligao de endereos de memria
feita em tempo de compilao ou de carregamento, ento o processo no pode ser movido
para localizaes diferentes de memria. Se a ligao em tempo de execuo usada, ento
possvel retirar um processo da memria e recoloc-lo em um espao de memria diferente,
uma vez que os endereos fsicos so calculados em tempo de execuo.
= 1/10 segundo
= 100 milisegundos
usado por vrios sistemas operacionais em PCs para permitir que vrios processos estejam em
execuo concorrentemente. Um exemplo o Microsoft Windows, que suporta execuo
concorrente de processos em memria. Se um novo processo carregado e a memria
insuficiente, um processo mais antigo retirado para o disco. Este SO, entretanto, no prov
swapping completo, uma vez que os processos dos usurios, e no o escalonador, que decidem
se hora de trocar um processo em memria por outro em disco. Qualquer processo em disco
permanece l at que um processo executando o escolha para execuo. A verso mais nova do
Windows, o NT (e hoje tambm, o Windows 95), faz uso dos recursos avanados da MMU
encontrada nos PCs de hoje, que foram introduzidos com o processador Intel 80386.
Sistema
Operacional
em RAM
Programa do
Usurio
a
Programa do
Usurio
Programa do
Usurio
Livre
Livre
b
c
Sistema
Operacional
em ROM
b
d
Livre
Device Drivers
em ROM
Sistema
Operacional
0
a
CPU
rea do
programa do
usurio
boundary
register
a
b
Espao livre
c
O boundary register contm o endereo da memria mais alta usada pelo SO. Cada
vez que um programa do usurio faz referncia a um endereo de memria, o registrador de
limitao verificado para certificar que o usurio no est prestes a escrever sobre a rea de
memria do SO. Se o usurio tenta entrar no cdigo do SO, a instruo interceptada e o job
terminado com uma mensagem de erro apropriada. Entretanto, claro que o programa do
usurio eventualmente precisa chamar certas funes que esto no cdigo do SO. Para isso o
usurio usa uma instruo especfica com a qual ele requisita servios do SO (uma instruo de
chamada em modo supervisor - supervisor call). Por exemplo, o usurio desejando ler da
unidade de fita vai disparar uma instruo requisitando a operao ao SO, que executar a
funo desejada e retornar o controle ao programa do usurio.
Entretanto,
conforme
SOs
ficaram
mais
complexos
tornaram-se
Sistema
Operacional
0
1432
rea do
programa do
usurio
CPU
1432
7000
8432
registrador
de relocao
registrador
de limite
Espao livre
Com este esquema, toda vez que um processo solicita acesso memria, ele deve
passar pela verificao dos dois registradores, conforme a figura 3.7:
Registrador
de limite
superior
CPU
Endereo
lgico
Registrador
de relocao
sim
<
Endereo
fsico
Memria
no
Exceo: erro de
endereamento
3.5Memria Virtual
3.5.1Paginao
3.5.2Algoritmos de Paginao
3.5.3Segmentao