130 likes | 200 Views
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.
E N D
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érico Procedure 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 caso end
Sistemas Assíncronos Multicast_1 => AS_Rel_Multicast Multicast_2 => Multisend Excepção => Suspeita de falha Propõe(x) => Unif_Cons(x)
Protocolo Genérico Procedure 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 caso end
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érico Procedure 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 caso end
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.