Disciplina: Sistemas Distribudos

AULA 10 Sincronizao em SDs

Um aspecto muito importante associado a comunicao em SDs a sincronizao e cooperao que existe entre os processos. Dentre os principais problemas a destacar podemos citar: como as regies crticas so implementadas em um SD ou como os recursos so alocados aos processos. Como foi visto em SO, em sistemas monoprocessados os problemas de excluso mtua e regio crtica so solucionados atravs de semforos ou monitores. Tais mtodos utilizam memria compartilhada para implementar a soluo, portanto, impossvel de ser feito em um SD. Logo, como promover a sincronizao em um ambiente distribudo?

Sincronizao atravs de CLOCK

Uma das maiores dificuldades em estabelecer algum tipo de sincronismo em um sistema distribudo reside no fato destes sistemas utilizarem algoritmo distribudo na implementao de servios e aplicaes. Geralmente no possivel, ou desejvel, ter todas as informaes sobre o sistema em um nico lugar (desta forma a deciso poderia ser feita da mesma forma que nos Sistemas Centralizados). Os algoritmos distribudos apresentam as seguintes propriedades: * As informaes relevantes so espalhadas pelas mltiplas mquinas; * Os processos tomam as decises baseadas somente em informaes locais; * Um ponto de falha que paralise todo o sistema deve ser evitado; * No existe relgio comum ou um tempo global.

Clocks Lgicos
Em Lamport (1978) - Time, Clocks, and the Ordering of Events in a Distributed System ele mostra que a sincronizao dos relgios possivel e apresenta o algoritmo para se conseguir isto. Posteriormente, em outro artigo ele defende que a sincronizao dos clocks no precisa ser absoluta, pelos seguintes motivos: 1. Se dois processos no interagem, no necessrio que seus clocks sejam sincronizados (no observvel).

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos 2. Usualmente o que importa no que todos os processos concordem com o exato tempo em que os eventos aconteceram, mas que concordem na ordem em que os eventos ocorreram. * Clock Lgico - consistncia interna o que importa e no quanto eles esto prximos do tempo real. * Clock Fsico - os clocks no podem diferir do tempo real mais que um determinado valor.

Algoritmo de Lamport Lamport definiu a seguinte relao: acontece-antes: a --> b (a acontece antes de b) Significa que todos os processos concordam que primeiro o evento a ocorreu e depois disto, o evento b ocorreu. Esta relao pode ser observada em duas situaes: 1. Se a e b so eventos no mesmo processo, e a ocorre antes de b, ento a--> b verdadeiro 2. Se a o evento de uma mensagem sendo enviada por um processo, e b o evento da mensagem sendo recebida por outro processo, ento a--> b tambm verdadeiro. Uma

mensagem no pode ser recebida antes de ser enviada, ou no mesmo tempo em que foi enviada. A relao acontece-antes transitiva, logo: se a--> b e b--> c, ento a--> c Se dois eventos x e y, acontecem em diferentes processos que no trocam mensagens, ento x--

>y no verdadeiro, nem y-->x verdadeiro. Estes eventos so ditos concorrentes, o que significa que nada pode ser dito sobre quando eles aconteceram. Precisamos de um modo de medir o tempo de tal forma que para todo evento a, ns podemos assumir que ele aconteceu em um tempo C(a) no qual todo processo concorda. Se a-->b, ento C(a) < C(b).

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos

Viso de Trs Processos

0
0 6 12 18 24 30 36 42 48 54 60

1
0 8 16 2 4 32 40 48 56 64 72 80

2
0 10 20 30 40 50 60 70 80 90 100

Figura 1. Processos com clocks em freqncias diferentes. O que acontece de estranho entre as trocas de mensagens? Para fazer as correes necessrias o tempo de relgio C precisa sempre ser incrementado (nunca decrementado). Por exemplo, uma vez que C deixa sua mq uina no tempo 60 ele deve chegar na mquina destino no tempo 61 ou mais tarde. Assim, quando uma mensagem chega ao destino, o receptor verifica o tempo que a mensagem traz consigo referente ao tempo de origem e, com isso, o receptor adianta seu clock de modo a torn-lo uma unidade maior que o instante da transmisso.

