SINCRONIZAÇÃO ATRAVÉS DO CLOCK

SINCRONIZAÇÃO ATRAVÉS DO CLOCK

Prof. Tiago Garcia de Senna Carneiro DECOM/UFOP

Em geral, os algoritmos distribuídos têm as seguintes propriedades

1) As informações relevantes estão espalhadas entre diversas máquinas.

2) Os processos tomam decisões baseados exclusivamente nas informações disponíveis no local onde eles estão rodando.

3) Deve ser evitada a qualquer custo a existência de um único ponto de falha.

4) Não existe nenhuma fonte de clock comum, ou qualquer outra fonte precisa de tempo global.

Os três primeiros tópicos listados dizem respeito à impossibilidade de se coletar informações em outros pontos para processamento local. Por exemplo, para fazer alocação de recursos, atribuindo dispositivos de entrada/saída a processos de forma a evitar deadcloks, não é aceitável que se envie todas as requisições a um único processo-gerente, que teria a responsabilidade de examinar todas as requisições e atendê-las ou não, baseado em informações constantes de suas tabelas. Fica evidente que nos sistemas de maior porte, este tipo de solução coloca uma carga muito pesada no processo-gerente. Além do mais um único ponto de falha torna este sistema inconsistente.

Pensando por um momento sobre as implicações da falta do tempo global, vamos nos valer do exemplo do programa make do UNIX, e extrair dele algumas conclusões. Normalmente os programas grandes em UNIX são divididos em vários arquivos-fonte, de forma que uma alteração no código em geral só exige a recompilação de um arquivo-fonte, em vez de obrigar que todo o programa seja recompilado. Se determinado programa constar de 100 arquivos-fonte, o fato de só ser necessária a recompilação de um único arquivo quando de uma modificação no código aumenta em muito a produtividade da equipe de programação.

A idéia por trás é a seguinte se um arquivo imput.c foi alterado em um instante 1 e seu arquivo objeto no instante 0.9, fica claro que o arquivo fonte deve ser

recompilado.

Agora imagine o que poderia ocorrer em um sistema distribuído no qual não houvesse uma fonte única de geração de tempo. Suponha que output.o tenha associado a ele o valor de 2.144 e que logo depois output.c tenha sido modificado, recebendo o valor de 2.143 em função do clock nesta máquina ser um pouco mais lento, conforme mostrado na Fig. 11.1. Neste caso o programa make não vai chamar o compilador para recompilar o arquivo-fonte, fazendo com que o programa executável resultante seja uma mistura de arquivos-objeto obtidos de arquivos-fonte velhos e novos. Ele provavelmente não vai funcionar, e o programador vai ficar maluco tentando descobrir o que há de errado com o seu código.

A questão é a seguinte: é possivel sincronizar o tempo em um sistema distribuido?

Clocks Lógicos

O termo exato para designá-los deveria ser temporizador. Em geral, um temporizador usado em computadores é uma máquina baseada em um cristal de quartzo absolutamente preciso. Quando tensionados, os cristais de quartzo oscilam em uma freqüência muito bem definida, que vai depender do tipo do cristal, de como ele foi cortado, e da pressão a qual ele está submetido. Associado a cada cristal estão dois registradores, um contador e um de retenção. Cada oscilação do cristal decrementa o contador de uma unidade. Quando o contador chega a zero, é gerada uma interrupção, e o contador é recarregado com o valor armazenado no registrador de retenção. Desta forma é possível programar-se um temporizador para gerar interrupções a uma taxa de por exemplo, 60 vezes por segundo, ou em qualquer outra freqüência escolhida. Este tipo de interrupção é denominado interrupção de tempo.

Tão logo foram introduzidos os sistemas com mais de um processador, cada um deles com seu próprio clock, a situação mudou bastante. Apesar da freqüência de cada

oscilador ser bastante estável, não é possível garantir que todos os cristais de todos os processadores estejam oscilando exatamente na mesma freqüência. Na prática,

quando um sistema tem n processadores, todos os n cristais estão oscilando em freqüências ligeiramente diferentes uns dos outros, fazendo com que os clocks (software) pouco a pouco percam o sincronismo, e forneçam valores diferentes quando lidos pelos processos. Esta diferença nos valores de tempo é denominada escorregamento do clock. Como conseqüência do escorregamento, os programas que considerarem como corretos e independentes de onde foram gerados, os tempos associados a arquivos, processos, ou mensagens poderão vir a falhar miseravelmente, como no exemplo acima com o programa make.

