¿Qué tan caro es el estado de bloqueo?

Question

He estado experimentando con multi-threading y procesamiento paralelo y necesitaba un contador para hacer un recuento básico y un análisis estadístico de la velocidad del procesamiento. Para evitar problemas con el uso concurrente de mi clase que he usado un comunicado bloqueo en una variable privada de mi clase:

private object mutex = new object(); 

public void Count(int amount) 
{ 
lock(mutex) 
{ 
    done += amount; 
} 
} 

Pero me preguntaba ... ¿Cuánto cuesta el bloqueo de una variable? ¿Cuáles son los efectos negativos en el rendimiento?

Answer 1

Aquí está an article que va en el costo. La respuesta corta es 50ns.

Answer 2

Esto no responde a su pregunta sobre el rendimiento, pero puedo decir que el .NET Framework es que ofrece un método Interlocked.Add que permitirá que usted agregue su amount a su miembro done sin bloquear manualmente en otro objeto.

Answer 3

lock (Monitor.Enter/Exit) es muy económico, más barato que otras alternativas como Waithandle o Mutex.

Pero, ¿y si fuera (un poco) lento, preferiría tener un programa rápido con resultados incorrectos?

Answer 4

Hay algunas formas diferentes de definir el "costo". Existe la sobrecarga real de obtener y liberar la cerradura; como Jake escribe, eso es insignificante a menos que esta operación se realice millones de veces.

De mayor relevancia es el efecto que esto tiene en el flujo de ejecución. Este código solo se puede ingresar por un hilo a la vez. Si tiene 5 hilos que realizan esta operación de forma regular, 4 de ellos terminarán esperando a que se libere el bloqueo, y luego será el primer hilo programado para ingresar ese fragmento de código después de que se libere ese bloqueo. Por lo tanto, su algoritmo va a sufrir significativamente. Cuánto depende del algoritmo y con qué frecuencia se llama la operación. No se puede evitar sin introducir condiciones de carrera, pero se puede mejorar minimizando la cantidad de llamadas al código bloqueado.

Answer 5

La respuesta técnica es que es imposible de cuantificar, depende en gran medida del estado de los búferes de recuperación de memoria de la CPU y de la cantidad de datos que el capturador previo debe descartarse y volverse a leer. Que son ambos muy no deterministas. Utilizo 150 ciclos de CPU como una aproximación de respaldo del envolvente que evita grandes decepciones.

La respuesta práctica es que es waaaay más económico que la cantidad de tiempo que quemará al depurar su código cuando crea que puede omitir un bloqueo.

Para obtener un número difícil tendrá que medir. Visual Studio tiene una resolución concurrency analyzer disponible como extensión.

Answer 6

El costo de un bloqueo en un circuito cerrado, en comparación con una alternativa sin bloqueo, es enorme. Puede darse el lujo de repetir muchas veces y aún ser más eficiente que un bloqueo. Es por eso que las colas sin bloqueo son tan eficientes.

using System; 
using System.Collections.Generic; 
using System.Diagnostics; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 

namespace LockPerformanceConsoleApplication 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      var stopwatch = new Stopwatch(); 
      const int LoopCount = (int) (100 * 1e6); 
      int counter = 0; 

      for (int repetition = 0; repetition < 5; repetition++) 
      { 
       stopwatch.Reset(); 
       stopwatch.Start(); 
       for (int i = 0; i < LoopCount; i++) 
        lock (stopwatch) 
         counter = i; 
       stopwatch.Stop(); 
       Console.WriteLine("With lock: {0}", stopwatch.ElapsedMilliseconds); 

       stopwatch.Reset(); 
       stopwatch.Start(); 
       for (int i = 0; i < LoopCount; i++) 
        counter = i; 
       stopwatch.Stop(); 
       Console.WriteLine("Without lock: {0}", stopwatch.ElapsedMilliseconds); 
      } 

      Console.ReadKey(); 
     } 
    } 
} 

Salida:

With lock: 2013 
Without lock: 211 
With lock: 2002 
Without lock: 210 
With lock: 1989 
Without lock: 210 
With lock: 1987 
Without lock: 207 
With lock: 1988 
Without lock: 208 

Answer 7

Oh cielos!

¡Parece que la respuesta correcta señalada aquí como LA RESPUESTA es inherentemente incorrecta! Me gustaría pedirle al autor de la respuesta, respetuosamente, que lea el artículo vinculado hasta el final.article

El autor del artículo de 2003 article fue la medición en la máquina de doble núcleo y sólo en el primer caso de medición, se mide bloqueo con un solo hilo solamente y el resultado fue de aproximadamente 50 ns por acceso a la cerradura.

No dice nada sobre un bloqueo en el entorno concurrente. Así que tenemos que seguir leyendo el artículo y en la segunda mitad el autor estaba midiendo el escenario de bloqueo con dos y tres hilos, lo que se acerca más a los niveles de concurrencia de los procesadores de hoy.

Así que el autor dice que, con dos hilos en Dual Core, los bloqueos cuestan 120ns, y con 3 hilos va a 180ns. Por lo tanto, parece ser claramente dependiente del número de subprocesos accedidos simultáneamente y más es peor.

Así que es simple, no es 50 ns, a menos que sea un solo hilo, donde la cerradura se vuelve inútil.

Otro tema a tener en cuenta es que se mide como tiempo promedio!

Si se midiera el tiempo de iteraciones, incluso habría tiempos entre 1ms y 20ms, simple porque la mayoría era rápida, pero pocos hilos esperarán el tiempo de los procesadores e incluso retrasos de milisegundos.

Estas son malas noticias para cualquier tipo de aplicación que requiera un alto rendimiento, baja latencia.

Y el último problema a tener en cuenta es que podría haber operaciones más lentas dentro del bloqueo y muy a menudo ese es el caso. Cuanto más tiempo se ejecuta el bloque de código dentro de la cerradura, mayor es la disputa y los retrasos se elevan a gran altura.

Tenga en cuenta que ya ha pasado más de una década desde 2003, es decir, algunas generaciones de procesadores diseñados específicamente para funcionar de manera simultánea y el bloqueo está perjudicando considerablemente el rendimiento de los mismos.