As implementações intertravadas baseadas no CompareExchange devem usar o SpinWait?

Abaixo está uma implementação de um método intertravado baseado em Interlocked.CompareExchange.

É aconselhável que esse código use uma SpinWaitrotação antes de reiterar?

public static bool AddIfLessThan(ref int location, int value, int comparison)
{
    int currentValue;
    do
    {
        currentValue = location; // Read the current value
        if (currentValue >= comparison) return false; // If "less than comparison" is NOT satisfied, return false
    }
    // Set to currentValue+value, iff still on currentValue; reiterate if not assigned
    while (Interlocked.CompareExchange(ref location, currentValue + value, currentValue) != currentValue);
    return true; // Assigned, so return true
}

Eu já vi SpinWaitusado nesse cenário, mas minha teoria é que deveria ser desnecessário. Afinal, o loop contém apenas algumas instruções e sempre há um thread em progresso.

Digamos que dois threads estejam correndo para executar esse método, e o primeiro thread seja bem-sucedido imediatamente, enquanto o segundo thread inicialmente não faz alterações e precisa reiterar. Sem outros concorrentes, é possível que o segundo thread falhe em sua segunda tentativa ?

Se o segundo thread do exemplo não puder falhar na segunda tentativa, o que podemos ganhar com a SpinWait? Eliminando alguns ciclos no caso improvável de centenas de threads correrem para executar o método?

Minha opinião de não especialista é que, nesse caso em particular, onde duas threads ocasionalmente chamam AddIfLessThan, a SpinWaité desnecessário. Pode ser benéfico se os dois threads estiverem chamando AddIfLessThanem um loop apertado, para que cada thread possa progredir ininterruptamente por alguns μs.

Na verdade, fiz um experimento e medi o desempenho de um thread chamando AddIfLessThanem um loop apertado versus dois threads. Os dois threads precisam quase quatro vezes mais para criar o mesmo número de loops (cumulativamente). A adição de SpinWaita à mistura torna os dois segmentos apenas um pouco mais lentos que o único.

Dois tópicos simplesmente não são um assunto para SpinWaitdiscussão. Mas esse código não nos diz quantos threads realmente podem competir pelo recurso e, com um número relativamente alto de threads, o uso do SpinWaitpode se tornar benéfico. Em particular, com um número maior de encadeamentos, a fila virtual de encadeamentos, que está tentando adquirir o recurso com sucesso, fica mais longa e os encadeamentos que são servidos no final têm boas chances de exceder seu intervalo de tempo alocado pelo agendador que, por sua vez, pode levar a um maior consumo de CPU e pode afetar a execução de outros encadeamentos agendados, mesmo com maior prioridade. oSpinWaittem uma boa resposta para essa situação, definindo um limite superior de rotações permitidas, após o qual a alternância de contexto será executada. Portanto, é uma troca razoável entre a necessidade de fazer uma chamada cara do sistema, a fim de acionar uma alternância de contexto e um consumo descontrolado de CPU do modo de usuário que corre o risco de afetar a execução de outros threads em determinadas situações.