Apostila - SD

SISTEMAS
DISTRIBUDOS
Notas de Aula
Prof. Dr. Gilberto Nakamiti
Sistemas Distribudos
Introduo
Sistema distribudo fracamente acoplado
Figura 01 Sistema fracamente acoplado Sistema distribudo fortemente acoplado
Figura 02 Sistema fortemente acoplado
Granularidade do sistema distribudo (gro de paralelismo)

Pseudo-paralelismo (por Ter uma s CPU) para sistemas fracamente acoplados. - Gro nmero mdio de ciclos de CPU para executar uma tarefa (# instrues de uma tarefa tpica) fina, baixa tarefas pequenas - Granularidade x tempo de comunicao entre tarefas 1
maximizar tempo de processamento de uma tarefa t para redes tempo de comunicao
Sistema distribudo fracamente acoplado (SDFA)

um conjunto de N tarefas que executam em M>1 processadores conectados atravs de via de dados lenta (ex.: rede local). As tarefas cooperam na soluo do problema para o qual o sistema foi concebido.
Motivao para o desenvolvimento de SDFA

custo dos processadores tradicionais (ex.: estaes de trabalho PCs); topologias de interconexo (LAN, MAN, WAN(acop. + fraco)); diversidade de processadores dedicados; confiabilidade (graceful degeneration degradao amena); demanda tecnolgica de outras reas (ex.: projeto concorrente, rea mdica) Requisitos bsicos para o desenvolvimento de SDFA - promover (fazendo uso de hardware e software): - comunicao entre tarefas (troca de informaes) . ponto a ponto
Figura 03 Ligao ponto a ponto
. compartilhamento de informao (multiponto)
Figura 04 Ligao multiponto
controle entre tarefas . execuo de tarefas (depurar, matar, ...) . disciplina de acesso aos recursos compartilhados (ex.: semforo, transao, flags de leitura/escrita etc.)
Dificuldades para o desenvolvimento de SDFA

- separao entre tarefas - tarefas com espao de endereamento disjuntos - tarefas gerenciadas por sistemas operacionais distintos (pelo menos duas instncias ou 2 SOs diferentes) - prover transparncia Transparncia: quanto ao acesso (mesmas primitivas para acessar recursos locais e remotos) quanto a localizao (mover um recurso entre ns (host/processador) da rede sem afetar operacionalidade) quanto concorrncia (mesmo mecanismo de controle de acesso - ex.: atravs de determinado semforo) quanto replicao (no se sabe com qual cpia est lidando) quanto falha (tarefas passam a ser executadas em outro n a partir do mesmo ponto ou instncias da mesma tarefa em ns diferentes) quanto migrao (migrao de tarefas para balancear cargas de processamento) quanto ao desempenho (mesmo desempenho independentemente da situao / configurao do sistema) quanto escala (aumento de desempenho com aumento de recursos) O que controla cada HOST
aplicaes soft-real-time
- sistema operacional com capacidade de comunicao inter-tarefas inter-hosts (ex.: UNIX + TCP/IP) - sistema operacional de rede (netowork OS) (ex.: UNIX ou SUN OS + NFS (Network file System) + RPC (Remote Process Call)) - (facilita a comunicao inter-tarefas interhosts) - sistema operacional distribudo (mgrao, disparar e controlar tarefas em hosts remotos)
Sistemas Distribudos aplicaes hard-real-time (aplicaes militares, ...) Tarefa Tarefa um processo. Processo
Prof. Dr. Gilberto Nakamiti - sistema operacional para tempo real com capacidade de servios - comunicao intertarefas inter-hosts
a unidade de escalonamento que possui um conjunto prprio de recursos.
Figura 05 - Processo
Redes de computadores
Modelo OSI/ISO
O Open System Interconection ou Modelo de Referncia para interconexo de sistemas abertos (RM-OSI/ISO) um documento da ISO que tem como objetivo padronizar as arquiteturas de redes locais. Esse modelo consiste em sete camadas ou mdulos a saber: Camada 7 Camada 6 Camada 5 Camada 4 Camada 3 Camada 2 Camada 1 Camada de aplicao Suporte a utilizao de recursos distribudos (servios de alto nvel) ex.: login remoto, transferncia de arquivos, correio eletrnico, ODP (Open Distributed Processing) - Bancos de dados distribudos. Camada de apresentao Transforma os dados representados internamente numa representao (representao de rede). Protocolo EDP (External Data Representation). Outras transformaes: - codificao secreta dos dados (criptografia); - compresso dos dados. Camada de sesso Estabelece conexes virtuais entre dois processos comunicantes Camada de transporte Responsvel pela entrega de mensagens atravs de circuitos virtuais ou de datagramas. A camada estabelece: - traduo de endereo lgico para endereo fsico; - segmentao de mensagens; - prover transmisso confivel para circuitos virtuais; cannica Transporte Rede Enlace Fsica Aplicao Apresentao Sesso
Camada de rede Gera rotas para transmisso dos pacotes oriundos da camada de transporte (utilizada para WANs). Camada de enlace Transmite pacotes entre hosts efetuando deteco e recuperao de erros, controle de fluxo, etc. Camada fsica Controla os drivers de rede.
Figura 06 Comunicao segundo o modelo OSI-ISO
Tecnologias (tipos) de redes
Figura 07 Topologias de redes Ethernet XEROX, 1973 IEEE 802.3 CSMA/CD Carrier Sense multiple Access with Collision Detection
Figura 08 Frame Ethernet Um HOST fica permanentemente escutando por pacotes a ele endereados. Para enviar um pacote: - detecta ausncia de carrier - propaga o pacote - compara o contedo do envio com a recepo. Se detectar coliso: . propaga um jamming signal . espera um tempo aleatrio antes de tentar novo acesso. Token Ring IBM, 1969 7
Sistemas Distribudos IEEE 802.5
Figura 09 Frame Token Ring Envio - espera token livre - adiciona campos ao token - compe o pacote - torna o token ocupado [ muda status se quiser enviar] Recepo - compara endereo de destino com endereo local. Se diferente, passa o token (mensagem). Se igual, retira (cpia) os campos do token, tornando-o livre. 1.1.Comparao - Para cargas leves : - Ethernet mais eficiente para mensagens de comprimento longo (por causa dos repetidores do token ring) - capacidade de transmisso - Token ring determinstica - Para cargas moderadas ou altas - Token ring menos sensvel em relao ao tempo mdio de transmisso. FDDI um padro de rede que opera em 100Mbps, normalmente utiliza fibra. Emprega topologia em anel.
Figura 10 Topolgia em anel utilizando concentrador
Mecanismos de comunicao
Tipos de comunicao - Sncrona - Assncrona
Figura 11 Mecanismos de comunicao Mecanismos - Troca de mensagens (sncrona/assncrona). - Compartilhamento de dados (no compartilhamento de memria!; pois trata-se de sistemas distribudos). - Chamada de processamento remoto (sncrono, do tipo servidor-cliente) [rendezvous-> ADA]
Comunicao interprocessos Troca de mensagens

Supe endereos (origem/destino)
PORT : um recurso utilizado para o envio e recepo de mensagens. Mensagem : uma cadeia de bytes trocada entre processos (normalmente via rede). Estrutura : [Cabea informaes gerais (quem emitiu, tamanho do corpo, tipo de mensagens...) [Corpo contedo. Envio de mensagem : um processo pode enviar uma mensagem para : outro processo; grupo de processos (multicast); todos os processos em todos os hosts (broadcast); Recepo de mensagem : seletiva (transmissor (remetente) especificado); [ack] [ confirmation] no seletiva (recebe de qualquer remetente).
Pode ser sncrona ou assncrona. Codificao de mensagens : cpia de memria (ns homogneos mesma arquitetura (representao) Tempo real) representao cannica (e.g. ASCII, EBCDIC; DSI:EDR; TCP/IP UNIX : XDR)
10
Sistemas Distribudos (para dados bsicos) P1 int i; char buff [20]; i = 3; sprintf(buff,%d,3); envia buff;
P2 int j; char buff[20]; recebe b; sscanf(b,%d,&j); Troca de mensagens no UNIX
Domnio (famlia) - UNIX (entre 2 processos da mesma mquina). Superado! - INET (Internet). Protocolos - UDP (User Data Protocol) (no confivel (SIC), entrega de datagramas, baseado no IP); - TCP/IP (confivel, baseado em stream). Endereo de Host - 32 bits (unsigned long) endereo fsico. - nome simblico (strings) eg. alias, Leblon, ..., Iemanja,...., Leblon.Def.FEE.Unicamp.br endereo lgico. - Nome lgico SYS CALL Nome fsico. Soquete (Socket). uma generalizao do conceito de port. um recurso utilizado tambm para o envio de mensagens. (usar como descritor de arquivos pode usar as mesmas sys-calls).
Local ao processo Global na mquina
default_Tcp/Ip int s; domnio datag./stream s = socket ( AF_INET , SOCK_DGRAM , 0 ) SOCK_STREAM
Atribuio/Associao (Binding) de nomes. Nmero de ports so inteiros BIND (s, ...)
O nmero do port pode ser atribudo pela aplicao (soquete passivo) ou pelo S.O. (soquete ativo).
11
Figura 12 Atribuio do port. Processamentos para comunicao para datagramas : - cria socket - bind - receive { processa mensagem - send (resultado) - close socket Servidor - cria socket - bind - send } aguarda resultado - receive - close socket Cliente Conexo listen (systemcall) torna um soquete passivo. - soquetes passivos aguardam conexes. - Soquetes ativos iniciam conexes.
Liberao de um soquete
12
Close (s). [ UDP at 8 kbytes por mensagem : 64k garante que funciona ]
Representao cannica de dados OSI (ISO) EDR (External Data Representation) TCP/IP XDR
XDR : - conceito de filtro (utilizado na codificao ou decodificao). [cra-se] stream : buffer utilizado para codificar ou decodificar. Filtro uma funo utilizada tanto na codificao quanto na decodificao de dados. int Filtro (Stream,&dado); p/ inteiro no XDR: int buff[128]; int i; float F; XDR *str; str = xdrmem_create(&str,buff,128,XDR_Encode); i = 3; xdr_int(&str,&i); F=3.14; Idr_float(&str,&F); /* abre socket */ write(s,buff,128);
| | | | | | | | | | | peer
read (s,buff,128);
13
Mapeador de Portas (Portmapper)

[Texto resumido, extrado de uma especificao realizada por G. Nakamiti e K. Souza]
Funcionalidade
Um mapeador de portas um processo cuja funo principal prestar informaes acerca de servios disponveis em um ou mais hosts, no que diz respeito ao host que oferece o servio e porta do processo correspondente. Para que cumpra o seu objetivo, o mapeador possui dois tipos de funes: Funes de Registro: fazem a insero ou deleo de um servio na tabela de controle do mapeador. Estas so requisitadas pelos servidores quando desejam se cadastrar/descadastrar; Funes de Pesquisa: procuram na tabela de controle do mapeador o servio desejado por um cliente, informando o par <host,port> correspondente, caso o servio exista, ou uma indicao de que este no est disponvel.
Projeto e Implementao
Na fase de projeto de um mapeador de portas, deve-se tomar decises quanto: forma de comunicao entre os processos, poltica de acesso seguida pelo mapeador quando um servio oferecido por vrios servidores, e quanto ao tratamento de inconsistncias causadas pela morte de um servidor.
Forma de Comunicao entre Processos

O mapeador de portas ser implementado utilizando a suite Internet de protocolos. Nesta suite pode-se escolher o protocolo a ser utilizado para a camada de transporte de informaes (TCP ou UDP), ou seja, se a comunicao com o mapeador ser feita por meio de uma conexo ou atravs do envio de datagramas. Na forma conectada, a comunicao confivel, livre de erros e sem contornos, e o protocolo que a implementa se encarrega da retransmisso de mensagens recebidas com erros, porm, esta forma se justifica melhor pelo seu uso frequente. No envio de datagramas, cada mensagem endereada individualmente e a sua entrega no garantida. utilizado principalmente em requisies que requerem resposta do destinatrio em um temporazovel, antes que seja tentada uma retransmisso.
14
Para a implementao do presente trabalho foi escolhida a forma de datagramas pela seguinte razo: A comunicao entre os servidores/clientes e o mapeador consiste apenas de uma requisio e de uma confirmao/resposta. Desta forma, caso uma conexo fosse estabelecida, esta seria bastante sub-utilizada.
Poltica de Acesso
Quando um servio oferecido por vrios servidores, o mapeador deve escolher um deles para enviar como resposta ao cliente. Para garantir uma melhor distribuio de carga entre os servidores decidiu-se pela escolha atravs de uma distribuio uniforme entre eles.
Tratamento de Inconsistncias
Quando um dos servidores morre devido a um crash no sistema, ou a um problema interno ao prprio processo, deve-se tomar alguma providncia no sentido de no informar ao cliente que determinado servio est disponvel, quando na verdade ele no est. Neste sentido, vrias solues so possveis, com maior ou menor confiabilidade: Cadastro Peridico dos Servidores: onde cada servidor faz o seu recadastramento peridico, indicando que o servio ainda est disponvel. Esta possui o incoveniente de o servidor morrer logo aps um recadastramento e o mapeador continuar a informar que o servio oferecido por ele ainda est disponvel, porm, este um indeterminismo que existe em maior ou menor grau em qualquer das solues encontradas para o problema. Esta soluo, alm de causar sobrecarga na rede, tambm implica em um aumento da complexidade de cada servidor cadastrado; Verificao de Servidor Ativo: procura reduzir a complexidade mencionada no item anterior, levando-a para o mapeador, que verifica periodicamente, ou quando um servio solicitado, a existncia de um dado servidor. Neste caso, deve-se fazer uma estatstica de utilizao de cada servidor para escolher a melhor poltica: a verificao peridica mais indicada para os servidores de maior utilizao, enquanto que a feita no momento em que um deles selecionado mais indicada no caso oposto. Esta ltima opo, apesar de reduzir a sobrecarga na rede, implica em um aumento no tempo de resposta do mapeador; Informao do Cliente: ao receber uma informao invlida (servidor que no mais existe), o cliente envia uma mensagem ao mapeador indicando que aquele servidor deve ser descadastrado. Esta soluo no apresenta atrasos nem sobrecarga na rede, entretanto, causa um aumento na complexidade dos clientes que interagem com o mapeador;
15
Ativao do Servidor pelo portmapper: o proprio mapeador, ao receber um pedido do cliente, ativa o servidor e retorna o seu par <host, port>correspondente. Neste caso, o mapeador se utilizaria de RPCs (Remote Procedure Calls) para fazer a ativao do servidor.
Aumento de Desempenho do Mapeador

Nas sees anteriores ressaltamos o atraso na consulta/envio da resposta que existe em qualquer forma de implementao do mapeador, alm de sobrecarga na rede se o mapeador estiver numa nica mquina. Para amenizar estes problemas propem-se as seguintes medidas: Armazenamento em cache local, onde se faria a consulta ao mapeador apenas quando a informao no estivesse disponvel localmante. A vantagem principal deste est na rapidez da consulta quando o servio solicitado frequentemente, e a sua desvantagem est na manuteno desta estrutura de cache, principalmente quanto a problemas de consistncia; Replicao dos mapeadores em todas as mquinas, cujas vantagens seriam a rapidez na resposta e diminuio na carga imposta rede. Suas principais desvantagens so: o aumento na carga imposta aos vrios processadores pela adio de mais um processo por mquina, e o problema de se manter uma consistncia global; A transformao do mapeador em um servidor de RPC, no qual, ao ser recebida uma solicitao de servio, uma mensagem enviada pelo mapeador ao prprio provedor do servio, que dispara um processo que ir atend-lo, enviando de volta uma resposta.
16
Chamadas de procedimentos remotos (RPC)
Figura 13 Chamada de procedimento remoto (RPC)
Transparncia das chamadas

transparncia total - RPC embutido na linguagem de programao [no existe]; ou - Usar pr-processador (STUB) das chamadas, que identifica se chamada local/remota, extrai os tipos de parmetros, codifica, localiza, abre ports, comunica, recebe (depende do compilador, verso difcil manter). transparncia limitada.
Estrutura do servidor
17
Figura 14 Estrutura do servidor Passagem de parmetros (para transparncia limitada) passagem sempre por valor; os parmetros so passados numa forma cannica (e.g. XD2); restries na quantidade de parmetros passados/retornados (normalmente 1/1).
Registro de procedures (servios)
18
Sistemas Distribudos 1. localizao do servidor (HOST,PORT); 2. localizao da procedure (normalmente Nome simblico).
Figura 15 Registro de procedures
SUN RPC
total indeterminismo (no garante tempo para atendimento de chamdas) velocidade baixa (software de alto nvel implementado com RPC competio com servios normais de rede). Identificao de procedures - identificao do servidor (ID); - verso do servidor; - ID da procedure.
Exemplo : um servio de nmeros globais.
19
MAILBOXES
Idntico a troca de mensagens, exceto no conceito de port. MAILBOX (MB) uma extenso do conceito de port. mais abstrato, de mais alto nvel. identificado por u nome simblico XYZ. Eventualmente tipado, i.., um MB do tipo t recebe mensagens apenas do tipo t. Eventualmente possui um grupo de proprietrios. Dois esquemas : 1 l ou todos lem. Possui limites na criao (e.g. tamanhos diferentes de mensagens pendentes). Primitivas bsicas :
[grupos de]
cria_mb(XYZ,tipo,limites,usurios); ch=acessa_mb(XYZ); port_mb(ch,msg); get_mb(ch,&msg); destri_mb(ch);
RENDEZVOUS (ADA)
Para comunicao entre tarefas. Normalmente embutido na linguagem de programao. Similar RPC, mas com aceite da execuo da procedure explicitado pelo servidor.
20
Memria distribuda com replicao de dados

MRSW
Figura 16 Memria distribuda com replicao de dados Procedimento para leitura de mi : a) existe cpia local de mi a1) Vlida l a2) Invalida obtm cpia vlida (diretrio, instalando-a localmente, atualizando a lista de onde est as cpias secundrias); l. b) no existe cpia local de mi obtm cpia vlida (diretrio), instalando-a localmente; l. Procedimento para gravao (atualizao) Dois esquemas so possveis a) gravaes sempre se realizam no host onde se localiza a cpia mestre. a1) invalida todas as cpias secundrias (recebendo ack). a2) grava. b) gravaes so sempre locais (a cpia mestre muda de host). b1) invalida todas as cpias secundrias [ack]. 21
Sistemas Distribudos b2) migra cpia mestre. b3) grava. Vantagens : -
tolerncia parcial a falhas; eficiente quando a taxa de leitura sobre gravaes (L/G) alta; paralelismo total para leitura; por parties (parcial) para gravaes.
Desvantagens : complexidade na manuteno da consistncia.
MRMW
Figura 17 Memria distribuda com replicao de dados Problema : O broadcast entrega aos hosts em instantes diferentes, pois em SDs no existe clock central. Soluo : Invalidar as cpias antes do broadcast eficincia !! baixa. Vantagens : equivalente a anterior, muito mais com replicao total sempre consistente tolerante a falhas. 22
Desvantagens : equivalente a anterior, mais gargalo no sequenciador (melhora com 1 sequenciador para cada partio da memria). Maior necessidade de remontar verses ante a ocorrncia de gaps de verses uso do log.
Estruturao de memria
buffer no interpretado no sentido de empacotamento; no ocorre empacotamento/desempacotamento de dados struct conhecido por todos s cpia de bits. Serve para tempo real. S para redes homogneas. (Normalmente cada mensagem mk corresponde a um buffer Bk, que corresponde a um struct Sk). dados estruturados depende da aplicao. Tem que ser interpretado. - n-uplas (e.g. string,19,17-47)
Comunicao por compartilhamento de dados
Vantagens : assincronismo entre produtor/ consumidor de informao; modularidade/ extensibilidade; definio mais precisa de estado; familiar ao programador ( IPC sockets, __ ) no favorece nenhuma arquitetura particular de sistemas distribudos.
Desvantagens : velocidade de comunicao; controle de acesso (e.g. problemas de corrida- transao ). 23
Compartilhamento de dados em sistemas distribudos
Figura 18 Compartilhamento de dados em SD Operaes bsicas Fetch (real) Store (write) atmicas (sic)
Implementao de memria compartilhada em SD atravs de processos
Figura 19 Implementao de memria compartilhada atravs de processos memria centralizada
24
Figura 20 - Implementao de memria compartilhada atravs memria centralizada Vantagens : a litura retorna sempre o valor da ltima escrita; consistncia sempre garantida (se as operaes forem atmicas); implemetao simples.
Desvantagens : criao de gargalo, com prejuzo da eficincia; confiabilidade.
Implementaes alternativas para memria centralizada
Figura 21 Implementao alternativa para memria centralizada. Vantagens e desvantagens similar a anterior.
Esquemas de localizao de memria compartilhada

