Confirmação Atómica não-Bloqueante

13
Confirmação Atómica não- Bloqueante Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente, confirmar ou abortar a transacção.

description

Confirmação Atómica não-Bloqueante. Definição do Problema Garantir que todos os participantes correctos de uma transacção tomem a mesma decisão, nomeadamente, confirmar ou abortar a transacção. Confirmação Atómica não-Bloqueante. - PowerPoint PPT Presentation

Transcript of Confirmação Atómica não-Bloqueante

Page 1: Confirmação Atómica não-Bloqueante

Confirmação Atómica não-Bloqueante

• Definição do Problema

Garantir que todos os participantes

correctos de uma transacção tomem a

mesma decisão, nomeadamente,

confirmar ou abortar a transacção.

Page 2: Confirmação Atómica não-Bloqueante

Confirmação Atómica não-Bloqueante

• Protocolo NBAC depende dos votos dos participantes e das falhas dos mesmos

• Requisitos do protocolo– Terminação;– Integridade;– Acordo Uniforme;– Validade;– Não-Trivialidade.

Page 3: Confirmação Atómica não-Bloqueante

Não-Trivialidade

• Para solucionar cenários de falha.

• Decisão independente dos votos e do cenário de falha.– S-Não-Trivialidade - Se todos votam YES e

não existem falhas, então o resultado é Commit;

– AS-Não-Trivialidade - Se todos votam YES e não existem suspeitas de falhas, então o resultado é Commit.

Page 4: Confirmação Atómica não-Bloqueante

Protocolo GenéricoProcedure nbac(voto, participantes)

begin(1.1) multicast_2(voto, participantes);(2.1) espera ((entrega de um voto NO de um participante)(2.2) ou (existe participante q: excepção(q) foi notificada a p)(2.3) ou (de cada participante q: entrega de um voto YES)(2.4) );(3.1) caso(3.2) receba um voto NO -> resultado := propõe(Abort)(3.3) notificação de excepção -> resultado := propõe(Commit)(3.4) todos os votos YES -> resultado := propõe(Commit)(3.5) fim casoend

Page 5: Confirmação Atómica não-Bloqueante

Sistemas Assíncronos

• Multicast_1 => AS_Rel_Multicast

• Multicast_2 => Multisend

• Excepção => Suspeita de falha

• Propõe(x) => Unif_Cons(x)

Page 6: Confirmação Atómica não-Bloqueante

Protocolo GenéricoProcedure AS_nbac(voto, participantes)

begin(1.1) Multisend(voto, participantes);(2.1) espera ((entrega de um voto NO de um participante)(2.2) ou (existe participante q: suspeita(q))(2.3) ou (de cada participante q: entrega de um voto YES)(2.4) );(3.1) caso(3.2) receba um voto NO -> resultado := Unif_Cons(Abort)(3.3) notificação de excepção -> resultado := Unif_Cons(Commit)(3.4) todos os votos YES -> resultado := Unif_Cons(Commit)(3.5) fim casoend

Page 7: Confirmação Atómica não-Bloqueante

Porque é que funciona?• Integridade: por 3.2 e 3.4, se o sub-protocolo

Unif_Cons satisfizer a propriedade;

• Validade: resulta da linha 3.4. Se todos votarem YES, o output de Unif_Cons será Commit;

• Acordo Uniforme: resulta da propriedade Acordo Uniforme do sub-protocolo Unif_Cons;

• AS-Não-Trivialidade: pela Completude do detector de falhas, pelo Acordo Uniforme e Validade de Unif_Cons, segue-se que a decisão será Commit;

Page 8: Confirmação Atómica não-Bloqueante

Porque é que funciona?• Terminação: depende da Completude dos

detectores de falhas. Assuma-se que estes satisfazem a propriedade Completude Forte (i.e., a falha de um participante será suspeitada por todos os correctos). Assuma-se também uma rede fiável. Então p recebe um voto de q ou suspeita dele. Então o comando espera (2.1 a 2.4) termina para cada participante correcto. Pela propriedade de Terminação de Unif_Cons, todos os participantes correctos irão decidir.

Page 9: Confirmação Atómica não-Bloqueante

Sistemas Assíncronos

• Multicast_1 => Multisend

• Multicast_2 => S_Rel_Multicast

• Excepção => Por timeout

• Propõe(x) => x

Page 10: Confirmação Atómica não-Bloqueante

Protocolo GenéricoProcedure S_nbac(voto, participantes)

begin(1.1) S_Rel_Multicast(voto, participantes);(2.0) coloca timer a δ + Δ;(2.1) espera ((entrega de um voto NO de um participante)(2.2) ou (timeout)(2.3) ou (de cada participante q: entrega de um voto YES)(2.4) );(3.1) caso(3.2) receba um voto NO -> resultado := Abort(3.3) timeout -> resultado := Commit(3.4) todos os votos YES -> resultado := Commit(3.5) fim casoend

Page 11: Confirmação Atómica não-Bloqueante

Porque é que funciona?• Terminação: ninguém espera mais que δ + Δ;

• Integridade: resulta da estrutura do protocolo;

• Validade: resulta de linha 3.4;

• S-Não-Trivialidade: Se não existirem falhas todos votam. Cada participante recebe os votos antes do seu timer expirar. Se os votos são todos YES então Commit;

Page 12: Confirmação Atómica não-Bloqueante

Porque é que funciona?• Acordo Uniforme: por absurdo, se p decide Commit e q

Abort então por 3.4, p recebeu YES de todos e q decidiu em 3.2 ou 3.3. Em 3.2 é impossível porque todos enviam o mesmo voto para p e q (YES). Por 3.3 o timer de q (δ + Δ) expirou, por não receber o voto de r. Mas, no pior caso, r recebeu trans δ após q receber. Como p recebeu YES de r, pela propriedade de acordo uniforme da primitiva S_Rel_Multicast usada por r ao enviar o seu voto e pelo limite Δ associado a essa primitiva, segue-se que q recebeu o voto de r antes do seu timer expirar. Contradição.

Page 13: Confirmação Atómica não-Bloqueante

Optimizações• Se p recebe um voto NO de q pode decidir

abortar imediatamente.

• Para Unif_Cons terminar p terá que propor um valor (Abort). No entanto, não terá que esperar pelo output pois já decidiu Abort.

• Pode também disseminar a decisão de Abort aos outros participantes através da primitiva AS_Rel_Multicast.