confirmação atómica não-bloqueante
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 PresentationTRANSCRIPT
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
• Protocolo NBAC depende dos votos dos participantes e das falhas dos mesmos
• Requisitos do protocolo– Terminação;– Integridade;– Acordo Uniforme;– Validade;– Não-Trivialidade.
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.
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
Sistemas Assíncronos
• Multicast_1 => AS_Rel_Multicast
• Multicast_2 => Multisend
• Excepção => Suspeita de falha
• Propõe(x) => Unif_Cons(x)
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
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;
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.
Sistemas Assíncronos
• Multicast_1 => Multisend
• Multicast_2 => S_Rel_Multicast
• Excepção => Por timeout
• Propõe(x) => x
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
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;
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.
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.