Sistemas Operacionais

Distribudos

Alunos: Wanderlei Pereira Alves Junior

Jlio Cezar Estrella

Orientao: Prof. Dr. Norian Marranghello

Sistemas Operacionais Distribudos UNESP/IBILCE

Sistemas Operacionais Distribudos

Mecanismos de Linguagens e Threads

Tpicos Abordados

Introduo: Classificao dos Sistemas Operacionais

Surgimento dos Sistemas Operacionais Distribudos
O que um Sistema Operacional Distribudo?

Blocos de controle de ramificaes (Threads)

Comparao entre ramificaes e processos
Custo de criao e implementao de ramificaes
Ramificaes no servidor ou no ncleo de sistemas operacionais
Ramificaes em multiprocessadores
O modelo cliente/servidor
Construes de linguagens
Mecanismos de sincronizao
Especificao de atividades concorrentes
Sincronizao e comunicao entre processos
Execuo no deterministic de processos
Estrutura de programas
Estrutura de dados
Estruturas de controle
Sincronizao de variveis compartilhadas
Semforos
Monitores
Regies criticas condicionais
Path Expressions
Sincronizao por passagem de mensagens
Chamada remota de procedimentos
Ada Rendevouz
Processos Concorrentes

2
Sistemas Operacionais Distribudos UNESP/IBILCE

1. Classificao dos Sistemas Operacionais

Os sistema operacionais podem ser classificados de acordo com seu grau de acoplamento, a
saber:

9 Redes
9 Autmatos
9 Centralizados
9 Distribudos

Para classific-los deste modo, so levados em considerao os seguintes fatores:

9 Interoperabilidade
9 Transparncia
9 Autonomia

Apenas citaremos as funcionalidades de alguns sistemas referenciados acima, uma vez que
a nfase ser dada aos Sistemas Distribudos.

1.1. Sistemas Centralizados

Caractersticas:

So fortemente acoplados, so do tipo monoltico, ou seja no h o particionamento do

ncleo. Nos sistemas monolticos os servios do sistema e do ncleo fazem parte de um
mesmo programa.

1.2. Sistemas em Rede

Caractersticas:

um multicomputador fracamente acoplado no qual no existe nenhum tipo de controle

direto de uma mquina sobre as outras e no qual a comunicao entre as outras mquinas
bem mais lenta que dentro de uma dada mquina.
O compatilhamento de recursos o objetivo principal dos sistemas em rede.

1.3. Sistemas Autmatos

Tais sistemas mantm as noes de transparncia e interoperabilidade que existem nos

Sistemas Distribudos, mas abolem a impresso de que existe somente um usurio no
sistema.

3
Sistemas Operacionais Distribudos UNESP/IBILCE

1.4. Sistemas Distribudos

So aqueles que gerenciam as atividades e os recursos distribudos, possibilitando um

processamento descentralizado e melhorando o desempenho do sistema.

Outra definio: Um conjunto de processos que so executados de forma concorrente,

cada um dos quais acessando um subconjunto de receursos do sistema por meio de um
mecanismo de troca de mensagens atravs de uma rede de comunicao, que nem sempre
confivel.

As vantagens de um Sistema Distribudo em relao aos outros sua maior disponibilidade,

geralmente resultante da redundncia de seus componentes

Sistema Distribudo Mais transparente que os Sistemas em Rede

Essa transparncia pode ser notada em vrios aspectos:

9 Transparncia de acesso a arquivos

9 Transparncia de desempenho
9 Transparncia de localizao
9 Transparncia de concorrncia

Aspectos importantes na construo de um sistema operacional:

Eficincia

Os parmetros para medir o desempenho do sistema (eficincia) so diversos, tais como:

vazo, tempo de execuo de uma determinada tarefa, taxa de uso do sistema e de seus
recursos.

Obs: A eficincia em sistemas distribudos mais complexa em relao aos Sistemas

Operacionais Convecionais, devido aos atrasos na comunicao.
Obs: O tempo gasto na propagao dos dados depende fortemente do protocolo de
comunicao utilizado, motivo pelo qual este deve ser bem projetado, como base em
primitivas de comunicao eficientes.

