Você está na página 1de 30

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

CURSO DE ANLISE E DESENVOLVIMENTO DE SISTEMAS

SIDNEY TETSUO KATO


WILLIAM DE SOUZA COLODRO

SISTEMAS OPERACIONAIS - PROCESSOS

PROJETO DE PESQUISA

Pato Branco
2015

SIDNEY TETSUO KATO


WILLIAM DE SOUZA COLODRO

SISTEMAS OPERACIONAIS - PROCESSOS

Projeto de Pesquisa do curso de Tecnologia em


Anlise

Desenvolvimento

de

Sistemas

da

Universidade Tecnolgica Federal do Paran


UTFPR, como atividade para composio de mdia
final da disciplina de Sistemas Operacionais

Pato Branco
2015

1. CONCEITOS
1.1. INTRODUO
Um processo basicamente um programa em execuo. Cada processo est
associado ao seu espao de endereamento, sendo ela uma lista de posies de
memria, que vai de 0 at um mximo, que esse processo pode ler e escrever. O
espao de endereamento contm o programa executvel, os dados do programa e
sua pilha. Tambm associado a cada processo est um conjunto de recursos,
normalmente incluindo registradores, uma lista dos arquivos abertos, alarmes
pendentes, listas de processos relacionados e todas as demais informaes que se
fazem necessrias para a execuo de um programa. Um processo
fundamentalmente um continer que armazena todas as informaes necessrias
para executar um programa.
A gerncia de um ambiente multiprogramvel funo exclusiva do sistema
operacional que deve controlar a execuo dos diversos programas e o uso
concorrente do processador e demais recursos. Para isso, um programa ao ser
executado deve estar sempre associado a um processo.
A gerncia de processos uma das principais funes de um sistema operacional,
possibilitando

aos

programas

alocar

recursos,

compartilhar

dados,

trocar

informaes e sincronizar suas execues. Nos sistemas multiprogramveis os


processos so executados concorrentemente, compartilhando o uso do processador,
memria principal e dispositivos de entrada e sada, dentre outros recursos. Nos
sistemas com mltiplos processadores no s existe a concorrncia de processos
pelo uso do processador como tambm a possibilidade de execuo simultnea de
processos nos diferentes processadores.

Pato Branco
2015

1.2. ESTRUTURA DO PROCESSO


Para que a troca de programas ocorra sem problemas, necessrio que todas as
informaes do programa interrompido sejam guardadas para que, quando este
retornar a ser executado, no lhe falte nenhuma informao necessria
continuao do processamento. Todas as informaes importantes e necessrias
execuo de um programa fazem parte do processo.
Um processo formado por trs partes, conhecidas como contexto de hardware,
contexto de software e espao de endereamento, que juntas mantm todas as
informaes necessrias execuo de um programa.

Figura 1 - Estrutura do Processo, UTFPR, Campus Pato Branco-PR, 2015.

Pato Branco
2015

1.2.1. CONTEXTO DE HARDWARE


O contexto de Hardware armazena o contedo dos registradores gerais da CPU e
de uso especfico, como o program counter (PC), o stack pointer (SP) e o registrador
de status (PSW).
Quando um processo est em execuo, os registradores da CPU so utilizados.
Assim que o processo perde a utilizao da CPU, o sistema salva o contexto de
hardware no processo. A troca de um processo por outro na CPU chamada de
mudana de contexto.

1.2.2. CONTEXTO DE SOFTWARE


