Linux spin_lock vs NT KeAcquireSpinLock

Question

Da quello che ho potuto capire:

• NT KeAcquireSpinLock equivale a spin_lock_bh: quella IRQL eleva a DISPATCH_LEVEL, le altre maschere le mezze interrupt fondo - funzionalmente lo stesso. Mentre la variante NT mantiene OldIrql, la variante di Linux non sembra memorizzare "wereInterruptsAlreadyMasked" ovunque. Questo significa che spin_unlock_bh li smaschera sempre?
• NT KeAcquireInterruptSpinLock è come spin_lock_irqsave.

Qual è l'equivalente NT di spin_lock?

Se spin_unlock_bh smaschera sempre interrupt (in NT-parlare, scende sempre IRQL a < DISPATCH_LEVEL), significa spin_lock è simile a KeAcquireSpinLockAtDpcLevel?

Answer 1

Il raw spin_lock può essere utilizzato quando si sa che nessun interrupt o fondo-metà si contenderanno mai il blocco. Evitando il mascheramento dell'interrupt, si mantiene la latenza dell'interrupt verso il basso, evitando comunque il sovraccarico di un mutex per le sezioni critiche abbastanza corte da girare.

In pratica, sembrano essere principalmente utilizzati da elementi come i driver del filesystem, per bloccare le strutture interne della cache e altre cose in cui non è mai necessario bloccare su IO quando si tiene il blocco. Poiché i dorsi e le interruzioni del driver non toccano mai direttamente il driver FS, non è necessario mascherare gli interrupt.

Sospetto che l'equivalente di Windows sia un CRITICAL_SECTION o qualsiasi sia l'equivalente dell'API del kernel NT; tuttavia, a differenza di una sezione critica NT, gli spinlock di Linux non ricadono su un mutex quando vengono contesi; continuano a girare.

E, sì, spin_unlock_bh ripristina incondizionatamente le metà inferiori. Puoi tenere traccia di quando abilitare/disabilitare manualmente (dato che in genere dovresti rilasciare i blocchi nell'ordine opposto di acquisizione, di solito non è un problema), o semplicemente ricorrere a spin_lock_irqsave.