Si varios hilos esperan un mismo lock para escribir los mismos datos, por más hilos que se añadan, solo se ejecuta uno a la vez.
Por qué Varios hilos usan a la vez datos compartidos, como la casa de subastas o el almacén del gremio → Efecto Los demás esperan hasta que termina el hilo que tiene el lock → En pantalla Solo una función va lenta y, en los casos graves, se retrasa todo el tick
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Dividir los locks en piezas más pequeñas, reducir el trabajo dentro del lock, usar un modelo basado en mensajes (asignar un hilo responsable a cada dato y que los demás hilos solo le envíen solicitudes por mensaje).
Cifras de referencia
Si el trabajo dentro del lock es el 20% del total, por más hilos que se añadan, el rendimiento se queda como máximo en 5 veces el de un solo hilo; si es el 40%, en 2.5 veces.
En el gráfico
Sube con la carga · Tiempo de procesamiento de solicitudes, CPU y cambios de contexto por hilo
Dónde mirar
Cambios de contexto voluntarios por hilo (cswch/s, veces que se detuvo para esperar un recurso) con pidstat -w -t 1; dónde esperan los hilos fuera de la CPU (tiempo de espera por pila de llamadas) con offcputime -p de bcc. En .NET, el número de contenciones de lock en dotnet-counters (dotnet.monitor.lock_contentions desde .NET 9; Monitor Lock Contention Count en la 8 y anteriores)
Se confirma si
Al aumentar la carga, el uso de CPU sigue bajo pero el tiempo de procesamiento aumenta, la mayor parte de la espera se concentra en pilas de llamadas que intentan adquirir un lock y el número de contenciones sube a la par
Se descarta si
Si la CPU está al tope, es un problema de cálculo (“Tick que excede su presupuesto”, “Sobrecarga de una zona de un solo hilo (hotspot)”). Si esperan en llamadas a la BD o a archivos, apunta a “Llamadas síncronas en el hilo del juego”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Ocurre en diseños en los que varios hilos modifican juntos los datos del juego. Los diseños en los que cada zona o función tiene un solo hilo y todo se comunica por mensajes casi no tienen locks; a cambio, hay que vigilar que el trabajo no se concentre en un hilo (“Sobrecarga de una zona de un solo hilo (hotspot)”). Si el hilo del juego espera un lock que retiene una operación de guardado lenta, se detiene todo ese tick.
Amdahl's Law in the Multicore EraIEEE Artículo de IEEE Computer 2008 (versión pública de los autores). Si la fracción que no se puede paralelizar es 1−f, por más núcleos que se añadan, la aceleración no supera 1/(1−f) (ley de Amdahl)
Request schedulingMicrosoft Los grains (actores) de Orleans usan un modelo de ejecución de un solo hilo que procesa cada solicitud de principio a fin, así que el estado no se modifica en paralelo; si se esperan respuestas mutuamente, puede haber deadlock
pidstat(1) — Linux manual pagesysstat cswch/s de -w: número de cambios de contexto voluntarios por detenerse a esperar un recurso; con -t, por hilo
Well-known EventCounters in .NETMicrosoft Monitor Lock Contention Count (monitor-lock-contention-count): veces que hubo contención al intentar adquirir un monitor lock
.NET runtime metrics.NET dotnet.monitor.lock_contentions desde .NET 9: veces que hubo contención al intentar adquirir un monitor lock desde el inicio del proceso