1 SD Cap.

5-6

1 SD Cap. 5-6

Cap. 5 Objetos Distribudos e

Invocao Remota
Aplicao distribuda: conjunto de processos que cooperam entre si;
Precisam invocar operaes em processos remotos para realizar
servios.
Modelos de programao usados:
Chamada de procedimentos: extendida no RPC para permitir a
chamada de procedimentos remotos;
Invocao de mtodos: extendida no RMI para permitir a
invocao de mtodos em objetos remotos;
Programao orientada a eventos: permite a objetos receber
notificaes de eventos em objetos onde registraram interesse.
Extendida para permitir notificao sobre eventos distribudos.
Middleware
Aplicaes
RMI, RPC e eventos
Protocolo request reply
Representao externa de dados
Sistema operacional

Middleware

Aspectos importantes:
Transparncia de localizao: no RPC, quem chama uma
funo no sabe se ela local ou no, se roda no mesmo
processo ou num diferente. Se for remota, no se sabe onde est
o processo que vai ser executado. Recebendo um evento

distribudo, o processo no sabe onde est o processo que o

gerou.
Protocolos: so independentes do sistema de comunicao
bsico.
Diferenas de hardware: so encobertas por operaes de
marshalling com EDR.
Sistema operacional: a aplicao que usa o middleware no
depende do SO local.
Linguagens diferentes: alguns middlewares permitem
independncia de linguagem. Um objeto escrito numa linguagem
pode invocar mtodos em objetos escritos em outra.

5.1.1 Interfaces
Na programao por mdulos, o relacionamento entre mdulos
feito via uma interface. Nela, relaciona-se quais mtodos esto
disponveis para acessar determinado mdulo.
Enquanto a interface permanecer igual, o acesso ao mdulo no
alterado, mesmo que a implementao mude.
Interfaces em SDs
Num programa distribudo, um mdulo no pode acessar variveis
de outro.
A interface de um mdulo no pode especificar acesso a variveis.
O IDL do CORBA permite especificar atributos, mas o acesso no
direto. A plataforma insere funes de consulta e atualizao de
variveis automaticamente.

2 SD Cap. 5-6

Os mecanismos de passagem de parmetros das chamadas locais no

se aplicam em programas distribudos (passagem por valor ou por
referncia).
Na interface, a especificao de parmetros indica apenas input e/ou
output:
Input: parmetros passados para a funo invocada que
fornecem valores para o seu algoritmo;
Output: parmetros que recebem resultados da funo
invocada.
Ponteiros no podem ser usados em invocaes de funes.
Diferena entre RPC e RMI:
Interface de servio: conjunto de funes disponveis para
acessar os servios de um servidor no modelo cliente-servidor;
Interface remota: mtodos de um objeto disponveis para
invocao por outros objetos;
o Define parmetros e forma de acesso;
o Aceita passagem de objetos como argumentos;
o Permite passagem de referncias para objetos.

5.2 Comunicao entre objetos

distribudos

2 SD Cap. 5-6

Tipos de erros que um processo pode encontrar durante sua

execuo:
Erros controlveis: valores inconsistentes de argumentos, falha
em encontrar um dado num BD, etc.
Erros externos: falha em acessar arquivos ou sockets, etc.
Erros internos: diviso por zero, endereos de memria
invlidos, etc.
Erros de dependncia: ocorrem em processos hierarquicamente
superiores.
O modelo de objetos permite colocar tratamento de erros atravs de
comandos throw. Isso evita que o programador insira todos os testes
no meio do cdigo de um servio.
O tratamento colocado em blocos separados e a execuo desvia
para esses blocos quando um evento catched pelo programa.
Garbage collection
Objetos ocupam espao e devem ser liberados quando no so mais
necessrios.
Algumas linguagens (ex. Java) possuem mecanismos para liberar
objetos quando no so mais referenciados.
Outras no possuem e obrigam o programador a fazer esse controle
(ex. C++). Operao sujeita a erros.

5.2.1 Modelo de Objetos

5.2.2 Objetos distribudos
Excees
Objetos distribudos podem se organizar de vrias formas.
A invocao de seus mtodos segue modelos previamente estudados.

3 SD Cap. 5-6

Um dos pontos importantes verificar se um determinado objeto (ou

mtodo) pode ser invocado concorrentemente (+ de uma invocao
no mesmo intervalo uma invocao feita antes da anterior ser
executada).
O fato de que os dados de um objeto so acessados apenas pelos
seus mtodos permite aplicar tcnicas de controle:
Ex.: Java - mtodos sinchronized;
Objetos podem ser copiados para caches locais, sendo acessados
diretamente;
Invocao via RMI permite acesso ao mesmo objeto por
plataformas diferentes possveis converses so feitas por
EDR.

5.2.3 O modelo de objetos distribudos

Tipos de invocao:
Local: feitas dentro do mesmo processo;
Remota: feita entre processos diferentes podem residir ou no
em mquinas diferentes.
Para ser acessado remotamente, um objeto deve ter uma referncia
remota.
Cada objeto remoto deve ter uma interface remota, que especifica
quais dos seus mtodos podem ser acessados remotamente.
Referncia a objeto remoto
Identificador que permite acessar um objeto remotamente.

3 SD Cap. 5-6

nico no sistema inteiro e permite identificar um objeto

determinado, independente de sua localizao.
Seu formato diferente de uma referncia local.
Referncias remotas podem ser passadas como argumentos.
Interfaces remotas
A classe de um objeto remoto implementa os mtodos de sua
interface remota.
Outros objetos s podem invocar mtodos de um objeto que
pertencem a sua interface remota.

5.2.4 Quetes de projeto para RMI

Diferenas entre chamadas locais e remotas:
Chamadas locais so executadas exatamente 1 vez; sobre
chamadas remotas j no sempre assim;
O nvel de transparncia do RMI precisa ser definido.
Semnticas de invocao RMI
Escolhas sobre protocolos request-reply:
Mensagens retry: at quando retransmitir uma requisio, antes
de receber a resposta ou assumir que o servidor falhou;
Filtro de duplicados: com a possibilidade de retransmisses, se
o servidor deve usar um filtro;
Retransmisso de resultados: se um histrico deve ser mantido
em vez de re-executar sempre cada comando;

4 SD Cap. 5-6

Medidas de tolerncia a falhas

Retransmitir
Filtro de
Re-executar ou Semnticas de
invocao
requisies
duplicados
retransmitir
reply
No
No aplicvel
No aplicvel
Maybe
Sim
No
Re-executar
At-least-once
Sim
Sim
Retransmite
At-most-once
Obs.: para invocao de mtodos locais, a semntica exactly-once!
Transparncia
No RPC, certas atividades (marshalling, envio de mensagens,
retransmisso da requisio aps um timeout) so escondidas do
programador e realizadas de forma transparente.
Com objetos distribudos, isso extendido para localizar e contactar
objetos remotos.
Invocaes remotas so diferentes das locais porque envolvem
redes. Pode haver falhas de rede ou mquina sem que se possa
distinguir uma da outra.
A grande questo se a mquina destino recebeu a msg e se
conseguiu execut-la.
Isso obriga os objetos remotos a tratamentos para recuperao de
cada caso.
O atraso de uma invocao remota enorme comparado a uma
operao local. Ento, interessante minimisar esse custo.

4 SD Cap. 5-6

Apesar de se procurar por transparncia, interessante que a

diferena entre invocaes locais e remotas sejam explcitas, j que
as implicaes so grandes.
Ex.:
Corba repassa ao programa erros de comunicao como exceo;
A IDL tambm permite especificar o tipo de semntica que se
deseja isso informa o projetista sobre que tipo de operao o
objeto deve realizar;
Java RMI separa invocaes locais de remotas.

