¿Es útil el bloqueo de giro en una arquitectura de núcleo único de un procesador?

Question

Estoy confundido por la función de bloqueo de giro.

El bloqueo de giro se utiliza para detener el proceso de reprogramación. Sin embargo, en una máquina con solo un núcleo, ¿es útil usar el bloqueo de giro para evitar el cambio de contexto?

Answer 1

Respuesta corta: no.

Según http://uw714doc.sco.com/en/man/html.3synch/Intro.3synch.html

cerraduras de vuelta no debe ser utilizado en un sistema de procesador único. En el mejor de los casos, un bloqueo de giro en un solo sistema de procesador desperdiciará recursos, ralentizando al propietario del bloqueo; en el peor de los casos, bloqueará el procesador.

Desde: http://blogs.microsoft.co.il/blogs/sasha/archive/2008/08/10/practical-concurrency-patterns-spinlock.aspx

En los sistemas de un solo procesador, no son necesarios spinlocks porque se requiere la sincronización spinlock en sólo IRQLs altos. En IRQL altos (por encima de IRQL de despacho) no se puede producir un cambio de contexto, por lo que en lugar de girar, el hilo de adquisición puede simplemente solicitar una interrupción en el IRQL relevante y regresar; la interrupción se enmascarará hasta que el hilo de liberación baje el IRQL por debajo del IRQL solicitado.

Para sistemas de procesador único, el kernel ignorará el valor de recuento de centrifugado y lo tratará como cero, lo que esencialmente hace que un spinlock no funcione.

Sí, los bloqueos por giro pueden ser útiles y mejorar la eficacia de algunas operaciones.Sin embargo, en general debe comenzar con un mutex, y si el perfil muestra que es un cuello de botella, es posible que desee considerar un spinlock.

Answer 2

Sí y no; dependiendo de qué sistema operativo esté presente, si hay alguno presente y de lo que está tratando de lograr.

Si tiene el lujo de un sistema operativo multitarea y multihilo completo disponible, entonces debe elegir sus primitivos de la colección que le proporciona, o corre el riesgo de ineficiencias en el mejor de los casos y sincronización no operativa en el peor. Cada sistema operativo tiene sus expresiones idiomáticas y sus mecanismos preferidos, y el no seguir esas convenciones también puede tener costos.

Cuanto más se obtiene de un kernel completo (o más profundamente en el kernel y los controladores de dispositivos que se obtienen), encontrará que los mejores modismos implican primitivas de sincronización de bajo nivel.

Incluso una CPU de un solo núcleo tiene manejadores de interrupción que pueden ejecutarse (en principio) entre cualquier par de instrucciones, o incluso durante ciertas instrucciones de ciclos múltiples en algunas arquitecturas. Esto es efectivamente un tipo de concurrencia, aunque más débil que un segundo núcleo, por lo que se requieren primitivas de sincronización cuando se comunican entre los hilos de primer plano y cualquier manejador de interrupciones en el fondo. En un solo núcleo, la sincronización entre los hilos de primer plano debe implicar un cambio de contexto, por supuesto.

Esperando en una condición establecida en un controlador de interrupción o en una condición establecida en un registro de hardware, ambos son casos en los que una única rosca en primer plano podría no tener más opción que girar el indicador o registro.

Edit: He tratado de aclarar esta respuesta para dejar en claro que estoy hablando de sincronización en general más que cualquier implementación específica de un spinlock en un sistema operativo específico. La pregunta no es específica sobre qué sistema operativo (si corresponde) y tampoco está etiquetada para ningún sistema operativo específico.

Answer 3

Su observación es buena: en un sistema de uniprocesador, no tiene sentido agitarse para esperar un recurso, porque también puede cambiar los hilos más pronto que tarde. Mutexes y semáforos hacen exactamente esto.

En un sistema de multiprocesador, un hilo en otro procesador puede soltar el bloqueo sin su cambio de contexto. Spinlocks puede ser útil, entonces, si no esperas esperar mucho, porque puede ser más rápido simplemente esperar hasta que el otro hilo desbloquee la cosa. Si te vas a dormir con mutex, básicamente tienes asegurado un tiempo muerto significativo antes de que te reprogramen.

En el código del kernel, sin embargo, la situación cambia: los manejadores de interrupciones necesitan acceder a los recursos compartidos con el resto del kernel, pero no pueden dormir. Los Mutexes pondrán el kernel en modo de suspensión, por lo que no podrás usarlos, pero los spinlocks tampoco son útiles porque nada interrumpirá un controlador de interrupciones en un uniprocesador (bueno, tal vez otra interrupción, pero eso da miedo).

En un núcleo, a continuación, gira dentro de un controlador de interrupción compilar a una no-operativa. Están completamente eliminados, tal como podrías pensar. Al mismo tiempo, para evitar carreras, los "spinlocks" en el resto del kernel desactivan las interrupciones justo antes de que realmente giren en algo (porque las tareas del núcleo se pueden programar). Estos códigos solo necesitan "spinlocks" (en lugar de "mutexes") si comparten código con un manejador de interrupciones.

En general, tienes razón: spinlocks realmente no tiene mucho sentido en un solo procesador si tiene mutex, porque mutex perder menos tiempo.

Answer 4

Nº

Para una respuesta mucho más detallada, consulte "How Do Locks Lock?", junto con los comentarios.