¿Cuándo es pthread spin lock lo correcto a usar (por ejemplo, sobre un pthread mutex)?
Dado que pthread_spin_lock está disponible, ¿cuándo lo usaría y cuándo no debería usarlos?
Es decir, ¿cómo decidiría proteger una estructura de datos compartida con un pthread mutex o un pthread spinlock ?
4 answers
La respuesta corta es que un spinlock puede ser mejor cuando planea mantener el bloqueo durante un intervalo extremadamente corto (por ejemplo, para no hacer nada más que incrementar un contador), y se espera que la contención sea rara, pero la operación se está produciendo con suficiente frecuencia como para ser un cuello de botella de rendimiento potencial. Las ventajas de un spinlock sobre un mutex son:
- Al desbloquear, no hay necesidad de verificar si otros hilos pueden estar esperando el bloqueo y despertarlos. El desbloqueo es simplemente un instrucción de escritura atómica.
- La falta de obtener inmediatamente el bloqueo no pone su hilo en suspensión, por lo que puede ser capaz de obtener el bloqueo con una latencia mucho menor tan pronto como esté disponible.
- No hay riesgo de contaminación de caché al entrar en kernelspace para dormir o despertar otros hilos.
El punto 1 siempre se mantendrá, pero los puntos 2 y 3 son de utilidad algo disminuida si se considera que las buenas implementaciones de mutex probablemente girarán un número decente de tiempos antes de pedir ayuda al núcleo esperando.
Ahora, la respuesta larga:
Lo que debe preguntarse antes de usar spinlocks es si estas ventajas potenciales superan una desventaja rara pero muy real: qué sucede cuando el hilo que sostiene el bloqueo es interrumpido por el programador antes de que pueda liberar el bloqueo. Esto es, por supuesto, raro, pero puede suceder incluso si el bloqueo se mantiene solo para una sola operación de incremento de variable o algo igualmente trivial. En en este caso, cualquier otro hilo que intente obtener el bloqueo seguirá girando hasta que el hilo retenga el bloqueo se programe y tenga la oportunidad de liberar el bloqueo. Esto nunca puede suceder si los hilos que intentan obtener el bloqueo tienen prioridades más altas que el hilo que contiene el bloqueo. Ese puede ser un caso extremo, pero incluso sin diferentes prioridades en juego, puede haber retrasos muy largos antes de que el propietario de la cerradura se programe de nuevo, y lo peor de todo, una vez que comienza esta situación, puede escalar rápidamente tantos hilos, todos con la esperanza de obtener el bloqueo, comenzar a girar en él, atando más tiempo de procesador y retrasando aún más la programación del hilo que podría liberar el bloqueo.
Como tal, tendría cuidado con los spinlocks... :-)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-07-07 03:22:00
El spinlock es un bloqueo de "espera ocupada". Su principal ventaja es que mantiene el hilo activo y no causará un cambio de contexto, por lo que si sabe que solo estará esperando por un tiempo muy corto (porque su operación crítica es muy rápida), entonces esto puede dar un mejor rendimiento que un mutex. Por el contrario, un mutex causará menos demanda en el sistema si la sección crítica toma mucho tiempo y es deseable un cambio de contexto.
TL; DR: Depende.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-07-06 21:47:34
El método más seguro con un aumento de rendimiento es un híbrido de los dos: un mutex adaptativo.
Cuando su sistema tiene varios núcleos que girar durante unos pocos miles de ciclos para capturar el mejor caso de baja o ninguna contención, a continuación, diferir a un mutex completo para ceder a otros hilos para bloqueos largos contendidos.
Tanto POSIX (PTHREAD_MUTEX_ADAPTIVE_NP) como Win32 (SetCriticalSectionSpinCount) tienen mutexes adaptativos, muchas plataformas no tienen una API POSIX spinlock.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-10-04 20:25:53
Spinlock solo tiene interés en el contexto MP. Se utiliza para ejecutar tareas pseudo-atómicas. En el sistema monoprocesador el principio es el siguiente :
- Bloquear el scheduler (si la tarea trata con interrupciones, bloquear interrupciones en su lugar)
- Hacer mi táctica atómica
- Desbloquear el programador
Pero en los sistemas MP no tenemos garantías de que otro núcleo no ejecute otro hilo que pueda entrar en nuestra sección de código. Para evitar esto, se ha creado el bloqueo de giro, su propósito es posponer la ejecución de otros núcleos evitando problemas de concurrencia. La sección crítica se convierte en :
- Bloquear el programador
- SpinLock (evitar la entrada de otros núcleos)
- Mi tarea
- SpinUnlock
- Desbloqueo de tareas
Si se omite el bloqueo de tarea, durante una programación, otro subproceso podría intentar ingresar a la sección an en bucle al 100% de la CPU esperando la próxima programación. Si esta tarea es de alta prioridad, producirá un punto muerto.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-10-04 20:03:55