Lamport observou que o sincronismo do clock não precisa ser absoluto. Se dois

pois a perda da sincronização não vai ser observada, e como tal não poderá causar

nenhum tipo de problema. Além do mais, Lamport deixou claro que o que realmente importa não é que todos os processos estejam de acordo sobre o valor exato do tempo em determinado momento, mas sobre a ordem na qual eventos venham a ocorrer. No exemplo do programa make, o que conta é se input.c é mais antigo ou mais recente que input.o, não o momento exato em que cada um foi criado.

Para muitos propósitos é suficiente que todas as máquinas estejam de acordo a respeito de determinada marcação de tempo, não sendo porém importante que este tempo coincida com o tempo real, anunciado no rádio ou na televisão. Para que o programa make rode com sucesso, basta que todas as máquinas estejam de acordo com o fato de que são 10:00 horas, apesar do relógio atômico do Observatório Nacional estar marcando 10:02:30 horas, conforme anunciado a cada minuto pela Rádio Relógio Federal. Desta forma, para certas classes de algoritmos, o que vale é a consistência interna dos clocks, e não o quanto eles estão próximos do tempo real. No âmbito de tais algoritmos é usar referir-se aos clocks como clocks lógicos.

Pode acontecer de haver uma restrição adicional que exija que os clocks não somente sejam os mesmos, mas que também não possam diferir do tempo real mais que um determinado valor. Neste caso, os clocks são chamados de clocks físicos.

Lamport definiu uma relação denominada acontecimento-anterioridade. A expressão a → b é lida como “a acontece antes de b” e significa que todos os processos concordam com o fato de primeiro acontecer o evento a e depois ocorrer o evento b. A relação acontecimento-anterioridade pode ser observada diretamente em duas situações:

1) Se a e b são eventos no mesmo processo, e se a ocorre antes de b, então a→b é verdadeira.

2) Se a é o evento de uma mensagem sendo enviada para um processo, e b é evento da mesma mensagem sendo recebida por um outro processo, então a relação a → b também é verdadeira. Observe que uma mensagem não pode ser recebida antes de ter sido enviada, pois ela demora um tempo finito para chegar ao destino.

A relação acontecimento-anterioridade é uma relação transitiva, de foram que se a → b e b → c, então a → c. Se dois eventos x e y acontecerem em processos diferentes e que não trocam mensagens (nem mesmo indiretamente, através de um terceiro processo), então nem x → y nem y → x são verdadeiros. Tais eventos são considerados

concorrentes, o que simplesmente significa que nada pode ser dito (ou nada precisa ser

dito) a respeito de quanto tais eventos ocorrerem, ou sobre qual deles ocorreu antes e qual ocorreu depois.

Tudo o que precisamos é de uma forma de medida de tempo de tal maneira que para cada evento a possamos atribuir um valor C (a), correspondente a um instante de

tempo, com o qual todos os processos concordem. Esses valores devem ser tais que se a

→ b então C(a) < C(b). Desta forma, podemos apresentar novamente as duas condições anteriores, definindo-as de outro modo. Se a e b são dois eventos dentro do mesmo processo e a ocorre antes de b, então C(a) < C(b). Da mesma maneira, se a é o envio de uma mensagem para um processo, e b é a recepção desta mensagem por outro processo, então devem ser atribuídos valores a C(a) e C(b) de maneira que C(a) < C(b). Além disso, o tempo medido pelo clock, C, deve ser sempre crescente, nunca decrescente. Correções nos valores do clock podem ser feitas adicionando-se um valor positivo ao valor corrente do clock, nunca subtraindo. (Veja fig.11.2 página 318 do livro texto)

Existe um algoritmo, proposto por Lamport para atribuir tempos a eventos. Considere os três processos. Tais processos rodam em máquinas diferentes, cada uma delas com seu próprio clock, rodando em velocidades que não são necessariamente as mesmas. Em um mesmo intervalo de tempo real, houve seis interrupções de clock para o processo 0, oito para o processo 1, e 10 para o processo 2. vale observar que todos os três clocks oscilam a uma velocidade constante, apenas as taxas de oscilação são diferentes, devido a diferenças em cada um dos cristais.

No tempo 6, o processo 0 manda uma mensagem A para o processo 1. o tempo que esta mensagem leva para chegar ao destino vai depender do clock que estivermos tomando como base. De qualquer forma, o clock do processo 1 estará marcando 16 quando a mensagem chegar. Se esta levar a informação de que foi despachada no tempo 6, o processo 1 acreditará que ela demorou 10 unidades de tempo para percorrer seu caminho. Este valor certamente é um valor plausível. De acordo com o mesmo raciocínio, a mensagem B levou 16 unidades de tempo para sair da máquina onde roda o processo 1 e chegar à do processo 2, novamente um valor aceitável.

