Cap. 06 – Sincronização - FACOMfaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch06.pdf · 6.2 – Relógios...

Luís F. Faina - 2013 Pg. 1/97

Cap. 06 – Sincronização

6.1 – Sincronização de Relógio6.1.1 Relógio Físicos

6.1.2 Sistema de Possicionamento Global

6.1.3 Algoritmos de Sincronização de Relógio

6.2 – Relógios Lógicos6.2.1 Relógio Lógico de Lamport

6.2.2 Relógios de Vetores


… Cap. 06 – Sincronização

6.3 – Exclusão Mútua6.3.1 Algoritmo Centralizado

6.3.2 Algoritmo Descentralizado

6.1.3 Algoritmo Distribuído

6.1.4 Algoritmo Token Ring

6.4 – Algoritmos de Eleição6.4.1 Algoritmos de Eleição Tradicional

6.4.2 Eleição em Ambiente sem Fio

6.4.3 Eleição em Sistemas de Larga Escala


Referências Bibliográficas

● Andrew S. Tanenbaum; Maarten van Steen - Distributed Systems: Principles and Paradigms, Prentice-Hall, 2007, ISBN-10: 0132392275, ISBN-13: 9780132392273

… Lectures dos autores Andrew S. Tanenbaum e Maarteen van Steen (“www.cs.vu.nl” e “www.distributed-systems.net/”)

● George Coulouris; Jean Dollimore; Tim Kindberg – Sistemas Distribuídos: Conceitos e Projeto, Bookman, 4th Edition, 2007, ISBN 9788560031498

● Notas de Aula do Prof. Ricardo Anido do Instituto de Computação (IC) da UNICAMP - www.ic.unicamp.br/~ranido/

http://www.cs.vu.nl/


6 Sincronização

6 Sincronização

● Objetivo do Cap. 06 – discutir como processos podem sincronizar suas atividades em um ambiente distribuído;

● e.g., ... considere o cenário de múltiplos processos acessando simultaneamente recursos compartilhados, como impressoras.

● objetivo – ... permitir que os processos cooperem entre si para garantir que cada um acesse individualmente e, por uma certo período de tempo, o recurso objeto do compartilhamento.

● Problema – sincronização em sistemas distribuídos é frequente- mente mais difícil comparada com a sincronização em sistemas monoprocessados ou multiprocessados.


6 Sincronização - 6.1 Sincronização de Relógio

6.1 Sincronização de Relógio

● tempo – grandeza determinística em sistemas centralizados, no entanto, não se pode dizer o mesmo em sistemas descentralizados;

● ... quando um processo deseja saber o tempo, ele simplesmente invoca uma chamada de sistema e o kernel o informa;

● e.g., ... considere o caso de 02 processos (A e B) que solicitam informações de tempo em sequência, ou seja, A e depois B;

● resposta: ... o tempo obtido pelo processo B será >= (maior ou igual) ao tempo obtido pelo processo A.

● problema – em sistemas distribuídos a mesma operação não necessariamente irá produzir o mesmo resultado;

● e.g., apenas pense, por um momento, nas implicações da falta de um medida global de tempo ao programa “make” do UNIX ?!



… 6.1 Sincronização de Relógio

● e.g., apenas pense, por um momento, nas implicações da falta de uma medida global de tempo no programa “make” do UNIX ?!

● “make” - no UNIX, programas grandes são normalmente divididos em múltiplos programas, de modo que a mudança em um arquivo fonte requeira a recompilação apenas daquele arquivo;

● ... se um programa contempla 100 arquivos, não recompilar tudo em razão da mudança de um arquivo, aumenta consideravel- mente a velocidade com que programadores podem trabalhar.

● ... de fato o uso do “make” funciona bem em sistemas em que a medida de tempo é global, mas quais serão as implicações se não tivermos a medida global de tempo – p.ex. sistemas distribuídos ?!



… 6.1 Sincronização de Relógio

● Fig. 6.1 – Quando cada máquina dispõe de relógio próprio, um evento que acontece após o outro jamais estará associado a um tempo anterior como o tempo do primeiro evento !



6.1.1 Relógios Físicos

● Quase todos os computadores dispõem de circuitos para rastrear o tempo e, embora o termo “clock” seja utilizado para referenciar estes dispositivos, ele não é usado no sentido real;

● “timer” - com certeza é uma palavra que melhor ilustra o que estamos medindo ou interessados em medir;

● ... em sistemas computacionais o “timer” (cronômetro) é precisa- mente implementado por um dispositivo de cristal de quartzo;

● ... associado ao cristal, há 02 registradores: “holding register” e “counter” cujo valor é decrementado de 1 a cada oscilação do cristal de quartzo (quando submetido a tensão elétrica);

● ... quando o “counter” chega a zero, uma interrupção é gerada e o “counter” é recarregado com o valor do “holding register”.



… 6.1.1 Relógios Físicos

● ... desta forma é possível gerar 60 interrupções - “clock tick” - a cada segundo ou qualquer outra frequência que se deseje.

● Com a introdução de múltiplas CPUs, cada qual com o seu “clock”, a situação muda radicalmente;

● ... pois embora o cristal gere oscilações estáveis, não é possível garantir que cristais em diferentes máquinas operem na mesma frequência.

● ... no mundo real, um sistema com “n” computadores, os “n” cristais oscilam em frequências levemente diferentes, causando no tempo diferenças de valores entre as “n” diferentes leituras - “clock skew”;

● ... com consequência do “clock skew”, programas que esperam pelo tempo correto associado ao arquivo, objeto, processo ou menssagem e independente da máquina onde foi gerado podem falhar.




● Em Sistemas de Tempo Real há algumas exigências como a de tempo de relógio real, ou seja, necessidade de relógios externos;

● ... assim, por razões de eficiência e redundância, a presença de múltiplos relógios físicos é desejável, mas produz 02 problemas:

● como sincronizá-los com o relógio do mundo real ?!

● como sincronizar os relógios uns com os outros !?

● ... antes de respondermos a esta questão, vejamos como de fato o tempo é medido, ou seja, quais eventos naturais são utilizados e como são contabilizados na medida do tempo.




● Fig. 6.2 – Medição do Tempo – “mean solar day”.