Fatores que afetam a eficincia:

9 Tempo gasto na propagao dos dados

9 Balanceamento de carga
9 Ganulosidade das tarefas
9 Tolerncia a faltas

4
Sistemas Operacionais Distribudos UNESP/IBILCE

Flexibilidade

Fatores associados:

9 Interoperabilidade
9 Modularidade
9 Portabilidade
9 Escalabilidade

Consistncia

Um sistema consistente se:

9 Permite um uso uniforme

9 E se possui um comportamento previsvel

Fatores que afetam a consistncia do sistema:

9 Ausncia de um mecanismo global

9 Inexistncia de informaes a respeito do desempenho global

Robustez

Para ser robusto um Sistema Distribudo tem que estar disponvel a maior parte do tempo,
apresentando dados confiveis.
A confiabilidade deste sistema tambm est associado aos mecanismos de proteo
existentes.
Transparncia

Capacidade que um Sistema apresenta, de esconder dos usurios, detalhes de

implementao, em particular queles mais complexos, e apresentar na medida do possvel
um modelo lgico da mquina como os usurios gostariam de usar e no como o sistema
realmente.

2. O que so Threads?

Definio bsica: Fluxo de controle seqencial isolado dentro de um programa.

Outra denominao: LightWeight Processes (Processos Peso Pena)
Ou processos leves que compartilham o espao de endereos lgicos.
Programas multithreaded: Mltiplos threads concorrentes de execuo num nico
programa, realizando vrias tarefas ao mesmo tempo.

5
Sistemas Operacionais Distribudos UNESP/IBILCE

Exemplo: programa do usurio + coleta de lixo

Diferentes threads podem executar em diferentes processadores, se disponveis, ou

compartilhar um processador nico

Diferentes threads no mesmo programa compartilham um ambiente global (memria,

processador, registradores, etc.)

2.1. Quais as funcionalidades dos threads?

Threads permitem que um programa simples possa executar vrias tarefas diferentes ao
mesmo tempo, independentemente umas das outras.
Quando executado, um programa pode gerar ramificaes no seu fluxo de controle. Tais
ramificaes (threads) tem seus estados locais individuais, mas permanecem associados ao
processo que as gerou.
Cada um desse processos possui um TCB (Thread Control Blocks), semelhante ao PCB dos
processos. Como os threads so processos leves, associados aos processos que os gerou,
esses TCB possuem informaes locais reduzidas (contador de programa, apontadores de
pilha e conjunto de registradores).
A mudana de contexto de um thread em relao a um processo mais rpida pois os
threads alm possuem informaes locais, compartilham o restante das informaes com os
processos que os gerou.
Os processos funcionam como mquinas virtuais, pois compartilham seu espao de
endereamento com os threads.

2.2. Onde so implementado os threads?

Depende!!!
Agilidade
Se o objetivo agilidade, deve-se implement-los no espao do usurio.
Neste caso o controle de processos feito diretamente pelo sistema operacional, mas os
threads so controlados por procedimentos em tempo de execuo que serve como interface
entre a mquina virtual (processos) onde rodam os threads e o sistema operacional.
Obs: Neste caso, o sistema operacional no enxerga os threads, pois eles so
implementados no espao do usurio, sendo submissos ao processo que os criou.
Os threads no podem usufruir do sistema de interrupes do sistema operacionais e
portanto so no-preemptveis.

6
Sistemas Operacionais Distribudos UNESP/IBILCE

Vantagens
9 agilidade
9 o gerenciamento menos complicado
Desvantagens
9 no preempo
9 impedidos de utilizar interrupes do sistema operacional

Eficincia
Se o objetivo eficincia, ento os threads podem ser implementados no ncleo do sistema
operacional, podendo serem vistos pelo SO e usufruindo de seu sistema de interrupes.
Portanto passam a serem preemptveis.
Nesse sentido os threads passam a ser tratados como processos, possibilitando o bloqueio
de outros threads e tambm eficincia no escalonamento.
O leitor deve notar que agora no h necessidade de interromper o processo que o gerou
(processo pai), uma vez que o thread um processo.
Com isso o Sistema Operacional pode interromper um thread sem interromper o processo
pai, e tambm outras ramificaes em execuo. O thread tambm ir competir igualmente
com os processos os ciclos do processador.
Vantagens de implementao no ncleo

