Por que o número de consenso para teste e configuração é 2?

Segundo a Wikipedia ,

A operação de teste e configuração pode resolver o problema de consenso sem espera por não mais que dois processos simultâneos.

Por que não pode resolver o problema por mais de dois processos?

Apenas para garantir que estamos na mesma página, primeiro consideremos estas três definições:

Definição. Test-and-set é uma instrução de leitura-modificação-gravação em algum registro binário (digamos que 0 e 1 são valores possíveis) em que um thread obtém o valor antigo e grava 1.

Definição. É alcançado consenso entre threads se todos os threads decidirem o mesmo valor (o requisito de consistência) e todos os threads decidirem sobre um valor que foi realmente proposto por um dos threads (o requisito de validade).$n$$n$

Definição. Um protocolo de consenso fica livre de espera se toda chamada de método terminar em um número finito de etapas.

Agora siga dois esboços de prova.

Reivindicação 1. O número de consenso de teste e configuração é pelo menos 2. Prova. Suponha que tenhamos dois threads 0 e 1 que precisam chegar a um consenso. Poderíamos fazer isso deixando que cada thread seguisse o protocolo de consenso abaixo:

1. Escreva seu valor proposto em , onde é o ID do encadeamento e é uma matriz de tamanho 2.t $A[t]$$t$$A$
2. Execute as instruções de teste e configuração em algum registro , com R inicializado em 0.$R$$R$
3. Se o valor de retorno for 0, você foi o primeiro: retorne . Caso contrário, você seria o segundo: retornar A [ | t - 1 | ] .$A[t]$$A[|t-1|]$

Você pode verificar se o consenso e a espera não são satisfeitos. $\square$

(Para a próxima prova, aninharei algumas provas e definições porque acho que facilitará o acompanhamento.)

Reivindicação 2. O número de consenso de teste-e-conjunto é no máximo 2. Prova. Por contradição. Suponha que temos três linhas , B e C que desejam decidir sobre valores a , b e c , respectivamente, e que temos algum protocolo de consenso livre de espera válido que é implementado utilizando test-and-set (e lê e escreve atômica )$A$$B$$C$$a$$b$$c$

Podemos visualizar o processo de consenso como uma árvore direcionada, onde:

• A raiz é o estado em que nenhum dos threads 'fez um movimento';
• O filho esquerdo de um nó representa o estado resultante após uma movimentação de , o filho do meio representa o estado resultante após uma movimentação de B e o filho direito representa o estado resultante de uma movimentação de C ;$A$$B$$C$
• Um nó folha representa um estado em que todos os encadeamentos foram finalizados. Associado a um nó folha está um valor , b ou c , em que o valor depende de qual valor foi decidido para essa execução específica.$a$$b$$c$

Definição. Permita que um estado seja multivalente se o resultado do processo de consenso ainda não estiver determinado. Em outras palavras, nem todas as intercalações possíveis dos movimentos restantes levam ao mesmo resultado. Deixe um estado ser univalente quando o resultado do processo de consenso for determinado.

A raiz é multivalente. Prova. Se apenas um segmento estiver ativo e os outros segmentos permanecerem inativos para sempre, então X terminará em um número finito de etapas (garantido pela suposição de ausência de espera) e decidirá x (pois ele tem apenas acesso a esse valor e sua decisão satisfará o requisito de validade de consenso). Assim, para a nossa situação, a , b e c são todos os resultados possíveis. $X$$X$$x$$a$$b$$c$$\square$

Definição. Deixe um estado crítico ser um estado que é multivalente, com a propriedade adicional que um movimento por vão determinar um , e uma jogada de B irá determinar b .$A$$a$$B$$b$

Existe um estado crítico. Prova. De cima, sabemos que começamos em um estado multivalente. Deixe não fazer nenhum movimento. Desde que A ou B não force a árvore a um estado univalente, deixe-a agir. A ausência de espera garante que a árvore seja finita; portanto, em algum momento, um estado crítico deve ser encontrado. $C$$A$$B$$\square$

Agora considere um cenário em que estamos em um estado crítico. Existem pelo menos duas possibilidades:

1) faz o seu movimento (determinando assim a ) e pára. B então faz o seu movimento e pára. O próximo C é executado até terminar, eventualmente decidindo a .$A$$a$$B$$C$$a$

2) faz o seu movimento (determinando assim b ) e pára. O próximo C é executado até terminar, eventualmente decidindo b . A não faz um movimento.$B$$b$$C$$b$$A$