● ... como pode ser verificado, o período do evento que queremos medir é o de trânsito do sol, ou seja, o tempo entre 02 passagens consecutivas do sol pelo ponto mais alto no céu - “solar day”;

● “solar second” - 1 / 86400 do dia solar, ou seja, 1 / (24 * 3600) do dia solar como mostrado na Fig. 6.2.

● ... como há outras variáveis envolvidas no processo de cálculo do dia solar bem como do segundo solar, a quantidade resultante é denominas média do segundo solar - “mean solar second”;

● ... com o advento do relógio atômico, o segundo solar passou a ser medido pelo número de transações do Átomo Cesium 133, ou seja, são necessárias 9.192.631.779 transações para que 01 segundo tenha transcorrido no tempo.




● Periodicamente laboratórios espalhados pelo mundo informam ao Bureau International de l'Heure (BIH) o tempo atômico ou no francês - “Temps Atomique International” – TAI;

● TAI – média do número de ticks do Átomo Cesium 133 desde a 00:00 de 01/Jan/1958 quando então deu-se início a medida dividido por 9.192.631.779;

● Obs.: ... embora seja altamente estável, há o sério problema com os 86.400 segundos que agora são 3 ms menor que a média do dia solar, pois o dia solar vem se tornando maior a cada dia;

● “leap seconds” - ... ou segundos bissextos, acompanha a diferença entre o TAI e o dia solar real está crescendo e hoje já assume o valor de 800 ms.




● Fig. 6.3 – Segundos TAI são constantes, diferentemente dos segundos solares, pois isso, foi introduzido os “leap seconds”;

● “leap seconds” - mantém em fase o TAI e o dia solar.




● Para prover “Universal Coordinated Time” - UTC para aqueles que precisam do tempo real, o NIST - “National Institute of Standard Time” opera uma estação de ondas curtas;

● ... esta estação emite um pulso a cada início de segundo UTC e sua precisão é não mais do que +-1 ms, mas por questões de interferência na propagação do pulso esta precisão na prática é não mais do que +-10 ms.

● Vários satélites também oferecem o Serviço UTC e o satélite “Geostationary Environment Operational” - GEOS pode prover o UTC com precisão de 0.5 ms.



6.1.2 Sistema de Possicionamento Global

● “Global Positioning System” – sistema distribuído baseado em satélite lançado em 1978 que pode determinar a posição geográfica de qualquer um na Terra;

● ... composto de 29 satélites em órbita a uma altura de aproximadamente 20.000 Km, cada qual com até 04 relógios atômicos calibrados regularmente de estações na Terra;

● ... um satélite radiodifunde - “broadcast” continuamente sua posição e adiciona em cada mensagem o tempo local, ou seja, hora local no satélite proveniente do(s) relógio(s) atômico(s);

● ... esta difusão de mensagens permite aos destinatários calcular a sua posição, utilizando em princípio informações de 03 satélites.



… 6.1.2 Sistema de Possicionamento Global

● Fig. 6.4 – Cálculo da posição no espaço bi-dimensional.

● eixo “y” representa a altura; e o eixo “x” representa uma linha ao longo da superfície terrestre no nível do mar e os círculos representam pontos a uma mesma distância para cada um dos centros.




● Princípio da intersecção de círculos pode ser expandido para 03 dimensões, ou seja, necessitamos de 03 satélites para determinar a longitude, latitude e altitude de um “receiver” na terra;




● Há 02 fatos do mundo real que precisamos considerar:

● ... tempo de propagação da mensagem até o “receiver”;

● ... relógio do “receiver” normalmente não sincronizado com o do satélite.

● Seja Δr o desvio do relógio do “receiver” com o tempo real, assim, quando a mensagem do satélite “i” como “timestamp” “Ti” é recebida, o atraso Δ i = ( Tnow – Ti) + Δr ;

● ... como o sinal progaga na velocidade da luz, a distância percorrida é c * Δi, ou seja, di = c * (Tnow – Ti);

● ... distância real entre o “receiver” e o satélite pode ser calculada pela equação: di = sqrt[ (xi – xr)2 + (yi – yr)2 + (zi – zr)2 ] onde xi, yi e zi são as coordenadas do satélite “i”.




● Obs.: Medida GPS irá também conceder a medida do tempo real, além da posição do “receiver” na Terra.

● ... em geral o cálculo preciso da posição não é trivial e exige a consideração de outros aspectos não discutidos aqui;

● ... muitos premissas sobre as quais repousam as hipóteses aqui apresentadas contém inúmeras fontes de erros como:

● desvios na medida UTC; relógios atômicos nos satélites não estão perfeitamente sincronizados; as próprias medidas não são precisas;

● posição do satélite não é precisa; propagação do sinal não é constante bem com a sua velocidade, terra não é uma esfera perfeita; etc.



6.1.3 Algoritmo de Sincronização de Relógio

● Todos os algoritmos seguem praticamente o mesmo modelo, ou seja, cada máquina contempla um cronômetro - “timer” que gera H interrupções por segundo;

● ... quando um ciclo se completa, o tratador de interrupção adiciona 1 ao relógio de software que por sua vez mantém o nro de ticks ou interrupção tendo por base uma referência do passado;

● e.g., ... considere que o tempo UTC seja “t” e o valor do relógio numa máquina “p” seja Cp(t);

● ... no mundo perfeito, teremos Cp(t) = t para todo “p” e todo “t”, ou seja, C'p(t) = dC / dt deve idealmente ser 1;

● C'p(t) é a frequência de “p” no tempo “t”, enquanto que C'p(t) – 1 reflete quão distante a frequência está do relógio perfeito.



… 6.1.3 Algoritmo de Sincronização de Relógio

● Cronômetros reais não geram H interrupções por segundo, pois teoricamente para H = 60 são necessários 216.000 ticks por hora, ou seja, 1 * 60 * 60 * 60 = 216.000 ticks;

● ... na prática o erro relativo obtido em cronômetros modernos está em torno de 1/105 , ou seja, uma máquina pode obter valores na faixa entre 215.998 e 216.002 ticks por hora;

● ... 1 – ρ <= dC/dt <= 1 + ρ onde a constante “ρ” é especificada pelo fabricante bem como é conhecida por “maximum drift rate”




● Fig. 6.5 – Relação entre o tempo de relógio e o UTC quando frequência de ticks de relógio e diferente.