5.2.5 Implementao de RMI

Mdulo de comunicao

Executa o protocolo request-reply;

Especifica tipo de msg, requestId, referncia remota;
Determina a semntica;
No servidor, seleciona o dispatcher.

Mdulo de referncia remota

Traduo entre referncias remotas e locais;

Cria referncias remotas;
Mantm uma tabela de objetos remotos:
o Entradas para todos os objetos remotos relacionados ao
processo;
o Entradas para cada proxy local.

5 SD Cap. 5-6

5 SD Cap. 5-6

Software RMI

Camada entre objetos da aplicao e mdulos de comunicao e

referncia remota.
Funo de seus componentes:
Proxy:
o Torna transparente para o cliente as invocaes
(comporta-se como um objeto local, mas repassa as
invocaes para os objetos remotos);
o Esconde detalhes da referncia remota, marshalling,
unmarshalling, envio e recepo de msgs;
o Um proxy para cada objeto remoto que o processo usa.
Dispatcher:
o Servidores possuem um dispatcher e um skeleton para
cada classe de objetos remotos;
o Recebe requisies; methodId diz que mtodo deve ser
chamado; passa a requisio.
Skeleton:
o Implementa os mtodos de uma interface;
o Faz unmarshall da requisio e invoca o mtodo
correspondente do objeto remoto;
o Faz marshall do resultado (e excees);
o Passa a msg reply para o proxy para transmisso.

Mtodos fbricas

Interfaces no incluem construtores;

Assim, objetos remotos no podem ser criados por invocao
remota;

So criados na inicializao de processos ou em mtodos de

interfaces remotas;
Um mtodo fbrica aquele que cria objetos remotos;
Objeto fbrica aquele que possui mtodos fbricas.

Binder
Servio de um SD que mantm tabelas de mapeamento entre nomes
de servios e referncias remotas.
Permite aos servidores se registrarem e aos clientes procurar um
servio.
Corba: Corba Name Service;
Java: RMIregistry.
Ativao de objetos remotos
As aplicaes necessitam que as informaes sejam mantidas por
longos perodos. Isso no justifica manter objetos em processos se
eles no so necessrios todo o tempo.
Assim, os processos so disparados quando necessrio.
Um objeto remoto que pode ser invocado chamado de ativo.
Se ele no est ativo, mas pode ser ativado, chamado de passivo.
Um objeto passivo:
Implementao dos mtodos;
Seu estado na forma marshalled.
Processos que disparam servidores para manter objetos remotos so
chamados de ativadores.

6 SD Cap. 5-6

Armazns de objetos persistentes

Objeto persistente: pode manter seu estado e informaes entre
perodos de ativao.
Ex.:
Servio de objetos persistentes Corba;
Java Persistente.
O processo de ativao transparente.
O estado dos objetos salvo periodicamente em pontos ntegros para
fins de tolerncia a falhas.
Duas abordagens para decidir se um objeto persistente ou no:
Razes persistentes: objetos acessveis atravs de uma raiz
persistente um objeto persistente. Ex.: Java Persistente e
PerDis;
Classes persistentes: objetos persistentes so instncias dessas
classes ou derivados delas. Ex.: Arjuna.
Alguns armazns permitem a ativao de objetos em caches dos
clientes. Ex.: PerDis e Khazana. Isso exige um protocolo de
consistncia de caches.

5.3 Remote Procedure Calling - RPC

Programa distribudo:
Conjunto de componentes de software;
Executam sobre um nmero de computadores da rede.

6 SD Cap. 5-6

Modelo cliente-servidor:
Uma aplicao pode ser cliente de qualquer servio da rede;
Um servidor pode ser cliente de outros servios;
Cada servio possui um conjunto de operaes que podem ser
invocadas pelos clientes;
A comunicao entre clientes e servidores baseada no
protocolo requisio-resposta;
O cliente sempre espera pela resposta para continuar, mesmo que
no haja retorno de valor (pode haver erro!).
RPC:
Integrao entre clientes e servidores de forma conveniente;
Clientes se comunicam com servidores atravs da chamada de
procedimentos;
A chamada feita no programa local;
A execuo ocorre num programa remoto.
Servio ao nvel RPC:
Uma interface que exportada para os programas de um sistema;
Conjunto de funes que operam sobre certos dados ou recursos;
Aspectos semnticos de RPC:
Parmetros de entrada e sada:
Parmetros de entrada so passados para o servidor;
Valores enviados na requisio e copiados nas variveis do
servidor;
Parmetros de sada so enviados para o cliente na resposta;
Substituem as variveis da chamada;
Parmetros podem ser I/O.

7 SD Cap. 5-6

Parmetros de entrada ~ passagem por valor

Se passagem por referncia (ptr em C):
Indicar se I, O ou I/O;
Motivo para uma linguagem de definio de interface.
Procedimento remoto:
Executado em ambiente diferente de quem chama;
No pode acessar dados do cliente (ex.: globais);
Endereos de memria do cliente no tem significado para o
servidor;

Concluso: parmetros no podem incluir ponteiros!

Referncia opaca:
Referncia que o cliente passa para o servidor;
Endereo do servidor;
No tem significado para o cliente.
Estruturas complexas podem ser serializadas:
Ex.: uma rvore pode ser convertida em uma expresso.

Questes de projeto
Histrico:
1981 - Xerox Courier RPC: padro de desenvolvimento de
aplicaes remotas;
1984 - Birrel e Nelson:

7 SD Cap. 5-6

RPC para o ambiente de programao Cedar;

Datagramas sobre a Internet da Xerox;
Linguagem Mesa.

Classes de RPC:
1. o mecanismo RPC integrado com uma linguagem especfica;
inclui uma notao de definio de interface;
ex.: Cedar, Argus, Arjuna;
pode incluir construes especficas para RPC (ex.:
excees);
2. linguagem de definio de interfaces (pr-compilador ?!).
ex.: SUN RPC (base do NFS);
Matchmaker (Jones e Rashid, 1986): pode ser usado com C,
Pascal, LISP, MIG (Mach Interface Generator);
No ligado a um ambiente particular.
Linguagem de definio de interfaces:
Especifica as caractersticas do servidor que so visveis para o
cliente;
Nomes de procedimentos, tipos dos parmetros;
Tipo de acesso a um parmetro: I, O ou I/O;
O acesso indica se o valor precisa ser encapsulado na requisio
ou na resposta (marshaling);
Compiladores de interfaces podem gerar descries que podem ser
usadas em diferentes linguagens, permitindo a comunicao de
clientes e servidores de plataformas diferentes.

8 SD Cap. 5-6

8 SD Cap. 5-6

Tratamento de excees:
Qualquer RPC pode falhar:
Falha no servidor;
Sobrecarga do servidor (atraso na resposta).
RPC deve devolver erros:
Timeouts (inerente distribuio);
Erros de execuo (FD invlido, leitura aps EOF, diviso
por zero, etc.).
Erros detectados pelos procedimentos (cdigos invlidos,
datas erradas, etc.).

Tipos de semnticas RPC:

1. Maybe: sem tolerncia a falhas. No h garantias de que o
procedimento foi executado. No se pode saber se o servidor
executou a requisio ou se a resposta foi perdida.
2. At-least-once: o cliente informado de que um timeout ocorreu
e retransmite a requisio. Eventualmente o servidor receber
uma requisio duplicada. Se ele for projetado para executar
operaes idempotentes, no h problema.
3. At-most-once: o servidor filtra requisies duplicadas e
retransmite as respostas.

Obs.: na falta de um mecanismo de indicao de erros (como

excees em JAVA), o sistema pode usar um mtodo bem definido
de indicao de problemas (retorno de 0 ou 1 em UNIX).

