1. Sistemas Operacionais
Distribuídos
Alunos: Wanderlei Pereira Alves Junior
Júlio Cezar Estrella
Orientação: Prof. Dr. Norian Marranghello

2. Sistemas Operacionais Distribuídos UNESP/IBILCE
Sistemas Operacionais Distribuídos
Mecanismos de Linguagens e Threads
Tópicos Abordados
Introdução: Classificação dos Sistemas Operacionais
Surgimento dos Sistemas Operacionais Distribuídos
O que é um Sistema Operacional Distribuído?
Blocos de controle de ramificações (Threads)
Comparação entre ramificações e processos
Custo de criação e implementação de ramificações
Ramificações no servidor ou no núcleo de sistemas operacionais
Ramificações em multiprocessadores
O modelo cliente/servidor
Construções de linguagens
Mecanismos de sincronização
Especificação de atividades concorrentes
Sincronização e comunicação entre processos
Execução não deterministic de processos
Estrutura de programas
Estrutura de dados
Estruturas de controle
Sincronização de variáveis compartilhadas
Semáforos
Monitores
Regiões criticas condicionais
Path Expressions
Sincronização por passagem de mensagens
Chamada remota de procedimentos
Ada Rendevouz
Processos Concorrentes
2

3. Sistemas Operacionais Distribuídos UNESP/IBILCE
1. Classificação dos Sistemas Operacionais
Os sistema operacionais podem ser classificados de acordo com seu grau de acoplamento, a
saber:
Redes
Autômatos
Centralizados
Distribuídos
Para classificá-los deste modo, são levados em consideração os seguintes fatores:
Interoperabilidade
Transparência
Autonomia
Apenas citaremos as funcionalidades de alguns sistemas referenciados acima, uma vez que
a ênfase será dada aos Sistemas Distribuídos.
1.1. Sistemas Centralizados
Características:
São fortemente acoplados, são do tipo monolítico, ou seja não há o particionamento do
núcleo. Nos sistemas monolíticos os serviços do sistema e do núcleo fazem parte de um
mesmo programa.
1.2. Sistemas em Rede
Características:
É um multicomputador fracamente acoplado no qual não existe nenhum tipo de controle
direto de uma máquina sobre as outras e no qual a comunicação entre as outras máquinas é
bem mais lenta que dentro de uma dada máquina.
O compatilhamento de recursos é o objetivo principal dos sistemas em rede.
1.3. Sistemas Autômatos
Tais sistemas mantém as noções de transparência e interoperabilidade que existem nos
Sistemas Distribuídos, mas abolem a impressão de que existe somente um usuário no
sistema.
3

4. Sistemas Operacionais Distribuídos UNESP/IBILCE
1.4. Sistemas Distribuídos
São aqueles que gerenciam as atividades e os recursos distribuídos, possibilitando um
processamento descentralizado e melhorando o desempenho do sistema.
Outra definição: Um conjunto de processos que são executados de forma concorrente,
cada um dos quais acessando um subconjunto de receursos do sistema por meio de um
mecanismo de troca de mensagens através de uma rede de comunicação, que nem sempre é
confiável.
As vantagens de um Sistema Distribuído em relação aos outros é sua maior disponibilidade,
geralmente resultante da redundância de seus componentes
Sistema Distribuído Mais transparente que os Sistemas em Rede
Essa transparência pode ser notada em vários aspectos:
Transparência de acesso a arquivos
Transparência de desempenho
Transparência de localização
Transparência de concorrência
Aspectos importantes na construção de um sistema operacional:
Eficiência
Os parâmetros para medir o desempenho do sistema (eficiência) são diversos, tais como:
vazão, tempo de execução de uma determinada tarefa, taxa de uso do sistema e de seus
recursos.
Obs: A eficiência em sistemas distribuídos é mais complexa em relação aos Sistemas
Operacionais Convecionais, devido aos atrasos na comunicação.
Obs: O tempo gasto na propagação dos dados depende fortemente do protocolo de
comunicação utilizado, motivo pelo qual este deve ser bem projetado, como base em
primitivas de comunicação eficientes.
Fatores que afetam a eficiência:
Tempo gasto na propagação dos dados
Balanceamento de carga
Ganulosidade das tarefas
Tolerância a faltas
4

