Pato Branco 2015

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 e 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 a CPU, neste caso, h 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 intra-

classe.

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 acess-

lo 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: . Acesso em: 16 mar.

2015.

Sincronizao e Comunicao entre Processos FACOL. Disponvel em:

. Acesso em: 16 mar. 2015.

Sistemas Operacionais - Captulo 6 - 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.