Como as leituras e gravações atômicas têm o número de consenso 1, os movimentos de e B tiveram que ser instruções de teste e configuração no mesmo registro (se os registros forem diferentes, C não seria capaz de dizer a ordem em que A e Os movimentos de B aconteceram). Da perspectiva de C , então, os cenários 1 e 2 são indistinguíveis, portanto devemos ter que C decida ambos a e b . Isto é impossível. $A$$B$$C$$A$$B$$C$$C$$a$$b$$\square$

O fato de a instrução de teste e ajuste possuir o número de consenso 2 segue das reivindicações 1 e 2.

O artigo da wikipedia tem uma referência que responde à sua pergunta, mas talvez você não queira ler esse documento de 26 páginas. Darei uma versão simplificada da prova (bastante técnica), mostrando que o teste e o conjunto não podem resolver o consenso binário para três processos. Esse tipo de argumento é amplamente usado para provar números de consenso.

Vamos supor que temos um algoritmo de consenso usando registros TAS para 3 processos.

A qualquer momento, cada processo terá um movimento (instrução) pronto para ser executado. Qual das três instruções será executada é não determinística.

Suponha que estamos em um estado bivalente (um estado no qual ainda é possível uma decisão 0 ou 1) e, conforme o processo que se segue, o estado subsequente será univalente. Esse estado deve ser alcançado devido à condição de espera sem espera.

Suponha (wlg) que se o processo 1 for movido, o estado será 0-valente e que se o processo 2 for movido, o estado será 1 valente. Ambos os movimentos devem ser uma operação TAS (ou pelo menos: algum tipo de gravação) no mesmo registro, pois se fossem operações TAS em registros distintos, não poderíamos dizer se o processo 1 foi movido primeiro ou o processo 2 foi movido primeiro.

Vamos considerar essas duas execuções possíveis:

• O processo 1 se move primeiro, depois o processo 2 se move e o processo 3 é executado sozinho
• O processo 2 se move primeiro, depois o processo 3 é executado sozinho

Do ponto de vista do processo 3, esses estados são indistinguíveis, pois apenas vê o valor gravado pelo processo 2. No entanto, no primeiro caso, ele deve dar 0 como saída e no segundo 1 como saída. Claramente, isso é uma contradição.

Os processos 1 e 2 podem decidir entre si quais se moveram primeiro (porque podem ver qual valor havia no registro antes de serem gravados), mas um terceiro processo de espectador não pode.

Outra maneira de provar que o teste e conjunto não pode ser usado para resolver o consenso de três processadores é mostrar que o teste e o conjunto podem ser implementados usando o consenso de dois processadores. Então, supondo que o teste e conjunto possa resolver o consenso de três processadores leva a uma contradição: suponha que o teste e o conjunto possam resolver o consenso de três processadores; substituindo test-and-set por sua implementação usando o consenso de 2 processadores, obtém-se uma implementação do consenso de 3 processadores usando o consenso de 2 processadores, o que é impossível. Portanto, o teste e conjunto não pode resolver o consenso de três processadores.

Para implementar o teste-e-conjunto para n-processadores usando o consenso de 2 processadores, permita que os processadores determinem um vencedor do teste-e-conjunto usando um torneio em que cada partida é implementada usando o consenso de 2 processadores (em uma partida, os processadores propor seu identificador e o resultado do consenso informa quem vence).

No sentido prático, uma definição de consenso menos estrita pode ser suficiente (aqui eu chamo de consenso leve):

Definição . O consenso de luz é alcançado entre n threads, se (a) cada thread decidir sobre o mesmo valor ou o valor for desconhecido, (b) pelo menos um thread souber o valor e (c) esse valor foi realmente proposto por um dos os fios.

Portanto, esse consenso em seu sentido mais claro permite que algum segmento não conheça o consenso, o valor que é decidido.

Corolário : nesse sentido mais claro, o teste e configuração tem um número infinito de consenso de luz.

Reivindicação : Esse sentido mais leve é ​​prático. Por exemplo, para selecionar o segmento para entrar na seção crítica, não é necessário criar consenso no sentido estrito. Ou seja: cada thread deve saber se foi selecionado ou não, no entanto, se não for selecionado, não precisará saber qual foi selecionado. Em outras palavras, para exclusão mútua, não é necessário um consenso estrito, basta luz.