Como implica la pregunta al decir que los spinlocks son un "desperdicio", los spinlocks deben mantenerse solo brevemente.
Spinlocks no son la única forma de sincronizar múltiples subprocesos. Mutexes/semáforos también se utilizan en el kernel de Linux, al igual que otras primitivas de sincronización (por ejemplo, colas de espera, eventos).
Sin embargo, el kernel tiene que lidiar con casos que el espacio de usuario nunca ve, siendo uno común los controladores de interrupciones. Los controladores de interrupciones no se pueden reprogramar en Linux, pero a menudo tienen que usar alguna primitiva de sincronización (por ejemplo, para agregar un elemento de trabajo a una lista vinculada que algún otro hilo procesará más). Dado que los controladores de interrupciones no pueden dormir, no pueden usar mutexes, colas de espera, etc. Eso prácticamente deja spinlocks. Si un subproceso necesita sincronizar el acceso con un controlador de interrupciones, entonces también debe usar el mismo spinlock.
Spinlocks no son necesariamente un desperdicio. Están optimizados para el caso de no contención/no espera y se pueden tomar y liberar muy rápidamente. En ese caso, son más rápidos e implican menos sobrecarga que otras primitivas de sincronización.
La elección entre un spinlock y otra construcción que hace que la persona que llama bloquee y renuncie al control de una CPU se rige en gran medida por el tiempo que lleva realizar un cambio de contexto (guardar registros/estado en el subproceso de bloqueo y restaurar registros/estado en otro hilo). El tiempo que lleva y también el costo de caché de hacer esto pueden ser significativos.
Si se usa un spinlock para proteger el acceso a los registros de hardware o similar donde cualquier otro subproceso que esté accediendo solo tomará unos milisegundos o menos antes de que libere el bloqueo, entonces es un uso mucho mejor del tiempo de la CPU para hacer girar la espera. en lugar de cambiar de contexto y continuar.
Otros han respondido. Resumiré los casos en los que usaría spinlock y las reglas para usar spinlock.
1. ¿Cuándo se usa spinlock?
Respuesta:En las siguientes situaciones.
- El subproceso que mantiene el candado no puede dormir.
- El hilo que está esperando un bloqueo no duerme, sino que gira en un bucle cerrado.
Cuando se usa correctamente, spinlock puede brindar un mayor rendimiento que el semáforo. Ejemplo:controlador de interrupción.
2. ¿Cuáles son las reglas para usar spinlocks?
Respuesta:
Regla - 1:cualquier código que tenga el spinlock, no puede ceder el procesador por ningún motivo excepto por interrupciones de servicio (a veces ni siquiera entonces). Por lo tanto, el código que contiene spinlock no puede dormir.
Motivo:supongamos que el controlador que sostiene spinlock se va a dormir. Ej:llama a la función copy_from_user() o copy_to_user() , o la preferencia del kernel se activa, por lo que el proceso de mayor prioridad hizo a un lado su código. Efectivamente, el proceso renuncia a la CPU que mantiene spinlock.
Ahora no sabemos cuándo el código liberará el candado. Si algún otro subproceso intenta obtener el mismo bloqueo, giraría durante mucho tiempo. En el peor de los casos, resultaría en un deedlock.
El caso de preferencia del kernel es manejado por el propio código spinlock. Cada vez que el código del núcleo contiene un spinlock, la preferencia se desactiva en el procesador correspondiente. Incluso el sistema monoprocesador debe deshabilitar la preferencia de esta manera.
Regla - 2:deshabilite las interrupciones en la CPU local, mientras se mantiene el spinlock.
Motivo:Apoye a su controlador para que tome un spinlock que controle el acceso al dispositivo y luego emita una interrupción. Esto hace que se ejecute el controlador de interrupciones. Ahora el controlador de interrupciones también necesita el bloqueo para acceder al dispositivo. Si el controlador de interrupciones se ejecuta en el mismo procesador, comenzará a girar. El código del controlador tampoco puede ejecutarse para liberar el bloqueo. ASÍ que el procesador girará eternamente.
Regla - 3:Spinlocks debe mantenerse durante el mínimo tiempo posible.
Motivo:los tiempos prolongados de retención de bloqueo también evitan que el procesador actual se programe, lo que significa que un proceso de mayor prioridad puede tener que esperar para obtener la CPU.
Por lo tanto, afecta la latencia del kernel (el tiempo que un proceso puede tener que esperar para programarse). Por lo general, los spinlocks deben mantenerse durante el tiempo, menos de lo que tarda la CPU en hacer un cambio de contexto entre subprocesos.