5. Sistemas Operacionais Distribuídos UNESP/IBILCE
Flexibilidade
Fatores associados:
Interoperabilidade
Modularidade
Portabilidade
Escalabilidade
Consistência
Um sistema é consistente se:
Permite um uso uniforme
E se possui um comportamento previsível
Fatores que afetam a consistência do sistema:
Ausência de um mecanismo global
Inexistência de informações a respeito do desempenho global
Robustez
Para ser robusto um Sistema Distribuído tem que estar disponível a maior parte do tempo,
apresentando dados confiáveis.
A confiabilidade deste sistema também está associado aos mecanismos de proteção
existentes.
Transparência
Capacidade que um Sistema apresenta, de esconder dos usuários, detalhes de
implementação, em particular àqueles mais complexos, e apresentar na medida do possível
um modelo lógico da máquina como os usuários gostariam de usar e não como o sistema é
realmente.
2. O que são Threads?
Definição básica: “ Fluxo de controle seqüencial isolado dentro de um programa.”
Outra denominação: LightWeight Processes (Processos Peso Pena)
Ou processos leves que compartilham o espaço de endereços lógicos.
Programas multithreaded: Múltiplos threads concorrentes de execução num único
programa, realizando várias tarefas “ao mesmo” tempo.
5

6. Sistemas Operacionais Distribuídos UNESP/IBILCE
Exemplo: programa do usuário + coleta de lixo
Diferentes threads podem executar em diferentes processadores, se disponíveis, ou
compartilhar um processador único
Diferentes threads no mesmo programa compartilham um ambiente global (memória,
processador, registradores, etc.)
2.1. Quais as funcionalidades dos threads?
Threads permitem que um programa simples possa executar várias tarefas diferentes ao
mesmo tempo, independentemente umas das outras.
Quando executado, um programa pode gerar ramificações no seu fluxo de controle. Tais
ramificações (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 são processos leves, associados aos processos que os gerou,
esses TCB possuem informações locais reduzidas (contador de programa, apontadores de
pilha e conjunto de registradores).
A mudança de contexto de um thread em relação a um processo é mais rápida pois os
threads além possuem informações locais, compartilham o restante das informações com os
processos que os gerou.
Os processos funcionam como máquinas virtuais, pois compartilham seu espaço de
endereçamento com os threads.
2.2. Onde são implementado os threads?
Depende!!!
Agilidade
Se o objetivo é agilidade, deve-se implementá-los no espaço do usuário.
Neste caso o controle de processos é feito diretamente pelo sistema operacional, mas os
threads são controlados por procedimentos em tempo de execução que serve como interface
entre a máquina virtual (processos) onde rodam os threads e o sistema operacional.
Obs: Neste caso, o sistema operacional não “enxerga” os threads, pois eles são
implementados no espaço do usuário, sendo submissos ao processo que os criou.
Os threads não podem usufruir do sistema de interrupções do sistema operacionais e
portanto são não-preemptíveis.
6

7. Sistemas Operacionais Distribuídos UNESP/IBILCE
Vantagens
agilidade
o gerenciamento é menos complicado
Desvantagens
não preempção
impedidos de utilizar interrupções do sistema operacional
Eficiência
Se o objetivo é eficiência, então os threads podem ser implementados no núcleo do sistema
operacional, podendo serem vistos pelo SO e usufruindo de seu sistema de interrupções.
Portanto passam a serem preemptíveis.
Nesse sentido os threads passam a ser tratados como processos, possibilitando o bloqueio
de outros threads e também eficiência no escalonamento.
O leitor deve notar que agora não 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 também outras ramificações em execução. O thread também irá competir igualmente
com os processos os ciclos do processador.
Vantagens de implementação no núcleo
Maior autonomia dos threads
Desvantagens
sistema perde em portabilidade, as mudanças de contexto dos threads tem agora a
mesma complexidade dos processos e a concorrência fica reduzida a dois níveis
(threads e processos).
2.3. Quando um thread deixa de existir?
Quando terminam sua execução
Quando o tempo alocado a seu processo pai foi esgotado
Ou se solicitou algum recurso do sistema
7

8. Sistemas Operacionais Distribuídos UNESP/IBILCE
2.4. Aplicações Multithread
Programas multithread são programas que contém várias 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 página enquanto
carrega uma imagem ou executa vários applets ao mesmo tempo.
Exemplos:
Programação Reativa : aplicação responde a eventos de entrada.
Exemplo: interfaces com o usuário, onde cada evento corresponde a uma ação
Programação Interativa: uma tarefa para fazer alguma interação com o usuário, outra para
exibir mensagens, outra para fazer animação, etc..
Paralelismo físico/ distribuição: para tirar vantagem de múltiplas CPUs centralizadas ou
distribuídas
2.5. Exemplo de aplicação utilizando ramificações
Implementação de processos servidores que prestam serviços a processos clientes.
O emprego de ramificações na estrutura de controle do servidor, permite o agrupamento
dos threads num mesmo espaço de endereçamento, admitindo acesso concorrente de vários
clientes a um único servidor.
Há dois tipos de ramificações:
Ramificações Estáticas:
Criadas em tempo de compilação
Exemplo: Servidores de terminais
Servidor cria ramificações
Essas ramificações são locais ao servidor
Ramificações atendem usuários enquanto estiverem conectados
8

9. Sistemas Operacionais Distribuídos UNESP/IBILCE
Essas ramificações compartilham o mesmo espaço de endereço (dos processos pais), então
quando precisam acessar algum recurso compartilhado, a exclusividade do acesso é feita
via mecanismos de sincronização como os monitores e semáforos.
Como a ramificação fica no sistema enquanto o usuário estiver conectado, ela ocupa o
espaço de memória mesmo que o cliente não requisite nenhuma operação do servidor.
Ramificações Dinâmicas:
Criadas e destruídas de acordo com as necessidades.
Exemplo: Servidores de arquivos
Nesses servidores há diversas operações de leitura/escrita. Nesse contexto existe um
processo que têm a função de coordenar essas atividades.
Cada vez que um cliente solicita uma operação, o servidor cria uma ramificação que ficará
responsável por determinada tarefa (leitura/escrita) e terminado sua execução o controle
volta novamente ao processo que a criou.
Por exemplo, se forem feitas várias operações de leitura, serão geradas várias ramificações
do processo responsável pela operação de leitura.
O mesmo acontece com a operação de escrita.
Obs: É importante ressaltar novamente que essas ramificações (threads) serão executadas
“independentes” uma das outras, e serão extintas assim que o serviço para qual foram
criadas, também termine.
Vantagens da implementação no servidor
Aumenta a flexibilidade
Agrupamento de threads no mesmo espaço de endereçamento
Desvantagens
Complica o gerenciamento das ramificações
2.6. Conclusão
A utilização do mecanismos de ramificações permite que a memória seja otimizada e
também reaproveitada assim que essas terminem sua execução, levando a uma redução
considerável no custo do sistema.
Além da localização da implementação que descrevemos anteriormente serão mencionados
nos próximos tópicos, a importância também dos mecanismos de gerenciamento de threads,
o uso de regiões críticas e também o uso de variáveis globais.
9

10. Sistemas Operacionais Distribuídos UNESP/IBILCE
3. Ramificações em Multiprocessadores
Se um programa corre em um multiprocessador, os processos leves executam em
simultâneo, cada um no seu processador.
Vantagens
Mesmo em monoprocessadores o desempenho de uma aplicação pode ser melhorado
usando esta técnica: 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 programação que representa as interações
entre o processos e estruturas do sistema. Esse modelo é usado para melhorar a estrutura
do sistema operacional, movendo-se a maior quantidade possível de funções para níveis
mais altos do sistema, reduzindo o tamanho do núcleo.
O modelo cliente/servidor geralmente refere-se a um modelo onde dois ou mais
computadores interagem de modo que um oferece serviços aos outros. Este modelo
permite ao usuários acessarem informações e serviços de qualquer lugar.
Cliente/Servidor é uma arquitetura computacional que envolve requisições de serviços de
clientes para servidores.
Portanto a definição para cliente/servidor seria a existência de uma plataforma base para
que as aplicações, onde um ou mais clientes e um ou mais servidores, juntamente com o
sistema operacional de rede, executem processamento distribuído.
O modelo poderia ser entendido como a interação entre software e hardware em diferentes
níveis, implicando na composição de diferentes computadores e aplicações.
Para se entender o paradigma cliente/servidor é necessário observar que o conceito está na
ligação lógica e não na física.
Cliente e servidor pode ou não existir na mesma máquina, porém um ponto importante para
uma real abordagem cliente/servidor é a necessidade de que a arquitetura definida
represente uma computação distribuída.
Caracteríscas
Cliente
Também denomidado de “front-end” e “workstation”, é um processo que interage com o
usuário através de uma interface gráfica ou não, permitindo consultas ou comandos para a
10

11. Sistemas Operacionais Distribuídos UNESP/IBILCE
recuperação de dados e análise, e representando o meio pela qual os resultados são
apresentados.
Além disso o processo cliente apresenta algumas características distintas:
É um processo ativo na relação cliente/servidor
Inicia e termina as conversações com os servidores, solicitando serviços distribuídos
Não se comunica com outros clientes
Torna a rede transparente ao usuário
Servidor
Também denominado servidor ou “back-end”, fornece um determinado serviço que fica
disponível para todo cliente que o necessita. A natureza e o escopo dos serviços são
definidos pelo objetivo da aplicação cliente/servidor.
Suas propriedades distintas são:
É o processo reativo na aplicação cliente/servidor
Possui uma execução contínua
Recebe e responde às solicitações dos clientes
Não se comunica com outros servidores enquanto estiver fazendo o papel de servidor
Presta serviços distribuídos
Atende a diversos clientes simultaneamente
Tipos de servidores
Servidores de arquivos
Servidores de impressão
Servidores de Banco de Dados
Servidor de Redes
Vantagens do modelo
Confiabilidade: Se uma máquina apresenta algum problema, ainda que seja um dos
servidores,parte do sitema continua ativo.
O sistema cresce facilmente: Torna-se fácil modernizar o sistema quando necessário
Escalabilidade: Capacidade de responder ao aumento da procura de serviços sem degradar
a performance.
O Cliente e o Servidor possuem ambientes operacionais individuais: Pode-se misturar
várias paltaformas para melhor atender às necessidades individuais de diversos setores e
usuários.
11

12. Sistemas Operacionais Distribuídos UNESP/IBILCE
Desvantagens do modelo
Manutenção: 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, não raras as vezes obriga o
desenvolvimento de ferramentas próprias. Em função do grande poderio das novas
linguagens de programação, esta dificuldade está ser tornando cada vez menor.
Gerenciamento: O aumenta da complexidade do ambiente e a escassez de ferramentas de
auxílio tornam difícil o gerenciamento da rede.
O processo Cliente requisita serviços ao Servidor:
Pedido
Resposta
É um modelo baseado no estabelecimento de uma conexão, sendo possível ser
implementado sobre um canal de comunicação por meio de troca de mensagens.
Primitivas de comunicação como send e receive são implementadas no núcleo, e não há
preocupação se o serviço é orientado a conexão ou não orientado a conexão. Outras
primitivas como connect e accept também são implementadas no núcleo do sistema.
Essas primitivas são classificadas de acordo com os critérios abaixo:
1. O estado em que ficam os processos durante a transmissão de uma mensagem
2. A forma como as mensagens são disponibilizadas
3. Confiabilidade do mecanismo de troca de mensagens
12

13. Sistemas Operacionais Distribuídos UNESP/IBILCE
Segundo o primeiro critério, as primitivas são classificadas como bloqueadoras e não
bloqueadoras. Bloqueadoras quando o processo fica paralisado durante a transmissão de
um mensagem. Não bloqueadoras quando o processo fornece uma cópia da mensagem ao
sistema de comunicação, devido a solicitação de um seviço.
De acordo com o segundo critério as primitivas podem ou nõ utilizarem de bbuffer para
comunicação.
O terceiro trata da confiabilidade das primitivas, que é não confiável, pois utiliza-se a
resposta como confirmação do recebimento da solicitação.
5. Processos Concorrentes
São vários processos executados em paralelo. Essa execução paralela não significa
execução simultânea. A execução concorrente admite as seguintes possibilidades:
Pseudo-paralela: Execução em um único processador;
Paralela: Execução em vários processadores que compartilham uma memória;
Distribuída: Execução em vários processadores independentes, sem compartilhamento
de memória.
Os objetivos da programação concorrente são:
Reduzir o tempo total de processamento;
Aumentar confiabilidade e disponibilidade;
Obter especialização de serviços;
Implementar aplicações distribuídas.
Fluxo Único de Execução Vários Fluxos de Execução
PROC 1
PROC 2 PROC 1 PROC 2 PROC 3
PROC 3
13

14. Sistemas Operacionais Distribuídos UNESP/IBILCE
6. Sincronização e Comunicação de Processos
Uma forma de comunicação entre processos freqüentemente usada em Sistemas
operacionais é feita através de variáveis compartilhadas onde os processos podem ler e
escrever dados. Nesta forma de comunicação existe a possibilidade de ocorrer situações de
corrida, que são situações onde dois ou mais processos atuam sobre dados compartilhados
e o resultado final do processamento depende de quem executa quando. A análise de
programas em que ocorrem condições de corrida não é uma tarefa fácil. Os resultados da
maioria dos testes são consistentes com a estrutura do programa, mas de vez em quando
ocorre algo imprevisto e inexplicável, em função do não-determinismo potencial, causado
pelas condições de corrida.
Para evitar estas situações de corrida, implementamos mecanismos para assegurar que
quando um processo atua sobre uma variável compartilhada os demais serão impedidos de
faze-lo (exclusão mútua).
A parte do programa que pode levar a ocorrência de condições de corrida, é denominada
região crítica.
6.1. Construtores Das Linguagens
As linguagens concorrentes são obtidas pelo acréscimo de certas construções próprias para
sincronização e comunicação de processos concorrentes a linguagens seqüenciais. Os
principais construtores das linguagens, usados na implementação dos mecanismos de
sincronização e comunicação entre processos concorrentes, são:
Estrutura do programa: especifica a composição do programa (procedimentos,
comandos, variáveis, etc.);
Estrutura de dados: representam objetos do programa;
Estrutura de controle: regulam o fluxo de execução do programa (if-then-else, while-do,
etc.)
Chamadas a procedimentos e ao sistema: ativam rotinas especiais ou serviços do
sistema.
6.2. Semáforos
Dijkstra introduziu a noção de semáforo para impor a exclusão mútua entre processos. É
uma construção também usada para sincronizar processos concorrentes. Um semáforo S é
uma variável inteira positiva sobre a qual os processos podem fazer duas operações
primitivas (indivisíveis): P(S) e V(S). P e V têm sua origem das palavras parsen (passar) e
e vrygeren (liberar). As operações P e V são assim definidas:
14

15. Sistemas Operacionais Distribuídos UNESP/IBILCE
P(S) : se S > 0 então S:=S-1
senão Bloqueie o processo na fila do semáforo
V(S) : se algum processo está bloqueado no semáforo S
então desbloquear o processo
senão S:=S+1
Os semáforos são classificados de acordo com o valor com que são inicializados como:
Semáforos binários: o valor inicial é 1;
Semáforos de contagem: o valor inicial é normalmente maior do que 1.
Adicionar semáforos às linguagens de programação 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 semáforos. Para facilitar a escrita de
programas paralelos, Hoare e Brinch Hansen propuseram uma primitiva de alto nível para
sincronização de processos, denominada monitor. Um monitor é um conjunto de
procedimentos, variáveis e estruturas de dados, todas agrupadas em um módulo especial.
Os processos não podem acessar diretamente as estruturas de dados e variáveis internas do
monitor a partir de procedimentos declarados fora do monitor. Os monitores têm uma
propriedade muito importante: somente um processo pode estar ativo dentro do monitor em
um dado instante. É tarefa do compilador implementar a exclusão mútua de execução sobre
o monitor, sendo o caminho mais usual utilizar semáforos binários.
Os monitores oferecem uma forma simples de se obter a exclusão mútua, mas ainda não é o
suficiente, é preciso que haja uma forma de bloqueio de processos quando não houver
condições lógicas para eles continuarem o processamento. Isto é feito com as variáveis de
condição e duas operações sobre elas, WAIT e SIGNAL. Essas variáveis de condição
permitem a sincronização entre processos.
Ilustração de um monitor escrita em uma linguagem imaginária, parecida com Pascal:
monitor exemplo
integer i;
condition c;
procedure produtor(x);
.
.
.
end;
15

16. Sistemas Operacionais Distribuídos UNESP/IBILCE
procedure consumidor(x);
.
.
.
end;
end monitor;
Para usar monitores, é necessário uma linguagem específica que suporte este conceito.
Hoje, existem poucas linguagens com esta característica.
6.4. Regiões Críticas Condicionais
Uma região crítica condicional (RCC) é uma versão estruturada da abordagem com
semáforos. Códigos da região crítica são explicitamente nomeados e expressados por
region-begin-end. Uma vez na região crítica uma condição pode ser testada pelo atributo
when. Se a condição não for satisfeita, o processo é suspenso e outros processos poderão
entrar em suas regiões críticas.
Esta abordagem de estrutura de controle assume variáveis compartilhadas e requer
compilação de regiões críticas dentro de primitivas de sincronização que são
disponibilizadas pelo sistema operacional. A necessidade de um endereço comum e a
impossibilidade de compilação separada não faz do RCC um bom candidato para adaptação
em sistemas distribuídos.
“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. Expressões de Caminho
É uma especificação de linguagem de alto nível que descreve como operações definidas por
um objeto compartilhado podem ser invocadas de forma a satisfazer os requisitos de
sincronização. Por esta razão, nós nos referimos a ela como uma estrutura de programa
desde que ela lembra a descrição formal de um programa.
Ex:
path 1:([read], write) end
16

17. Sistemas Operacionais Distribuídos UNESP/IBILCE
A constante 1 restringe o número de atividades simultâneas nos parênteses a apenas uma e
então determina a exclusão mútua entre processo leitor e escritor. Os colchetes indicam que
os leitores podem ser concorrentes.
6.6. Sincronização por Passagem de Mensagem
Sem memória compartilhada, a passagem de mensagem é a única forma de comunicação
em sistemas distribuídos. A passagem de mensagem é também uma forma de sincronização
implícita desde que as mensagens só podem ser recebidas depois delas terem sido enviadas.
Para a maioria das aplicações, é comum assumir que a primitiva receive bloqueia o
processo e a primitiva send pode ou não bloquear o processo. Diremos que a passagem de
mensagem é assíncrona quando a primitiva send não bloqueia o processo, e quando ela o
bloqueia, diremos que a passagem de mensagem é síncrona.
6.6.1. Passagem de Mensagem Assíncrona
Embora não haja variáveis compartilhadas, o canal de comunicação é compartilhado. O
bloqueio proveniente da primitiva receive é equivalente à operação P em um semáforo e a
primitiva send quando não bloqueia o processo é análoga à operação V. A passagem de
mensagem assíncrona é uma extensão do conceito de semáforo em sistemas distribuídos.
6.6.2. Passagem de Mensagem Síncrona
Aqui, a primitiva send bloqueia o processo. Isto é necessário quando não há buffers no
canal de comunicação. 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 compatíveis de send e receive se unam e troquem dados em um ponto de
sincronização e continuem suas execuções separados a partir daí. Este tipo de
sincronização é chamado de um ponto de encontro (rendezvous) entre send e receive.
6.7. Chamada Remota a Procedimentos
Com o objetivo de facilitar a implementação de aplicações 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 comunicação providas pela rede de
computadores. O mecanismo de RPC tem por objetivo possibilitar que procedimentos que
se encontram em outras máquinas possam ser chamados da mesma forma como
procedimentos que se encontram na máquina onde se encontra o código cuja execução
resultou na chamada ao procedimento. Quando procedimentos locais são chamados, o fluxo
de execução do programa é desviado para o procedimento, o procedimento é executado e o
fluxo de execução retorna para a instrução seguinte à chamada do procedimento. Em uma
aplicação cliente-servidor desenvolvida com o mecanismo de RPC, o procedimento
chamado se encontra em uma máquina diferente daquela onde está sendo executado o
17

18. Sistemas Operacionais Distribuídos UNESP/IBILCE
código que resultou na chamada ao procedimento. O programa cliente chama
procedimentos que se fazem passar pelos procedimentos que serão executados no servidor.
O código presente nos procedimentos esconde do restante do cliente os detalhes envolvidos
na comunicação com os procedimentos remotos. O servidor contém o código que
implementa a lógica da aplicação e o código inserido pelo ambiente de desenvolvimento. O
código inserido recebe as solicitações do cliente, chama o procedimento local adequado e
envia os resultados de volta para o cliente. Este código esconde do servidor os detalhes do
processo de comunicação através da rede. Os ambientes de desenvolvimento que suportam
RPC contêm um compilador que insere o código necessário tanto no cliente quanto no
servidor. Para que a comunicação entre cliente e servidor seja realizada com sucesso, é
necessário que o cliente chame os procedimentos remotos com a quantidade e tipos de
parâmetros esperados pelo servidor. É também necessário que o cliente aguarde a mesma
quantidade e tipos de resultados que serão retornados pelo servidor. A compatibilidade
entre cliente e servidor é garantida por informações em um arquivo usado quando da
compilação tanto do cliente quanto do servidor. Em tal arquivo são encontradas as
definições dos procedimentos, as quais são compostas pelos nomes dos procedimentos,
quantidades e tipos dos argumentos, quantidades e tipos dos valores retornados. Os
arquivos de definição são escritos usando-se uma linguagem de definição própria do
ambiente de desenvolvimento. Para que a compilação seja realizada com sucesso, o código
no cliente e no servidor precisam aderir ao arquivo de definições. Após a compilação do
cliente e do servidor, os programas serão instalados nas máquinas apropriadas e, quando da
execução do cliente, será necessária a identificação da máquina na qual se encontra o
servidor. A identificação pode ser feita através de informações inseridas no código do
cliente ou através de um serviço de binding. Este serviço é provido pelo binder, responsável
por armazenar informações que possibilitam aos clientes identificar onde se encontram os
servidores. As informações armazenadas no binder são providas pelos próprios servidores
quando iniciam a sua execução. Em outras palavras, os servidores se registram com o
binder. Após identificar em que máquina o serviço é provido, o cliente se comunica com
um processo que executa na mesma máquina onde se encontra o servidor. O processo é
responsável por informar ao cliente em que porta de comunicação o servidor pode ser
encontrado. Em uma rede de computadores, um servidor pode ser encontrado desde que se
saiba o endereço da máquina onde se encontra e o número da porta de comunicação
utilizada. Portanto a localização do servidor pelo cliente ocorre em duas etapas. Na
primeira etapa é identificada a máquina e, na segunda, a porta onde o serviço é prestado. A
porta usada pelo processo que informa as portas usadas pelos servidores é conhecida pelos
clientes. Isto possibilita a localização do processo pelos clientes.
6.8. Ada Rendevouz
A construção de monitores não moldam a sincronização em sistemas distribuídos, onde
seria necessário a sincronização de unidades, na qual cada processador teria sua própria
memória, em vez de uma única memória compartilhada.
Para impor a exclusão mútua ou para sincronizar os processos independentes é comum a
utilização de monitores, mas quando estamos em sistemas onde não há memória comum
nem uma único processador, a implementação dos monitores se torna inviável, porque que
18

19. Sistemas Operacionais Distribuídos UNESP/IBILCE
não existe nenhum meio físico central. A linguagem de programação Ada surge com a
técnica de encontros (Rendez-Vous) para tratar estes casos.
Na linguagem ADA é permitida a programação de atividades paralelas, que normalmente
necessitam de sincronização. Referimo-nos a essa atividades como tarefas (tasks). Para a
programação dessas tarefas utilizamos a técnica de encontros, que incorpora os mecanismos
de exclusão mútua e de comunicação.
Existem dois tipos de processos aos quais nos referiremos durante a explicação do
funcionamento da técnica de encontros na linguagem ADA:
Tarefa servidora: tarefa que contém operações definidas em seu código;
Tarefa atuante: : tarefa que invoca as operações existentes na tarefa servidora.
É denominada entrada cada conjunto de operações associada aos meios de comunicação
existentes entre os processos. Uma entrada é definida dentro de uma tarefa, para acessá-la é
necessário conhecer o nome da tarefa em tempo de programação.
A estrutura do comando ACCEPT permite que a tarefa servidora implemente operações
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 pôr ordem de chegado. Quando a ordem de atendimento não for por
ordem de chegada, utiliza-se o comando SELECT e os seus blocos contém comandos
guardados que associados aos comandos ACCEPT, possibilitam encontros condicionais. O
comando SELECT possui também uma cláusula ELSE, cujo código é executado quando
não houver comandos com guarda atendida.
O bloqueio de tarefas atuantes, pode ser evitado pôr meio de chamadas condicionais, que
realiza o CALL somente se o encontro for possível imediatamente. Em tarefas servidoras, o
bloqueio é evitado verificando, antes do ACCEPT, se existem tarefas aguardando para
serem atendidas pôr aquela entrada.
19

20. Sistemas Operacionais Distribuídos UNESP/IBILCE
Bibliografia
TANENBAUM, A. S. Modern Operating Systems, 1992.
MARRANGHELLO N. Apostila de Sistemas Operacionais Distribuídos, 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