Apostila+ SD PDF

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)
aplicaes hard-real-time
(aplicaes militares, ...)

- sistema operacional para tempo real com
capacidade de servios - comunicao intertarefas inter-hosts
Tarefa
Tarefa um processo.
Processo
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
Aplicao
Camada 6
Apresentao
Camada 5
Sesso
Camada 4
Transporte
Camada 3
Rede
Camada 2
Enlace
Camada 1
Fsica
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.
cannica
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;
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
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
(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).
Global
na
mquina
Local ao
processo
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).
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
- cria socket
- bind
- send
} aguarda resultado
- receive
- close socket
Servidor
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
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
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
-
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
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
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
-
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).
RPC
- time-outs
- priorizao (processos leves).
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
-
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>
mtodos peridicos
Tratamento de prioridades
-
associadas a clientes
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
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
#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. */
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
{
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. */
#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 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila+ SD PDF

Enviado por

Direitos autorais:

Formatos disponíveis

SISTEMAS

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Figura 01 Sistema fracamente 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

Sistema distribudo fracamente acoplado (SDFA)

Motivao para o desenvolvimento de SDFA

custo dos processadores tradicionais (ex.: estaes de trabalho PCs);

- promover (fazendo uso de hardware e software):

Figura 03 Ligao ponto a ponto

. compartilhamento de informao (multiponto)

Figura 04 Ligao multiponto

Prof. Dr. Gilberto Nakamiti

controle entre tarefas

Dificuldades para o desenvolvimento de SDFA

O que controla cada HOST

- sistema operacional com capacidade de

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Prof. Dr. Gilberto Nakamiti

Figura 06 Comunicao segundo o modelo OSI-ISO

Tecnologias (tipos) de redes

Prof. Dr. Gilberto Nakamiti

Figura 07 Topologias de redes

Figura 08 Frame Ethernet

Prof. Dr. Gilberto Nakamiti

Figura 09 Frame Token Ring

Prof. Dr. Gilberto Nakamiti

Figura 10 Topolgia em anel utilizando concentrador

Figura 11 Mecanismos de comunicao

Prof. Dr. Gilberto Nakamiti

PORT : um recurso utilizado para o envio e recepo de mensagens.

seletiva (transmissor (remetente) especificado); [ack] [ confirmation]

Pode ser sncrona ou assncrona.

cpia de memria (ns homogneos mesma arquitetura (representao) Tempo real)

Prof. Dr. Gilberto Nakamiti

(para dados bsicos)

uma generalizao do conceito de port. um recurso utilizado tambm para o envio

Prof. Dr. Gilberto Nakamiti

Figura 12 Atribuio do port.

listen (systemcall) torna um soquete passivo.

Prof. Dr. Gilberto Nakamiti

Representao cannica de dados

Prof. Dr. Gilberto Nakamiti

Mapeador de Portas (Portmapper)

Funes de Registro: fazem a insero ou deleo de um servio na tabela de

Funes de Pesquisa: procuram na tabela de controle do mapeador o servio

Forma de Comunicao entre Processos

Prof. Dr. Gilberto Nakamiti

Para a implementao do presente trabalho foi escolhida a forma de datagramas pela

Verificao de Servidor Ativo: procura reduzir a complexidade mencionada no

Informao do Cliente: ao receber uma informao invlida (servidor que no mais

Prof. Dr. Gilberto Nakamiti

Ativao do Servidor pelo portmapper: o proprio mapeador, ao receber um pedido

Aumento de Desempenho do Mapeador

Armazenamento em cache local, onde se faria a consulta ao mapeador apenas

Replicao dos mapeadores em todas as mquinas, cujas vantagens seriam a rapidez

A transformao do mapeador em um servidor de RPC, no qual, ao ser recebida

Prof. Dr. Gilberto Nakamiti

Chamadas de procedimentos remotos (RPC)