Linux vs spin_lock NT KeAcquireSpinLock

De lo que he entendido:Linux vs spin_lock NT KeAcquireSpinLock

de NT KeAcquireSpinLock es equivalente a spin_lock_bh: el IRQL eleva a DISPATCH_LEVEL, las otras máscaras las interrupciones mitad inferior - funcionalmente lo mismo. Mientras que la variante NT mantiene el OldIrql, la variante de Linux no parece almacenar "wereInterruptsAlreadyMasked" en ninguna parte. ¿Esto significa que spin_unlock_bh siempre los desenmascara?
NT KeAcquireInterruptSpinLock es como spin_lock_irqsave.

¿Cuál es el equivalente NT de spin_lock?

Si spin_unlock_bh siempre desenmascara interrupciones (en NT-hablar, siempre cae IRQL a < DISPATCH_LEVEL), significa spin_lock es similar a KeAcquireSpinLockAtDpcLevel?

Fuente

2011-10-15 Ilya

Como ha señalado, el bloqueo de la ventana se logra a través de retoques IRQL. Entonces, si este concepto no está presente en Linux, entonces siguiendo la lógica, spin_lock no tiene un equivalente directo, ya que ambos OS usan mecanismos ligeramente diferentes para lograr lo mismo. – LordDoskias

IRQL es una abstracción sobre el enmascaramiento de interrupción, y Linux obviamente tiene eso. Lo que me pregunto es para qué escenario es útil spin_lock, y ¿por qué la gente de NT no apoyó este escenario? – Ilya

Además, revisé mi pregunta después de algunas cosas más que entendí re: spin_lock_bg. – Ilya

La spin_lock sin procesar se puede utilizar cuando usted sabe que no habrá interrupciones o mitades de fondo que contengan el bloqueo. Al evitar el enmascaramiento de interrupción, se mantiene baja la latencia de interrupción, al tiempo que se evita la sobrecarga de un mutex para las secciones críticas lo suficientemente cortas como para girar.

En la práctica, parecen ser utilizados principalmente por cosas como controladores de sistema de archivos, para bloquear estructuras internas de caché, y otras cosas donde nunca hay una necesidad de bloquear en IO cuando se mantiene el bloqueo. Debido a que las interrupciones en la parte posterior y las interrupciones del controlador nunca tocan directamente al controlador FS, no es necesario enmascarar las interrupciones.

Sospecho que el equivalente de Windows sería un CRITICAL_SECTION, o cualquiera que sea el equivalente API NT kernel; sin embargo, a diferencia de una sección crítica de NT, los spinlocks de Linux no recurren a un mutex cuando se disputan; solo siguen girando.

Y, sí, spin_unlock_bh restaura incondicionalmente las mitades inferiores. Puede realizar un seguimiento de cuándo habilitar/deshabilitar manualmente (ya que generalmente debe liberar bloqueos en orden de adquisición opuesto, por lo general no es un problema), o simplemente recurrir a spin_lock_irqsave.

Fuente

2011-10-16 01:36:29 bdonlan

spin_lock todavía llama a preempt_disable. ¿Estás diciendo que preempt_disable simplemente marca una bandera y no desactiva las interrupciones, específicamente las interrupciones de la mitad inferior (DPC en NT-speak?) Y las interrupciones de los dispositivos? – Ilya

En NT, todas las funciones que "adquieren" un spinlock elevan el IRQL a DISPATCH_LEVEL, lo que significa a) no prioridad, y b) DPC (mitad inferior de rutinas) no se ejecutarán. ¿Deshabilita esto las interrupciones per se? ¿No seguiría interrumpiendo el reloj, pero no haría nada porque el IRQL es lo suficientemente alto? – Ilya

También en Linux, puedo ver que local_bh_disable simplemente llama a algo llamado add_preempt_count, que es la misma función llamada por preempt_disable. Entonces, ¿qué diferencia a local_bh_disable y preempt_disable? – Ilya

Linux vs spin_lock NT KeAcquireSpinLock

Respuesta

Cuestiones relacionadas