Transparncia:
O modelo Birrel e Nelson garante que a chamada a
procedimentos remotos igual chamada dos locais;
RPC Cedar:
identifica os procedimentos remotos;
acrescenta o cdigo necessrio para o marshalling e
unmarshalling;
faz retransmisso da requisio aps um timeout;
a durao de uma chamada indefinida desde que o servidor
permanea ativo.

Garantia de entrega:
Implementaes possveis do DoOperation:
Repetio da requisio: at receber uma resposta ou assumir
que o servidor falhou;
Filtro de duplicados: usado com retransmisso, para evitar
duplicao no servidor;
Retransmisso da resposta: evita a reexecuo de uma
requisio.
Garantia de Entrega
Repete Req.
Filtra Duplic.
N
S
N
S
S

Semntica RPC
Reexec/Retrans
Maybe
Reexecuta
At-least-once
Retransmite
At-most-once

RPC mais vulnervel do que chamadas locais:

envolve redes, outros computadores e outro processos;
consome muito mais tempo do que chamadas locais;
deve tratar erros que no acontecem nas chamadas locais.

9 SD Cap. 5-6

9 SD Cap. 5-6

Implementao
O software de suporte ao RPC tem 3 funes:
Processamento da interface:
marshalling e unmarshalling;
despacho das requisies.
Tratamento da comunicao:
Transmitir requisies e receber as respostas;
Binding:
Localizao de um servidor para um servio qualquer.
Processamento da interface:

Retorno

Unmarsh

Receive

Compilador de interfaces:
processa as definies de uma IDL.
1. Gera os stubs do cliente;
2. Gera os stubs do servidor;
3. Gera as operaes de marshall e unmarshall;
4. Fornece os cabealhos das funes (o corpo o que a funo
faz deve ser fornecido pelo programador).

Binding

Requisio
Cliente
Chamada Marshall Send

Construindo o programa servidor:

entregador (despatcher);
conjunto de stubs servidores.

Servidor
Receive Unmarsh. Executa
Seleo!
Send
Marshall Retorno

Resposta
Cada procedimento de uma interface numerado com um nmero
nico (0, 1, 2, 3, ...).
Construindo um programa cliente:
Stub:
converte chamada local em remota;
faz o casamento dos parmentros.

Mapeamento de um nome para um objeto determinado (identificador

de comunicao).
Ex.: no Unix, um socket com nmero IP e Porta.
Ex.: Mach, Chorus e Amoeba, uma porta independente de
localizao.
Evita a recompilao dos clientes quando o servidor muda de porta.
Se o endereo inclui a identificao do host, o cliente precisa ser
recompilado toda vez que o servidor mudar de host.
Num sistema distribudo, o binding um servio separado que
mantm tabelas associando nomes de servios com portas de
servidores.
Ex.: o prprio Binding, DNS, etc.
Funes:
Register(servio: string, porta: port, verso: integer);
Withdraw(servio: string; pota: port; verso: integer);
LookUp(servio: string; verso: integer): port.

10 SD Cap. 5-6

Quando um servidor inicia seus servios, ele envia uma mensagem

para o Binding para se registrar.
Quando ele encerra suas atividades, ele pede para ser retirado das
tabelas do Binding.
Quando um cliente quer usar um servio, manda uma mensagem ao
Binding para descobrir o endereo do servidor.
Se o servidor falha, o cliente pode requisitar ao Binding a porta de
outro servidor do mesmo servio.
Se o sistema usa portas independentes de localizao, um servidor
pode se mover para outro host sem informar o Binding. Os clientes
no so afetados pela mudana.
Se o identificador de porta inclui o host, o Binding deve ser
informado toda vez que o servidor for movido. Os clientes vo ter
requisies ignoradas. Eles devem contatar o Binding para descobrir
o novo endereo do servio.
Servio nico: todos os outros dependem dele:
Tolerante a falhas (ex.: salvando as tabelas em arquivos toda vez
que elas so alteradas);
Um sistema distribudo dependente de um nico Binder no
escalvel:
As tabelas podem ser particionadas (maior desempenho);
Tambm podem ser replicadas em um grupo de Binders
(tolerncia a falhas).

10 SD Cap. 5-6

Alguns servios so representados por mltiplos servidores, cada um

rodando em um host diferente:
Cada um deles uma instncia de um servio;
Um Binder deve ser capaz de registrar as vrias instncias de um
servio;
Se o Binder no usa a instncia de um servio, o cliente deve
informar qual delas ele quer usar (nmero seqencial);
Numa falha, o cliente pega a prxima instncia.
Se o Binder usar a instncia, ele pode distribuir os clientes pelas
diversas instncias de um servio (balanceamento de carga)
Exportao: registro de um nome de interface associado com a
porta de um servidor.
Importao: pergunta ao Binder pelo nome de um servio
retornando um nmero de porta.
Localizao do Binder:
Endereo bem definido, compilado em todos os clientes;
Clientes e servidores precisam ser recompilados se o Binder
for mudado;
O Kernel informa o endereo do Binder (ex.: varivel de
ambiente). Permite a relocao ocasional do Binder;
Quando clientes ou servidores iniciam, mandam mensagens de
broadcast para localizar o Binder (ex.: no Unix, o Binder fica
numa porta bem conhecida. Num broadcast, o Binder que
receber informa qual o seu host).

11 SD Cap. 5-6

RPC Assncrono
Ex.: sistema de janelas X-11
Utiliza uma forma assncrona de RPC:
X-11 um servidor de janelas;
As aplicaes que querem mostrar alguma coisa na tela (texto,
grficos, etc.) so os clientes.
Caractersticas:
Para gerar ou atualizar a informao de uma janela, o cliente
envia vrias requisies ao servidor, cada uma delas com uma
pequena quantidade de informaes:
Strings, troca de fonte, um caracter.
O cliente no recebe respostas para suas requisies;
Cliente e servidor trabalham em paralelo;
Algumas requisies podem exigir intensa computao - h
ganhos em realiz-las enquanto o servidor atende requisies
anteriores;
O servidor pode manipular requisies de vrios clientes;
Ou mesmo de dispositivos;
O servidor tem uma performance melhor se ele no precisa
enviar respostas para as requisies.
RPC sem respostas e sem bloqueio chamado de assncrono.
Comparao:
No RPC sncrono, no existe paralelismo;
No RPC assncrono, o cliente faz todas as requisies de que
necessita; s ento espera pelos resultados;

11 SD Cap. 5-6

A espera no lado do cliente se resume ao intervalo entre a ltima

requisio e a recepo da primeira resposta;
Se no houver necessidade de resposta s requisies, o tempo
de espera no existe.

Otimizao possvel:
Armazenar as requisies no lado do servidor at que ocorra um
timeout ou que o cliente pea uma resposta;
S ento as requisies so enviadas como uma comunicao s;
Isto reduz a latncia de rede.

Requisies paralelas para vrios servidores

Ex.: considere um banco com vrios servidores, cada um
responsvel por registrar os lanamentos feitos em uma agncia.
Para saber o saldo de uma conta, preciso consultar os
lanamentos de todas as agncias;
RPC sncrono:
O cliente faz requisies para um servidor de cada vez,
esperando a resposta;
S aps chegar uma resposta, ele manda a requisio para o
prximo.
RPC assncrono:
O cliente envia as requisies para todos os servidores em
seqncia e depois espera por todas as respostas;
Os servidores trabalham em paralelo.
Comparao entre RPC sncrono e assncrono:

12 SD Cap. 5-6

12 SD Cap. 5-6

RPC assncrono

RPC sncrono
argumentos
marshall
send

transmisso

receive
unmarshall
executa
marshall
send