Agora vem a parte estranha do procedimento. A mensagem C, enviada do processo 2 para o processo 1 deixa a máquina do processo 2 no tempo 60 e chega à máquina do processo 1 no tempo 56. Da mesma forma, a mensagem D, do processo 1 para o processo 0 sai no instante 64 e chega no instante 54. Claramente isto não é possível. Esta situação é que precisa ser evitada.

A solução proposta por Lamport segue diretamente a relação acontecimento-anterioridade. Uma vez que C deixa a sua máquina no tempo 60, ele deve chegar ao destino no tempo 61 ou mais tarde. Desta forma, cada mensagem leva consigo o instante de tempo a transmissão de acordo com o clock do transmissor. Quando a mensagem chega, e o tempo do receptor indica um tempo anterior ao que ela traz consigo, o receptor adianta seu clock, fazendo-o tornar-se uma unidade maior que o instante da transmissão.

Com uma pequena modificação, este algoritmo cumpre os requisitos necessários para a implementação do tempo global. A modificação é que, entre dois eventos, o clock precisa rodar pelo menos uma vez. Se um processo envia ou recebe uma mensagem em rápida sucessão, ele precisa avançar seu clock (no mínimo) de uma unidade entre os dois eventos.

podem nunca ocorrer exatamente no mesmo instante de tempo. Para alcançar este objetivo, pode-se juntar o número do processo no qual o evento ocorre aos bits de mais baixa ordem do tempo, separados pelo ponto decimal. Então, se acontecerem dois eventos nos processos 1 e 2 no tempo 40, o tempo do primeiro passa a ser 40,1s e o do segundo 40,2.

Usando este método, passamos a ter uma forma de atribuir tempos a todos os eventos em um sistema distribuído, sujeita às seguintes condições:

1) Se a ocorrer antes de b no mesmo processo, então C(a) < C(b).

2) Se a e b são o envio e a recepção de uma mensagem, então C(a) < C(b). 3) Para quaisquer eventos a e b, C(a) ≠ C(b).

Clocks Físicos

Em alguns sistemas, como, por exemplo, os de tempo real, o conhecimento do instante de tempo real é muito importante. Para tais sistemas são necessários clocks físicos externos. Por motivos de eficiência e de redundância, considera-se desejável a existência de mais de um clock externo, o que nos causa dois problemas:

(1) como sincronizá-los com o clock de tempo real, (2) como sincronizar estes clocks externos entre si.

O evento do Sol alcançando seu ponto de maio altura aparente no céu é chamado de trânsito do Sol. Este evento ocorre aproximadamente no meio de cada dia. O intervalo entre dois trânsitos consecutivos do Sol é chamado dia solar.

Com a invenção do relógio atômico em 1948, tornou-se possível medir o tempo com um grau de precisão muito maior, e de maneira independente das condições vigentes no globo terrestre e na atmosfera que o cerca, através da contagem das transições do átomo do céssio 133. Os físicos tomaram dos astrônomos a tarefa de medir o tempo, e definiram o segundo como o tempo necessário a que o átomo de césio 133 faça exatamente 9.192.631.770 transições. O BIH – Bureau International Del’Heure - faz uma média destas informações e produz o Tempo Atômico Internacional, abreviado por

TAI.

O BIH introduziu os segundos bissextos (leap) sempre que a discrepância entre o tempo solar e o TAI ultrapassar a casa dos 800 ms. Esta correção deu origem a um sistema de tempo baseado em segundos TAI constantes, mas que permanecem em fase com o movimento aparente do Sol. Este sistema de tempo é denominado Tempo

Para tornar o UTC acessível às pessoas que por qualquer motivo venham a precisar dele, o National Institute of Standard Time (NIST) opera uma estação de rádio em ondas curtas com o prefixo WWV, a partir de Fort Collins, Colorado. A WWV envia em broadcast um pulso no início de cada segundo UTC. A precisão fornecida pela WWV é de mais ou menos 1 ms, mas devido às condições randômicas da atmosfera que podem alterar o comprimento do sinal, na prática a precisão é em torno de mais ou menos 10 ms.

