¿Las implementaciones entrelazadas basadas en CompareExchange deben usar SpinWait?

A continuación se muestra una implementación de un método entrelazado basado en Interlocked.CompareExchange.

¿Es aconsejable que este código use un SpinWaitgiro 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
}

Lo he visto SpinWaitusado en este escenario, pero mi teoría es que debería ser innecesario. Después de todo, el bucle solo contiene un puñado de instrucciones, y siempre hay un hilo que avanza.

Digamos que dos hilos están compitiendo para realizar este método, y el primer hilo tiene éxito de inmediato, mientras que el segundo hilo inicialmente no hace ningún cambio y tiene que reiterar. Sin otros contendientes, ¿es posible que el segundo hilo falle en su segundo intento ?

Si el segundo hilo del ejemplo no puede fallar en el segundo intento, ¿qué podríamos ganar con un SpinWait? ¿Afeitarse algunos ciclos en el improbable caso de que cientos de hilos compitan para realizar el método?

Mi opinión no experta es que en este caso particular, donde dos hilos ocasionalmente llaman AddIfLessThan, a SpinWaites innecesario. Podría ser beneficioso en el caso de que los dos hilos estuvieran llamando AddIfLessThanen un bucle cerrado, de modo que cada hilo pudiera avanzar sin interrupciones durante algunos μseg.

En realidad hice un experimento y medí el rendimiento de una llamada de hilo AddIfLessThan en un bucle cerrado frente a dos hilos. Los dos hilos necesitan casi cuatro veces más para hacer la misma cantidad de bucles (acumulativamente). Agregar SpinWaita la mezcla hace que los dos hilos sean solo un poco más lentos que el hilo único.

Dos hilos no es un tema de SpinWaitdiscusión. Pero este código no nos dice cuántos hilos pueden realmente competir por el recurso y con un número relativamente alto de hilos SpinWaitpuede ser beneficioso. En particular, con un mayor número de subprocesos, la cola virtual de subprocesos, que intentan adquirir con éxito el recurso, se alarga y los subprocesos que finalmente se atienden tienen buenas posibilidades de exceder su intervalo de tiempo asignado por el planificador, que a su vez puede conducir a un mayor consumo de CPU y puede afectar la ejecución de otros subprocesos programados incluso con mayor prioridad. losSpinWaittiene una buena respuesta a esta situación estableciendo un límite superior de giros permitidos después de lo cual se va a ejecutar el cambio de contexto. Por lo tanto, es una compensación razonable entre la necesidad de realizar una costosa llamada al sistema para activar un cambio de contexto y un consumo de CPU en modo de usuario no controlado, que corre el riesgo de afectar la ejecución de otros hilos en ciertas situaciones.