receive
unmarshall
processa
argumentos
marshall
send

receive
unmarshall
processa
receive
unmarshall
executa
marshall
send

Servidor

receive
unmarshall
executa
marshall
send
receive
unmarshall
executa
marshall
send

receive
unmarshall
processa
Cliente

receive
unmarshall
processa
Cliente

argumentos
marshall
send
argumentos
marshall
send

Servidor

13 SD Cap. 5-6

RPC assncrono no sistema Mercury

Otimizaes necessrias no paradigma RPC:
Se no h necessidade de resposta, o cliente pode fazer um
RPC e continuar sua execuo;
Se no h necessidade de resposta, vrias requisies podem
ser armazenadas e enviadas no mesmo send;
Se h necessidade de resposta, o cliente pode processar at
que ela seja necessria para s ento requisit-la.
Sistema Mercury MIT, 1988:
Call-stream: combina RPC sncronos e assncronos;
As diferenas nos mtodos de comunicao no so visveis para
os servidores:
Eles s recebem requisies e devolvem respostas.
Simplifica o projeto dos servidores;
O cliente determina o mtodo que vai utilizar;
Diferente de outros sistemas onde a interface define o mtodo e
o servidor precisa ser projetado de acordo;
Se o cliente no precisa da resposta a uma requisio, o callstream no a devolve para o cliente.

Promessas

Liskov e Shrira, 1988;

Uma promessa criada no momento de uma chamada a um
servidor;
Pode assumir dois estados possveis:
Bloqueado;
Pronto.

13 SD Cap. 5-6

Quando criada, a promessa fica no estado bloqueado;

Uma promessa associada com uma requisio especfica;
Quando chega a resposta a essa requisio, ela armazenada na
promessa correspondente;
Neste caso, o estado da promessa passa para pronto;

Funes:
claim(): extrai a resposta de uma promessa;
se ela estiver no estado bloqueado, o cliente bloqueia at que
a promessa passe para o estado de pronto ou que ocorra uma
exceo.
ready(): testa o estado de uma promessa.

5.4 Eventos e notificaes

Objetos que geram eventos numa plataforma distribuda

publicam os eventos disponveis para observao por outros
objetos;
Objetos que querem receber notificaes de eventos publicados
assinam tipos de eventos em que tm interesse;
Objetos que representam eventos so chamados de notificaes.

Sistemas baseados em eventos tm 2 caractersticas principais:

Heterogneos: permite que objetos no projetados para
interoperao trabalhem em conjunto. Um sistema de eventos
que permite publicao e assinatura pode permitir trabalho
conjunto para objetos que no foram projetados com esse fim;

14 SD Cap. 5-6

Assncronos: permite notificao de eventos aos assinantes sem

necessidade de sincronismo, o que significa bloqueio dos
envolvidos.

5.4.1 Participantes em notificaes de eventos

distribudos
Arquitetura que permite independncia entre autores e assinantes:
Banco de dados com eventos publicados e interesse dos
assinantes;
Quando ocorre um evento que possui interessados, uma
notificao enviada.
Participantes:
Objetos de interesse: aqueles que possuem mtodos que podem
alterar estados isso gera eventos que podem ter interessados;
Evento: ocorre como resultado da execuo de um mtodo;
Notificao: objeto que contm informaes sobre um evento:
Assinante: assina algum tipo de evento em outro objeto recebe
notificaes dele;
Observadores: objetos que isolam autores de assinantes. Eles
monitoram os eventos e notificam aqueles assinados;
Autor: objeto que declara que vai gerar notificaes de certos
tipos de eventos. Pode ser um objeto de interesse ou um
observador.
Possveis casos de comportamento em um servio de eventos:

14 SD Cap. 5-6

Objetos de Interesse enviam notificaes diretamente aos

assinantes;
OdI enviam notificaes via observadores aos assinantes;
OdI fora do servio de eventos. Observadores fazem consultas ao
OdI para descobrir quando ocorre um evento. Ele notificado
aos assinantes.

Papis dos observadores

Encaminhar notificaes para os assinantes de um ou + objetos

de interesse. So os objetos de interesse que informam os
observadores sobre seus assinantes;
Filtros de notificaes: aplicados pelos observadores para
reduzir a quantidade de notificaes. So baseados em regras
informadas pelos assinantes. Ex.: num banco, retiradas, mas
apenas as maiores que 10000,00;
Padres de eventos: relao de eventos entre si. Ex.: num
banco, quero ser informado sempre que houver 3 retiradas sem
um depsito;
Caixas de correio para notificaes: usadas para encaminhar
notificaes sem que o assinante receba na hora. Ex.: ele no
possui uma conexo permanente, ou tornou-se passivo. As
notificaes so recuperadas mais tarde.

15 SD Cap. 5-6

Cap. 6 Suporte dos Sistemas

Operacionais
6.1 Introduo
Funo importantes de um SD: compartilhamento de recursos.
Clientes invocam operaes sobre recursos em outros ns ou
outros processos.
Middleware: permite a interao entre aplicaes clientes e recursos
(gerentes).
O SO fica abaixo do middleware;
O que importa aqui o relacionamento entre os dois;
Como o SO permite ao middleware o acesso aos recursos fsicos,
como ele implementa polticas de acesso, etc.
Abstraes:
SO fornece modelos para manipular certos recursos;
Ex.: arquivos x blocos de disco;
Ex.: sockets x fluxo de redes.
Num SO de rede (Unix, NT, etc.), o usurio que precisa executar um
programa numa mquina diferente precisa se envolver:
Telnet, fornece senha, executa o programa.
SO Distribudo:

15 SD Cap. 5-6

O usurio no se preocupa com o n em que seu programa

executa;
No importa onde esto os recursos;
O usurio v uma nica imagem do sistema;
A esolha de um n para executar um programa depende da
poltica de escalonamento.

Caracterizao de um SOD:
Permite a programao de um SD, permitindo a implementao
de uma grande gama de aplicaes;
Apresenta para as aplicaes abstraes genricas e orientadas
aos problemas dos recursos do sistema;
Num SD aberto, o SOD implementado como um conjunto de
kernels e servidores.
No h uma distino clara entre os servios do sistema e as
aplicaes que rodam no topo do SOD.
Exemplos: Mach e Chorus.
Resultados de grandes perodos de pesquisa nos anos 80 e 90;
Alto nvel de interesse tcnico e comercial;
Outros exemplos tcnicos:
Amoeba, Clouds, V System;
No aceitos para uso geral;
Todos esses projetos empregam microkernel.
SOD:
Infraestrutura de gerenciamento genrico de recursos e
transparente em rede;

16 SD Cap. 5-6

Recursos de baixo nvel: processadores, memria, placas de

rede, perifricos em geral;
Plataforma para recursos de alto nvel: planilhas, troca de
mensagens eletrnicas, janelas;
Oferecidos aos clientes pelos servios do sistema;

Acesso aos recursos pelo sistema:

Feito de forma transparente;
Identificadores independentes de localizao;
Uso das mesmas propriedades;
Transparncia fornecida no nvel mais baixo, para que no
precise ser feita em cada servio;
Um SOD deve fornecer ferramentas para encapsular recursos:
De forma modular;
Modo protegido;
Amplo acesso via rede.
Encapsulamento de recursos:
Interface padronizada implementao escondida do usurio;
Concorrncia recursos compartilhados por vrios usurios;
Proteo segurana contra acesso ilegtimo.
Os clientes acessam os recursos atravs da passagem de
identificadores como argumentos:
Em system calls para o kernel;
RPC para um servidor.
Invocao: acesso a um recurso encapsulado.

16 SD Cap. 5-6

Tarefas relacionadas com a invocao de recursos:

Resoluo de nomes localizao;
Comunicao para acesso aos recursos;
Escalonamento: processamento das invocaes no kernel.
Middleware x SOs de rede

No h SOs distribudos em uso corrente hoje;

Apenas SOs de rede (Unix, NT, MacOS, etc.);
Motivos:
o Usurios se preocupam com suas aplicaes de uso
comum;
o No trocam seus SOs por melhor que seja um outro
produto se no puderem executar suas aplicaes;
o Usurios preferem ter um certo controle sobre suas
mquinas;
o A idia de entregar os recursos a outros usurios sem
controle estranha.

Por outro lado, o uso de um middleware com um SO de rede +

verstil e aceitvel:
O usurio consegue rodar seus programas favoritos;
Ele tem controle sobre os recursos de sua mquina;
Os usurios remotos tm um certo grau de transparncia no
acesso aos recursos da rede;
possvel acessar recursos compartilhados com um certo grau
de concorrncia.

17 SD Cap. 5-6

17 SD Cap. 5-6

6.2 Camada de sistema operacional

Aplicaes, servios
Middleware
OS1
Processos, threads,
comunicao, etc.

OS2
Processos, threads,
comunicao, etc.

Hardware do
computador e rede

Hardware do
computador e rede

N 1

N 2

As interfaces apresentadas por kernels e servidores devem apresentar

pelo menos o seguinte:
Encapsulamento: conjunto mnimo de operaes fornecidas aos
clientes. Detalhes de implementao escondidos;
Proteo: evita acessos indevidos;
Concorrncia: clientes devem acessar os recursos de forma
concorrente. Isso deve ser transparente para eles.

Kernel
Kernels e proteo:
O Kernel executa com privilgio de acesso total;

Ex.: pode controlar a unidade de MM;

Pode conceder privilgio de acesso a recursos fsicos;
Determina o espao de endereamento:
Permite que os processos se protejam uns dos outros;
Evita que um processo invada reas indevidas.
Modo supervisor e usurio:
Processos usurios podem rodar em modo supervisor quando
tem acesso direto a um dispositivo;
System call trap: mecanismo de invocao de recursos
gerenciados pelo kernel;
Kernel monoltico e microkernel um SOD aberto deve permitir:
Executar apenas o suficiente para tornar o ambiente operacional
(mdulos suprfluos gastam recursos);
Alteraes no software ou sistema que implementa um servio,
independentemente de outros elementos;
Alternativas do mesmo servio para atender usurios ou
aplicaes diferentes;
Introduo de novos servios sem prejudicar os existentes.
Um certo grau de abertura obtido com a utilizao de kernels
tradicionais como base.
Ex.: o DCE da OSF usa Unix, VMS, OS/2, etc.
Permitem a execuo de processos servidores;
Suportam protocolos (ex.: RPC);
Possuem binding e servios de nomes;
Servios de tempo (sincronizao);
Segurana;
Threads.

18 SD Cap. 5-6

18 SD Cap. 5-6

Unix:
Monoltico;
Sugere um sistema massivo;
Executa todas as operaes bsicas do sistema;
1 MB de cdigo e dados;
No diferencivel: codificado de forma no modular;
Intratvel: a alterao de um mdulo para adequao a novos
requisitos muito difcil.
Sn

S1

Carregado dinamicamente

S2

S3

S1

Kernel monoltico

S2

S3

MicroKernel

Principais funes de um microkernel:

Processos;
Memria;
IPC;
Todos os outros servios carregados dinamicamente em
servidores especficos;
Um servio extra s carregado na mquina que precisa dele;
Acesso via invocao (RPC).
O microkernel na hierarquia de um sistema:

Servios abertos processos/objetos das aplicaes

Suporte de
linguagem

Suporte de
linguagem

Emulao
de OS

Microkernel
Hardware
Comparao:
Abertura;
Modularidade;
Um kernel pequeno tem mais chances de ter menos bugs;
Mais fcil de manter;

Kernel monoltico mais difcil de ser modular;

Impossvel extrair um mdulo para execuo remota;
Um bug num mdulo pode se espalhar para os demais;
Alterar um mdulo implica em recompilar o kernel e reinici-lo;
Vantagem: eficincia para realizar as tarefas.

Arquitetura de um microkernel
Em princpio, no h uma definio clara de quais mdulos um
microkernel deve ter.
Todos os produtos dessa categoria incluem:
Gerncia de processos;
Gerncia de memria;

19 SD Cap. 5-6

19 SD Cap. 5-6

Passagem de mensagens local.

Tamanho: 10 KB at vrias centenas de KB de cdigo e dados
estticos.

Microkernels so projetados para serem portveis:

A maior parte de seu cdigo escrito em linguagem de alto nvel
(C, C++, etc.);
Recursos fsicos so agrupados em camadas;
Componentes dependentes de mquina so reduzidos:
Manipulao do processador, unidade de gerncia de
memria, registradores da unidade de ponto flutuante;
Tratamento de interrupes;
Traps;
Excees.

A arquitetura de um microkernel geral pode ser visto na figura:

Aplicaes
Gerente de Processos
Gerente
de
Comunicaes
Gerente de
Threads
Supervisor
Hardware

6.4 Processos e threads

Unix: 1 processo, 1 atividade de processamento (1980).
Processo: recurso caro para criar e manter.
O compartilhamento entre atividades relacionadas caro e
complexo.
Soluo: generalizao do conceito de processo.
Associar mais de uma atividade ao mesmo processo.
Processo: ambiente de execuo + 1 ou mais threads.
Thread: abstrao de atividade do sistema operacional.
"Thread of execution".

Gerente de
Memria

Gerente de processos: criao, interface, etc.

Gerente de Threads: criao, sincronizao, escalonamento.
Processadores disponveis. Poltica de escalonamento a critrio
do usurio.
Gerente de comunicao: IPC.
Gerente de memria: memria fsica, MMU, caches.
Supervisor: tratamento de interrupes, system calls, excees.

Ambiente de execuo: unidade de gerenciamento de recursos.

Coleo de recursos gerenciados pelo kernel local, aos quais suas
threads tm acesso;

Ambiente de execuo:
Espao de endereamento;
Sincronizao de threads e IPC, como semforos; interfaces de
comunicao (portas);
Recursos de alto nvel (arquivos, janelas, etc.).

20 SD Cap. 5-6

Obs.: num microkernel, recursos de alto nvel como arquivos e

janelas no fazem parte dos recursos de um ambiente de execuo.
So acessados via servidores.

Ambientes de execuo so caros e difceis de criar;

Vrias threads podem compartilhar o mesmo ambiente;
Threads podem ser criadas e destrudas dinamicamente;
Objetivo: maximizar o grau de concorrncia entre operaes
relacionadas.
Threads: lightweight process.

20 SD Cap. 5-6

Um ambiente de execuo consiste de um jarro com gua e

comida;
A 1 thread desse processo uma mosca dentro do jarro;
A mosca pode gerar filhos (outras threads) ou mat-los;
As moscas podem consumir a gua e/ou a comida;
2N

Regies
Auxiliares

6.4.1 Espaos de endereamento

Os espaos no so contguos.
Gaps permitem o crescimento das regies.
Componente mais caro de um ambiente de execuo;
Grande (232 um valor tpico);
Consiste de uma ou mais regies;
Regio: rea contgua de memria virtual acessvel pelas threads
do processo; Regies no se sobrepem;

Stack

Memria
Virtual
(ex.: 232)

Heap

Propriedades das regies:

Extenso: endereo mais baixo e tamanho;
Permisses para as threads: read/write/execute;
Direo de crescimento: para cima ou para baixo;
Analogia para processos e threads:

Text
0

Gaps

21 SD Cap. 5-6