Para se obter o tempo UTC, seja por meio das transmissões em ondas curtas ou das emissões dos satélites, é necessária a precisa determinação das posições relativas entre o transmissor e o receptor, de maneira a compensar o retardo de propagação do sinal. Existem receptores de rádio disponíveis comercialmente para captar os sinais enviados pela WWV, pelo satélite GEOS, e por outras fontes do tempo UTC. Seu custo varia de alguns poucos milhares de dólares a dezenas de milhares de dólares, dependendo da fonte dos sinais, sendo tão mais cara quanto mais confiável for a fonte. O UTC também pode ser obtido de forma mais econômica, porém menos precisa, através de uma linha telefônica conectada à sede do NIST em Fort Collins. Neste caso, também é necessária uma correção, em função da velocidade do modem e do caminho percorrido pelo sinal desde o emissor até o destino. Tal correção introduz um grau de incerteza no valor do tempo obtido, tornando muito difícil a obtenção de tempos altamente precisos.

Algoritmos para Sincronização de Clock

Se uma das máquinas de determinado sistema distribuído possuir um receptor WWV, o problema resume-se a manter todas as demais máquinas do sistema em sincronismo com ela. Se nenhuma máquina do sistema possuir o receptor, então cada uma delas deve cuidar de seu próprio tempo, e o problema passa a ser o de manter tais máquinas juntas, tanto quanto possível.

Assume-se, em primeiro lugar, que todas as máquinas têm um temporizador que causa uma interrupção H vezes por segundo. Quando este temporizador expira, a rotina de manipulação da interrupção adiciona uma unidade a um clock mantido por software, que controla o número de interrupções ocorridas a partir de um determinado tempo passado, conhecido por todas as máquinas do sistema.

Nosso sistema de sincronização está longe do ideal por uma série de motivos. O principal deles é que os temporizadores reais não geram exatamente H interrupções em um segundo. Teoricamente, um temporizador com H = 60 deveria gerar 216.000 interrupções por hora. Na prática, os modernos chips temporizadores apresentam um erro relativo de mais ou menos 10-5, o que significa que uma determinada máquina pode obter entre 215.998 e 216.002 interrupções por hora.

Algoritmo de Cristian

Um algoritmo projetado para rodar em sistemas que tenham uma máquina como o receptor WWV, onde o problema é fazer com todas as outras máquinas se sincronizem com esta. Vamos chamar a máquina com o receptor WWV de servidor de tempo. O algoritmo em análise é baseado no trabalho de Cristian (1989). Periodicamente, cada máquina envia uma mensagem para o servidor de tempo, perguntando pelo tempo corrente. A máquina onde roda o servidor de tempo responde o mais rápido possível, com uma mensagem contendo o tempo corrente, C_UTC.

Este algoritmo tem dois problemas, um maior e outro menor. O maior é que o tempo nunca pode andar para trás. Se o clock do transmissor estiver adiantado, o valor de C_UTC será menor do que o valor corrente de C na máquina transmissora. A adoção pura e simples do valor de C_UTC por tal máquina pode causar sérios problemas, tal como o de um arquivo-objeto compilado imediatamente após a mudança do clock passar a ter um tempo associado anterior ao do arquivo-fonte que foi modificado imediatamente antes da mudança.

A conclusão a que se chega é que tal mudança deve ser feita gradativamente. Uma das maneiras de implementá-la está descrita a seguir. Suponha que o temporizador seja programado para gerar 100 interrupções por segundo. Em geral, cada interrupção adicionam-se 10 ms ao tempo corrente. Quando houver necessidade de atrasar o tempo corrente, a rotina de interrupção pode adicionar apenas 9 ms de cada vez, até chegar ao valor necessário à correção.

O outro problema citado, menos importante que o que acabamos de descrever, é que a consulta ao servidor de tempo, e o conseqüente envio da resposta por parte deste servidor, gasta um tempo não-nulo. Pior ainda é o fato deste retardo poder vir a ser grande, variando com a carga de trabalho da rede. A forma escolhida por Cristina para tratar este assunto foi a de tentar medir este tempo. É muito simples para a máquina-cliente determinar precisamente o tempo gasto desde o envio da solicitação ao servidor de tempo, até o recebimento da resposta. Tanto o instante do início da contagem dos tempos, T₀, quanto o instante do final da contagem, T₁, são medidos usando o mesmo clock, de forma que o intervalo determinado é relativamente preciso, mesmo no caso de o clock do transmissor estar bastante defasado do UTC.

Algoritmo de Berkely