0 6 12 18 24 30 36 42 48 70 76

0 8 16 24 32 40 48 61 69 77 85

0 10 20 30 40 50 60 70 80 90 100

Figura 2. Algoritmo de Lamport para solucionar o problema.

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos Dessa forma, podemos utilizar o algoritmo de Lamport para atribuir tempos a todos os eventos em um SD, com as seguintes condies: 1. se a ocorrer antes de b no mesmo processo, ento C(a) < C(b). 2. se a e b so o envio e a recepo de uma mensagem, ento C(a) < C(b). 3. para quaisquer eventos a e b, C(a) ? C(b).

Clock Fsico
Em alguns sistemas (tempo-real por exemplo) um clock real importante. Nestes sistemas necessitamos de clocks fsicos externos. Por motivos de eficincia e de redundncia, desejvel que se tenha mais de um clock externo, o que causa os seguintes problemas: como sincroniz-los com o clock de tempo real e como sincronizar estes clocks entre si.

Algoritmos de Sincronizao de Relgios

Algoritmo de Cristian (1989) Para sistemas com uma mquina com receptor de UTC (Tempo Universal Coordenado base de todos os sistemas de medida de tempo civil adotados atualmente). A mquina que tem o receptor UTC chamada Servidor de Tempo.

Periodicamente, cada mquina envia uma mensagem para o Servidor de Tempo perguntando pelo tempo corrente (atual). Esta mquina responde o mais rpido possvel com uma mensagem contendo o tempo corrente Cutc.

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos

Algoritmo de Cristian

Adquirindo o tempo corrente do Servidor de Tempo T0 Requisio

Tempo

Cutc T1 Mquina Transmissora

Tempo de manipulao (I) da interrupo

Servidor de Tempo

T0 e T1 so medidos com o mesmo clock Tempo de Propagao da Mensagem (TP) TP = (T1 - T0)/2 No entanto, a estimativa pode ser melhorada considerando o tempo de manipulao da interrupo I: TP = (T1 - T0 - I)/2

Algoritmo de Berkeley (1989) - nenhuma mquina tem um receptor UTC Servidor de Tempo ativo, e requer, periodicamente de cada mquina, o tempo do seu relgio (estratgia oposta a proposta por Cristian). O Servidor de Tempo calcula a mdia dos tempos (considerando o tempo dele mesmo) e diz para cada mquina como ajustar seu relgio para ter seu tempo igual a mdia calculada.

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos

Algoritmo de Berkeley
3:00 +25 3:00 -10 -20 3:05 +15

3:25

2:50

3:25

2:50

3:05

3:05

Excluso Mtua - Algoritmo Centralizado A melhor maneira de se conseguir excluso mtua em um sistema distribudo imitar o que feito no sistema centralizado (com um nico processador): 1. Um processo eleito como Coordenador. Quando um processo quer entrar na regio crtica, ele envia uma mensagem requisitando ao Coordenador permisso para isso. 2. Se nenhum outro processo est na regio crtica, o coordenador envia uma resposta dando permisso. Ao receber a mensagem o processo requisitante entra na regio crtica. Supondo que outro processo pea permisso para entrar na regio crtica, e o Coordenador sabendo que outro processo est na regio, no envia resposta bloqueando este processo at que ele possa entrar na regio. Uma outra opo enviar uma mensagem negando a solicitao. Por fim, quando o processo deixa a regio, ele envia para o Coordenador uma mensagem liberando a regio crtica.

Excluso Mtua (Algoritmo Centralizado)

0
requisio

1
OK

1
requisio

2
OK

Nenhuma liberao Resposta

