XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010
XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010
XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>XI</strong> <strong>Workshop</strong> <strong>de</strong> <strong>Testes</strong> e Tolerância a <strong>Falhas</strong> 9<br />
Task T 1: every monitoringInterval do<br />
(1) for_each p j , p j ≠ p i do<br />
(2) timeout i [p j ] ← CT i () + 2δ + α;<br />
(3) send “are-you-alive?” message to p j<br />
(4) end<br />
Task T 2: when ∃p j : (p j /∈ faulty i ) ∧ (CT i () ><br />
timeout i [p j ])) do<br />
(5) if (QoS(c i/j ) = T ) then<br />
(6) faulty i ← faulty i ∪ {p j };<br />
(7) send notification (p i , p j ) to<br />
every p x such that p x ≠ p i ∧ p x ≠ p j<br />
(8) else do nothing (wait for a remote notification)<br />
(9) end_if<br />
Task T 3: when “I-am-alive” is received from p j do<br />
(10) timeout i [p j ] ← ∞; /* cancels timeout */<br />
(11) if (p j ∈ faulty i ) then<br />
faulty i ← faulty i − p j ;<br />
Task T 4: when notification(p x , p j ) is received do<br />
(12) if p j /∈ faulty i then<br />
(13) faulty i ← faulty i ∪ {p j };<br />
(14) end_if<br />
Task T 5: when “are-you-alive?” is received from p j do<br />
(15) send “I-am-alive” to p j<br />
Figure 1. Algoritmo do <strong>de</strong>tector <strong>de</strong> <strong>de</strong>feitos xP para o processo p i com recuperação.<br />
alteram seu estado entre síncrono/assíncrono.<br />
Como o número <strong>de</strong> partições síncronas existentes é estável, digamos k partições, e por<br />
<strong>de</strong>finição [Macêdo and Goren<strong>de</strong>r 2008, Macêdo and Goren<strong>de</strong>r 2009], toda partição síncrona<br />
possui ao menos um processo que não falha, permanecendo correto, temos no mínimo k<br />
processos que não falham durante a sua execução.<br />
4.2. Mecanismo para eleição <strong>de</strong> lí<strong>de</strong>r<br />
Assumimos a existência <strong>de</strong> um mecanismo para eleição <strong>de</strong> lí<strong>de</strong>r para o mo<strong>de</strong>lo Spa, baseado<br />
no <strong>de</strong>tector <strong>de</strong> <strong>de</strong>feitos utilizado (classe P ou xP ). Este mecanismo sempre indica como lí<strong>de</strong>r<br />
um processo pertencente a alguma partição síncrona (caso a proprieda<strong>de</strong> strong partitioned<br />
synchrony seja válida será qualquer processo). Inicialmente, o mecanismo indica como lí<strong>de</strong>r<br />
do grupo, para cada processo p i ∈ Π, o processo <strong>de</strong> menor i<strong>de</strong>ntificação, que seja membro <strong>de</strong><br />
alguma partição síncrona, e que não tenha a sua i<strong>de</strong>ntificação inserida no conjunto faulty i .<br />
Durante a execução do sistema novos processos lí<strong>de</strong>res po<strong>de</strong>m ser indicados pelo<br />
mecanismo, à medida em que os lí<strong>de</strong>res atuais falhem. Neste caso, quando o módulo do<br />
<strong>de</strong>tector <strong>de</strong> <strong>de</strong>feitos <strong>de</strong> cada processo p i ∈ Π <strong>de</strong>tectar a falha do lí<strong>de</strong>r atual, sendo a i<strong>de</strong>ntificação<br />
<strong>de</strong>ste inserida no conjunto faulty i , um novo processo lí<strong>de</strong>r será escolhido para substituir o que<br />
falhou. Este novo lí<strong>de</strong>r será um processo membro <strong>de</strong> partição síncrona que não apresente falha,<br />
e cuja i<strong>de</strong>ntificação seja a <strong>de</strong> menor número, <strong>de</strong>s<strong>de</strong> que maior do que a i<strong>de</strong>ntificação do lí<strong>de</strong>r a<br />
ser substituído. Desta forma, os lí<strong>de</strong>res serão sempre escolhidos em or<strong>de</strong>m crescente <strong>de</strong> suas<br />
i<strong>de</strong>ntificações. Este dispositivo evita que processos instáveis possam falhar e se recuperar com<br />
freqüência, voltando a li<strong>de</strong>rar o grupo, e gerando instabilida<strong>de</strong> na execução <strong>de</strong> protocolos.<br />
No pior caso, como existem por <strong>de</strong>finição ao menos k processos corretos, um para