No UNIX de Berkely, foi adotada a estratégia exatamente oposta a esta (Gusella e Zatti, 1989). Nela, o servidor de tempo é uma entidade ativa que consulta periodicamente cada uma das máquinas do sistema a fim de saber o tempo corrente em

cada uma delas. Baseado nas respostas, ele calcula um tempo médio, e informa a todas as outras máquinas para avançar ou atrasar seus clocks, tornando-os iguais ao tempo médio calculado. Este método é adequado aos sistemas onde nenhuma máquina tem o receptor WWV. O ajuste do tempo do servidor de tempo deve ser feito periodicamente pelo operador, de forma manual.

Neste modelo ainda persistem os problemas apresentados no algoritmo de Cristian.

Algoritmos Baseados na Média

Todos modelos acima foram algoritmos altamente centralizados. Agora vamos examinar alguns algoritmos descentralizados.

Existe uma classe de algoritmos descentralizados para sincronização do clock que trabalham dividindo o tempo em intervalos fixos de ressincronização. O i-ésimo intervalo começa em T₀ + iR e vai até o T₀ + (i + 1)R, onde T₀ é um instante de tempo do conhecimento de todas as máquinas, e R um parâmetro do sistema. No início de cada intervalo, cada uma das máquinas envia em broadcast uma mensagem contendo seu tempo corrente. Pelo fato de o clock nas máquinas do sistema não ser exatamente o mesmo, estas mensagens em broadcast não vão ser emitidas todas ao mesmo tempo.

Depois de determinada máquina ter enviado sua mensagem, ela deve inicializar um temporizador local para coletar todas as outras mensagens em broadcast que chegarem durante um intervalo de tempo S. Quando todas as mensagens forem recebidas, ela deve rodar um algoritmo para calcular o novo tempo corrente, baseado nos tempos informados pelas demais máquinas. Tal algoritmo, em sua implementação mais simples, calcula a média dos valores dos tempos correntes de todas as máquinas da rede.

Uma outra variação é tentar corrigir cada mensagem, adicionando-lhe um valor estimado do tempo de propagação a partir da fonte. Esta estimativa pode ser feita com base na topologia da rede, ou medindo o tempo gasto para que mensagens de teste ecoem.

Sistemas com Várias Fontes Externas de Tempo

Para os sistemas onde é necessária uma sincronização altamente precisa com o UTC, é possível equipar o sistema com diversos receptores para WWV, GEOS, ou outras fontes UTC. No entanto, devido à imprecisão inerente à própria fonte de tempo, bem

como às flutuações sofridas pelo sinal em seu caminho, o melhor que o sistema operacional pode fazer nestes casos é estabelecer uma faixa (um intervalo de tempo), dentro do qual o UTC deve situar-se. Em geral, as várias fontes de tempo vão produzir intervalos diferentes, o que vai fazer com que as máquinas ligadas a cada uma delas tenham que entrar em acordo a respeito do assunto.

Uma forma de se chegar a tal acordo é fazer com que cada máquina ligada a fonte UTC envie periodicamente uma mensagem em broadcast, informando seu intervalo às demais. Tais mensagens podem ser enviadas, por exemplo, no exato momento do início de cada minuto UTC. Observe que pelo fato das máquinas não estarem sincronizadas, nenhuma delas vai receber os pacotes com as informações do intervalo de tempo instantaneamente. Pior do que isto, o retardo entre a transmissão e a recepção depende da distância de cabo e do número de gateways que o pacote tem que atravessar, parâmetros estes que variam com cada par (fonte UTC, processador). Outros fatores também podem ter influência na precisão deste método, a exemplo dos retardos devido às colisões ocorridas quando várias máquinas tentam transmitir informações no mesmo instante em uma rede Ethernet.

Assim, mesmo que dois processadores consigam ajustar seus clocks para o UTC correto, depois de poucos segundos, estes clocks não serão mais os mesmos em função do escorregamento verificado entre eles.

Outra técnica é a denominada média local. Suponha que as máquinas de determinado sistema distribuído possam ser organizadas, pelo menos conceitualmente, se não for possível organizá-las fisicamente, de acordo com determinado padrão, tal como um anel ou uma grade. Periodicamente, em intervalos menores que os das atualizações do UTC, cada máquina pode trocar informações de tempo com seus vizinhos na estrutura, e ajustar seu clock tomando a média das informações obtidas, considerando seu próprio clock no cálculo da média.

A conclusão a que chegamos é a de que manter os clocks de um sistema distribuídos sincronizados por 5 ou 10 ms UTC é uma tarefa bastante dispendiosa e não-trivial.