9 Maior autonomia dos threads

Desvantagens
9 sistema perde em portabilidade, as mudanas de contexto dos threads tem agora a
mesma complexidade dos processos e a concorrncia fica reduzida a dois nveis
(threads e processos).

2.3. Quando um thread deixa de existir?

9 Quando terminam sua execuo

9 Quando o tempo alocado a seu processo pai foi esgotado
9 Ou se solicitou algum recurso do sistema

7
Sistemas Operacionais Distribudos UNESP/IBILCE

2.4. Aplicaes Multithread

Programas multithread so programas que contm vrias threads, executando tarefas

distintas, simultaneamente. O browser HotJava, implementado em Java, um exemplo. Da
mesma forma que o Netscape, o HotJava poder fazer um scroll em uma pgina enquanto
carrega uma imagem ou executa vrios applets ao mesmo tempo.

Exemplos:

Programao Reativa : aplicao responde a eventos de entrada.

Exemplo: interfaces com o usurio, onde cada evento corresponde a uma ao

Programao Interativa: uma tarefa para fazer alguma interao com o usurio, outra para
exibir mensagens, outra para fazer animao, etc..

Paralelismo fsico/ distribuio: para tirar vantagem de mltiplas CPUs centralizadas ou

distribudas

2.5. Exemplo de aplicao utilizando ramificaes

Implementao de processos servidores que prestam servios a processos clientes.

O emprego de ramificaes na estrutura de controle do servidor, permite o agrupamento

dos threads num mesmo espao de endereamento, admitindo acesso concorrente de vrios
clientes a um nico servidor.
H dois tipos de ramificaes:

Ramificaes Estticas:

Criadas em tempo de compilao

Exemplo: Servidores de terminais

Servidor cria ramificaes

Essas ramificaes so locais ao servidor

Ramificaes atendem usurios enquanto estiverem conectados

8
Sistemas Operacionais Distribudos UNESP/IBILCE

Essas ramificaes compartilham o mesmo espao de endereo (dos processos pais), ento
quando precisam acessar algum recurso compartilhado, a exclusividade do acesso feita
via mecanismos de sincronizao como os monitores e semforos.

Como a ramificao fica no sistema enquanto o usurio estiver conectado, ela ocupa o
espao de memria mesmo que o cliente no requisite nenhuma operao do servidor.

Ramificaes Dinmicas:

Criadas e destrudas de acordo com as necessidades.

Exemplo: Servidores de arquivos

Nesses servidores h diversas operaes de leitura/escrita. Nesse contexto existe um

processo que tm a funo de coordenar essas atividades.
Cada vez que um cliente solicita uma operao, o servidor cria uma ramificao que ficar
responsvel por determinada tarefa (leitura/escrita) e terminado sua execuo o controle
volta novamente ao processo que a criou.

Por exemplo, se forem feitas vrias operaes de leitura, sero geradas vrias ramificaes
do processo responsvel pela operao de leitura.
O mesmo acontece com a operao de escrita.

Obs: importante ressaltar novamente que essas ramificaes (threads) sero executadas
independentes uma das outras, e sero extintas assim que o servio para qual foram
criadas, tambm termine.

Vantagens da implementao no servidor

9 Aumenta a flexibilidade
9 Agrupamento de threads no mesmo espao de endereamento

Desvantagens

9 Complica o gerenciamento das ramificaes

2.6. Concluso

A utilizao do mecanismos de ramificaes permite que a memria seja otimizada e

tambm reaproveitada assim que essas terminem sua execuo, levando a uma reduo
considervel no custo do sistema.

Alm da localizao da implementao que descrevemos anteriormente sero mencionados

nos prximos tpicos, a importncia tambm dos mecanismos de gerenciamento de threads,
o uso de regies crticas e tambm o uso de variveis globais.

9
Sistemas Operacionais Distribudos UNESP/IBILCE

3. Ramificaes em Multiprocessadores

Se um programa corre em um multiprocessador, os processos leves executam em

simultneo, cada um no seu processador.

