operating system - rotación - ¿Es útil el bloqueo de giro en una arquitectura de núcleo único de un procesador?
rotación de pantalla (4)
No.
Para obtener una respuesta mucho más detallada, consulte " ¿Cómo se bloquea el bloqueo? " Junto con los comentarios.
Estoy confundido por la función de bloqueo de giro.
El bloqueo de giro se utiliza para evitar que el proceso vuelva a programarse. Sin embargo, en una máquina con solo un núcleo, ¿es útil usar el bloqueo de giro para evitar el cambio de contexto?
Si y no; dependiendo de qué sistema operativo esté presente, si hay alguno presente, y lo que está tratando de lograr.
Si tiene el lujo de contar con un sistema operativo completo multitarea y multihilo disponible, entonces debe elegir sus primitivos de la colección que le proporciona, o arriesga 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 profundo 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 núcleo único tiene controladores de interrupción que pueden ejecutarse (en principio) entre cualquier par de instrucciones, o incluso durante ciertas instrucciones de ciclo múltiple 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.
Esperar en una condición establecida en un manejador de interrupciones o en una condición establecida en un registro de hardware son ambos casos donde una sola hebra en primer plano en un solo núcleo podría no tener mejor opción que girar el indicador o registro.
Editar: 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. La pregunta no es específica sobre qué sistema operativo (si corresponde) y tampoco está etiquetada para ningún sistema operativo específico.
Su observación es buena: en un sistema 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 multiprocesador, un hilo en otro procesador puede liberar el bloqueo sin que usted cambie 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.
Sin embargo, en el código del kernel, 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 kernel, entonces, spinlocks dentro de un controlador de interrupción compila a un no-op. 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" (a diferencia de los "mutexes") si comparten el código con un manejador de interrupciones.
En general, tienes razón: los spinlocks realmente no tienen mucho sentido en un uniprocesador si tienes mutex , porque los mutex pierden menos tiempo.
Respuesta corta: no.
De acuerdo con http://uw714doc.sco.com/en/man/html.3synch/Intro.3synch.html
Los bloqueos de giro no se deben usar en un solo sistema de procesador. 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.
En los sistemas de un solo procesador, no se necesitan los "spinlocks" porque la sincronización de "spinlock" solo se requiere en los IRQL 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 un solo procesador, el kernel ignorará el valor de conteo de vueltas y lo tratará como cero, esencialmente haciendo que un spinlock no funcione.
Sí, las cerraduras giratorias pueden ser útiles y mejorar la eficiencia 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.