● “Network Time Protocol” - protocolo que permite aos clientes obterem informações de um servidor de tempo;

● Fig. 6.6 – Obtendo o tempo corrente de um Servidor de Tempo.




● “A” envia uma requisição para “B” com a marca de tempo “T1” e “B” registra o tempo de recepção da “msg” em “T2”;

● “B” retorna uma resposta para “A” com a marca de tempo “T3” bem como informa o valor de “T2”;

● … “A” registra o tempo de chegada da resposta de B em “T4”




● Como apresentado na Fig. 6.6, A pode estimar a distância relativa para B como “teta” = T3 – [(T2 – T1) + (T4 – T3)] / 2 que reescrita torna-se “teta” = [(T2 – T1) + (T3 – T4)] / 2;

● ... se o relógio de A é mais rápido, então “teta” < 0 o que sugere que A, em princípio, deva atrasar o relógio;

● ... tal ocorrência não deve ser permitida pois pode causar sérios problemas, p.ex., quando um arquivo objeto compilado logo após o relógio mudar tem um marca de tempo anterior do arquivo fonte que por sua vez foi modificado um pouco antes do relógio mudar;

● solução – mudanças como estas devem ser feitas gradualmente.

● e.g., ... considere a frequência de 100 ticks por segundo, ou seja, cada interrupção irá acrescentar 10 ms ao tempo por vez;




● e.g., ... considere a frequência de 100 ticks por segundo, ou seja, cada interrupção irá acrescentar 10 ms ao tempo por vez;

● ... se diminuirmos a frequência, a rotina de interrupção irá adicio- nar 9 ms a cada tick de relógio até que a correção seja feita;

● ... de modo semelhante o relógio pode ser avançado adicionando 11 ms a cada interrupção ou tick de relógio, ao invés de efetuarmos saltos grandes de uma única vez.

● No caso do NTP, o protocolo estabelece um emparelhamento entre os servidores, ou seja, B irá também sondar A em relação ao tempo, assim, um desvio “delta” é também estimado;