cadeia de ponteiros; broadcast (com quem est?); 25
Sistemas Distribudos diretrio central (e.g. portmapper). token [lgico].
Memria distribuda sem replicao
Obs.: o diretrio central pode ser substitudo por um esquema de broadcast. Vantagens : consistncia garantida; implementao simples; paralelismo de leitura/gravao (para regies disjuntas mi mj = ).
Desvantagens : confiabilidade (morte sbita de processador/ processo) (bottleneck pode ser resolvido pelo particionamento e alocao de memria).
Obs.: Esse esquema tambm permite imigrao (por ex. para balanceamento dinmico de carga, sobrevivncia a paradas programadas). - frames {classe [ATR,VALOR] ... [ATR, VALOR] }
26
Memria compartilhada (M.C.)

Controle de acesso manter consistncia : Lock : uma chave de acesso para uma dada regio da memria compartilhada (granularidade). Locks possuem certa abrangncia (granularidade). Tipos : - leitura. - gravao.
A serializao implica numa poltica de obteno de locks.
Locking em 2 fases
Teorema : Se um conjunto de operaes (R/W) obedece as regras : a) antes de ler ou gravar uma regio de memria, obtenha o respectivo lock para aquela regio; b) depois de liberar um lock nenhum outro ser requisitado para essa seqncia de operaes; Ento qualquer conjunto de operaes realizvel (preserva a consistncia mas no a ordem temporal em sistemas distribudos deadlocks) 1) Locking por marcas de tempo (m.t.) (menos flexvel para locks em regies interdependentes). Regies de memria compartilhada tm a elas associadas marcas de tempo; hora da ltima leitura; hora da ltima gravao.
Antes de iniciar uma seqncia de operaes, o processo obtm um time-stamp (T.S.). Protocolo : uma leitura numa dada regio de memria s se processa se a M.T.W. (marca de tempo de gravao) for menor que o time-stamp. Uma gravao numa dada regio da M.C. s se processa se: MTW < TS MTREAD < TS
(Se qualquer dessas operaes falhar, o processo pede outra M.T. e tanta repetir a operao)
27
Locking por validao otimista