Uma mosca no pode sair de seu jarro para entrar em outros

jarros;
As moscas podem colidir, quando resultados imprevisveis
podero ocorrer;
As moscas podem consumir toda a gua e comida o ambiente
passa a ser invivel.

O sistema com um nmero indefinido de regies permite o

mapeamento de arquivos no espao de endereamento:
Um arquivo mapeado acessado como um array de bytes;
O sistema VM garante que as atualizaes se reflitam no sistema
de arquivos.

6.4.2 Criao de um novo processo

Unix:
Um processo que chama o comando fork() cria um novo
processo copiando o seu espao de endereamento;
A diferena o valor retornado pelo fork();
O comando exec() transforma o programa que chama num
processo do arquivo em disco passado como parmetro.
Num SD, h duas novas consideraes:
Mltiplos computadores;
A infraestrutura de suporte reside em servios separados.
Aspectos de criao de processos em um SD:
Escolha do host alvo (onde o novo processo vai residir);
Criao de um ambiente de execuo;

21 SD Cap. 5-6

Criao de uma thread, com um ponteiro de pilha default e um

contador de instrues.

Escolha de um host alvo

Depende do sistema:
V System: executa um processo num host determinado ou no
mais ocioso;
Amoeba: escolhe um dos processadores do pool onde o processo
vai residir. transparente.
Depende da necessidade. Se necessrio trabalhar com paralelismo
explcito, pode ser necessrio indicar hosts especficos.
Tipos de polticas:
Poltica de transferncia: diz se um novo processo local ou
executado num host remoto. Depende da carga;
Poltica de localizao: determina o host remoto que recebe um
novo processo;
o Depende da carga, da arquitetura e de possveis recursos
especializados que o host tem.
As polticas podem ser estticas ou adaptativas:
Estticas no consideram o estado atual do sistema;
o Podem ser deterministas (a transferncia sempre ocorre
de A para B);
o Ou probabilsticas (a transferncia ocorre de A para um
entre B-E escolha aleatria).
Adaptativas: usam heursticas sobre fatores momentneos.

22 SD Cap. 5-6

Sistemas de carga compartilhada:

Centralizados: um gerente de carga para o sistema;
Hierrquicos: vrios gerentes, organizados em rvore;
Decentralizados: todos so gerentes.
Tipos de algoritmos de carga compartilhada:
Iniciados pelo transmissor: disparado quando a carga local
atinge um limite mximo;
Iniciados pelo receptor: quando a carga local cai abaixo de um
certo valor, o n avisa os demais que passou a ser um receptor de
carga.
Sistemas migratrios: a carga pode ser distribuda a qualquer
momento:
Recurso pouco usado;
O custo para transferir um processo muito alto;
Extrair o estado de um processo do kernel muito difcil.
Criao de um novo ambiente de execuo
Opes:
O sistema inicia um espao de endereamento genrico, baseado
em certos parmetros que ele possui: tamanho da rea de cdigo,
stack, etc.
Gerao a partir de um j existente: fork()
Pai e filho compartilham a rea de cdigo!
Isto feito pelo mapeamento da regio de texto do pai dentro
do espao de endereamento do filho.
Stack e heap so copiados do pai para o filho.

22 SD Cap. 5-6

Mach e Chorus: usam copy-on-write:

Regies herdadas do pai so copiadas apenas logicamente;
A cpia fsica s ocorre quando um dos processos tenta
escrever sobre a regio:
O compartilhamento desfeito;
Ocorre a cpia fsica;
Esta cpia pode acontecer em disco, caso ocorra um page
fault.

Obs.: herana um problema caso haja uma ou mais portas em uso

pelo processo pai. Dois processos no podem compartilhar fluxos de
mensagens.

6.4.3 Threads
Considere um servidor com uma ou mais threads.
Assumimos que uma requisio qualquer utiliza 2 msegs de
tratamento e 8 msegs de I/O (sem o uso de cache). O computador
possui apenas um processador.
Mximo throughput dependendo do nmero de threads:
1: 2 + 8 = 10 msegs. 100 requisies por segundo.
2: uma thread pode processar enquanto a outra est esperando.
As threads de um processo no podem fazer I/O em paralelo. Assim,
todos os I/Os devem ser feitos seqencialmente.
Se todas as requisies de I/O forem serializadas, temos
1000/8 = 125 requisies por segundo.

23 SD Cap. 5-6

Considere agora um cache de blocos de disco. O servidor mantm

blocos em buffers em seu espao de endereamento. Se h uma
requisio, ele 1 verifica se o bloco est no cache. Se estiver, a
requisio atendida com I/O zero.
Considerando uma taxa de acerto de 75%,
Tempo mdio por requisio = 0,25 * 8 + 0,75 * 0 = 2 msegs.
Mximo throughput = 500 requisies por segundo.
Entretanto, h um acrscimo de tempo pela pesquisa no cache.
Vamos supor que o tempo mdio por requisio real seja de 2,5
msegs.
Mximo throughput = 400 requisies por segundo.
Arquiteturas para servidores multi-thread
Pool de trabalhadores:
O servidor mantm um pool de trabalhadores para processar as
requisies;
Em geral, uma thread de I/O recebe as msgs atravs de vrias
conexes;
As requisies so colocadas em filas para tratamento.
Threads-por-requisio:
A thread de I/O cria uma thread para cada requisio que chega;
Ela se destri quando a tarefa est feita;
Maximiza o I/O;
Custo de criao e destruio de threads.

23 SD Cap. 5-6

Threads-por-conexo:
O servidor coloca uma thread para cada conexo de cliente;
Em uma conexo, cada cliente pode fazer vrias requisies.
Threads-por-objeto:
Uma thread associada a cada objeto remoto;
Cada objeto possui sua fila.
Threads nos clientes
Nos clientes, o uso de threads interessante para evitar bloqueios
indesejveis em certas operaes:
Em requisies a um servidor;
Em RMI (ou RPC), quando se faz invocao a um objeto
remoto.
Formas organizao de threads nos clientes:
Por requisio: para cada requisio feita no cliente disparada
uma thread que gerencia o processo;
Por conexo: cada conexo estabelecida com um servidor
remoto recebe uma thread toda comunicao nessa conexo
feita por meio dela;
Por objeto: para cada objeto remoto usado pelo cliente
disparada uma thread cada uma faz as invocaes remotas para
o seu objeto.
Threads x mltiplos processos
A mesma sobreposio pode ser alcanada por mltiplos processos.
Por que um sistema multithread prefervel?

24 SD Cap. 5-6

Ambiente de execuo (processo):

Espao de endereamento;
Portas, interfaces de comunicao, etc.
Semforos, objetos de sincronizao, etc.
Lista de threads.
Thread:
Registradores salvos;
Estado (ex.: bloqueado) e prioridade;
Informao sobre tratamento de interrupes.
Elementos comuns entre processos e threads:
Pginas residentes em memria;
Entradas de caches.
Sumrio:
Criar uma nova thread para um processo j existente mais
barato do que criar um novo processo;
Chavear para outra thread de um processo mais barato do que
para threads de processos diferentes;
O compartilhamento dos recursos de um processo por suas
threads mais simples do que por processos separados;
O problema que as threads no tm proteo uma das outras.
Custo de criao de uma thread:
Alocao da regio da pilha;
Valores iniciais para os registradores;
Estado inicial: SUSPENDED ou RUNNABLE;
Prioridade;
Acrscimo de identificador no registro de threads.

24 SD Cap. 5-6