Vantagens

9 Mesmo em monoprocessadores o desempenho de uma aplicao pode ser melhorado

usando esta tcnica: se um dos processos se bloqueia numa chamada ao sistema, outro
processo leve pode ocupar o processador.

4. Modelo Cliente Servidor

O modelo cliente/servidor um paradigma de programao que representa as interaes

entre o processos e estruturas do sistema. Esse modelo usado para melhorar a estrutura
do sistema operacional, movendo-se a maior quantidade possvel de funes para nveis
mais altos do sistema, reduzindo o tamanho do ncleo.

O modelo cliente/servidor geralmente refere-se a um modelo onde dois ou mais

computadores interagem de modo que um oferece servios aos outros. Este modelo
permite ao usurios acessarem informaes e servios de qualquer lugar.

Cliente/Servidor uma arquitetura computacional que envolve requisies de servios de

clientes para servidores.

Portanto a definio para cliente/servidor seria a existncia de uma plataforma base para
que as aplicaes, onde um ou mais clientes e um ou mais servidores, juntamente com o
sistema operacional de rede, executem processamento distribudo.

O modelo poderia ser entendido como a interao entre software e hardware em diferentes
nveis, implicando na composio de diferentes computadores e aplicaes.

Para se entender o paradigma cliente/servidor necessrio observar que o conceito est na

ligao lgica e no na fsica.

Cliente e servidor pode ou no existir na mesma mquina, porm um ponto importante para
uma real abordagem cliente/servidor a necessidade de que a arquitetura definida
represente uma computao distribuda.

Caracterscas

Cliente

Tambm denomidado de front-end e workstation, um processo que interage com o

usurio atravs de uma interface grfica ou no, permitindo consultas ou comandos para a

10
Sistemas Operacionais Distribudos UNESP/IBILCE

recuperao de dados e anlise, e representando o meio pela qual os resultados so

apresentados.
Alm disso o processo cliente apresenta algumas caractersticas distintas:

9 um processo ativo na relao cliente/servidor

9 Inicia e termina as conversaes com os servidores, solicitando servios distribudos
9 No se comunica com outros clientes
9 Torna a rede transparente ao usurio

Servidor

Tambm denominado servidor ou back-end, fornece um determinado servio que fica

disponvel para todo cliente que o necessita. A natureza e o escopo dos servios so
definidos pelo objetivo da aplicao cliente/servidor.

Suas propriedades distintas so:

9 o processo reativo na aplicao cliente/servidor

9 Possui uma execuo contnua
9 Recebe e responde s solicitaes dos clientes
9 No se comunica com outros servidores enquanto estiver fazendo o papel de servidor
9 Presta servios distribudos
9 Atende a diversos clientes simultaneamente

Tipos de servidores

9 Servidores de arquivos
9 Servidores de impresso
9 Servidores de Banco de Dados
9 Servidor de Redes

Vantagens do modelo

Confiabilidade: Se uma mquina apresenta algum problema, ainda que seja um dos
servidores,parte do sitema continua ativo.

O sistema cresce facilmente: Torna-se fcil modernizar o sistema quando necessrio

Escalabilidade: Capacidade de responder ao aumento da procura de servios sem degradar

a performance.

O Cliente e o Servidor possuem ambientes operacionais individuais: Pode-se misturar

vrias paltaformas para melhor atender s necessidades individuais de diversos setores e
usurios.

11
Sistemas Operacionais Distribudos UNESP/IBILCE

Desvantagens do modelo

Manuteno: As diversas partes envolvidas nem sempre funcionam bem juntas. Quando
algum erro ocorre, existe uma extensa lista de itens a serem investigados.

Ferramentas: A escassez de ferramentas de suporte, no raras as vezes obriga o

desenvolvimento de ferramentas prprias. Em funo do grande poderio das novas
linguagens de programao, esta dificuldade est ser tornando cada vez menor.

Gerenciamento: O aumenta da complexidade do ambiente e a escassez de ferramentas de

auxlio tornam difcil o gerenciamento da rede.

O processo Cliente requisita servios ao Servidor:

Pedido

Resposta

um modelo baseado no estabelecimento de uma conexo, sendo possvel ser