So especificadas as caractersticas e limites dos recursos que podem ser alocados
pelo processo, como prioridade para execuo, privilgios, tamanho do buffer para
operaes de entrada e sada, etc.
O contexto de software formado por trs grupos de informaes, sendo elas:
identificao (principalmente o nmero de identificao do processo [PID] e nmero
de identificao do usurio que o criou [UID]), quotas (limites de cada recurso do
sistema que um processador pode alocar) e privilgios (o que o processo pode ou
no fazer em relao ao sistema e aos outros processos.

Pato Branco
2015

1.2.2. ESPAO DE ENDEREAMENTO


a rea do processo onde as instrues e os dados do programa so armazenados
para execuo. Cada processo possui o seu espao, nenhum outro poder ocup-lo,
sendo assim, deve ser protegido do espao de endereamento dos demais
processos.

Figura 1 - Caractersticas da estrutura de um processo. UTFPR, Campus Pato Branco-PR,


2015.

Pato Branco
2015

1.3. ESTADO DO PROCESSO


Nos

sistemas

operacionais

multitarefa,

um

processo

no

poder

ocupar

exclusivamente uma CPU. Para que o compartilhamento da CPU seja efetivado, um


processo passa por vrios estados ao longo de seu completo processamento.
A mudana no estado do processo pode ser gerada tanto por eventos do sistema
operacional quanto por si prprio. Um processo ativo pode se encontrar em trs
estados, sendo eles: pronto (processo pronto e esperando ser executado pela CPU),
execuo (processo sendo executado pela CPU) e espera (processo est esperando
por algum evento externo ou por algum recurso para poder prosseguir com seu
processamento).

1.4. MUDANA DE ESTADO DO PROCESSO


Os processos podem ter seu estado alterados por eventos do prprio processo
(eventos voluntrios) ou pelo sistema operacional (eventos involuntrios). Essas
mudanas so divididas em 4 partes, sendo elas:

Pronto -> Execuo

Execuo -> Espera

Espera -> Pronto

Execuo -> Pronto

Um processo em estado de pronto ou espera pode no se encontrar na memria


principal. Esta condio existe quando no existe espao suficiente para todos os
processos na memria principal e parte do processo levada para a memria
secundria. Essa tcnica chamada de swapping.

Pato Branco
2015

2. THREADS
2.1. Introduo
Em sistemas operacionais tradicionais, cada processo tem um espao de
endereamento e um nico thread de controle. Na verdade, isso quase uma
definio de processo. Conteudo, frequentemente h situaes em que desejvel
ter mltiplos threads de controle no mesmo espao de endereamento executando
um quase-paralelo, como se eles fossem processos separados (exceto pelo espao
de endereamento compartilhado).

2.2. Ambiente Monothread


Em um ambiente monothread, um processo suporta apenas um programa no seu
espao

de

endereamento.

Neste

ambiente,

aplicaes

concorrentes

so

implementadas apenas com o uso de mltiplos processos independentes ou


subprocessos.
A utilizao de processos independentes e subprocessos permite dividir uma
aplicao em partes que podem trabalhar de forma concorrente. O problema neste
tipo de implementao 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.

Pato Branco
2015

Outro problema a ser considerado quanto ao compartilhamento de 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 disto, o compartilhamento de recursos comuns aos processos
concorrentes, como memria e arquivos abertos, no simples.

Figura 3 - Ambiente monothread. UTFPR, Campus Pato Branco-PR, 2015.

Pato Branco
2015

2.3. AMBIENTE MULTITHREAD


Em um ambiente multithread no existe a ideia de programas associados a
processos, mas, sim, a threads. O processo, neste ambiente, tem pelo menos um
thread de execuo, mas pode compartilhar o seu espao de endereamento com
inmeros outros threads.

Figura 4 - Ambiente multithread. UTFPR, Campus Pato Branco-PR, 2015.

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. Desta forma, um ambiente multithread
possibilita a execuo concorrente de sub-rotinas dentro de um mesmo processo.

Pato Branco
2015

Na figura 5 existe um programa principal que realiza a chamada de duas sub-rotinas


assncronas (Sub_1 e Sub_2). Inicialmente, o processo criado apenas com o
Thread_1 para a execuo do programa principal. Quando o programa principal
chama as sub-rotinas Sub_1 e Sub_2, so criados os Thread_2 e Thread_3,
respectivamente, e executados independentemente do programa principal. Neste
processo, os trs threads so executados concorrentemente.

Figura 5 - Aplicao multithread. UTFPR, Campus Pato Branco-PR, 2015.

Pato Branco
2015

No ambiente multithread, cada processo pode responder a vrias 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, alm 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). Para permitir a
troca de contexto entre os diversos threads, cada thread possui seu prprio contexto
de hardware, com o contedo dos registradores gerais, PC e SP. Quando um thread
est sendo executado, seu contexto de hardware est armazenado nos
registradores do processador. No momento em que o thread perde a utilizao da
UCP, as informaes so atualizadas no seu contexto de hardware.
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 (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.
A grande diferena entre aplicaes monothread 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. Esta caracterstica permite que o
compartilhamento de dados entre threads de um mesmo processo seja mais simples
e rpido, se comparado a ambientes monothread.

Pato Branco
2015

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 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 srie 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 menos overhead. 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.

Pato Branco
2015

3. ESCALONAMENTO
3.1. INTRODUO
Um Escalonador de Processos um subsistema do Sistema Operacional
responsvel por decidir o momento em que cada processo obter a CPU. utilizado
algoritmos de escalonamento que estabelecem a lgica de tal deciso. Nesse
momento de decidir qual escalonador ser utilizado no sistema operacional, cabe
avaliar o cenrio que o sistema ser utilizado.
Deve-se ter cuidado com algumas variveis como em casos que necessitam de mais
processamento, ou seja, ao da CPU. Como com processos que necessitam de
processamento, ocuparo a CPU por um tempo maior e no precisaro, ou de
pouca, interveno do usurio. Por exemplo, programas de clculo cientfico, que o
usurio insere parmetros e executa o programa que demorar um determinado
tempo para mostrar os resultados, isso exige processamento da CPU, com entrada
e sada de dados apenas no momento inicial. J processos que necessitam de mais
entrada e sada de dados, ou seja, o processo necessita de interveno do usurio.
Por exemplo, ao digitar um texto, h entrada e sada de dados, logo, a resposta do
ato de teclar e a resposta de aparecer isso na tela exige que esse processo entra e
sai da CPU inmeras vezes e em um pequeno espao de tempo.
A seguir dois diferentes comportamentos de processos. Aqueles orientados a
Entrada e Sada (IN/OUT bound) e aqueles orientados a orientados a CPU (CPU
bound):

Pato Branco
2015

Figura 6 - Comportamento de processos. UTFPR, Campus Pato Branco-PR, 2015.

3.2. QUANDO ESCALONAR


O sistema operacional toma a deciso de intervir ou no sobre qual processo
ganhar

CPU,

neste

caso,

dois

cenrios

de

escalonamento:

O Escalonamento No Preemptivo que ocorre apenas em situaes que


praticamente obrigam que uma deciso seja tomada. Esse cenrio tem as seguintes
condies: Criao de um novo processo; Trmino de um processo; Processo ser
bloqueado; Aps alguma interrupo.
E o Escalonamento Preemptivo que escolhe um processo e lhe concede a CPU
durante certo tempo. Findado esse tempo, a CPU de outro processo. Esse cenrio
tem as seguintes condies: Criao de um novo processo; Trmino de um
processo; Processo ser bloqueado; Aps alguma interrupo; Periodicamente, a
cada k intervalos de relgio.

Pato Branco
2015

3.3. CATEGORIAS.
O Escalonamento de Processos pode envolver diferentes tipos de requisitos,
seguindo assim diferentes parmetros e diferentes lgicas. sugerida uma
classificao segundo o tipo de sistema, o tipo de aplicao onde o algoritmo estar
atuando. Segue os sistemas e seus objetivos:
Todos os sistemas possuem o objetivo geral de justia, dar a cada processo uma
poro justa da CPU; aplicao da poltica do algoritmo, verificar se a poltica
estabelecida est sendo cumprida; equilbrio e manter ocupada todas as partes do
sistema.
Sistemas em Lote possuem o objeto de vazo (throughput), maximizar o nmero de
Jobs por hora; tempo de retorno, minimizar o tempo entre a submisso e o trmino;
utilizao de CPU, manter a CPU ocupada por todo tempo.
Sistemas Interativos possuem o objetivo de tempo de resposta, responder
rapidamente s requisies; proporcionalidade, satisfazer as expectativas dos
usurios.
Sistemas de Tempo Real possuem o objetivo de cumprimento dos prazos, evitar a
perda de dados; previsibilidade, evitar a degradao da qualidade em sistemas
multimdia.

Pato Branco
2015

3.4. ESCALONAMENTO POR PRIORIDADES COM ESCALONAMENTO ROUND


ROBIN
Esse mtodo um misto entre o Algoritmo Prioridade e o Algoritmo Round Robin.
Falando sobre o Algoritmo Escalonamento Round Robin: Trata-se de um algoritmo
para um escalonamento por alternncia circular onde cada processo ganha um
intervalo de tempo para uso contnuo da CPU (quantum), se ao final do quantum o
processo ainda est processando, h preempo e outro processo ser escolhido.
Mas se houver bloqueio ou o processo terminou antes do fim do quantum, outro
processo ser escolhido. O dimensionamento do quantum um detalhe sensvel e
merece observaes futuras.
E falando sobre o Algoritmo por Prioridades: Cada processo possui uma prioridade.
O processo pronto com maior prioridade ganha a CPU. Processo de mais alta
prioridade deixaria a CPU somente quando quisesse. Pode-se baixar a prioridade do
processo executando, a cada tique do relgio. Ou estabelecer um quantum mximo.
A atribuio das prioridades dos processos pode ser esttica ou dinmica.
Ento, falando sobre o Algoritmo de escalonamento por Prioridade + Round Robin:
Definem-se as classes de prioridade. Normalmente promove justia apenas intraclasse.

Pato Branco
2015

A figura a seguir mostra a organizao dos processos numa fila ordenada de tal
forma que os processos com maior prioridade esto em cima, e conforme for
diminuindo a posio na fila, diminui a prioridade dos processos. O funcionamento
conforme o Algoritmo Round Robin organiza os processos de uma mesma posio
na fila de prioridades onde ao sair da CPU vai para o final da fila dentro desse grupo
de prioridades.

Figura 7 - Round Robin com prioridades. UTFPR, Campus Pato Branco-PR, 2015.

Pato Branco
2015

4. SINCRONIZAO E COMUNICAO ENTRE PROCESSOS


4.1. INTRODUO
natural que processos de uma aplicao concorrente compartilhem recursos do
sistema, como arquivos, registros, dispositivos de entrada e sada e rea de
memria. O compartilhamento de recursos entre processos pode ocasionar
situaes indesejveis, capazes at de comprometer a execuo das aplicaes.
Para evitar esse tipo de problema, os processos concorrentes devem ter suas
execues sincronizadas, a partir de mecanismos oferecidos pelo sistema
operacional, com o objetivo de garantir o processamento correto dos programas.
Muitas vezes, em aplicaes concorrentes e/ou em aplicaes paralelas,
necessrio

que

processos

se

comuniquem.

Esta

comunicao

pode

ser

implementada atravs de diversos mecanismos, como variveis compartilhadas na


memria principal ou troca de mensagens.

Figura 8 - Sincronizao e comunicao entre processos. UTFPR, Campus Pato Branco-PR,


2015.

Pato Branco
2015

Os mecanismos que garantem a comunicao entre processos concorrentes e os


acessos aos recursos compartilhados so chamados mecanismos de sincronizao.
No projeto de sistemas operacionais multiprogramveis, fundamental a
implementao destes mecanismos para garantir a integridade e a confiabilidade na
execuo de aplicaes concorrentes.

4.2. PROBLEMAS DE COMPARTILHAMENTO DE RECURSOS


Os

sistemas

operacionais

multiprogramveis

executam

diversos

processos

concorrentemente, e cada processo por sua vez, pode executar diversas partes do
seu cdigo concorrentemente tambm, ou seja, cada processo pode ter diversas
threads.

Como

processos

executando

concorrentemente

ou

em

paralelo

compartilham recursos do sistema, isso pode ocasionar alguns problemas, como


compartilhamento de um arquivo em disco ou uma varivel na memria sendo
compartilhada por dois processos.
Para evitar este tipo de problema, em qualquer um dos dois exemplos anteriores,
seja para o compartilhamento de arquivos em disco, seja para o compartilhamento
de uma mesma varivel na memria, o sistema operacional deve implementar
mecanismos de controle, entre elas a excluso mtua (Mutex) que evita que dois ou
mais processos acessem um mesmo recurso simultaneamente. Para isso, enquanto
um processo estiver acessando um determinado recurso e, caso algum outro
processo necessite acessar o mesmo recurso, este processo deve aguardar o
trmino da utilizao do recurso pelo primeiro processo, ou seja, o recurso fica de
uso exclusivo do processo que iniciou primeiro sua utilizao. Essa ideia chamada
de excluso mtua.

Pato Branco
2015

Outra situao a espera ocupada (busy wait) onde um processo que est fora de
sua regio crtica, quando executa seu protocolo de entrada na regio crtica e no
consegue acesso ao recurso, ento fica testando permanentemente se pode entrar
na sua regio crtica.
Diversas solues foram propostas para garantir a excluso mtua de processos
concorrentes, podendo ser via hardware ou software.

4.3 SOLUES DE HARDWARE


Uma soluo de hardware seria desabilitar todas as interrupes antes de entrar em
uma regio crtica e as reabilitar aps deixar a mesma. Como a mudana de
contexto de processos s pode ser realizada atravs de interrupes, o processo
que as desabilitou ter acesso exclusivo garantido.
Outra soluo seria a instruo test-and-set que tem como caracterstica ser
executada sem interrupo, ou seja, trata-se de uma instruo indivisvel. Dessa
forma, garantido que dois processos no manipulem uma varivel compartilhada
ao mesmo tempo, possibilitando a implementao da excluso mtua.
O uso de uma instruo especial de mquina oferece algumas 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 de starvation, pois a seleo do processo para
acesso ao recurso arbitrria.

Pato Branco
2015

4.4. SOLUES DE SOFTWARE


No caso, existem algumas solues para software que seria a implementao de
diversos algoritmos, 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, mas depois foi desenvolvido de forma evolutiva uma soluo definitiva
para a excluso mtua entre N processos, entre elas, o algoritmo de Dekker, de
Peterson e tambm, algoritmos para solucionar o problema de espera ocupada
(busy wait) que foi a introduo de mecanismos de sincronizao que permitiriam
que um processo, quando no pudesse entrar em sua regio crtica, fosse colocado
no estado de espera.
Entre estas solues, est a sincronizao condicional, sendo utilizado em situaes
em que o acesso ao recurso compartilhado exige a sincronizao de processos
vinculada a uma condio de acesso. Um recurso pode no se encontrar pronto para
uso devido a uma condio especfica. Nesse caso, o processo que deseja acesslo dever permanecer bloqueado (em espera) at que o recurso fique disponvel.
Um exemplo clssico desse tipo de sincronizao a comunicao entre dois
processos atravs de operaes de gravao e leitura em um buffer, onde
processos geram informaes (processos produtores) utilizadas por outros
processos (processos consumidores). Nessa comunicao, enquanto um processo
grava dados em um buffer, o outro l os dados, concorrentemente. Os processos
envolvidos devem estar sincronizados a uma varivel de condio, de forma que um
processo no tente gravar dados em um buffer cheio ou realizar uma leitura em um
buffer vazio.

Pato Branco
2015

Outra soluo de software se encontra no conceito de Semforos, proposto por


Dijkstra em 1965, sendo apresentado como um mecanismo de sincronizao que
permitia implementar, de forma simples, a excluso mtua e sincronizao
condicional entre processos. Atualmente, a maioria das linguagens de programao
disponibiliza rotinas para uso de semforos.
Pode-se utilizar tambm a sincronizao condicional utilizando semforos, o qual
alm de permitir a implementao da excluso mtua, possibilita que semforos
sejam utilizados nos casos onde a sincronizao condicional exigida. Um exemplo
desse tipo de sincronizao ocorre quando um processo solicita uma operao de
Entrada/Sada. O pedido faz com que o processo execute uma instruo DOWN no
semforo associado ao evento e fique no estado de espera, at que a operao seja
completada. Quando a operao termina, a rotina de tratamento da interrupo
executa um UP no semforo, liberando o processo do estado de espera.
Semforos contadores so bastante teis quando aplicados em problemas de
sincronizao condicional onde existem processos concorrentes alocando recursos
do mesmo tipo (pool de recursos). O semforo inicializado com o nmero total de
recursos e sempre que um processo deseja alocar um recurso, executa um DOWN,
subtraindo 1 do nmero de recursos disponveis. Da mesma forma, sempre que o
processo libera um recurso, executa um UP. Se o semforo contador ficar como
valor igual a 0, ento no h mais recursos 18 disponveis no sistema e o processo
que solicitar o recurso permanecer em estado de espera at que o recurso seja
liberado.

Pato Branco
2015

H tambm mecanismos de sincronizao de alto nvel, como os Monitores. O


conceito de monitores foi proposto por Brinch Hansen em 1972, e desenvolvido por
C.A.R. Hoare em 1974, como um mecanismo de sincronizao estruturado, ao
contrrio dos semforos, que so considerados no estruturados.
Monitores so implementados no compilador. Inicialmente, algumas poucas
linguagens de programao, como o Concurrent Pascal, Modula-2 e Modula-3,
ofereciam suporte ao uso de monitores. Atualmente, a maioria das linguagens de
programao disponibiliza rotinas para uso de monitores.
O monitor formado por procedimentos e variveis encapsulados dentro de um
mdulo. Sua caracterstica mais importante a implementao automtica da
excluso mtua entre os procedimentos declarados, ou seja, somente um processo
pode estar executando um dos procedimentos do monitor em um determinado
instante. Toda vez que algum processo faz uma chamada a um desses
procedimentos, o monitor verifica se j existe outro processo executando algum
procedimento do monitor. Caso exista, o processo ficar aguardando sua vez em
uma fila de entrada. As variveis globais de um monitor so visveis apenas aos
procedimentos da sua estrutura, sendo inacessveis fora do contexto do monitor.
Toda a inicializao das variveis realizada por um bloco de comandos do monitor,
sendo executado apenas uma vez, na ativao do programa onde est declarado o
monitor.

Pato Branco
2015

Figura 9 - Estrutura de um monitor. UTFPR, Campus Pato Branco-PR, 2015.

A implementao da excluso mtua utilizando monitores no realizada


diretamente pelo programador, como no uso de semforos. As regies crticas
devem ser definidas como procedimentos do monitor, e o compilador se encarregar
de garantir a excluso mtua entre esses procedimentos.
A comunicao do processo com o monitor feita unicamente atravs de chamadas
aos seus procedimentos e dos parmetros passados.
Ainda possvel realizar a sincronizao condicional utilizando monitores.
Atravs de variveis especiais de condio, possvel associar a execuo de um
procedimento que faz parte do monitor a uma determinada condio, garantindo a
sincronizao condicional.

Pato Branco
2015

As variveis especiais de condio so manipuladas por intermdio de duas


instrues, conhecidas como WAIT e SIGNAL. A instruo WAIT faz com que o
processo seja colocado no estado de espera, at que algum outro processo sinalize
com a instruo SIGNAL que a condio de espera foi satisfeita. Caso a instruo
SIGNAL seja executada e no haja processo aguardando a condio, nenhum efeito
surtir.
Vrios processos podem estar em estado de espera esperando por vrias
condies. O monitor organiza os processos em espera utilizando filas associadas
s condies de sincronizao. A execuo da instruo SIGNAL libera apenas um
nico processo da fila de espera da condio associada.
Pode-se utilizar tambm o mecanismo de comunicao e sincronizao entre
processos pela troca de mensagens.
Troca de Mensagens um mecanismo de comunicao e sincronizao entre
processos. O sistema operacional possui um subsistema de mensagem que suporta
esse mecanismo sem que haja necessidade do uso de variveis compartilhadas.
Para que haja a comunicao entre os processos, deve existir um canal de
comunicao, podendo esse meio ser um buffer ou um link de uma rede de
computadores.
Os processos cooperativos podem fazer uso de um buffer para trocar mensagens
atravs de duas rotinas: SEND (receptor, mensagem) e RECEIVE (transmissor,
mensagem). A rotina SEND permite o envio de uma mensagem para um processo
receptor, enquanto a rotina RECEIVE possibilita o recebimento de mensagem
enviada pelo processo transmissor.

Pato Branco
2015

O mecanismo de troca de mensagens exige que os processos envolvidos na


comunicao tenham suas execues sincronizadas. A sincronizao necessria,
j que uma mensagem somente pode ser tratada por um processo aps ter sido
recebida, ou o envio de mensagem pode ser uma condio para a continuidade de
execuo de um processo.
A troca de mensagens entre processos pode ser implementada de duas maneiras:
comunicao direta e comunicao indireta. A comunicao direta entre dois
processos exige que, ao enviar ou receber uma mensagem, o processo enderece
explicitamente o nome do processo receptor ou transmissor. Isto pode ser um
problema, quando o processo muda de nome durante a execuo, no caso, o
programa deveria ser recompilado.
A comunicao indireta entre processos utiliza uma rea compartilhada, onde as
mensagens podem ser colocadas pelo transmissor e retiradas pelo receptor. Essa
rea chamada de mailbox ou port, um tipo de buffer, e tem como caractersticas
a sua identificao e capacidade de armazenamento de mensagens, que so
definidas no momento de sua criao.
Existem trs diferentes esquemas de implementar a sincronizao entre processos
que trocam mensagens. O primeiro esquema de sincronizao garantir que um
processo, ao enviar uma mensagem, permanea esperando at que o processo
receptor a leia. Na mesma condio, um processo, ao tentar receber uma
mensagem ainda no enviada, deve permanecer aguardando at que o processo
transmissor faa o envio. Esse tipo de comunicao implementa uma forma sncrona
de comunicao entre os processos que conhecida como rendezvous. O problema
dessa implementao que a execuo dos processos fica limitada ao tempo de
processamento no tratamento das mensagens.

Pato Branco
2015

O segundo esquema uma variao mais eficiente do rendezvous, que permitir


que o processo transmissor no fique bloqueado aguardando a leitura da
mensagem. Neste caso, possvel enviar mensagens para diversos destinatrios.
O terceiro esquema implementa uma forma assncrona de comunicao, onde tanto
o processo transmissor, quanto o processo receptor no permanecem aguardando o
envio e o recebimento de mensagens. Nesse caso, alm da necessidade de buffers
para armazenar as mensagens, deve haver outros mecanismos de sincronizao
que permitam ao processo identificar se uma mensagem foi recebida ou enviada. A
grande vantagem deste mecanismo aumentar a eficincia de aplicaes
concorrentes.

4.5. DEADLOCK
Deadlock a situao em que um processo aguarda por um recurso que nunca
estar disponvel ou um evento que nunca ocorrer. Essa situao consequncia,
na maioria das vezes, do compartilhamento de recursos, como dispositivos, arquivos
e registros, entre processos concorrentes onde a excluso mtua exigida. O
problema do deadlock torna-se cada vez mais frequente e crtico na medida em que
os sistemas operacionais evoluem no sentido de implementar o paralelismo de
forma intensiva e permitir a alocao dinmica de um nmero ainda maior de
recursos.

Pato Branco
2015

Para que ocorra o deadlock quatro situaes so necessrias simultaneamente:


1. Excluso mtua: cada recurso s pode estar alocado a um nico processo em um
determinado instante;
2. Espera por recurso: um processo, alm dos recursos j alocados, pode estar
esperando por outros recursos;
3. No preempo: um recurso no pode ser liberado de um processo s porque
outros processos desejam usar o mesmo recurso;
4. Espera circular: um processo pode ter de esperar por um recurso alocado a outro
processo e vice-versa.

Figura 10 - Espera circular. UTFPR, Campus Pato Branco-PR, 2015.

Pato Branco
2015

5. REFERNCIAS E BIBLIOGRAFIA
NOVATO, Douglas. Sistemas Operacionais - O que Escalonamento de Processos?
OFICINA DA NET. Disponvel em: <http://www.oficinadanet.com.br/post/12781sistemas-operacionais-o-que-e-escalonamento-de-processos>. Acesso em: 16 mar.
2015.
Sincronizao

Comunicao

entre

Processos

FACOL.

Disponvel

em:

<http://www.facol.br/sophia/2741/apostila09_sincronizacao_comunicacao_entre_pro
cessos.pdf>. Acesso em: 16 mar. 2015.
Sistemas

Operacionais

Captulo

Processo.

Disponvel

em:

<

http://www.gsigma.ufsc.br/~popov/aulas/so1/cap6so.html>. Acesso em: 17 mar.


2015.
Tanenbaum, Andrew S. Sistemas Operacionais Modernos 2. ed. Prentice Hall (
Pearson ), 2003.
Machado, F. B. Maia, L. P. Arquitetura de Sistemas Operacionais. 3. ed. LTC. 2002.

Pato Branco
2015