FASE A : As operaes so executadas sem preocupao com serializao. FASE B : Verifica se ocorreu violao com a serializao. Caso afirmativo, um conjunto de operaes desfeito.
Controle interprocessos
Mecanismos : instanciao (criao) e controle da execuo (e.g. Suspenso, trmino) sincronizao tratamento de excees.
Figura 22 Controle inter-processos
28
Deadlock
Figura 23 - Deadlock
Caracterizao do deadlock
Sejam Pj processos aguardando eventos Ei; Pj P; Ei E; Pj (Ei) (Pj aguarda evento Ei), de sorte que Ek E somente ocorre por ao de Pe P.
Condies necessrias para ocorrncia de deadlocks

1) excluso mtua; lgico (dados compartilhados); fsicos (e.g. impressora) e de comunicao (e.g. chegada de mensagens).
2) hold-and-wait; (segura os recursos necessrios que j obteve e espera a liberao de outros). 3) Inexistncia de preempo; 4) Existe (ou pode existir) espera circular. Obs.: Nem todas so necessrias ao mesmo tempo.
29
Grafo de alocao de recursos
Figura 24 Grafo de alocao de recursos
Tratamento de deadlocks
a) b) c) d) preveno (cuidar para no ocorrer); fuga (evitar a situao); deteco (j ocorreu); quebra (quebrar o ciclo).
Preveno 1) adio de recursos (condio 1); 2) protocolo de requisio (condio 2); permitir a utilizao de um nico recurso por vez; obteno de todos os recursos antes de sua utilizao. - Inefici6encia (fica com o recurso mais tempo que o necessrio); - starvation (funciona como com prioridades).
3) admitir a preempo (condio 3); Se um processo requisita um recurso no disponvel, todos os recursos de posse do processo lhe so tomados. 4) evitar a espera circular (condio 4). Enumera-se os recursos R1, R2, ... Rn e impe-se que os processos requisitem recursos apenas em ordem crescente. 30
ineficincia; starvation.
Fuga Algoritmo de banqueiro (empresta quando disponvel, seleciona quando escasso, mantm sempre uma situao saudvel) Dados : DISP[j]=k; k instncias do recurso j; MAX [i,j]=k; o processo Pi pode requisitar no mximo k instncias do recurso j; ALOC [i,j]=k; o processo Pi tem a ele alocado k instncias do recurso j; NEC [i,j] = MAX [i,j] ALOC [i,j] = k; Pi pode vir a necessitar (solicitar) de k instncias do recurso j; REQ [i,j] = k; o processo Pi est requisitando k instncias do recurso j; REQ [i,j] NEC [i,j].
Algoritmo 1) Se REQ [i,j] NE [i,j] prossiga SENO reporte erro; 2) Se REQ [i,] DISP [] prossiga SENO processo deve esperar; 3) Compute DISP[] = DISP[] REQ [i, ]; ALOC [i, ] = ALOC [i, ] + REQ [i, ]; NEC [i, ] = NEC [i, ] REQ [i, ]; 4) Para este novo estado, verifica a sua segurana Seja W [k] = DISP [k], k=1, __ , m; F [k] = FALSO, k=1, __, m; a) escolha k tal que : F [k] = FALSO; NEC [i,k] DISP [k]; Se k v para c b) W [k] = W [k] + ALOC [i,k]; F [k] = VERD; c) Se F [k] = VERD k ento o estado seguro, caso contrrio inseguro. 5) Se o estado seguro, conceda os recursos solicitados, caso contrrio desfaa o passo 3 e no conceda. Exemplo
31
Deteco 1) W [k] = DISP [k] Se ALOC [i,k] 0 F [i] = FALSO. SENO F [i] = VERD 2) escolha i tal que F [i] = FALSO REQ [i,k] W [k] Se i v para 4 3) W [k] = W [k] + ALOC [i,k] F [i] = VERD V para 2 4) Se F[i] = FALSO para um dado i, ento o sistema est em deadlock e o processo Pi P.
Processamento de transaes
Figura 25 Processamento de transaes - Centralizado Definio : Uma transao um conjunto de operaes delimitadas por um BeginTransaction e um EndTransaction , que satisfazem as seguintes propriedades : 1. Serializao (inter-transaes) para objetos comuns. 2. Atomicidade (em relao a falhas) (j era obtido com locks , o sistema no fica inconsistente). 3. Persistncia (em relao queda de processadores).
32
Sistemas Distribudos Operaes : locais ou remotas leitura (R); Gravao (W).
Processamento de transaes (do ponto de vista do usurio). 1) t-id = Begin_Transaction (); 2) if (lock (t_id, object, modo R/W)) { operaes ... } else Abort_Transaction (t_id); 3) End_Transaction (t_id). /* abertura */ /* aquisio obtm os locks */ /* operaes */
/* finalizao */
Figura 26 Processamento de transao Quebra (recuperao) 1) terminao; 2) preempo seleo da vtima; tomada dos recursos; roll_back (volta para algum estado anterior consistente).
Obs.: custoso (geralmente evita-se usando locks com time-outs) ; garante que no h deadlocks, mas no garante que haja progresso. Deadlock em Sistema Distribudo
33
Sistemas Distribudos Estratgias de preveno, fuga, deteco e recuperao. estratgia centralizada
Figura 27 Deadlock Estratgia centralizada Desvantagens : perda de mensagens (estado inconsistente); chegada de mensagens em ordem temporal trocada; toda a informao converge para um nico processo.
estratgia hierrquica
Figura 28 DeadLock Estratgia hierrquica estratgia distribuda aguardando mensagens (recursos de comunicao); time-out envia mensagem multicast, se voltar ele prprio est em deadlock e (se mata, mata filhos, ....) caso geral :
34
Figura 29 DeadLock Estratgia distribuda Protocolo de obteno de locks Locking em 2 fases mais simples, mais usado (nesse todos os locks s so liberados no final da transao, pois seno poderia ser lido um valor inconsistente alterado por uma transao que ainda iria ser abortada (para garantir atomicidade). Soluo: no prover primitivas para liberar locks s atravs do End_Transction ou Abort_Transaction. Timestamp necessita de marcas de tempo globais.
Locking em 2 fases Atomicidade : restaurar estado anterior: - cpia de objetos antes das modificaes. - undo log (guarda operao inversa ocupa menos espao em disco, mas mais difcil de implementar). Persistncia supe a existncia de uma mdia estvel (geralmente disco). 35
Sistemas Distribudos -
Tem que, aps falhas, deixar no estado aps a ltima transao (de escrita) terminada com sucesso. checkpoint global ao final das transaes. checkpoint parcial + log.
Protocolo de finalizao Commit em 2 fases
1 fase pr-commit (o coordenador pergunta aos participantes se esto prontos para terminar) se algum responder no abort para todos e recuperando estado dos objetos, seno:
Figura 30 Protocolo de finalizao 1 fase 2 fase commit (o coordenador manda uma mensagem para terminar a transao os participantes mudam o estado provisrio para o estado novo e liberam os locks) Tempo real time-outs (para locks e todas as transaes); priorizao das transaes; relaxamento da persistncia (usando eg. Memria RAM, EPROM). - time-outs - priorizao (processos leves).
RPC
SELECT Verifica o estado dos descritores para leitura, gravao e condues especiais .
36
37
Arquiteturas distribudas
Arquiteturas conjunto de agentes (mdulos) : os componentes da arquitetura
vias de comunicao entre os agentes
vias de controle entre os agentes - controle de execuo de agentes. - escalonamento de servios (tarefas trabalho, servio implementao atravs de processo ou funo)
relacionado atividade de resoluo do problema.
Arquiteturas (nveis)
estrutural - definio dos agentes; - vias de comunicao; - vias de controle. plano de controle/comunicao ( nvel de detalhamento como as aes de controle so tomadas, gerenciadas; e.g. como sair de um deadlock) 38
Nvel estrutural hierarquias vias de controle e comunicao formam uma rvore e um agente no nvel i
: * controla N agentes no nvel i+1; * comunica-se com n agentes no nvel i+1 e P agentes no nvel i-1.
Figura 31 - Hierarquias
heterarquias (no hierarquias) vias de controle e comunicao so indefinidas ou

dinmicas. Exemplo de hierarquia (no existe hierarquia pura em caso de emergncia, pode-se controlar/comunicar com nveis diferentes). O plano de controle/comunicao normalmente descrito em determinado nvel.
39
Figura 32 Heterarquia Exemplo de heterarquia
Figura 33 Exemplo de heterarquia
Plano de controle/comunicao BLACKBOARD (pool de dados) monitor; fila de escalonamento uma hierarquia(sic)
data oriented; memria passada com 2 BBs.
TIME ASSNCRONOS
eg. a) minimizar funes; b) caixeiro viajante.
40
CONTRACT NETS (MERCADOS/SERVIOS)
via RPC, por exemplo. 3 fases : - anncio do servio; - recebe propostas; - contrata (pode haver relao mais direta).
Modelo de Objetos
a nvel de linguagem de programao; a nvel de sistema (distribudo).
Utilizao de modelo de objetos Dispor de: gerenciador de objetos (Camelot); linguagem de programao concorrente ou distribuda (Avalon); sistema operacional (com linguagem de programao embutida) (Art, Amoeba).
Modelos de objetos classificao/instanciao; 41
Sistemas Distribudos herana; polimorfismo. eg. Print(...) /* p/quadrado, circulo, etc. */
Objetos So instncias de classes Classe um conjunto de atributos (que iro definir o estado do objeto) mais um conjunto de operaes (mtodos) envolvendo os atributos. Classe { char rd[16]; /* identificao do sensor */ double leitura; /* conjunto de atributos (pode haver dados pblicos */ float frequncia; /* no acessados s por operaes) */ int estado; .... int le_sensor(); /* conjunto de operaes (mtodos) */ double valor(); ... } sensor; sensor S1; S1.le_sensor(); Estrutura de objetos
Figura 34 Estrutura de objetos Granularidade dos objetos
42
Figura 35 Granularidade dos objetos Modelo de objeto para Sistema Distribudo objetos passivos no define mtodos so apenas dados no tm funes.
Figura 36 Modelos de objetos (objetos passivos) objetos ativos os mtodos possuem execuo autnoma
43
Figura 37 Modelo de objetos (objetos ativos) servidor de classes (XYZ atributos, derivados das classes wt ...) deve ser capaz de fornecer todos os atributos (mtodos) da classe para quando for criar instncias. Quando forem mtodos, passar ponteiros para o arquivo executvel (se fosse Lisp, passaria o prprio cdigo, pois difcil o tratamento de erros, por ex. com erros de compilao em C++).
Problemas Chamada de mtodos em paralelo manter a consistncia dos dados ( memria compartilhada 1 mtodo por vez, semforo, lock por regies, ...) 44
Interao inter-objetos Localizao do objeto - Identificador de objeto (Servidor de nomes, host + n do port que recebe RPC) <ID Global, Host, PORT> - nameserver (cache) - broadcast (cache) n ltimas sequncias.
Problema Gerenciamento de falhas (ocorre nas 2 extremidades quem chama e quem serve)
tme-out probing ( a cada intervalo de tempo, verifica se est ok).
Gerenciamento de recursos limitar o nmero de mtodos concorrentes por processo (eg. Definido na classe); manter objetos em disco - gerenciador cria processo para executar o objeto quando for referenciado e no estiver executando. escalonamento de objetos - onde criar objetos (em que host?) - onde for referenciado; - no host especificado na criao; - no host menos sobrecarregado (+difcil de implementar). migrao (geralmente s se migra dados e no processos) - no outro lado, cria-se um processo para abrigar o objeto, ou atravs de um gerenciador de objetos.
45
Figura 38 Gerenciamento de recursos
Modelo de objetos para tempo real
Figura 39 Modelo de objetos para tempo real
46
Temporizao
Problema : S.O. orientado para time-sharing (e.g. UNIX)
Figura 40 Ilustrao de processo de temporizao
Escalonamento baseado em prioridades (no ser prempted)