2
Coordenador Fila Vazia

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos Excluso Mtua - Algoritmo Distribudo Algoritmo centralizado tem o problema de uma falha no Coordenador inviabilizar o mecanismo. Algoritmo distribudo - Quando um processo quer entrar na regio crtica, ele constri uma mensagem contendo o nome da regio, nmero do processo e o tempo corrente. Ele envia a mensagem para todos os outros processos. Quando um processo recebe uma mensagem de requisio de outro processo sua ao vai depender de sua situao relativa a regio crtica: 1- Se o receptor no est na regio crtica e no quer entrar, ele envia de volta uma msg OK; 2- Se o receptor j est na regio, ele no responde e coloca a requisio na fila; 3- Se o receptor quer entrar na regio crtica mas ainda no o fez, ele compara o tempo da msg que chegou com o tempo da msg que ele enviou para os outros processos. O menor tempo vence. Se a msg que chegou menor ele envia de volta uma msg com OK. Se a sua msg tem o menor tempo ele coloca na fila a requisio que chegou e no envia nada. Aps pedir permisso um processo espera at que todos tenham dado a sua permisso. Quando todas as permisses chegam o processo pode entrar na regio crtica. Quando ele sai da regio crtica, ele envia uma msg OK para todos os processos na sua fila.

Excluso Mtua (Algoritmo Distribudo)

8 0 8 8 1 12 2 12 1
OK

Entra na Regio Crtica 12 0

OK OK

0
OK

2 Entra na Regio Crtica

Qual o problema deste algoritmo?? (Agora existe n pontos de falha)

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos Algoritmo Token Ring construido um anel lgico por software no qual a cada processo atribuido uma posio no anel. Quando o anel inicializado, o processo 0 ganha o token. O token circula no anel (passa do processo k para o k+1). Quando o processo ganha o token ele verifica se ele quer entrar na regio crtica. Caso positivo, ele entra na regio, realiza o seu trabalho e ao deixar a regio passa o token para o elemento seguinte do anel. No permitido entrar em uma segunda regio crtica com o mesmo token. Se o processo no quer entrar na regio crtica ele simplesmente passa o token. Como consequncia quando nenhum processo quer entrar na regio crtica o token fica circulando pelo anel. Problemas: 1. Se o token perdido ele precisa ser regenerado. A deteco de um token perdido dificil. 2. Se um processo falha tambm ocorrem problemas. A soluo fazer o processo que recebe o token confirmar o recebimento. O processo que falhou pode ser retirado do anel, e o token enviado para o processo seguinte. Essa soluo requer que todos os processos conheam a configurao do anel.

Algoritmo Token Ring

Processos 0 2 4 9 7 1 6 5 8 3

1 0 9 8

3 token 4

5 7 6

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos

Comparao dos Algoritmos

Algoritmo Mensagens p/ entrar e sair da RC Atraso Problemas

Centralizado

3 2(n-1)

2 2(n-1) 0 a n-1

Falha do Coordenador Falha de qualquer processo

Distribuido

Token Ring 1 a infinito

Perda do Token

Algoritmo de Eleio Muitos algoritmos distribudos requerem um processo como coordenador. Em geral no importa qual seja o processo coordenador, mas um deles inequivocamente tem que exercer esta funo. Algoritmo do Ditador (Garcia e Molina 1982) Quando um processo nota que o coordenador no est respondendo a uma requisio, ele inicia uma eleio. A eleio convocada por um processo P da seguinte forma: 1- P envia uma mensagem de ELEIO para todos os processos com nmeros maiores que o seu; 2- Se nenhum responde, P ganha a eleio e se torna coordenador; 3- Se um processo com nmero maior responde, ele assume a coordenao. Quando um processo recebe uma mensagem de ELEIO de um processo de menor nmero, ele envia uma mensagem OK de volta indicando que ele vai tomar o comando. Depois disso ele inicia uma eleio. Eventualmente todos os processos abandonam a disputa, com exceo de um que o novo coordenador. Ele envia uma mensagem a todos os processos avisando que o novo coordenador. Se um processo que estava fora do ar volta, ele inicia uma eleio. Caso ele seja o processo ativo de nmero mais alto rodando no sistema, ele ganha a eleio e assume a coordenao.

_ Prof. Dr. Jean M. Laine

