1 / 13

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. Confirmação Atómica não-Bloqueante.

Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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.

  2. 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.

  3. 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.

  4. 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

  5. Sistemas Assíncronos Multicast_1 => AS_Rel_Multicast Multicast_2 => Multisend Excepção => Suspeita de falha Propõe(x) => Unif_Cons(x)

  6. 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

  7. 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;

  8. 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.

  9. Sistemas Assíncronos Multicast_1 => Multisend Multicast_2 => S_Rel_Multicast Excepção => Por timeout Propõe(x) => x

  10. 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

  11. 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;

  12. 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.

  13. 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.

More Related