Comparao de tempos:
Sistema Unix;
Arquitetura CVAX;
Kernel Topaz;
Anderson et al., 1991;
Teste: processo ou thread criados para fazer uma chamada nula;
Processo: 11 msegs;
Thread: 1 mseg.
Memria:
Um processo recebe page faults logo que inicia sua execuo;
Uma thread tambm!
Entretanto, threads podem se beneficiar dos acessos feitos sobre
suas reas por outras threads;
Pode aproveitar reas colocadas nos caches por outras threads.
Programao de Threads
A programao de threads Programao Concorrente!
Conceitos desta seo: race conditions, seo crtica, variveis de
condio e semforos.
Ex.:
Modula-3, Java: suporte direto threads;
C: extenso por biblioteca;
P Threads: padro de threads para o Posix desenvolvido pelo
IEEE;
GNU Threads: padro da Free Software Foundation para o
SunOS.

25 SD Cap. 5-6

25 SD Cap. 5-6

Chamadas Java para manipulao de Threads:

Thread(ThreadGroup grupo, Runnable alvo, String nome) cria
uma nova thread no estado SUSPENDED, que pertence a grupo
e identificada como nome; passa a executar pela chamada do
mtodo run() de alvo.
setPriority(int newPriority), getPriority() muda ou retorna a
prioridade da thread.
Run() executa o mtodo run() de seu objeto alvo, se houver; ou
seu prprio mtodo run() (Thread implementa Runnable).
start() muda o estado da thread de SUSPENDED para
RUNNABLE.
sleep(int millisecs) a thread passa para o estado SUSPENDED
pelo tempo especificado.
yield() passa para o estado READY e chama o escalonador.
destroy() destri a thread.

Obs.:
Grupos so isolados uns dos outros, no sentido de que no
podem ser gerenciados entre si;
Threads de um grupo no podem criar threads de outro;
Grupos podem ter prioridades limites estabelecidas pelo
processo.

Chamadas de sincronizao da biblioteca C Threads:

mutex_lock(mutexId)
mutex_unlock(mutexId)
condition_wait(conditionId, mutexId)
condition_signal(conditionId)

Chamadas da biblioteca C Threads:

threadId = cthread_fork(func, arg) - permite criar uma thread a
partir de outra, que executa a funo func passando um s
argumento arg;
cthread_exit(result) - termina a thread atual;
cthread_join(threadId) - a thread que criou threadId espera at o
seu trmino;

cthread_set_data(threadId, data) - associa dados globais

exclusivamente com uma thread;
cthread_data(threadId) - libera os dados associados a uma
thread;
cthread_yield() - permite que outra thread rode.

Problemas com Threads:

<stdio.h> em C;
1 buffer para cada stream de I/O (ex.: vdeo)
o problema ocorre quando mais de uma thread tenta mandar
caracteres para um terminal;
a ordem depende do escalonador;
a biblioteca mantm um ponteiro para a posio no buffer onde o
prximo caracter deve ser colocado:
pode levar a race conditions.

Escalonamento de Threads
Preemptivo: uma thread pode ser suspensa pelo escalonador para
que outra execute;
No preemptivo (corrotina): uma thread executa at fazer uma
chamada que cause sua suspenso.
Corrotinas:

26 SD Cap. 5-6

Qualquer seo que no apresenta chamadas uma seo crtica;

S servem para mquinas com 1 processador;
No servem para Real Time;
Aplicaes processor bound devem dar chances s outras (yield).

Implementao de Threads
Alguns kernels permitem processos com apenas uma thread;
Porm, h bibliotecas que permitem implementar processos
multithreads.
Ex.: SunOS 4.1 Lightweight Processes (pacote)
O kernel no reconhece as threads;
No h escalonamento de threads independentemente;
Se algum (o processo ou uma thread) faz uma sys call
bloqueante, todos bloqueiam;
As threads de um processo nessas condies no podem executar
num sistema multiprocessador;
A troca de contexto de threads dentro de um processo no
precisa ser feita via sys call;
O escalonamento pode ser especfico da aplicao;
Psyche (SO multiprocessador) - processador virtual (PV):
Um PV um recurso pertencente a um processo;
Implementado no kernel;
Associado com processadores reais;
O processo controla esses recursos diretamente;
Cada um executa uma funo;
O kernel informa o processo dos eventos;
O processo pode trocar uma thread bloqueada em um PV;
Ou pode trocar o PV de um processador real.

26 SD Cap. 5-6

6.4 Nomes e proteo

Um servio em geral gerencia vrios recursos:
Cada um deles pode ser acessado independentemente pelos
clientes;
Para esta finalidade, o servio fornece identificadores para cada
um dos seus recursos;
Servios precisam ser reconfigurveis - flexveis:
Para um grupo de servidores gerenciar um recurso
individual;
Para se localizar os servidores.
Clientes acessam recursos atravs de requisies a um servio,
passando o identificador correto.
Requisies so passadas a identificadores de comunicao, que
podem ser obtidos de um servio de binding;
Mach e Amoeba: portas;
Chorus: grupos de portas.
Identificao de um recurso deve-se fornecer:
Porta (grupo) de acesso ao servidor que gerencia o recurso;
Identificador especfico.

Identificadores independentes de localizao fornecem

transparncia de rede;
O formato dos identificadores escolhido por quem implementa
o servio;
boa prtica usar o mesmo formato para a mesma famlia de
servios;
Facilita a administrao e marshalling;

27 SD Cap. 5-6

Identificadores devem ser nicos num SD inteiro ou, ao menos,

dentro de um servio;
Amoeba: identificadores nicos em todo o SD;
Permite usar um identificador sem saber de que servio ele !

Reconfigurabilidade
Capacidade de um SD de se adaptar evoluo ou mudanas em
suas condies, tais como carga de rede ou falhas:
Relocao de servidores: ocorre pela criao de novas instncias
de servidores ou por migrao;
Mobilidade de recursos: recursos migram de um servidor para
outro no mesmo servio.
preciso manter as transparncias de localizao e de migrao;
Problema: como reconfigurar o servio on-line?

Proteo de recursos
Objetivo: garantir que os processos s possam acessar os recursos
para os quais tenham permisso.
Problemas:
As redes devem ter abertura;
Os computadores de um SD podem sofrer ataques que alterem
seu software;
A proteo deve ser especfica por servio;
Os servidores podem receber qualquer requisio de qualquer
computador/processo da rede;

27 SD Cap. 5-6

Domnios de proteo

J visto em SO I;
Conjunto de pares (recurso, direitos), relacionando todos os
recursos que podem ser acessados pelos processos que rodam
nesse domnio;

Ex.: Unix domnio determinado pelo grupo e usurio. Os direitos

so determinados pelas operaes RWX.
Implementaes:
Capabilities e Listas de controle de acesso.

6.5 Comunicao e invocao

Formas de comunicao:
Produtor-consumidor;
Cliente-servidor;
Comunicao de grupo.
Formas de qualidade de servio:
Garantia de entrega;
Banda de transmisso;
Latncia;
Segurana.
Questes relacionadas aos servios de comunicao:
Primitivas disponveis;

28 SD Cap. 5-6

Garantias de QoS;
Protocolos;
Abertura da implementao;
Procedimentos para aumentar a eficincia.

Primitivas de comunicao
Formas de passagem de mensagens:
Send-receive;
DoOperation-GetRequest-SendReply.
A implementao depende dos recursos disponveis:
As primitivas podem ser confiveis;
Se no forem, isso pode ser alcanado em nveis mais altos;
Uma das formas pode ser implementada usando a outra;
Isso pode ser feito em baixo nvel (kernel) ou em alto nvel (at
na aplicao).

Compartilhamento de memria

Comunicao local deve ser feita pela transferncia do contedo