● No caso do NTP, o protocolo estabelece um emparelhamento entre os servidores, ou seja, B irá também sondar A em relação ao tempo contabilizado no mesmo, assim, além de “teta”, um desvio “delta” é estimado como “delta” = [(T2 – T1 ) + (T4 – T3] / 2;

● ... após 08 medidas de pares “teta” e “delta”, podemos encontrar o menor “delta” como a melhor estimativa para o atraso entre os 02 servidores bem como o “teta” correspondente;

● Se aplicarmos NTP simetricamente em B, em princípio, irá permitir que B ajuste o seu relógio com o de A, mas se B é conhecido por ser mais preciso, então o ajuste não procede;

● ... para resolver este problema o NTP estratifica os servidores de modo que um servidor “stratum-1” mantém p.ex., um relógio atômico ou mesmo um relógio “www receiver”.




● solução - ... para resolver este problema o NTP estratifica os servidores de modo que um servidor “stratum-1” mantém p.ex., um relógio atômico ou mesmo um relógio “www receiver”.

● ... quando A contacta B, ele irá somente ajustar o seu tempo se o seu nível de “stratum” é maior que o “stratum” de B.

● Há importantes recursos sobre o NTP, muitos relacionados a erros de identificação e de ataques de segurança;

● ... aspectos de implementação e descrição de detalhes da versão 4 (NTPv4) podem ser encontrados em Mills (2006).




● “Berkeley Algorithm” - ... servidor de relógio - “time daemon” - solicita periodicamente a cada outro servidor de relógio que informe a sua sua medida de tempo;

● ... tendo por base os dados coletados, calcula a média do tempo e, na sequência, informa aos servidores se os mesmos devem avançar ou atrasar seus relógios;

● ... “time daemon” informa como ajustar os seus relógios.

● Obs.: ... em muitos sistemas, é suficiente que todas as máquinas ou servidores de relógio concordem com o mesmo valor, ou seja, não é essencial que a medida reflita o valor real de tempo.




● Fig. 6.7 – “daemon” solicita a outros servidores de relógio que informem seus valores, para na sequência computar o novo valor.




● “Clock Synchronization” - ... servidores de relógio podem ser implantados de modo eficiente e rápido em sistemas distribuídos tradicionais, conferindo assim uma grande vantagem.

● ... tais afirmações não são válidas em redes sem fio ou em redes de sensores onde recursos são limitados e multi rotas são caras, além da necessidade de economia de energia;

● ... ou seja, tais observações levam ao projeto de diferentes algoritmos de sincronização de relógio para redes sem fio.

● “Reference Broadcast Synchronization” - ... protocolo de sincroni- zação de relógio um pouco diferente de outras propostas;

● ... preocupa-se com a sincronização interna de relógios, ou seja, não tem por objetivo prover o relógio UTC para todos os nós;




● ... nesta abordagem, o remetente “broadcast” uma mensagem de referência para permitir que os receptores ajustem seus relógios;

● ... em redes de sensores o tempo de propagação do sinal para outros nós pode ser considerado como constante, desde que o roteamento de múltiplas saltos não esteja presente.

● “tempo de propagação” - ... medido a partir do instante em que a mensagem deixa a interface de rede do remetente, ou seja, 02 fontes de variação não mais governam o atraso de propagação:

● tempo gasto para construir a mensagem;

● tempo gasto para acessar a rede.




● Fig. 6.8 – Determinação usual de caminhos críticos em Redes Determinísticas e em “Reference Broadcast Synchronization”.




● NTP – medida do tempo é adicionada à mensagem antes de ser passada para a interface de rede em razão de fatores não determinísticos em redes sem fio;

● ... mas com a sincronização por referência - “Reference Broadcast Synchronization” estes fatores são eliminados.

● “Reference Broadcast Synchronization” - ... quando um nó emite uma mensagem de referência “m”, cada nó “p” simplesmente registra o tempo “Tp,m” em que “m” é recebida;

● ... ignorando “clock skew”, 02 nós “p” e “q” podem trocar os seus valores de relógio para estimar o “offset” mútuo:

● Offset [ p, q] = Somatório ( Tp,k - Tq,k ) / M com k=1 até M onde M é o total de mensagens de referências enviadas.




● ... nó “p” irá conhecer o valor do relógio de “q” relativo ao seu próprio valor e calcular “offsets” bem como armazená-los, mas não terá que ajustar seu relógio economizando assim energia.

● Infelizmente, relógios podem sofrer desvios e, neste cenário, o cálculo da média dos “offset” não irá funcionar !?

● ... ao invés de calcular a média dos valores, aplica-se a regressão linear para o cálculo do “Offset” como uma função:

● Offset[ p, q]( t ) = alfa * t + beta, onde as constantes “alfa” e “beta” são calculadas através dos pares (T p,k , Tq,k );

● ... esta cálculo irá proporcionar um valor mais preciso do relógio corrente de “q” pelo nó “p” e vice-versa.


6 Sincronização - 6.2 Relógios Lógicos

6.2 Relógios Lógicos

● ... discutimos que a sincronização de relógios está atrelada ao tempo real, mas basta ao nós acordarem o valor do tempo sem necessariamente assumir o valor do tempo real;

● ... muitas vezes, o rastreamento dos eventos uns dos outros é o que importa, ou seja, estamos falando dos relógios lógicos.

● “Lamport” mostrou em 1978 que embora seja possível a sincroni- zação de relógios, não é necessário que seja absoluta;

● ... pois se 02 processos não tem interação, não é necessário que os seus relógios estejam sincronizados, uma vez que a falta de sincronização não irá causar problemas.



6.2.1 Relógio Lógico de Lamport

● ... para sincronizar relógios lógicos, é necessário garantir a expressão “happens-before”, ou seja, “a → b” - “a happens before b” significa que todos os processos concordam que o evento “a” ocorreu primeiro e somente depois o evento “b”;

● 02 situações podem ser observadas:

● se “a” e “b” são 02 eventos no mesmo processo e “a” ocorre antes de “b”, então a cláusula “a → b” é verdadeira;

● se “a” é o evento de uma mensagem enviada por um processo e “b” é o evento de uma mensagem recebida por um outro processo, então “a → b” é também uma cláusula verdadeira.

● “happens-before” é transitiva, pois se “a → b” e “b → c”, então “a → c” é uma cláusula verdadeira.



… 6.2.1 Relógio Lógico de Lamport

● “happens-before” é transitiva, pois se “a → b” e “b → c”, então “a → c” é uma cláusula verdadeira;

● ... se 02 eventos, “x” e “y” acontecem em diferentes processos que não trocam mensagens nem mesmo indiretamente, então “x → y” não é verdade e nem mesmo “y → x” é verdade;

● ... podemos afirmar simplesmente que são eventos concorrentes, assim não é possível afirmar quando os eventos aconteceram ou qual evento dentre eles aconteceu primeiro.

● ... precisamos medir a noção de tempo tal que para todo evento “a” podemos associar um valor “C(a)” com o qual todos os processos concordam, ou seja, se “a → b” então “C(a) → C(b)”.




● Fig. 6.9 – a. 03 processos, P1, P2 e P3, cada qual com o seu relógio que mede o tempo em diferentes frequências.




● Para preparar nossa discussão para Relógio de Vetor, vamos formular este problema com mais precisão, ou seja, ajuste do relógio em um dado servidor através do Algoritmo de Lamport.

● ... é importante distinguir 03 camadas diferentes do software: camada de rede; camada de middleware e a camada de aplicação.

● ... faz-se necessário possicionar em que momento e em que camada os ajustes de relógio são realizados (Fig. 6.10).




● Fig. 6.10 – Possicionamento (ajustes) do Relógio Lógico de Lamport em Sistemas Distribuídos.




● Para implementar o Relógio Lógico de Lamport, cada processo Pi mantém um contador local Ci, atualizados da seguinte forma:

● antes de executar um evento (e.g., envio de uma mensagem na rede, entrega de uma mensagem para a aplicação ou algum outro evento interno), Pi executa Ci ← Ci + 1;

● quando um processo Pi envia uma mensagem “m” para Pj, atribui-se o “timestamp” de “m” - ts(m) igual a Ci após executar o passo anterior;

● na recepção da mensagem “m”, processo Pj ajusta o seu contador como Cj ← max[ Cj , ts(m) ], após o qual executa o primeiro passo e, na sequência, entrega a mensagem para a aplicação.

● Obs.: ... solução proposta deriva diretamente da relação/expres- são “happens before”, ou seja, “a → b” então “C(a) → C(b)”




● Fig. 6.9 – a. 03 processos, cada qual com o seu relógio que mede o tempo em diferentes frequências; b. correção dos relógios.




● Obs.: ... em algumas situações, requisito adicional é desejável: 02 eventos não ocorrem exatamente no mesmo tempo;

● ... para atender este requisito, podemos combinar o nro do processo no qual o evento ocorreu com a marca de tempo, p.ex., evento no tempo 40 no processo Pi será rotulado por “40.i”;

● Obs.: ... atribuindo o tempo do evento C(a) ← C i(a) se “a” aconteceu no processo Pi no tempo Ci(a), teremos uma implementação distribuida do valor de tempo global.



6.2.2 Relógio de Vetores

● Relógio Lógico de Lamport estabelece que todos os eventos em um sistema distribuído são ordenados com a propriedade na qual se “a” aconteceu antes de “b”, então C(a) < C(b);

● ... no entanto não podemos afirmar que se C(a) < C(b), então o evento “a” aconteceu antes do evento “b” ?!

● e.g., considere as mensagens enviadas por 03 processos:

● Tsnd(mi ) - tempo no remetente no qual a mensagem “mi” foi enviada;

● Trcv(mi) - tempo no destinatário em que a mensagem “mi” foi recebida;

● para cada mensagem Tsnd(mi) < Trcv (mi)

● O que podemos concluir de Trcv(mi) < Tsnd(mj) ?

● mi = m1 e mj = m3 ou mi = m1 e m j = m2



… 6.2.2 Relógio de Vetores

● Fig. 6.12 – Transmissão de mensagens concorrentes utilizando relógios lógicos – não há a captura da causalidade;

● 1o Caso: mi = m1 e mj = m3 2o Caso: mi = m1 e mj = m2




● Problema do Relógio Lógico de Lamport – ... não captura causalidade, o que pode ser contemplado nos Relógios de Vetores.

● “Vector Clock” - um relógio de vetor VC(a) atribuído a um evento “a” tem a propriedade de que se VC(a) < VC(b) para algum evento “b”, então o evento “a” precede o evento “b”.

● ... são construídos permitindo que cada processo Pi mantenha o vetor VCi com as seguintes propriedades:

● VCi [ i ] é o nro. de eventos que ocorreram no processo P i , ou seja, é o relógio lógico no processo Pi ;

● Se VCi [ j ] = k então Pi sabe que “k” eventos aconteceram em Pj, ou seja, Pi conhece o tempo local de Pj .




● ... primeira propriedade é mantida incrementando VCi[ i ] a cada ocorrência de um novo evento que acontece em Pi ;

● ... segunda propriedade é mantida através de vetores de realimentação com mensagens que são enviadas:

● antes de executar um evento (e.g., envio de uma mensagem na rede, entrega de uma mensagem para a aplicação ou algum outro evento interno), Pi executa VCi [ i ] ← VCi [ i ] + 1;

● quando um processo Pi envia uma mensagem “m” para Pj, ele torna o ts(m) igual a VCi após ter executado o passo anterior;

● na recepção da mensagem “m”, processo Pj ajusta o seu vetor VCj [ k ] ← max[ VCj[ k ] , ts(m)[ k ] ] para cada “k”, após o qual executa o primeiro passo e, na sequência, entrega a mensagem para a aplicação.




● Obs.: ... se um evento “a” tem rótulo de tempo “ts(a)”, então “ts(a)[ i ] – 1” denota o nro de eventos processados em “P i” que precedem “a”, como consequência:

● ... quando Pj recebe uma mensagem de Pi com rótulo de tempo ts(m), ele sabe o nro de eventos que ocorreu em Pi que casualmente precederam o envio da mensagem “m”;

● ... Pj pode informar quantos eventos em outros processos aconteceram antes de Pi enviar a mensagem “m”, ou seja, “timestamp” ts(m) informa quantos eventos em outros processos precederam o envio de “m”.




● ... ao utilizar relógio de vetor é possível garantir que uma mensagem seja entregue somente se todas as mensagens que a precederam forem também recebidas;

● “causally-ordered multicasting” - para este esquema, assume- se que as mensagens são repetidas para um grupo de processo;

● ... se 02 mensagens não estão relacionadas uma com a outra, não é necessário considerar em que ordem serão entregues, ou seja, podem ser entregues em ordem diferente ou localizações.

● Suponha que Pj recebe uma mensagem “m” de Pi com rótulo ts(m), assim, a mensagem será entregue a aplicação quando as 02 condições forem satisfeitas:

* ts(m)[ i ] = VCj [ i ] + 1 * ts(m)[ k ] <= VCj [ k ] para todo k <> i

●




● ... primeira condição estabelece que “m” é a próxima mensagem que Pj está esperando de Pi ;

● ... segunda condição estabelece que Pj tem conhecimento de todas as mensagens conhecidas por P i quando enviou “m”;

● Obs.: ... não é necessário que o processo P j atrase a entrega das suas próprias mensagens pelas condições estabelecidas.

● e.g., … considere Po, P1 e P2 trocando mensagens entre si, onde P0 envia no tempo (1,0,0) mensagem “m” para P1 e P2;

● … após receber a mensagem, P1 decide enviar m* para P 0 e P2, que chega antes da mensagem “m” (Fig. 6.13).




● Fig. 6.13 – Garantindo a comunicação causal

● ... neste ponto, P2 atrasa a entrega de m* até “m” ser recebida e entregue à camada de aplicação de P2.




● “Ordered Message Delivery” - ... há uma controvérsia quanto ao suporte da ordenação de mensagens – “totally-ordered” ou “causally-ordered” pela camada de comunicação de mensagens ou se as aplicações devem tratar a ordenação.

● Há 02 problemas ao contemplar a ordenação no “middleware”:

● 1o - como o middleware não pode dizer o que a mensagem contém, somente causalidade em potencial é capturada;

● e.g., 02 mensagens do mesmo remetente que são completamente independentes serão sempre marcadas como relacionadas, mas esta situação é muita restritiva e pode comprometer a eficiência;




● 2o - nem toda causalidade pode ser capturada.

● e.g., considere um quadro de boletim eletrônico compartilhado entre Alice e Bob que também eventualmente se comunicam por telefone além de se comunicarem pelo “bulletin board”;

● ... neste caso, a comunicação externa impede que o boletim eletrônico compartilhado capture a relação de causalidade.

● Em essência, aspectos de ordenação, podem ser adequadamente solucionados olhando-se para a aplicação na qual a comunicação está em curso - “end-to-end argument”.


6 Sincronização - 6.3 Exclusão Mútua

6.3 Exclusão Mútua

● “concurrency” e “collaboration” - ... em sistemas distribuídos a concorrência e colaboração entre múltiplos processos é essencial

● ... para coordenar a concorrência e colaboração entre os processos de modo coerente é necessário garantir aos processos o acesso aos recursos por exclusão mútua.

● Algoritmos de exclusão mútua em sistemas distribuídos podem ser divididos em 02 categorias:

● “token-based solutions” - exclusão mútua é alcançada pela passagem de uma mensagem especial entre os processos conhecida como “token”;

● “permission-based solutions” - processo esperando para acessar um dado recurso primeiro requer a permissão para outro processo.



… 6.3 Exclusão Mútua

● “token-based solutions” - ... exclusão mútua é alcançada pela passagem de uma mensagem especial entre os processos conhecida como “token” - único em todo o sistema;

● ... “token” é passado de processo para processo e, caso um processo não tenha interesse no acesso, ele simplesmente repassa para o próximo processo da lista.

● ... algumas propriedades interessantes:

● ... dependendo de como os processos são organizados, cada processo terá a chance de acessar o recurso, ou seja, evita-se “starvation”;

● ... “deadlocks” podem ser evitados, contribuindo para sua simplicidade;

● “desvantagem” - ... se o “token” for perdido, um intrincado processo distribuído tem que ser disparado para garantir que um novo “token” seja criado e que acima de tudo seja único.



… 6.3 Exclusão Mútua

● “permission-based solutions” - ... o processo à espera de um dado recurso primeiro requer a permissão para outro processo.

● ... há diferentes maneiras de conceder esta permissão que discutiremos nas próximas seções:

● eleição de um coordenador pelos pares que concede a permissão quando uma requisição de permissão é encaminhada;



6.3.1 Algoritmo Centralizado

● Abordagem mais rápida para garantir a exclusão mútua em sistemas distribuídos é simular como o problema seria resolvido em um sistema de processador único;

● ... um processo é eleito como coordenador e tem a responsabilidade de gerenciar que processo pode utilizar que recurso;

● ... quando uma concessão é concedida, o coordenador responde ao solicitante com uma mensagem de permissão.

● e.g., considere 03 processos que requisitam ao coordenador a permissão para utilizar um dado recurso objeto de concorrência entre os processos como representado na Fig. 6.14.



… 6.3.1 Algoritmo Centralizado

● Fig. 6.14 – Para garantir a exclusão mútua em sistemas distribuí- dos o caminho mais direto é simular como o problema seria resolvido em um sistema de processador único.




● ... como pode ser verificado, o algoritmo garante a exclusão mútua, pois a coordenação permite que somente um processo por vez acesse o recurso e na ordem que foram solicitados;

● ... ou seja, nenhum processo espera indefinidamente para acessar o recurso - “no starvation”.

● Este esquema é fácil de implementar e requer apenas 03 mensagens pelo uso de cada recurso - “request”, “grant” e “release”, tornando-se assim atrativo para soluções práticas.




● Por outro lado tem como principal desvantagem o fato do coordenador ser um ponto central de falha o que compromete o sistema.

● e.g., ... quando um processo é bloqueado após uma requisição, não há como distinguir se o coordenador está inativo/finalizado ou se a permissão não foi concedida;

● ... posto que em ambos os casos não há mensagem de retorno.

● conclusão – benefícios advindos da simplicidade podem superar as potenciais desvantagens como ponto central de falha ou gargalo de desempenho em grandes sistemas.



6.3.2 Algoritmo Descentralizado

● essência – cada recurso pode ser replicado “n” vezes, com cada réplica tendo o seu próprio coordenador responsável pelo controle de acesso pelos processos que concorrem pelos recursos;

● ... quando um processo quer acessar um recurso, ele necessita de um nro majoritário de votos “m” > “n/2” coordenadores;

● ... assume-se que se um coordenador não concede acesso a um dado recurso, ele deve responder ao processo solicitante.

● análise – ... este esquema torna a solução centralizada menos vulnerável a falhas em razão de um único coordenador;

● ... o problema é como se dá a recuperação da execução de um coordenador após uma falha ter ocorrido ?!



… 6.3.2 Algoritmo Descentralizado

● Se a suposição é que quando um coordenador falha, ele se recupera rapidamente sem se lembrar dos votos que concedeu antes de ter sofrido a falha, ou seja, não guarda o estado ...

● ... uma possível consequência é a concessão de uma permissão já encaminhada a um processo após a sua recuperação.

● Seja “p” a probabilidade do coordenador reinicializar-se durante o intervalo de tempo “delta” “t”, assim, a probabilidade P[ k ] que “k” coordenadores de um total de “m” coordenadores reinicializem durante o mesmo intervalo de tempo é:

P[ k ] = {m k} * pk * (1 – p) m-k



… 6.3.2 Algoritmo Descentralizado

● Seja “p” a probabilidade do coordenador reinicializar-se durante o intervalo de tempo “delta” “t”, assim, a probabilidade P[ k ] que “k” coordenadores de um total de “m” coordenadores reinicializem durante o mesmo intervalo de tempo é:

P[ k ] = {m k} * pk * (1 – p) m-k

● ... dado que ao menos “2*m – n” coordenadores necessitam reinicializar para violar a corretude do mecanismo de votação, a probabilidade que a violação ocorre é:

somatório P[ k ] com k = 2*m–n até n



6.3.3 Algoritmo Distribuído

● Para muitos, algoritmos corretos do ponto de vista da probabilidade não são suficientes, faz-se necessário algoritmos distribuídos determinísticos para garantir a mútua exclusão;

● “idéia” - … quando um processo deseja acessar um recurso compartilhado, ele constroi uma mensagem contendo o nome do recurso, nro do processo e o tempo lógico corrente;

● ... na sequência envia a mensagem para todos os outros processos, incluindo o próprio processo;

● ... quando um processo recebe uma requisição de um outro processo, a ação depende do seu estado com respeito ao recurso.

● Obs.: ... assume-se como premissa que a comunicação é confiável, ou seja, não há perda de mensagens.



… 6.3.3 Algoritmo Distribuído

● 03 diferentes casos são considerados:

● ... se o receptor não está acessando o recurso e não deseja acessá-lo, o mesmo envia uma mensagem de Ok ao remetente;

● ... se o receptor está acessando o recurso, ele simplesmente não responde, mas empilha a requisição do remetente;

● se o receptor deseja acessar o recurso mas ainda não o fez, ele compara o “timestamp” da mensagem que chegou com alguma mensagem que solicitou o recurso – menor “timestamp” vence;

● se a mensagem recebida contém o menor “timestamp”, o receptor envia de volta uma mensagem de Ok;

● se a sua mensagem contempla o menor “timestamp”, o receptor empilha a requisição que recebeu e não envia resposta.




● ... após enviar as requisições, um processo aguarda até que alguém conceda a permissão, de modo que tão logo a receba o processo vai em frente e utiliza o recurso;

● ... ao final da região crítica, o processo envia uma mensagem de Ok a todos os processos na sua fila e na sequência remove-os.

● e.g., considere 03 processos P0, P1 e P2 onde P0 e P2 desejam um recurso compartilhado ao mesmo tempo, mas P0 tem o menor “timestamp” quando comparado ao “timestamp” de P2.

● ... algoritmo funciona pois em caso de conflito, o menor “timestamp” vence e todos concordam com a ordenação das marcas de tempo, ou seja, “timestamps”.




● Fig. 6.15 – 02 processos P0 e P2 desejam um recurso compartilhado ao mesmo tempo, mas o P0 tem o menor “timestamp”. Ao final da utilização do recurso, P0 envia uma mensagem de Ok.




● ... note que a situação poderia ter sido diferente se P 2 tivesse enviado mais cedo a requisição antes que P0 tivesse feito a própria solicitação, pois neste caso, teria concedido;

● ... neste caso, P2 poderia notificar que tem acesso ao recurso no momento da requisição e, assim, não enviaria um “reply”.

● Como discutido anteriormente, a exclusão mútua é garantida sem “deadlock” e “starvation” e o nro de mensagens exigido por entrada é de 2*(n-1) onde “n” é o total de processos;

● ... outro aspecto igualmente importante é que não temos um ponto único de falha como na abordagem centralizada;

● ... na verdade, substituimos um único ponto de falha por “n” pontos de falha pois implica na não resposta às requisições !?




● ... quando um processo não responde a uma requisição, este silêncio pode ser interpretado incorretamente como uma negação de permissão - “denial of permission”;

● ... que por sua vez irá bloquear todas as tentativas subsequentes de todos os processos para entrar nas regiões críticas.

● Considerando que a probabilidade de um dos “n” processos falhar seja ao menos “n” vezes maior que a falha de um coordenador (algoritmo centralizado), qual a essência da proposta ?

● ... substituir um algoritmo pobre por um que é “n” vezes pior além de requerer maior tráfego na rede de comunicação.

● ... que modificações/alterações incluir para melhorar a proposta ?




● ... uma possibilidade é o receptor responder com “reply” negando ou concedendo permissão a toda e qualquer requisição que chega, mas ainda assim problemas persistem;

● ... no caso de uma requisição ou resposta se perderem, o remetente finaliza ou continua tentando até receber uma resposta ou então o remetente conclui que o receptor está morto;

● ... no caso da requisição ser negada, após inúmeras tentativas, o remetente será bloqueado a espera da subsequente mensagem de Ok – situação na qual poderá acessar a região crítica.




● Outro problema é a necessidade de se utilizar primitivas de comu- nicação “multicast”, senão, cada processo precisa manter uma lista de membros do grupos;

● ... tal lista de membros implicará em operações para entrada e saída de membros, ou seja, funciona para pequenos grupos.

● Finalmente, em algoritmos distribuídos, todos os processos são envolvidos em todas as decisões relacionadas ao acesso do recurso compartilhado, assim surge uma questão ...

● ... se considerarmos que um processo seja incapaz de tratar uma carga, forçar todos os processos a executarem a mesma coisa em paralelo não irá ajudar muito.



6.3.4 Algoritmo Token Ring

● Uma abordagem completamente diferente para garantir a exclusão mútua em um sistema distribuído, utiliza-se do modo determinístico para garantir que cada processo acesse um recurso objeto de concorrência e/ou compartilhamento;

● ... em essência, uma mensagem especial “token” circula entre os pares de processos garantindo a cada um em um dado momento a chance de acessar um recurso objeto da concorrrência;

● ... esta ordenação inerente ou não pode ser obtida com topologia de barramento ou de anel lógico dos processos que concorrem.



… 6.3.4 Algoritmo Token Ring

● Fig. 6.16 – a. Grupo não ordenado de processos em rede. b. Anel lógico de processos construído em software.




● ... quando o anel é inicializado, concede-se ao P0 o “token” que pode circular no anel de processo a processo, ou seja, de Pk a Pk+1 com mensagens ponto a ponto;

● ... quando um processo adquire um “token” de um vizinho, ele verifica se quer acessar um recurso compartilhado e, se sim, acessa o recurso compartilhado e ao final o libera;

● ... na sequência repassa o “token” para o vizinho no anel lógico;

● ... se o processo não tem interesse no acesso do recurso, ele simplesmente repassa o “token” para o anel;

● ... se nenhum processo requer acesso ao recurso, o “token” simplesmente circula no anel em alta velocidade.




● Como pode ser observado, somente um processo por vez tem a posse do “token”, assim somente um processo pode obter o recurso objeto da concorrência e/ou compartilhamento;

● ... necessário garantir a existência de um único “token”.

● ... “starvation” não está presente, pois o “token” circula entre os processos em uma ordem previamente definida;

● ... no pior caso quando um processo deseja acesso o recurso, o mesmo terá apenas que esperar pela passagem do “token”.




● Por outro lado, este algoritmo também apresenta problemas, como p.ex., perda do “token” (raro, mas pode acontecer);

● ... se acontecer, faz-se necessário a geração de um novo “token” e, adicionalmente, a aparição do “token” não é determinística, ou seja, não há limites de quanto em quanto tempo aparecerá;

● e.g., ... fato do “token” não ter aparecido por uma hora não significa que o mesmo foi perdido, muito provavelmente alguém está utilizando e irá liberá-lo em algum momento.

● ... em caso de pane no processo, a recuperação é mais fácil que em outros casos pois o “token” pode ser repassado para o próximo processo da lista ou o processo é recuperado.



… 6.3.5 Comparação dos 04 Algoritmos

● Para comparação dos 04 algoritmos anteriormente discutidos, 03 propriedades chaves são analisadas (Fig. 6.17):

a. nro de mensagens por um processo para acessar e liberar o recurso;

b. atraso antes do acesso ao recurso;

c. problemas associados com cada um dos algoritmos.




● Como pode ser constatado, o Algoritmo Centralizado é o mais simples e o mais eficiente por requer apenas 03 mensagens para solicitar o acesso bem como liberar um recurso.

● Algoritmo Distribuído requer “n-1” mensagens, uma para cada um dos demais processos e um adicional de “n-1” mensagens de permissão de um total de “2*(n-1)” mensagens;

● ... premissa: apenas comunicação ponto a ponto é utilizada.

● Algoritmo Token Ring teremos a média de uma passagem de “token” por entrada e saída por região crítica;

● ... por outro lado o “token” pode circular por horas sem ninguém se interessar por ele e, neste caso, o nro de mensagens por entrada na região crítica não está limitado.




● ... diferença semelhante está presente em relação ao tempo decorrido entre a sinalização do processo para entrar na região crítica até de fato obter permissão para acessá-la;

● ... tempo de espera torna-se um fator dominante quando recursos são utilizados por longos períodos de tempo.

● Por fim, todos os algoritmos sofrem pelo evento de acidentes - “crashes” com exceção do algoritmo descentralizado;

● ... neste caso, medidas especiais e complexidade adicional devem ser introduzidas para evitar que um acidente coloque todo o sistema em risco.

● ... irônico perceber que o algoritmo distribuído seja tão sensível a acidentes quando comparado com o algoritmo centralizado. !!!


6 Sincronização - 6.4 Algoritmos de Eleição

6.4 Algoritmos de Eleição

● Muitos sistemas distribuídos exigem que um processo atue como coordenador, iniciador ou algo que realize um papel especial;

● ... geralmente o que importa não é a responsabilidade em si, mas que algum processo necessita realizá-la.

● Em geral, algoritmos de eleição dedicam-se a localizar o processo com o maior nro de identificação para na sequência designá-lo como coordenador ou iniciador;

● ... os algoritmos diferem no modo que localizam o coordenador.



… 6.4 Algoritmos de Eleição

● premissa – cada processo é identificado por um nro. único, p.ex., endereço de rede se tivermos um processo por máquina;

● ... todo processo conhece o nro. único que identifica cada um dos demais processos do sistema.

● “objetivo” – garantir que uma vez iniciada a eleição, a conclusão virá com a indicação do coordenador através da concordância de todos os processos do sistema.



6.4.1 Algoritmos Tradicionais de Eleição

● Bully Algorithm - ... projetado por Garcia-Molina 1982, inicia-se quando um processo percebe que o coordenador não mais responde às requisições, neste caso inicia-se uma eleição:

● P envia uma mensagem “ELECTION” para todos os processos cujos identificadores sejam maiores que o seu identificador;

● se nenhum processo que recebeu a mensagem responde, P vence a eleição e torna-se o coordenador;

● se um processo dentre aqueles que receberam a mensagem responde, o mesmo assume o controle e P é finalizado.

● Na sequência, anuncia a vitória enviando a todos os processos que a partir daquele momento é o novo coordenador.



… 6.4.1 Algoritmos Tradicionais de Eleição

● Fig. 6.20 – a. P4 aguarda por uma eleição; b. P5 e P6 respondem, pedindo ao P4 que pare; c. P5 e P6 mantém uma eleição.




● Fig. 6.20 – Bully Algorithm: d. P6 solicita que P5 pare; e. P6 vence e informa a todos o novo coordenador.




● Um outro algoritmo de eleição tem por base o anel, sem no entanto utilizar o “token” como mensagem especial;

● ... assume-se que os processos estão fisicamente ou logicamente ordenados, de modo que cada processo conheça o seu sucessor.

● ... quando um processo percebe que o coordenador não está res- pondendo, ele constroi uma mensagem ELECTION contendo o número de processo e envia para o seu sucessor;

● ... se o sucessor não responder, o remetente procura pelo próximo membro no anel até encontrar um processo;




● ... se a mensagem voltar ao processo que iniciou, o processo reconhece o evento de receber uma mensagem contendo o seu próprio número de processo;

● ... neste ponto, a mensagem muda de tipo para COORDINATOR e circula mais uma vez, agora para informar a todos quem é o coordenador e quais os membros do anel;

● ... uma vez que a mensagem circule todo o anel, o remetente a remove e os processos iniciam seus trabalhos.




● Fig. 6.21 – Algoritmo de Eleição: P2 e P5 descobrem simultaneamente que P7 (coordenador) foi finalizado. Cada qual controi uma mensagem ELECTION e inicia a sua circulação pelo anel.




● ... eventualmente ambas as mensagens circulam pelo anel e são convertidas para mensagens COORDINATOR. Quando ambas percorrerem o anel, ambas as mensagens serão removidas.



6.4.2 Eleição em Ambientes Wireless

● Algoritmos de Eleição tradicionais são geralmente baseados na suposição que não são realísticos no ambiente sem fio;

● ... estas suposições são falsas em muitos ambientes sem fio, especialmente nas redes móveis “ad hoc”.

● “essência” – para eleger um lider, qualquer nó na rede, chamado de nó fonte pode iniciar uma eleição enviando uma mensagem ELECTION para o seu vizinho imediato;

● ... quando um nó recebe uma mensagem ELECTION pela primeira vez, este nó designa o remetente como o seu pai;

● ... na sequência envia a mensagem ELECTION para todos os vizinhos imediatos, exceto para o nó pai;

● ... ao final cada nó reporta ao nó pai o nó com maior capacidade.



… 6.4.2 Eleição em Ambientes Wireless

● Fig. 6.22 – Algoritmo de Eleição em Rede sem Fio: Nó “a” inicia a eleição enviando para “b” e “j” uma mensagem ELECTION.




● Fig. 6.22 – Algoritmo de Eleição em Rede sem Fio: ... a partir dos nós “b” e “j” a mensagem é propagada para os outros nós.




● Fig. 6.22 – Algoritmo de Eleição em Rede sem Fio: ... a partir dos nós “b” e “j” a mensagem é propagada para os outros nós.

● Na sequência, cada nó reporta ao nó pai o nó com maior capacidade.




● ... quando múltiplas eleições são iniciadas, cada nó irá decidir se juntar a um única eleição, neste sentido, cada nó fonte rotula sua mensagem ELECTION com um identificador único;

● ... nós irão participar somente da eleição com o maior identificador, interrompendo assim qualquer participação em alguma outra eleição em que porventura tenham se juntado.



6.4.3 Eleições em Sistemas de Larga Escala

● Em sistemas distribuídos pequenos, os algoritmos se concentram na seleção de um único nó coordenador;

● ... há situações onde é necessário eleger mais de um coordenador, ou seja, vários nós são selecionados como no caso de super nós em redes ponto a ponto.

● Dentre os requisitos que precisam ser satisfeitos para a seleção de super nós, destacamos:

● nós normais devem baixa latência de acesso aos super nós;

● super nós devem eventualmente distribuir na rede de sobreposição;

● deve ter sido definido uma porção de super nós relativo ao total de nós na rede de sobreposição;

● cada super nó não precisa atender mais que um nro fixo de nós.



… 6.4.3 Eleições em Sistemas de Larga Escala

● Fig. 6.23 – Deslocamento de “tokens” em um espaço bidimensional usando forças repulsivas.

Cap. 06 – Sincronização - FACOMfaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch06.pdf · 6.2 – Relógios...

Documents

Transcript of Cap. 06 – Sincronização - FACOMfaina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch06.pdf · 6.2 – Relógios...