multithreading - 为什么仅在preempt_count == 0时内核抢占才是安全的？

Question

Linux内核2.6引入了一个新的每线程字段-preempt_count-，该字段每当获取/释放锁时就递增/递减。该字段用于允许内核抢占:“如果设置了need_resched且preempt_count为零，则可以运行更重要的任务，并且可以安全地进行抢占。”

根据罗伯特·洛夫(Robert Love)的"Linux Kernel Development" book:
“那么重新安排什么时候安全？只要内核不持有锁，内核就可以抢占内核中正在运行的任务。”

我的问题是:为什么抢占内核中正在运行的任务并不安全？

如果安排了另一个任务并尝试获取该锁，它将阻塞(或旋转直到其时间片结束)，因此我们不会在同一关键节内同时获得两个线程。万一我们抢占了内核模式下的锁定任务，谁能概述一个有问题的情况？

谢谢!

Answer 1

尽管这是一个古老的问题，但可接受的答案是不正确的。
首先标题是问:

Why kernel preemption is safe only when preempt_count > 0?

这是不正确的，相反。当preempt_count> 0时禁用内核抢占，而当preempt_count == 0时启用内核抢占。
此外， claim :

If another task is scheduled and tries to grab the lock, it will block (or spin until its time slice ends),

并非总是如此。
假设您获得了自旋锁。抢占已启用。发生进程切换，并且在新进程的上下文中运行了一些softirq。运行softirqs时，抢占被禁用。如果这些softirqs之一尝试获取您的锁，则它会永远停止旋转，因为禁用了抢占。因此，您将陷入僵局。
您无法控制抢占您的进程是否将运行softirqs。禁用softirqs的preempt_count字段是特定于进程的。 Softirq必须在禁用抢占的情况下运行，以保留softirq的按CPU序列化。