Disciplina: Sistemas Distribudos Transaes Atmicas (Atomic Transactions) O controle de excluso mtua obtido com o uso dos semforos, por exemplo, essencialmente de baixo nvel e, muitas vezes, incmodo para o programador. O desejvel utilizar um nvel de abstrao mais alto que permita que o programador se concentre apenas no algoritmo da aplicao. Pensando nisso criou-se o que chamamos de transao atmica (tudo-ou-nada). Imagine que um processo anuncie que quer comear uma transao com um ou mais processos. Eles executam varias operaes (criar e apagar objetos) por um certo periodo de tempo. Ento o processo que iniciou a negociao anuncia que quer que todos os outros confirmem (commit) o trabalho feito at ento. Se todos concordam o trabalho feito se torna permanente. Se um ou mais processos se recusam (ou falham), a situao revertida para o estado em que todos estavam antes da transao comear. Este procedimento chamado de propriedade do tudo-ou-nada e facilita o trabalho do programador. Exemplo: Retirada de dinheiro de uma conta bancria e depsito em outra usando um PC com um modem. Operao em dois passos: 1- Retirar (quantia, conta1) 2- Depositar (quantia, conta2) Se a conexo cair depois do primeiro passo, mas antes do segundo, como consequncia teremos o desaparecimento do dinheiro. O problema resolvido agrupando os dois passos em uma transao atmica. Ou os dois passos so completados ou nenhum deles ser executados. Se a transao falhar o sistema restaura o estado inicial. Primitivas da Transao Atmica 1- BEGIN_TRANSACTION - Marca o inicio da transao. 2- END_TRANSAAO - Termina a transao e tenta confirmao (commit). 3- ABORT_TRANSACTION - Interrompe a transao restaurando os valores antigos. 4- READ - L dado de um arquivo ou de qualquer outro objeto. 5- WRITE - Escreve dado em um arquivo ou qualquer outro objeto.

_ Prof. Dr. Jean M. Laine

10

Disciplina: Sistemas Distribudos Propriedades das Transaes Atmicas Quatro propriedades essenciais: 1- Atomicidade - Para o ambiente externo, a transao acontece de forma indivisvel; 2- Consistncia - A transao no viola nenhuma invariante do sistema; 3- Isolamento - transaes concorrentes no interferem umas com as outras; 4- Durabilidade - Uma vez que a transao efetivada (commit), a mudana permanente. Estas propriedades so geralmente referenciadas pelas suas iniciais - ACID Implementao Questo: Como implementar as transaes atmicas? 1- Espao de Trabalho Privado Quando um processo comea uma transao, ele recebe um espao privado contendo todos os arquivos e demais objetos que ele tem que acessar. At o momento em que a transao se complete tudo o que o processo l ou escreve vai para esta rea de trabalho privada. O problema com este procedimento que o custo de copiar tudo para a rea privada geralmente proibitivo; entretanto, algumas otimizaes so possveis, por exemplo: quando um processo s l um arquivo no necessrio fazer uma cpia; em vez de copiar o arquivo todo, somente os indices do arquivo so copiados na rea privada. 2- Escrevendo um log (lista de intenes) Os arquivos so realmente modificados, mas antes de qualquer bloco ser modificado registrada, em um armazenamento estvel, a transao que est fazendo mudana; que arquivo e bloco esto sendo modificados; e os valores velho e novo. Se a transao abortar, o log pode ser usado para voltar o sistema ao estado original. Comeando do fim para o inicio, cada registro do log lido e a mudana desfeita. O log tambm pode ser usado para recuperar o sistema de uma falha. 3- Two-Phase Commit Protocol (Gray, 1978) A confirmao (committing) da transao precisa ser feita atomicamente, isto , de forma instantnea e indivisvel. Isto requer a cooperao de todos os processos participantes da transao. Um dos processos o coordenador, usualmente aquele que executou a transao. O protocolo comea quando o coordenador escreve uma entrada no arquivo log dizendo que ele comeou o _ Prof. Dr. Jean M. Laine 11

Disciplina: Sistemas Distribudos protocolo, enviando em seguida uma msg para cada processo participante dizendo para se prepararem para a confirmao. Cada um dos subordinados ir escrever no log e enviar a sua deciso para o coordenador. Este por sua vez ao receber todas as respostas saber se a transao teve sucesso ou no. O coordenador por sua vez comunica todos os outros participantes da deciso final.

Bibliografia
TANENBAUM, A. S. Distributed Operating Systems. 1st ed. New Jersey: Prentice Hall, 1994.

_ Prof. Dr. Jean M. Laine

12