Mi : <Durao mxima> Mi : <Incio, Fim, perodo, deadline> Tratamento de prioridades associadas a clientes mtodos peridicos
Figura 41 Tratamento de prioridade associado a cliente
Estratgias para evitar a inverso de prioridade
47
Figura 42 Terminao forada
Figura 43 - Preempo Problemas de terminao forada e preempo : consistncia do estado do objeto Solues possveis : - objetos sem estado - transao
Figura 44 Herana de prioridade No existe problemas com a consistncia do estado, mas deve-se Ter meios de alterar a prioridade de processos em run-time.
Multi-Threaded Objects
48
Figura 45 Multi-Threades Objects Tratamento de excees
Figura 46 Tratamento de excees Inverso de prioridade no subsistema de comunicao
49
Figura 47 Inverso de prioridade no subsistema de comunicao Minimizao do problema :
Figura 48 Minimizao do problema da inverso de prioridade no subsistema de comunicao Servidores com processos leves
Monitoramento de Sistemas Distribudos
50
Dificuldade : estabelecimento de relao causa-efeito. Duas fases : - especificao (anlise esttica do S.D.) ex.: linguagem Estelle (ISO) como um processo reage a determinados eventos causados por outros processos. - monitoramento da execuo (verificao dinmica) tcnica : introduo de eventos no S.D. (mensagens, acesso a dados compartilhados, mudana de estado dos processos, etc). eventos : - comunicao - controle deve prover aos eventos : - apresentao (eg. display, print) - ordenao.
51
A WEB COMO SISTEMA DISTRIBUDO
Padro iniciado pelo CERN (Centre/Organisation Europenne pour la Recherche Nuclaire), sede em Genebra, o mesmo do Colisor de Hdrons (Tim Berners-Lee em 1989 e aperfeioado por Robert Cailliau em 1990). Desde 1994, a responsabilidade passou ao W3C (World Wide Web Consortium), uma colaborao entre o CERN e o MIT., e depois (2007) juntaramse o INRIA (Institut National de Recherche en Informatique et Automatique) e a Universidade de Keio, do Japo.
ARQUITETURA E PROCESSOS
Lado cliente: browser; proxy (inicialmente para permitir ao browser executar protocolos de aplicao diferentes do HTTP. Hoje, usado para filtrar requisies e respostas, entrar em sistemas, comprimir arquivos, e armazenar). Problemas com proxies (RFC 3143); Lado servidor: Presena grande de replicao: clusters com front end (dispatcher) para redirecionar requisies de clientes a uma das rplicas. Trs estratgias: o Distribuio de requisio por contedo: requisies para o mesmo documento ao mesmo servidor. Para no sobrecarregar o front end, um (outro) dispatcher repassa a conexo TCP ao servidor; o DNS de varredura cclica, onde um nico nome de domnio associado a vrios IPs. O Bind, servidor de DNS, por ex. move em crculo as entradas das listas de endereo ao enviar o RR Registro de Recursos; o Broadcast: o front end repassa a requisio a todos, que decidem em conjunto qual servidor ir atender a requisio.
COMUNICAO
Baseada em HTTP, que por sua vez baseado no TCP. HTTP 1.0: conexes no persistentes, i.e., cada requisio de cliente exigia o estabelecimento de uma conexo (RFC 1945); HTTP 1.1: conexes persistentes. Alm disso, o cliente pode enviar vrias requisies sem esperar resposta do servidor pipeline (RFC 2616);
52
HTTPS: autenticao do servidor e/ou cliente por criptografia assimtrica (RFC 2246, 3546); SOAP: para comunicao com servios (Web Services), baseada em XML (RFC 3076).
SINCRONIZAO
Poucos trabalhos em sincronizao. Autoria Distribuda de Documentos: feita atravs do protocolo WebDAV (Web Distributed Authoring and Versioning) (RFC 2291, 3744) : o lock de escrita exclusiva; o lock de escrita compartilhada (no h checagem de consistncia. Nesse caso, espera-se que os autores modifiquem partes diferentes do documento); o no h necessidade de manter a conexo entre cliente e servidor. Isso quer dizer que se o cliente com o lock cair, o servidor deve retomar o lock. Mas esse procedimento no especificado.
CACHING
Possibilidades (RFC 3040): cache compartilhada: resultados de consultas de um cliente repassados a outros clientes; cache hierrquica: seguindo a rvore de nomes (domnios). Alta latncia por verificar em vrios caches; cache distribudo: verifica nos proxies vizinhos ou repassa ao servidor Web caso no encontre; campo Time to Live do RR para endereos; get if-modified-since: dado pelo proxy ao servidor Web (get,post,delete); com replicao total: todo o documento mantido em cache (til se a taxa de atualizao for baixa); com replicao parcial; cache ciente de contedo: manuteno de um BD local com as tabelas mais usadas (para servidores de borda); cache alheia ao contedo: o servidor de borda calcula um valor de hash para a consulta, usado para armazen-la; estudos para documentos dinmicos. Estratgias LFU, LRU, funo.
53
REPLICAO
Dados requisitos de desempenho, disponibilidade e custo, importante estimar quantas rplicas so necessrias (muitas rplicas aumentam o desempenho, mas tambm o custo e a necessidade de banda) (RFC 3040). A replicao soluciona problemas que no podem ser resolvidos unicamente atravs dos caches, pela dificuldade desses armazenarem contedo no esttico, por exemplo. Assim, necessrio considerar: quantas rplicas sero instaladas; sua localizao; quando instalar novas rplicas, dinamicamente. Algumas mtricas para estimar: mtricas de latncia / tempo de resposta: baseadas nos tempos para realizar operaes, como recuperar documentos; mtricas de banda: medio de largura de banda disponvel entre dois ns; mtricas espaciais: baseadas em distncia, usualmente em nmero de hops; mtricas de utilizao de rede: largura de banda consumida; algoritmos de aprendizagem, que usualmente tomam por base resultados e decises anteriores (Baentsch); algoritmos de otimizao (Awerbuch). Acesso s rplicas gerao de rplicas por gerao de processos, que podem ser criados e disparados local (fork) ou remotamente (atravs de front end) (Rabinovich); polticas de redirecionamento o DNS de varredura cclica; o Polticas anteriores (ex. mtrica baseada em distncia); gerao de rplicas por previsor de multido instantnea (MI): uma MI uma rajada de requisies a um determinado documento.O previsor d tempo ao servidor Web para instalar novas cpias (usualmente baseados em mtodos de extrapolao); replicao parcial de servidores/dados, tal como em cache, mas por prazos mais longos.
COORDENAO
Algumas abordagens: coordenao direta: quando os processos esto online e podem ser acessados diretamente (via mensagens, por exemplo);
54
coordenao indireta: do tipo mailbox; coordenao por reunio: tambm sncrona, mas o acesso feito indiretamente, atravs de uma estrutura (mesa de reunies); o blackboard; o publicar/subscrever: os processos concordam em receber mensagens e as publicam. Podem permanecer annimos (SD: Jini/ Sist.Coodenao: JavaSpaces) o mercado. comunicao geradora: dados compartilhados com equipamentos mveis. Os processos tm espaos de dados prprios, que podem ser compartilhados por proximidade. Tambm possvel trocas mensagens multicast e associa-los a um grupo.
TOLERNCIA A FALHAS
Algumas abordagens (nenhuma RFC !!!): usualmente obtida atravs de replicao de servidores e caches, isto , por redundncia; problemas com invocao em nveis, como nos Web Services, onde servidores podem requisitar servios de terceiros. Uma soluo por replicao de chamadas, mas pode ser muito caro; tolerncia falhas bizantina: chegar a um consenso (por votao e maioria) pode exigir muitas chamadas a servidores e ser muito cara; mensagens multicast enviadas aos vizinhos para reconstruir dados perdidos.
SEGURANA
A abordagem predominante baseada em canais e transaes seguras (RFC 2084): camada de sockets seguros (SSL) (RFC 3207); protocolo de segurana na camada de transporte (TLS) (RFC 4346, 5246), como HTTPS.
55
Relgio Lgico
uma marca (nmero inteiro) associada a cada evento. Cada processo mantm um nico relgio lgico e adiciona o seu contedo aos eventos gerados pelo processo. Notao :
Protocolos para atualizao dos relgios lgicos

