spinlock 和 cli 一起使用

发布于 2024-09-09 17:53:56 字数 675 浏览 5 评论 0原文

我最近从 http: //www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.34.1.tar.bz2 。我在 linux-2.6.34.1\Documentation 文件夹中名为 spinlocks.txt 的文件中遇到了以下段落。

“它确实意味着,如果你有一些代码这样做

cli();
.. critical section ..
sti();

,而另一个序列这样做,

spin_lock_irqsave(flags);
.. critical section ..
spin_unlock_irqrestore(flags);

那么它们不是相互排斥的,并且关键区域可能会发生 同时在两个不同的CPU上。这本身很好,但是 关键区域最好对不同的事物具有关键性(即它们 不能互相踩踏)。 ?

如果某些代码使用 cli()/sti() 而同一代码的其他部分使用 spin_lock_irqsave(flags)/spin_unlock_irqrestore(flags) ,它们会产生什么影响

I recently downloaded linux source from http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.34.1.tar.bz2 . I came across the below paragraph in the file called spinlocks.txt in linux-2.6.34.1\Documentation folder.

" it does mean that if you have some code that does

cli();
.. critical section ..
sti();

and another sequence that does

spin_lock_irqsave(flags);
.. critical section ..
spin_unlock_irqrestore(flags);

then they are NOT mutually exclusive, and the critical regions can happen
at the same time on two different CPU's. That's fine per se, but the
critical regions had better be critical for different things (ie they
can't stomp on each other). "

How can they impact if some code is using cli()/sti() and other part of the same code uses spin_lock_irqsave(flags)/spin_unlock_irqrestore(flags) ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

手心的温暖 2024-09-16 17:53:56

这里的关键部分是“在两个不同的CPU上”。一些背景:

  • 历史上,在单处理器 (UP) 系统上,唯一的并发源是硬件中断。在关键部分周围进行 cli/sti 就足以防止 IRQ 处理程序搞砸了。
  • 然后是巨型锁设计,其中内核将有效地在单个CPU上运行,并且一次只有一个进程可以在内核中(这就是巨型锁的用途)。同样,禁用中断足以保护内核免受其自身的影响。
  • 在完整的 SMP 系统上,多个线程可以同时在内核中处于活动状态,并且中断可以传递到几乎任何 CPU,仅在单个处理器上禁用中断或仅获取单个锁已不再足够。两者都是必需的:禁用中断可防止同一 CPU 上的 IRQ 处理程序受到影响,持有锁可防止其他线程进入不同 CPU 上的相同临界区。这正是发明 spin_lock_irqsave()spin_unlock_irqrestore() 的原因。

The key part here is "on two different CPUs". Some background:

  • Historically on uni-processor (UP) systems the only source of concurrency was hardware interrupts. It was enough to cli/sti around the critical section to prevent an IRQ handler from messing things up.
  • Then there was the giant lock design where the kernel would effectively run on a single CPU and only one process could be in the kernel at a time (that what the giant lock was for). Again, disabling interrupts was enough to protect kernel from itself.
  • On full SMP systems, where multiple threads could be active in the kernel at the same time and interrupts could be delivered to pretty much any CPU, it's no longer enough to only disable interrupts on single processor, or only grab a single lock. Both are required: disabling interrupts protects from IRQ handler on the same CPU, holding a lock protects from other threads entering the same critical sections on different CPU. This is exactly why spin_lock_irqsave() and spin_unlock_irqrestore() were invented.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文