Escolar Documentos
Profissional Documentos
Cultura Documentos
Distribuda
Fabio Mascarenhas
4 de julho de 2005
Introduc
ao
A Linguagem Oz
{NewCell foo C}
{Exchange C X1 bar}
{Exchange C X2 foo|bar}
{Access C X3}
end
A segunda linha do exemplo cria uma nova celula C, e atribui o valor foo
a ela (um atomo, uma string imutavel e u
nica no sistema). A linha seguinte
atribui o valor bar `a celula, e faz a variavel X1 assumir o valor anterior
(foo). A quarta linha faz uma nova atribuicao `a celula. Agora ela tem a
lista foo|bar como valor, e a variavel X2 assume o valor bar. Finalmente, a
u
ltima linha faz X3 assumir o valor corrente da celula.
Os outros elementos de Oz sao definidos em funcao desses elementos
basicos (variaveis e celulas), embora sua implementacao nao seja feita dessa
maneira, por razoes de eficiencia. Objetos sao uma funcao com apenas um
parametro, a mensagem (chamada de metodo) para esse objeto. A closure do
objeto faz referencia a celulas que guardam o estado do objeto. Os metodos
sao procedimentos que recebem uma referencia para o estado do objeto e a
mensagem. Classes sao um registro (um dos tipos imutaveis de Oz) contendo
a tabela de metodos e atributos, usados para construir o objeto.
A linguagem tem syntactic sugar para facilitar a criacao e uso de classes
e objetos, como mostrado no trecho a seguir:
class Counter
attr i
meth init i <- 0 end
meth inc i <- @i + 1 end
meth get(X) X = @i end
end
Obj = {New Counter init}
{Obj inc}
{Print {Obj get($)})
Outro elemento derivado sao as travas reentrantes, usadas para exclusao
m
utua. Elas tambem sao funcoes de um parametro, mas recebem uma funcao
sem parametros que define a secao crtica. A trava e reentrante pois uma
thread que possui a trava pode chama-la novamente sem problemas. Internamente (em sua closure) a funcao da trava mantem uma estrutura uma celula
a qual ela atribui uma variavel indefinida antes de entrar na secao crtica,
e espera ate o valor antigo dela ficar definido (a celula e inicializada com
3
um valor definido e u
nico). Saindo da secao crtica ela define a variavel que
associou anteriormente `a celula, liberando a proxima thread da sequencia.
Portas, canais assncronos para troca de mensagens entre threads, sao
mais um elemento da linguagem Oz. Uma porta encapsula uma lista cuja
cauda e uma variavel nao definida. Mandar uma mensagem para a porta
define essa variavel e aumenta a lista com mais uma variavel nao definida.
Ler a porta e ler a cauda da lista, o que faz a thread bloquear ate chegar
uma nova mensagem.
Acrescentando Distribui
c
ao a Oz
Valores (n
umeros, registros, listas, funcoes), variaveis e celulas sao as entidades basicas da linguagem Oz, com outras entidades como objetos, travas
e portas sendo compostas a partir destas entidades basicas. Mozart, portanto, acrescenta distribuicao `a linguagem Oz definindo o comportamento
distribudo de cada uma dessas entidades basicas. Cada uma das tres tem
um comportamento especfico, e um protocolo que o implementa.
Valores tem o protocolo mais simples: como sao imutaveis, sao copiados
toda vez que passam de um no a outro, e nao ha necessidade de nenhum
protocolo para manter a sua consistencia. O comportamento distribudo
das threads tambem e simples: elas nao podem ser transmitidas de um no
para o outro (a mobilidade de codigo em Mozart se restringe a funcoes). O
comportamento distribudo das outras entidades do sistema, e os protocolos
que o iplementam, sao o topico das proximas secoes.
3.1
Vari
aveis
Uma variavel em Oz tem dois estados bem distintos: ou nao esta definida,
e aguardando uma atribuicao que a defina, ou ja foi definida e nao pode
mais ser mudada. Na primeira vez que uma variavel nao definida e passada
para outro no, o sistema Mozart cria um manager para a variavel nesse
no, e substitui a referencia pra variavel por uma referencia para um proxy,
que por sua vez referencia o manager. Outro proxy e criado no no destino,
tambem com uma referencia para o manager. O sistema cria um novo proxy
sempre que uma variavel nao definida chega a um novo no, e todos os proxies
referenciam o mesmo manager.
A Figura 1 mostra o caso em que uma variavel nao definida foi mandada
para outros dois nos, e o protocolo que acontece quando o no 2 faz uma
atribuicao a ela. Essa atribuicao e enviada para o manager, que a aprova
e manda o novo valor da variavel para todos os nos. Isso nao e mostrado
4
No 1
No 2
3
P
1
2
3
4
2
3
No 3
4
Thread faz a atribuiao e bloqueia
Proxy envia atribuiao para o manager
Manager autoriza atribuiao e envia o valor para os proxies
Proxy passa o valor para a thread, que reinicia
Figura 1: Atribuicao a uma variavel
3.2
C
elulas e Objetos
Uma celula pode mudar de valor diversas vezes, e todos os nos que a referenciam devem ter uma visao consistente do valor atual da celula. Uma maneira
de se implementar esse comportamento seria manter o valor da celula em um
u
nico no, e fazer que todos os outros nos acessem a celula atraves dele. Isso
e basicamente o que Mozart faz, com uma mudanca: uma operacao de troca
de valor faz a celula migrar do no onde esta para o no que esta efetuando
a troca. A razao para isso e uma aposta de que o no que esta fazendo a
mudanca fara outras operacoes na celula em breve, e essas operacoes serao
mais rapidas se a celula estiver armazenada localmente.
Como uma variavel, uma celula sendo exportada pela primeira vez para
outro no faz o sistema Mozart criar um manager no no de origem, e substituir
as referencias diretas pra celula por referencias para proxies. O proxy do no
onde a celula esta tem uma referencia para ela. A partir da, exportar a
celula para outros nos implica na criacao de novos proxies para ela, em cada
um dos nos. Todos esses proxies tem uma referencia para o manager.
As Figuras 2 a 4 mostram o progresso de uma operacao de troca do
valor de uma celula. A Figura 2 mostra a situacao antes da execucao do
protocolo. Um pedido de troca feito pela thread T faz com o que o proxy
P c2 mande uma mensagem ao manager M c pedindo o valor de celula. O
5
Pc1
{Exhange C X Y}
Mc
Pc2
Valor 1
Valor 2
(a) Get
(b) Forward
Pc1
Mc
(c) Transfer
Valor 1
Pc2
Valor 2
Pc1
Mc
Pc2
Valor 1
Valor 2
Valor 1 X
Coleta de Lixo
Managers e proxies sao criados automaticamente toda vez que uma variavel
ou celula e referenciada remotamente. O sistema precisa ter uma maneira de
detectar quando as referencias remotas nao estao sendo mais usadas, para
que os proxies e managers sejam apagados e o as variaveis e celulas voltem a
ser apenas locais.
A deteccao e feita atraves de um algoritmo de contagem de referencias, em
que cada entidade ganha um dado n
umero de creditos quando fica disponvel
para outros nos. Os creditos sao distribudos entre os nos que a recebem,
7
e esses nos por sua vez distribuem parte dos creditos que receberam para
outros nos, quando repassam as entidades. Quando uma entidade e coletada
pelo coletor de lixo local, os creditos sao mandados de volta para o no onde
a entidade foi criada. Quando esse no recebe todos os creditos de volta e
porque a entidade nao tem mais referencias remotas, e o manager e coletado.
Se a entidade for exportada de novo outros managers e proxies sao criados,
independente dos anteriores.
Como todo mecanismo de contagem de referencia, esse mecanismo nao
funciona no caso de referencias cclicas entre celulas de diferentes nos. Nesse
caso o controle tem que ser feito pelo proprio programador, quebrando o ciclo
quando quiser que as celulas sejam coletadas.
Outras Quest
oes
O estabelecimento das conexoes iniciais entre nos e feito por meio de tquetes.
Um tquete e uma representacao textual de uma referencia remota. Eles podem ser um-pra-um, validos apenas para uma conexao, ou um-para-muitos.
Uma vez que um no consegue ma referencia para uma entidade em outro
no, outras podem ser obtidas pelas construcoes normais de linguagem Oz (a
referencia inicial pode ser para um objeto que retorna outros nas chamadas
a seus metodos, por exemplo).
Os protocolos apresentados acima nao funcionam bem na presenca de
falhas. A sua implementacao real e diferente, de modo a ser mais robusta
em caso de falha de nos (especialmente o que contem o manager). O programador tem liberdade para mudar o comportamento padrao do sistema
quando encontra uma falha, atraves da instalacao de handlers, chamados em
caso de falha da entidade para qual o handler foi instalado, durante alguma
operacao nessa entidade, e de watchers, que detectam falhas em entidades
mesmo quando nenhuma operacao esta sendo feita.
Finalmente, ha a questao de seguranca. No aspecto de seguranca da
linguagem, a linguagem Oz nao permite forjar referencias (e o sistema Mozart
nao permite forjar tquetes). O escopo lexico junto com funcoes como valores
de primeira classe permite a criacao facil de sandboxes que limitam o acesso a
determinados recursos. A maquina virtual nao faz uma checagem da validade
dos bytecodes, entretanto, o que e problematico em um sistema que permite a
transmissao de codigo. Mas uma solucao para esse problema seria ortogonal
ao resto do sistema, e nao afetaria o funcionamento dele. O mesmo vale para
seguranca no nvel da comunicacao entre os nos: nada impede que o sistema
seja modificado para usar conexoes seguras entre os nos.
6.1
Java RMI
6.2
Voyager
6.3
Erlang
Refer
encias
[1] DKFI. Oz Versao 2, 1996. Available at http://www.ps.uni-sb.de/
oz2/.
[2] Ericsson. Open Source Erlang, 2005. Available at http://www.erlang.
org.
11
12