implementado sobre um canal de comunicao por meio de troca de mensagens.
Primitivas de comunicao como send e receive so implementadas no ncleo, e no h
preocupao se o servio orientado a conexo ou no orientado a conexo. Outras
primitivas como connect e accept tambm so implementadas no ncleo do sistema.

Essas primitivas so classificadas de acordo com os critrios abaixo:

1. O estado em que ficam os processos durante a transmisso de uma mensagem

2. A forma como as mensagens so disponibilizadas
3. Confiabilidade do mecanismo de troca de mensagens

12
Sistemas Operacionais Distribudos UNESP/IBILCE

Segundo o primeiro critrio, as primitivas so classificadas como bloqueadoras e no

bloqueadoras. Bloqueadoras quando o processo fica paralisado durante a transmisso de
um mensagem. No bloqueadoras quando o processo fornece uma cpia da mensagem ao
sistema de comunicao, devido a solicitao de um sevio.

De acordo com o segundo critrio as primitivas podem ou n utilizarem de bbuffer para

comunicao.

O terceiro trata da confiabilidade das primitivas, que no confivel, pois utiliza-se a

resposta como confirmao do recebimento da solicitao.

5. Processos Concorrentes

So vrios processos executados em paralelo. Essa execuo paralela no significa

execuo simultnea. A execuo concorrente admite as seguintes possibilidades:

9 Pseudo-paralela: Execuo em um nico processador;

9 Paralela: Execuo em vrios processadores que compartilham uma memria;
9 Distribuda: Execuo em vrios processadores independentes, sem compartilhamento
de memria.

Os objetivos da programao concorrente so:

9 Reduzir o tempo total de processamento;

9 Aumentar confiabilidade e disponibilidade;
9 Obter especializao de servios;
9 Implementar aplicaes distribudas.

Fluxo nico de Execuo Vrios Fluxos de Execuo

PROC 1

PROC 2 PROC 1 PROC 2 PROC 3

PROC 3

13
Sistemas Operacionais Distribudos UNESP/IBILCE

6. Sincronizao e Comunicao de Processos

Uma forma de comunicao entre processos freqentemente usada em Sistemas

operacionais feita atravs de variveis compartilhadas onde os processos podem ler e
escrever dados. Nesta forma de comunicao existe a possibilidade de ocorrer situaes de
corrida, que so situaes onde dois ou mais processos atuam sobre dados compartilhados
e o resultado final do processamento depende de quem executa quando. A anlise de
programas em que ocorrem condies de corrida no uma tarefa fcil. Os resultados da
maioria dos testes so consistentes com a estrutura do programa, mas de vez em quando
ocorre algo imprevisto e inexplicvel, em funo do no-determinismo potencial, causado
pelas condies de corrida.

Para evitar estas situaes de corrida, implementamos mecanismos para assegurar que
quando um processo atua sobre uma varivel compartilhada os demais sero impedidos de
faze-lo (excluso mtua).

A parte do programa que pode levar a ocorrncia de condies de corrida, denominada

regio crtica.

6.1. Construtores Das Linguagens

As linguagens concorrentes so obtidas pelo acrscimo de certas construes prprias para

sincronizao e comunicao de processos concorrentes a linguagens seqenciais. Os
principais construtores das linguagens, usados na implementao dos mecanismos de
sincronizao e comunicao entre processos concorrentes, so:

9 Estrutura do programa: especifica a composio do programa (procedimentos,

comandos, variveis, etc.);
9 Estrutura de dados: representam objetos do programa;
9 Estrutura de controle: regulam o fluxo de execuo do programa (if-then-else, while-do,
etc.)
9 Chamadas a procedimentos e ao sistema: ativam rotinas especiais ou servios do
sistema.

6.2. Semforos

Dijkstra introduziu a noo de semforo para impor a excluso mtua entre processos.
uma construo tambm usada para sincronizar processos concorrentes. Um semforo S
uma varivel inteira positiva sobre a qual os processos podem fazer duas operaes
primitivas (indivisveis): P(S) e V(S). P e V tm sua origem das palavras parsen (passar) e
e vrygeren (liberar). As operaes P e V so assim definidas:

14
Sistemas Operacionais Distribudos UNESP/IBILCE

P(S) : se S > 0 ento S:=S-1

seno Bloqueie o processo na fila do semforo

V(S) : se algum processo est bloqueado no semforo S

ento desbloquear o processo

seno S:=S+1
Os semforos so classificados de acordo com o valor com que so inicializados como:

9 Semforos binrios: o valor inicial 1;

9 Semforos de contagem: o valor inicial normalmente maior do que 1.
Adicionar semforos s linguagens de programao existentes, uma tarefa relativamente
simples, basta programar duas rotinas em linguagem de montagem, adicionando-as
biblioteca de chamadas de sistema.

6.3. Monitores

Deve-se tomar muito cuidado ao trabalhar com semforos. Para facilitar a escrita de
programas paralelos, Hoare e Brinch Hansen propuseram uma primitiva de alto nvel para
sincronizao de processos, denominada monitor. Um monitor um conjunto de
procedimentos, variveis e estruturas de dados, todas agrupadas em um mdulo especial.
Os processos no podem acessar diretamente as estruturas de dados e variveis internas do
monitor a partir de procedimentos declarados fora do monitor. Os monitores tm uma
propriedade muito importante: somente um processo pode estar ativo dentro do monitor em
um dado instante. tarefa do compilador implementar a excluso mtua de execuo sobre
o monitor, sendo o caminho mais usual utilizar semforos binrios.

Os monitores oferecem uma forma simples de se obter a excluso mtua, mas ainda no o
suficiente, preciso que haja uma forma de bloqueio de processos quando no houver
condies lgicas para eles continuarem o processamento. Isto feito com as variveis de
condio e duas operaes sobre elas, WAIT e SIGNAL. Essas variveis de condio
permitem a sincronizao entre processos.

Ilustrao de um monitor escrita em uma linguagem imaginria, parecida com Pascal:

monitor exemplo
integer i;
condition c;

procedure produtor(x);
.
.
.
end;

15
Sistemas Operacionais Distribudos UNESP/IBILCE

procedure consumidor(x);
.
.
.
end;
end monitor;

Para usar monitores, necessrio uma linguagem especfica que suporte este conceito.
Hoje, existem poucas linguagens com esta caracterstica.

6.4. Regies Crticas Condicionais

Uma regio crtica condicional (RCC) uma verso estruturada da abordagem com
semforos. Cdigos da regio crtica so explicitamente nomeados e expressados por
region-begin-end. Uma vez na regio crtica uma condio pode ser testada pelo atributo
when. Se a condio no for satisfeita, o processo suspenso e outros processos podero
entrar em suas regies crticas.

Esta abordagem de estrutura de controle assume variveis compartilhadas e requer

compilao de regies crticas dentro de primitivas de sincronizao que so
disponibilizadas pelo sistema operacional. A necessidade de um endereo comum e a
impossibilidade de compilao separada no faz do RCC um bom candidato para adaptao
em sistemas distribudos.

processo leitor
region db begin rc:= rc + 1 end;
<l base de dados>
region db begin rc := rc 1 end;

processo escritor
region db when rc = 0
begin
<escreve na base de dados>
end;

6.5. Expresses de Caminho

uma especificao de linguagem de alto nvel que descreve como operaes definidas por
um objeto compartilhado podem ser invocadas de forma a satisfazer os requisitos de
sincronizao. Por esta razo, ns nos referimos a ela como uma estrutura de programa
desde que ela lembra a descrio formal de um programa.
Ex:

path 1:([read], write) end

16
Sistemas Operacionais Distribudos UNESP/IBILCE

A constante 1 restringe o nmero de atividades simultneas nos parnteses a apenas uma e

ento determina a excluso mtua entre processo leitor e escritor. Os colchetes indicam que
os leitores podem ser concorrentes.

6.6. Sincronizao por Passagem de Mensagem

Sem memria compartilhada, a passagem de mensagem a nica forma de comunicao