Tempo linear (relgio de Lamport) feita uma ordenao total (i, no se consegue determinar concorrncia entre eventos) hi : relgio lgico do processo i
Protocolo: R1 : Na produo de um evento pelo processo : hi = Hi + d (1). R2 : Quando o processo i recebe uma mensagem, ele atualiza o relgio: hi = max(hi,hmensagem) [e-executa R1] se a recepo de mensagem tambm for um evento
56
Figura 49 Diagrama representativo do processo de atualizao do relgio Propriedade : Se eventos no possuem relao causal, ento sua ordenao arbitrria ( o protocolo no diz se a ordenao foi casual ou no, o que pode ser desejvel). Tempo matricial mi[i,i] : relgio local ao processo i mi[k,l] : viso do processo i sobre o conhecimento que o processo k possui sobre a noo de tempo no processo l. R1 : Na produo de um evento pelo processo i mi[i,i] = mi[i,i] + d R2 : Quando o processo i recebe uma mensagem de j, o processo i atualiza o relgio: mi[i,k] = max(mi[i,k], mj[j,k]), mi[k,l] = max(mi[k,l],mj[k,l]), k,l=1,... N [e executa R1] Propriedade : Se min k (mi[k,i]) = t ento o processo i sabe que todos os processos esto informados que seu relgio atingiu t (pode descartar informaes antigas).
Relgios fsicos
57
Figura 50 Relgio fsico Ncleo de Aplicaes de tempo real Tendncia de padronizao do UNIX : IEEE POSIX interface (system calls) shell e ferramentas (eg. Correio eletrnico) procedimentos de testes (benchmarks) tempo real (em andamento) ADA Segurana Administrao Networking
O que recomendado pela IEEE: timers de alta resoluo escalonamento por prioridades memria compartilhada real time files (no buferizar writes, por ex.) semforos comunicao inter-processos notificao assncrona de eventos fixao de processos em memria I/O sncrono e assncrono (eg. Read no bloqueado)
58
Figura 51 Recomendao IEEE [SYSTEM CALLS:] O ncleo deve ser totalmente "preemptve" (seno inverso de prioridades) [Subsistema de Arquivos]
Figura 52 Subsistema de arquivos Representao interna de arquivos (por blocos) :
59
Figura 53 Representao interna de arquivos [Subsistema de Processos:]
Figura 54 Subsistema de processos Escalonamento Time sharing Prioridade : esttica)
F(CPU_utilizada,
recursos
consumidos,
prioridade
60
Figura 55 Subsistema de processos [Subsistema de Memria:] verses antigas (<system V; <4.2 BSD) : swapping
Figura 56 Subsistema de memria (Verses antigas) verses atuais : paginao por demanda
Figura 57 Subsistema de memria (Paginao por demanda) Melhoria :
61
Figura 58 Subsistema de memria (Melhoria)
Figura 59 Subsistema de memria Char *buff Buff = malloc (200) Char buff [200]; evita busca linear na lista Ao invs de 200, utilizar 500 pior caso. [Mecanismo de Interrupo:]
Figura 60 Mecanismo de interrupo Melhorias : Mecanismo de eventos (podem ser definidos tambm pelo usurio) 62
Figura 61 Mecanismo de eventos
Threads Uma thread conceitualmente um tipo de dados que representa um fluxo de controle. s threads deve ser associado um conjunto de operaes de manipulao, incluindo formas de controlar seu escalonamento e comunicao. Um processo leve representa uma thread de controle no intimamente ligado a um espao de endereamento. Threads normalmente podem executar mais rapidamente que processos normais. Isso porque sua comunicao se d atravs de memria compartilhada ao invs de sistema de arquivos. A disponibilidade de uso de processos leves prov uma abstrao adequada para a implementao de programas que rejam a eventos assncronos (como servidores, por exemplo). So adequados tambm para a implementao de programas de simulao que modelem situaes concorrentes. Pode-se considerar a abstrao de processos leves superior de sinais. No sistema Unix, por exemplo, um sinal ocasiona uma espcie de troca de contexto, para uma nova instruo, por exemplo, e as regies podem ser implementadas desabilitando interrupes. Com processos leves, a nica forma de tratar eventos assncronos atravs de threads. No existem excees assncronas em uma thread. Sees crticas so implementadas atravs de monitores, no havendo necessidade de travar interrupes, com a possibilidade de perda de informaes enquanto a regio crtica estiver sendo processada. Funcionalidade As bibliotecas referentes processos leves usualmente provem primitivas para manipulao de threads e controle de eventos em um processador. Vrias delas fornecem suporte apenas para processos a nvel de usurio. Nesses casos, a fatia de tempo alocada pelo sistema operacional a um processo deve ser compartilhada por todas as threads que pertencem quele processo. Alm disso, seus objetos no so acessveis fora desse processo.
63
Sistemas Distribudos Exemplos de primitivas que devem ser suportadas1:
Criao e destruio de threads, acesso a informaes de status, gerncia do escalonamento, suspenso e retomada da execuo; Multiplexao do relgio (vrios processos podem dormir concorrentemente); Mudana de contexto individualizada; Monitores e variveis de condio para sincronizao de threads; Extenso do conceito de rendez-vous (envio, recepo e resposta de mensagens) entre threads; Facilidades de manipulao de excees (ex. notificao e escape); Formas de mapear interrupes em rendez-vous; Formas de mapear traps em excees; Checagem de integridade de pilha, para ambientes onde no existam mecanismos sofisticados de gerenciamento de memria.
O escalonamento, por default, baseado em prioridade e no preemptivo dentro da mesma prioridade. Quando um conjunto de threads esto executando, assume-se que eles todos estejam compartilhando memria. Fundamentos de implementao O mecanismo de processos leves permite que vrias threads de controle compartilhem o mesmo espao de endereamento. Cada processo leve representado por um procedimento que ser convertido em uma thread atravs da primitiva lwp_create(). Quando uma thread criada, ela passa a ser uma entidade independente com sua prpria pilha. A primitiva lwp_create() aloca um contexto, inicializa uma pilha, e torna a thread pronta para ser chamada para execuo. Uma coleo de threads executam em um nico processo comum. Essa coleo denominada pod. Os processos leves ou threads so escalonados por prioridade. Assim, a thread no bloqueda de mais alta prioridade quem deve estar executando a cada momento. Elas pode bloquear em algumas circunstncias, como para a chegada de uma mensagem ou a requisio de um lock de monitor. Quando possurem a mesma prioridade, as threads executam com base na poltica FIFO (fila). Assim, se duas threads forem criadas com a mesma prioridade, elas devem executar na ordem de criao.
/* Programa que ilustra a criao de uma thread simples. Quando a thread main() termina, task() executa e termina tambm. A biblioteca de processos leves identifica que no h mais threads, e o processo termina. */ #include <lwp/lwp.h>
1
SunOS, em particular.
64
Sistemas Distribudos #include <lwp/stackdep.h> #define MAXPRIO 10 main(argc, argv) int argc; char *argv; { thread_t tid; int task(); printf(main here\n);
/* Transforma main() em um processo leve, e especifica a prioridade mxima de escalonamento. main() executa com prioridade 10, e prioridades 1..10 ficam disponveis. Assim, main() vai executar at que seja bloqueado ou passe o controle a outra thread. */ (void) pod_setmaxpri (MAXPRIO); /* Inicializa um cache de pilhas, a ser usado por futuras chamadas lwp_newstk(). Cada uma dessa chamadas dever retornar uma pilha de pelo menos 1000 bytes, sendo que o cache dever conter 2 pilhas. Muitas pilhas requerem mais memria, mas causam menos falhas de pilhas. No caso de falha, um cache de mesmo tamanho ser alocado. Quando uma thread morrer, sua pilha automaticamente liberada. */ lwp_setstkcache (1000, 2); /* Cria uma thread que iniciar sua execuo em task(), com prioridade 10 de escalonamentoe e usar o cache de pilhas. Sua identidade retornada em tid. */ lwp_create (&tid, task, MAXPRIO, 0, lwp_newstk(), 0); } task() { printf(hello world\n); }
O comando para compilar o programa o seguinte: cc o prog prog.c llwp Co-rotinas
65
possvel utilizar threads como co-rotinas puras, onde uma thread outorga explicitamente controle a outra. A primitiva lwp_yield() permite que uma thread aguarde uma thread especfica de mesma prioridade, ou a prxima thread de mesma prioridade.
/* Programa que ilustra o uso de 3 co-rotinas: main(), coroutine() e other(). O resultado a impresso dos nmeros de 1 a 7, em sequncia. */ #include <lwp/lwp.h> #include <lwp/stackdep.h> thread_t co1; thread_t co2; thread_t co3; /* identificador da thread principal */ /* identificador da coroutine */ /* identificador de other */
main(argc, argv) int argc; char ** argv[]; { int coroutine(), other(); lwp_self(&co1); lwp_setstkcache (1000,3); lwp_create (&co2, coroutine, MINPRIO, 0, lwp_newstk(), 0); lwp_create (&co3, other, MINPRIO, 0, lwp_newstk(), 0 ); printf (1\n); lwp_yield (THREADNULL); /* yield to coroutine */ printf (4\n); lwp_yield (co3); /* yield to other */ printf (6\n); exit(0); } coroutine() { printf (2\n); if (lwp_yield(THREADNULL) < 0) { lwp_perror (bad yield); return; } printf (7\n); } other()
66
Sistemas Distribudos { printf (3\n); lwp_yield (THREADNULL); printf (5\n); }
Escalonadores customizados H trs formas de prover controle de escalonamento ao cliente. A primeira no fazer nada, e prover ao cliente simplesmente um ponteiro para um contexto de thread que pode ser escalonada vontade dele. O grande empecilho deste mtodo que a maioria dos clientes no desejam construir seus prprios escalonadores. A segunda forma consiste em prover uma nica poltica de escalonamento, onde o cliente possui muito pouco controle sobre o que ser executado na seqncia. Um exemplo dessa poltica a sistema operacional Unix. Essa abordagem a mais simples do ponto de vista do cliente, mas torna difcil implementar polticas que levem em conta os diferentes tempos de resposta das threads clientes. A terceira forma consiste em prover primitivas que podem interferir na poltica de escalonamento padro, permitindo a construo de diferentes polticas de escalonamento. Exemplos de tais primitivas so lwp_suspend(), lwp_yield(), lwp_resume(), lwp_setpri() e lwp_resched(). A primitiva lwp_suspend() pode tambm ser utilizada em processos de correo de erros (debugging), para assegurar que uma thread tenha sido interrompida, antes de analis-la.
/* Exemplo de um programa que constri um escalonador roundrobin, time-sliced. Uma thread de mais alta prioridade atua como escalonador e dorme pelo quantum de tempo desejado. */ #include <lwp/lwp.h> #include <lwp/stackdep.h> #define MAXPRIO 10 main(argc, argv) int argc; char **argv; { int scheduler(), task(), i; (void) pod_setmaxpri(MAXPRIO); lwp_setstkcache (1000,5);
67
(void) lwp_create((thread_t *)0, scheduler, MAXPRIO, 0, lwp_newstk(), 0); for (i=1; i<3; i++) (void) lwp_create((thread_t *)0, task, MINPRIO, 0, lwp_setstk(), 1 , i); exit(0); } scheduler() { struct timeval quantum; quantum.tv_sec = 0; quantum.tv_usec = 10000; for(;;) { lwp_sleep(&quantum); lwp_resched(MINPRIO); } } /* Tarefas escalonadas round-robin, preempted */ task(arg) { for(;;) printf(task %d\n, arg); }
Trocas de contexto especiais Uma thread pode fingir estar executando sozinha em uma mquina, mesmo que vrias threads estejam executando. Isso pode ser realizado atravs de primitivas da biblioteca lwp.h. Essa biblioteca prov tambm trocas de contexto entre threads, que fazem com que recursos volteis de mquina sejam multiplexados, de forma que cada thread opere com seu prprio conjunto de recursos de mquina. Em muitos casos, uma troca de contexto somente requer que os registradores e a pilha sejam multiplexados. A biblioteca permite que as threads possuam quantidades diferentes de estados para que processos com necessidades diferentes de recursos possam coexistir. Uma thread possui tambm possui estados que podem ser modificados por outras primitivas. Esse estado privativo de cada thread inclui trocas de informaes na forma de mensagens. O espao disponvel para armazenamento desses estados bastante limitado, e somente as threads que necessitem de estados adicionais devem utiliz-los. Assim, no esto disponveis informaes como estados dos sinais, informao de accounting ou descritores de arquivos nesse contexto.
68
A biblioteca de threads aloca um novo buffer de contexto para cada novo contexto inicializado com uma thread, e disponibiliza um ponteiro para esse contexto para salvar e restaurar rotinas definidas nesse contexto. Para utilizar esse mecanismo de contexto, necessrio primeiro definir um contexto especial, atravs da primitiva lwp_ctxset(). Isso requer que sejam definidas as formas de salvar e restaurar os estados do contexto, atravs de procedimentos para isso. Uma vez que o contexto tenha sido definido, pode-se inicializar threads que utilizem o recurso multiplexado pelo contexto especial, usando a primitiva lwp_ctxinit(). A inicializao de uma thread que utilize um contexto especial pode ser feita diretamente ou, se os recursos permitirem, atravs de uma trap, quando o recurso for usado por uma thread pela primeira vez.
/* Programa que exemplifica a multiplexao e uso de recursos em threads. */ typedef struct libc_ctxt_t { int libc_errno; } libc_ctxt_t; static int LibcCtx; /* Permite contextos especiais em libc */ libcenable() { extern void libc_save(); extern void libcrestore(); LibcCtx = lwp_ctxset (libc_ctxt_t), TRUE); } (_libc_save, libcrestore, sizeof
/* Faz com que uma thread tenha o contexto libc */ lwp_libcset(tid) thread_t tid; { (void) lwp_ctxinit(tid, LibcCtx); } /* Rotinas para salvar/restaurar dados */
69
void _libc_save (cntxt, old, new) caddr_t cntxt; thread_t old; thread_t new; { extern int errno; #ifdef lint old=old; new=new; #endif lint ((libc_ctxt_t *)cntxt)-> libc_errno = errno; } void _libc_restore (cntxt, old, new) caddr_t cntxt; thread_t old; thread_t new; { extern int errno; #ifdef lint old = old; new = new; #endif lint errno = ((libc_ctxt_t *) cntxt) -> libc_errno; }
70
Referncias bibliogrficas 1. Networking Programming- Manual da SUN. 2. BALL,H.E., STEINER,J.G., TANEMBAUM,A.S. Programming Languages for Distributed Computing Systems, ACM Computing Servers, vol 21 n 3, Set. 1989. 3. COULOUNS,G.F., DOLLEMORE, J. Distributed Systems Concepts and Design, 1988. 4. FURTH, B. et al, KLUWER. Real Time Unix Systens, Academia Publisher, 1991. 5. J.E.B. MOSS. Nested Transactions Na Approach to Realiable Distributed Computing, MIT Press, 1989. 6. LAMPORT, L. Time. Clocks and the Ordering of Events in a Distributed System, Communication os the ACM, Vol. 21, n 7, Julho 1978. 7. NITZBERG,B.& LO,V. Distributed Shared Memory. A servey and Algorithms, IEEE Computer, Agosto 1991.
71
8. SILBERSCHATZ, A. PETERSON, J. GALVANI, P. Operating Systems Concepts, 3 ed, Addison-Westey, 1991. 9. STUM,M.& ZHOW,S. Algorithims Implementing Distributed Shared Memory, IEEE Computer, Maio 1990. 10. TANEMBAUM, Peterson. Livros de SO.
72

Apostila - SD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila - SD

Transféré par

Droits d'auteur :

Formats disponibles

SISTEMAS

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Figura 01 Sistema fracamente acoplado Sistema distribudo fortemente acoplado

Figura 02 Sistema fortemente acoplado

Granularidade do sistema distribudo (gro de paralelismo)

Prof. Dr. Gilberto Nakamiti

maximizar tempo de processamento de uma tarefa t para redes tempo de comunicao

Sistema distribudo fracamente acoplado (SDFA)

Motivao para o desenvolvimento de SDFA

Figura 03 Ligao ponto a ponto

. compartilhamento de informao (multiponto)

Figura 04 Ligao multiponto

Prof. Dr. Gilberto Nakamiti

Dificuldades para o desenvolvimento de SDFA

a unidade de escalonamento que possui um conjunto prprio de recursos.

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Figura 06 Comunicao segundo o modelo OSI-ISO

Tecnologias (tipos) de redes

Prof. Dr. Gilberto Nakamiti

Sistemas Distribudos IEEE 802.5

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Figura 10 Topolgia em anel utilizando concentrador

Prof. Dr. Gilberto Nakamiti

Comunicao interprocessos Troca de mensagens

Prof. Dr. Gilberto Nakamiti

P2 int j; char buff[20]; recebe b; sscanf(b,%d,&j); Troca de mensagens no UNIX

Local ao processo Global na mquina

default_Tcp/Ip int s; domnio datag./stream s = socket ( AF_INET , SOCK_DGRAM , 0 ) SOCK_STREAM

Atribuio/Associao (Binding) de nomes. Nmero de ports so inteiros BIND (s, ...)

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Mapeador de Portas (Portmapper)

Forma de Comunicao entre Processos

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Aumento de Desempenho do Mapeador

Prof. Dr. Gilberto Nakamiti

Chamadas de procedimentos remotos (RPC)

Figura 13 Chamada de procedimento remoto (RPC)

Transparncia das chamadas

Prof. Dr. Gilberto Nakamiti

Registro de procedures (servios)

Prof. Dr. Gilberto Nakamiti

Figura 15 Registro de procedures

Exemplo : um servio de nmeros globais.

Prof. Dr. Gilberto Nakamiti

cria_mb(XYZ,tipo,limites,usurios); ch=acessa_mb(XYZ); port_mb(ch,msg); get_mb(ch,&msg); destri_mb(ch);

Prof. Dr. Gilberto Nakamiti

Memria distribuda com replicao de dados

Sistemas Distribudos b2) migra cpia mestre. b3) grava. Vantagens : -

Prof. Dr. Gilberto Nakamiti

Desvantagens : complexidade na manuteno da consistncia.

Prof. Dr. Gilberto Nakamiti

Comunicao por compartilhamento de dados

Desvantagens : velocidade de comunicao; controle de acesso (e.g. problemas de corrida- transao ). 23

Prof. Dr. Gilberto Nakamiti

Compartilhamento de dados em sistemas distribudos

Implementao de memria compartilhada em SD atravs de processos

Figura 19 Implementao de memria compartilhada atravs de processos memria centralizada