Linux spin_lock 与 NT KeAcquireSpinLock
据我所知：
- NT 的
KeAcquireSpinLock相当于spin_lock_bh：一个将 IRQL 提升到 DISPATCH_LEVEL，另一个屏蔽下半部分中断——功能相同。虽然 NT 变体保留了 OldIrql，但 Linux 变体似乎没有在任何地方存储“wereInterruptsAlreadyMasked”。这是否意味着spin_unlock_bh总是会揭开它们的面纱？ - NT 的
KeAcquireInterruptSpinLock类似于spin_lock_irqsave。
spin_lock 在 NT 中的等价物是什么？
如果 spin_unlock_bh 始终取消屏蔽中断（在 NT 语言中，始终将 IRQL 降至 KeAcquireSpinLockAtDpcLevel？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您知道没有中断或下半部分会争夺锁时，可以使用原始的
spin_lock。通过避免中断屏蔽，您可以降低中断延迟，同时仍然避免关键部分的互斥体开销足够短以进行旋转。实际上，它们似乎主要由文件系统驱动程序等事物使用，用于锁定内部缓存结构，以及在持有锁时永远不需要阻塞 IO 的其他事物。由于后半部分和驱动程序中断永远不会直接接触 FS 驱动程序，因此无需屏蔽中断。
我怀疑 Windows 的等效项是 CRITICAL_SECTION，或者 NT 内核 API 的等效项；然而，与 NT 临界区不同，Linux 自旋锁在发生争用时不会回退到互斥体；他们只是不停地旋转。
是的，
spin_unlock_bh无条件恢复下半部分。您可以跟踪何时手动启用/禁用（因为您通常应该以与获取相反的顺序释放锁，这通常不是问题），或者只是诉诸spin_lock_irqsave。The raw
spin_lockcan be used when you know no interrupts or bottom-halves will ever contend for the lock. By avoiding interrupt masking, you keep interrupt latency down, while still avoiding the overhead of a mutex for critical sections short enough to spin on.In practice, they seem to be primarily used by things like filesystem drivers, for locking internal cache structures, and other things where there is never a need to block on IO when holding the lock. Since back-halves and driver interrupts never touch the FS driver directly, there's no need to mask interrupts.
I suspect the Windows equivalent would be a
CRITICAL_SECTION, or whatever the NT kernel API equivalent is; however, unlike a NT critical section, Linux spinlocks do not fall back to a mutex when contended; they just keep spinning.And, yes,
spin_unlock_bhunconditionally restores bottom-halves. You can either keep track of when to enable/disable manually (since you should generally release locks in opposite order of acquisition this usually isn't a problem), or just resort tospin_lock_irqsave.