Relógios Lógicos. Sumário. November 27, Relação Happened-Before. Relógios de Lamport. Relógios Vectoriais

Transcrição

1 Relógios Lógicos November 27, 29 Sumário Relação Happened-Before Relógios de Lamport Relógios Vectoriais

2 Eventos Nem sempre é necessário ter relógios sincronizados: Muitas vezes, é suficiente estabelecer uma ordem entre eventos. Um evento é a ocorrência duma acção executada por um processo: Ao longo da sua execução, um processo pode executar uma dada acção múltiplas vezes, a cada uma dessas ocorrências corresponde um evento. Assim, a execução dum processo P i consiste numa sequência de eventos: e i, e1 i, e2 i,... Relação Happened-Before (1/2) Eventos num sistema distribuído podem ser ordenados usando a relação happened-before, proposta por Lamport, denotada e definida como se segue: HB1 se e e e são eventos que ocorrem no mesmo processo por aquela ordem, então: e e ; HB2 se e é a transmissão duma mensagem e e a recepção dessa mensagem, então e e ; HB3 se e e e e e, então e e.

3 Relação Happened-Before (2/2) p 1 a b p 2 c d p 3 e m 2 f A relação happened-before é uma relação parcial: (a e) (e a) Eventos como a e e dizem-se concorrentes: a e. A relação captura o fluxo de informação entre eventos: indica potencial causalidade entre eventos; atenção a canais de comunicação externos/ocultos. Lamport Clocks and Timestamps (1/3) Além da relação, Lamport propôs: o uso dum relógio lógico por processo, conhecido por Lamport clock; a associação de timestamps geradas por esse relógio, Lamport timestamps, a cada evento. A relação entre a relação e Lamport timestamps é: e e L(e) < L(e )

4 Relógios Físicos e a Relação HB P 1 P 2 P 3 P 1 P 2 P m P 2 adjusts m its clock m m m m P adjusts its clock (a) (b) Relógios físicos não sincronizados não podem ser usados para gerar a Lamport timestamps. Lamport Clocks and Timestamps (2/3) As Lamport timestamps são geradas em cada processo, p i pelo Lamport clock local, L i. A actualização de L i é feita de acordo com as seguintes regras: LC1 L i é incrementado antes de p i executar um evento; LC2 a) Quando um processo p i envia uma mensagem m, anexa-lhe o valor t = L i ; b) Quando um processo p j recebe uma mensagem (m, t), actualiza o seu relógio L j = max(l j, t) e depois aplica LC1 antes de atribuir uma timestamp ao evento receive(m).

5 Lamport Clocks and Timestamps (3/3) p 1 p 2 p 3 a 1 b 2 e c d 3 4 m f Pode usar-se pares: (L(e), i) onde i é o identificador do processo para definir uma ordem total entre eventos. Porém, esta ordem é arbitrária. A principal limitação de Lamport timestamps é: L(e) < L(e ) / e e Uso de Lamport Clocks and Timestamps (1/3) Problema Como garantir ordem total em comunicação multicast? Solução Usar Lamport clocks e usar as Lamport timestamps para ordenar as mensagens. Importante distinguir entre entrega e recepção duma mensagem. Application layer Application sends message Message is delivered to application Adjust local clock and timestamp message Adjust local clock Middleware layer Middleware sends message Message is received Network layer

6 Uso de Lamport Clocks and Timestamps (2/3) Os únicos eventos que interessam são o envio de mensagens: p i incrementa L i antes de fazer o multicast; p j ajusta L j quando entrega a mensagem, mas não precisa de a incrementar previamente. Problemas E se os emissores pertencerem também ao grupo? Como garantir que mensagens enviadas ao mesmo tempo são consideradas por todos os destinatários? E falhas na comunicação? Uso de Lamport Clocks and Timestamps (3/3) O processo p j insere cada mensagem recebida numa fila de mensagens ordenadas por ordem crescente das suas timestamps; O processo p j entrega a mensagem m i à aplicação se: 1. m i está à cabeça da fila; 2. tiver recebido uma mensagem m k de cada um dos restantes processos p k. Pressupostos em Relação ao Canal de Comunicação Canal é fiável. Canal garante ordem (FIFO) na comunicação ponto-a-ponto.

7 Vector Clocks (1/3) A ideia (de Mattern, Fidge e Schmuck) é datar eventos usando vectores de relógios lógicos locais. O processo i mantém o seu próprio vector V i, o qual é actualizado de acordo com as seguintes regras: VC1 Inicialmente: V i [j] =, j VC2 Antes de p i datar um evento: V i [i] = V i [i] + 1 VC3 Sempre que envia uma mensagem, p i inclui o valor t = V i VC4 Quando p i recebe uma mensagem: V i [j] = max(v i [j], t[j]), j Isto é: V i [i] - n o de eventos datados por p i ; V i [j] - n o de eventos em p j que potencialmente afectaram p i. Vector Clocks (2/3) Seja: Então: V < V iff j : V [j] V [j] i : V [i] < V [i] e e V (e) < V (e ) V (e) < V (e ) e e Por outro lado: (V (e) < V (e )) (V (e ) < V (e)) e e

8 Vector Clocks (3/3) p 1 p 2 a (1,,) b (2,,) (2,1,) e f p 3 (,,1) (2,2,2) c d (2,2,) m 2 Note-se que a e e são eventos concorrentes. O principal inconveniente é a necessidade de n timestamps, enquanto que Lamport clocks exigem uma única: Mas não há maneira de o evitar (Charron-Bost). Causally Ordered Multicasting (1/2) Problema Como garantir ordem causal em comunicação multicast? Solução Usar vector clocks e usar as vector timestamps para ordenar as mensagens. Importante distinguir entre entrega e recepção duma mensagem. Os únicos eventos que interessam são o envio de mensagens: p i incrementa VC i [i] antes de fazer o multicast; p j ajusta VC j quando entrega a mensagem, mas não incrementa VC j [j]

9 Causally Ordered Multicasting (2/2) P VC = (1,,) VC = (1,1,) m P 1 VC = (1,1,) 1 m* VC = (1,1,) 2 P 2 VC 2 = (,,) VC 2 = (1,,) Leitura Adicional Capítulo 6 de Tanenbaum e van Steen, Distributed Systems, 2nd Ed. Secção 6.2: Logical Clocks