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

Middleware

2 SD Cap. 5-6 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

5.2.1 Modelo de Objetos Excees

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.2 Objetos distribudos Objetos distribudos podem se organizar de vrias formas. A invocao de seus mtodos segue modelos previamente estudados.

3 SD Cap. 5-6 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.

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 4 SD Cap. 5-6

Medidas de tolerncia a falhas Retransmitir requisies

Filtro de duplicados

Re-executar ou retransmitir

reply

Semnticas de

invocao

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.

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

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

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.). 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). 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 Semntica RPC Repete Req. N S S

Filtra Duplic. - N S

Reexec/Retrans - Reexecuta Retransmite

Maybe At-least-once At-most-once

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.

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. 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: Requisio Cliente Servidor Chamada Marshall Send Receive Unmarsh. Executa Seleo! Retorno Unmarsh Receive 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.

Construindo o programa servidor: entregador (despatcher); conjunto de stubs servidores. 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 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 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).

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

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 sncrono argumentos marshall send receive unmarshall transmisso executa marshall send receive unmarshall processa argumentos marshall send receive unmarshall executa marshall send receive unmarshall processa Cliente Servidor

RPC assncrono argumentos marshall send argumentos marshall send receive unmarshall executa marshall send receive receive unmarshall unmarshall executa processa marshall send receive unmarshall processa Cliente Servidor

13 SD Cap. 5-6 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 call-

stream 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.

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

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

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

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.

Carregado dinamicamente

Kernel monoltico 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:

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;

Sn

S1 S2 S3 S3S2S1

Microkernel

Hardware

Servios abertos processos/objetos das aplicaes

Suporte de linguagem

Suporte de linguagem

Emulao de OS

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 Hardware

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.

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". 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.).

Gerente de Processos

Supervisor

Gerente de Threads

Gerente de Memria

Gerente de

Comunicaes

20 SD Cap. 5-6 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.

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; 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:

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 Memria Gaps Virtual (ex.: 232) 0

Regies Auxiliares

Stack

Heap

Text

21 SD Cap. 5-6 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;

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

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

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

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 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: 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.

Chamadas de sincronizao da biblioteca C Threads: mutex_lock(mutexId) mutex_unlock(mutexId) condition_wait(conditionId, mutexId) condition_signal(conditionId) 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 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.

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

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

write); 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 processo-processo;

Problemas:

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

once; 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 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.

Tipos de operaes entre espaos de endereamento: Thread User kernel Thread 1 Thread 2 User 1 Kernel User 2 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.

trap

Instrues privilegiadas

System Call

RPC (no mesmo computador

RPC (entre computadores)

30 SD Cap. 5-6 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;

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

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

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).

Espao de enderea- mento

Kernel Kernelrede

Page fault msgs

Gerente externo