em sistemas distribudos. A passagem de mensagem tambm uma forma de sincronizao
implcita desde que as mensagens s podem ser recebidas depois delas terem sido enviadas.
Para a maioria das aplicaes, comum assumir que a primitiva receive bloqueia o
processo e a primitiva send pode ou no bloquear o processo. Diremos que a passagem de
mensagem assncrona quando a primitiva send no bloqueia o processo, e quando ela o
bloqueia, diremos que a passagem de mensagem sncrona.

6.6.1. Passagem de Mensagem Assncrona

Embora no haja variveis compartilhadas, o canal de comunicao compartilhado. O

bloqueio proveniente da primitiva receive equivalente operao P em um semforo e a
primitiva send quando no bloqueia o processo anloga operao V. A passagem de
mensagem assncrona uma extenso do conceito de semforo em sistemas distribudos.

6.6.2. Passagem de Mensagem Sncrona

Aqui, a primitiva send bloqueia o processo. Isto necessrio quando no h buffers no

canal de comunicao. Um send deve aguardar que o receive correspondente ocorra, e o
receive deve esperar pelo send correspondente. Este mecanismo permite que dois processos
com pares compatveis de send e receive se unam e troquem dados em um ponto de
sincronizao e continuem suas execues separados a partir da. Este tipo de
sincronizao chamado de um ponto de encontro (rendezvous) entre send e receive.

6.7. Chamada Remota a Procedimentos

Com o objetivo de facilitar a implementao de aplicaes cliente-servidor em uma rede de

computadores, ambientes de desenvolvimento passaram a suportar a Chamada a
Procedimentos Remotos (RPC - Remote Procedure Call). Os ambientes de
desenvolvimento que suportam o mecanismo de RPC escondem do programador boa parte
dos detalhes envolvidos no uso das facilidades de comunicao providas pela rede de
computadores. O mecanismo de RPC tem por objetivo possibilitar que procedimentos que
se encontram em outras mquinas possam ser chamados da mesma forma como
procedimentos que se encontram na mquina onde se encontra o cdigo cuja execuo
resultou na chamada ao procedimento. Quando procedimentos locais so chamados, o fluxo
de execuo do programa desviado para o procedimento, o procedimento executado e o
fluxo de execuo retorna para a instruo seguinte chamada do procedimento. Em uma
aplicao cliente-servidor desenvolvida com o mecanismo de RPC, o procedimento
chamado se encontra em uma mquina diferente daquela onde est sendo executado o

17
Sistemas Operacionais Distribudos UNESP/IBILCE

cdigo que resultou na chamada ao procedimento. O programa cliente chama

procedimentos que se fazem passar pelos procedimentos que sero executados no servidor.
O cdigo presente nos procedimentos esconde do restante do cliente os detalhes envolvidos
na comunicao com os procedimentos remotos. O servidor contm o cdigo que
implementa a lgica da aplicao e o cdigo inserido pelo ambiente de desenvolvimento. O
cdigo inserido recebe as solicitaes do cliente, chama o procedimento local adequado e
envia os resultados de volta para o cliente. Este cdigo esconde do servidor os detalhes do
processo de comunicao atravs da rede. Os ambientes de desenvolvimento que suportam
RPC contm um compilador que insere o cdigo necessrio tanto no cliente quanto no
servidor. Para que a comunicao entre cliente e servidor seja realizada com sucesso,
necessrio que o cliente chame os procedimentos remotos com a quantidade e tipos de
parmetros esperados pelo servidor. tambm necessrio que o cliente aguarde a mesma
quantidade e tipos de resultados que sero retornados pelo servidor. A compatibilidade
entre cliente e servidor garantida por informaes em um arquivo usado quando da
compilao tanto do cliente quanto do servidor. Em tal arquivo so encontradas as
definies dos procedimentos, as quais so compostas pelos nomes dos procedimentos,
quantidades e tipos dos argumentos, quantidades e tipos dos valores retornados. Os
arquivos de definio so escritos usando-se uma linguagem de definio prpria do
ambiente de desenvolvimento. Para que a compilao seja realizada com sucesso, o cdigo
no cliente e no servidor precisam aderir ao arquivo de definies. Aps a compilao do
cliente e do servidor, os programas sero instalados nas mquinas apropriadas e, quando da
execuo do cliente, ser necessria a identificao da mquina na qual se encontra o
servidor. A identificao pode ser feita atravs de informaes inseridas no cdigo do
cliente ou atravs de um servio de binding. Este servio provido pelo binder, responsvel
por armazenar informaes que possibilitam aos clientes identificar onde se encontram os
servidores. As informaes armazenadas no binder so providas pelos prprios servidores
quando iniciam a sua execuo. Em outras palavras, os servidores se registram com o
binder. Aps identificar em que mquina o servio provido, o cliente se comunica com
um processo que executa na mesma mquina onde se encontra o servidor. O processo
responsvel por informar ao cliente em que porta de comunicao o servidor pode ser
encontrado. Em uma rede de computadores, um servidor pode ser encontrado desde que se
saiba o endereo da mquina onde se encontra e o nmero da porta de comunicao
utilizada. Portanto a localizao do servidor pelo cliente ocorre em duas etapas. Na
primeira etapa identificada a mquina e, na segunda, a porta onde o servio prestado. A
porta usada pelo processo que informa as portas usadas pelos servidores conhecida pelos
clientes. Isto possibilita a localizao do processo pelos clientes.