de reas de memria entre os processos;
Feito pelo kernel atravs de operaes especiais (Copy-onwrite);
Transfere dados de pginas de um espao de endereamento para
pginas de outro;
Regies compartilhadas podem ser usadas para facilitar (dar
mais velocidade) a comunicao processo-kernel e/ou processoprocesso;
Problemas:

28 SD Cap. 5-6

Sincronismo;
Justifica se for bastante usado, j que o custo para estabelecer
alto.

Qualidade de Servio
O que possvel fazer com primitivas no confiveis?
possvel construir uma verso confivel de um Send;
At um RPC com semntica at-least-once ou mesmo at-mostonce;
Comunicao orientada a streams, com um sistema apropriado
de buffers;
Multicast de alto nvel;
Segurana para a comunicao, passando por um servio de
criptografia;
Principal dificuldade latncia satisfatria:
H servios que precisam de mais latncia do que outros;
Multimdia impem restries de tempo real;
O SO deve atender as solicitaes de um mnimo de qualidade
dos usurios ou recusar o servio;
Protocolos e abertura

Alguns sistemas incorporam seus prprios protocolos:

Ex.: Amoeba - Amoeba RPC;
V system - VMTP;
Sprite - Sprite RPC.
Problema: esses protocolos no so usados em ambientes de uso
geral;

29 SD Cap. 5-6

TCP, UDP e IP no suportam RPC diretamente;

Mach e Chorus tm outra estratgia:
Suportam apenas passagem de mensagens local;
Usam servidores no topo do kernel para tratar os protocolos
de rede;
Sistema aberto, j que qualquer um pode implementar seu
prprio servidor.

Desempenho de Invocao
Mecanismos de invocao:
Chamar um procedimento local;
System call;
Enviar uma mensagem;
RPC;
Chamar um mtodo de um objeto, etc.
Em todos os casos, cdigo executado fora dos limites de quem
chama.
preciso passar argumentos e retornar dados para quem chama.

29 SD Cap. 5-6

Tipos de operaes entre espaos de endereamento:

trap

Thread
User

kernel

Thread 1
User 1

System Call

Instrues privilegiadas
Thread 2

Kernel

RPC (no mesmo

computador

User 2
RPC (entre
computadores)

Thread 1

Thread 2
Rede

User 1

Kernel 1

Kernel 2

User 2

Tipos de operao:
Sncronas: chamada local e RPC;
Assncronas: operao sem retorno de valores.

Desempenho de RPC
RPC nulo: RPC sem parmetros, que executa um procedimento nulo
e no retorna valores.
Melhor tempo reportado para um RPC nulo entre 2 processos
usurios atravs de uma LAN: 1 milisegundo!
Uma chamada local de procedimento executada numa frao
pequena deste tempo.

30 SD Cap. 5-6

Um RPC nulo transfere cerca de 100 bytes, somando dados de

cabealhos de pacotes de rede.
A 100 Mbits/seg., o tempo total de rede para transferir essa
quantidade cerca de 0,1 milisegundos.
A maioria do tempo composta de atrasos impostos pelo SO e
pelo cdigo do RPC no nvel do usurio.

Estudo sobre a mdia de RPCs chamados (Bershad, 1990 1,5

milho de chamadas):
A chamada mais freqente de menos de 50 bytes do usurio;
A maioria das chamadas transfere menos que 200 bytes;
RPC que transfere blocos de disco tende a ter 1-8 kb;
O uso de caches tende a diminuir a freqncia dessas chamadas.
A maioria das chamadas RPC cabe num pacote de rede (em torno de
1 KB).
Um RPC nulo representa o overhead fixo que uma chamada
apresenta.
Figura 6.14:
O atraso de um RCP cresce proporcionalmente ao tamanho do
pacote;
H um salto toda vez que preciso acrescentar mais um pacote
na chamada.
Throughput:
O atraso no o nico elemento de interesse no RPC;
Throughput: taxa na qual os dados podem ser transferidos entre
computadores;

30 SD Cap. 5-6

Na fig. 6.14, o throughput pequeno para pequenas quantidades

de dados;
medida que cresce a quantidade de dados, cresce o throughput,
j que o overhead fixo torna-se menos significativo;
Hutchinson, 1989 mximo throughput = 750 KB/seg. (Ethernet
10 Mbits/seg!);
O throughput para quantidades maiores de dados deve aumentar
bastante com redes de 100 Mbits/seg (ou mais)!
Mesmo assim, para quantidades pequenas o overhead fixo deve
predominar;

Quais so esses overheads e o que fazer para minimiz-los?

Passos de um RPC:
Stub do cliente:
Marshalling dos argumentos;
Envio da requisio;
Recepo da resposta;
Unmarshalling da resposta.
Servidor:
Dispatcher recebe a requisio;
Chama o stub apropriado do servidor.

Stub do servidor:
Unmarshall dos argumentos;
Chamada do procedimento correto;
Marshalling dos argumentos;
Envio da resposta.

31 SD Cap. 5-6

Principais componentes do atraso de um RPC:

Marshalling: significa copiar e converter dados;
Cresce medida que a quantidade de dados aumenta.
Cpia de dados:
Cpia de memria para memria fica em torno de 10
MB/seg. nos processadores mais rpidos;
Mesma taxa de transferncia de uma rede 100 Mbits/seg;
Uma mensagem pode ser copiada diversas vezes num RPC:
Entre usurio e kernel;
Entre cliente e servidor;
Nos buffers do kernel;
Entre as camadas dos protocolos;
Entre as interfaces de rede e os buffers do kernel.
Obs.: no sentido interface-memria (na chegada), a transferncia
feita por DMA.

Inicializao de pacotes (headers, checksums, etc.): custo

proporcional quantidade de dados;
Escalonamento de threads e troca de contexto:
RPC invoca sistema de comunicao do kernel;
Aplicao usa threads para fazer um RPC;
Se h um processo gerente de rede, um Send implica em
troca de contexto.

6.6 Memria virtual

Objetivo: executar grandes problemas e combinaes de programas
cuja soma de cdigo e dados maior que a memria principal:

31 SD Cap. 5-6

Parte da memria usada como cache do sistema de

armazenamento.

Por manter apenas as sees de cdigo e dados atualmente em uso

pelos processos, possvel:
Executar programas maiores que a memria principal;
Aumentar o nvel de multiprogramao ao aumentar o nmero
de processos na memria principal;
Liberar os programadores das limitaes da memria fsica.
Idia generalizada para abranger o acesso a arquivos mapeados em
reas de memria:
Um processo l ou grave dados no arquivo lendo ou gravando
num array em memria;
Um arquivo aberto para uma linguagem de alto nvel aparece
como um array;
O kernel responsvel por trazer mais dados medida que os
dados do array so lidos;
O kernel transfere os dados para disco medida que eles so
alterados
Ex.: MULTICS, SunOS.
Demand paging: uma pgina s carregada por demanda (isto ,
quando algum precisa, ela carregada para a memria principal).

Gerenciadores externos
Em um SD, o computador que recebe um page fault no precisa ser
o mesmo que gerencia os dados:
Ex.: o 1o pode ser diskless;
O gerente um servidor de arquivos remoto;

32 SD Cap. 5-6

32 SD Cap. 5-6

Espao de
endereamento

Page fault

Gerente
externo

msgs

Kernel

Kernel
rede

O uso de gerenciadores externos permite implementar esquemas

customizados de paginao;
Uma abordagem para implementar memria compartilhada
distribuda;
O kernel continua responsvel por:
tratar page faults;
gerncia da memria principal;
poltica de alocao;
poltica de substituio.
Funo do gerenciador externo:
Receber e tratar dados de pginas purgadas pelo kernel;
Fornecer pginas ao kernel conforme ele pea;
Impor restries aos diversos kernels que acessam uma rea
(todos podem tentar manter caches de reas modificveis).