6.8. Ada Rendevouz

A construo de monitores no moldam a sincronizao em sistemas distribudos, onde

seria necessrio a sincronizao de unidades, na qual cada processador teria sua prpria
memria, em vez de uma nica memria compartilhada.
Para impor a excluso mtua ou para sincronizar os processos independentes comum a
utilizao de monitores, mas quando estamos em sistemas onde no h memria comum
nem uma nico processador, a implementao dos monitores se torna invivel, porque que

18
Sistemas Operacionais Distribudos UNESP/IBILCE

no existe nenhum meio fsico central. A linguagem de programao Ada surge com a
tcnica de encontros (Rendez-Vous) para tratar estes casos.

Na linguagem ADA permitida a programao de atividades paralelas, que normalmente

necessitam de sincronizao. Referimo-nos a essa atividades como tarefas (tasks). Para a
programao dessas tarefas utilizamos a tcnica de encontros, que incorpora os mecanismos
de excluso mtua e de comunicao.

Existem dois tipos de processos aos quais nos referiremos durante a explicao do
funcionamento da tcnica de encontros na linguagem ADA:

9 Tarefa servidora: tarefa que contm operaes definidas em seu cdigo;

9 Tarefa atuante: : tarefa que invoca as operaes existentes na tarefa servidora.

denominada entrada cada conjunto de operaes associada aos meios de comunicao

existentes entre os processos. Uma entrada definida dentro de uma tarefa, para acess-la
necessrio conhecer o nome da tarefa em tempo de programao.

A estrutura do comando ACCEPT permite que a tarefa servidora implemente operaes

diferentes para chamadas a uma mesma entrada, usando comandos ACCEPT para
procedimentos distintos. O comando ACCEPT atende chamadas originadas de qualquer
outra tarefa, mas apenas uma tarefa pode conter comandos ACCEPT a uma mesma entrada.

O atendimento feito pr ordem de chegado. Quando a ordem de atendimento no for por

ordem de chegada, utiliza-se o comando SELECT e os seus blocos contm comandos
guardados que associados aos comandos ACCEPT, possibilitam encontros condicionais. O
comando SELECT possui tambm uma clusula ELSE, cujo cdigo executado quando
no houver comandos com guarda atendida.

O bloqueio de tarefas atuantes, pode ser evitado pr meio de chamadas condicionais, que
realiza o CALL somente se o encontro for possvel imediatamente. Em tarefas servidoras, o
bloqueio evitado verificando, antes do ACCEPT, se existem tarefas aguardando para
serem atendidas pr aquela entrada.

19
Sistemas Operacionais Distribudos UNESP/IBILCE

Bibliografia

TANENBAUM, A. S. Modern Operating Systems, 1992.

MARRANGHELLO N. Apostila de Sistemas Operacionais Distribudos, 2001

CHOW e JOHNSON, Distributed Operating Systems, 1997

Links

Cliente/Servidor: http://www.whatis.com/clientse.htm

RPC: http://www.whatis.com/rpc.htm

Thread: http://www.whatis.com/thread.htm

20