在问题之前进行一点讨论。Linux2.4内核是非抢占的，所以当我们在内核模式下处理系统调用时，如果需要上下文切换，我们只需要设置需要重新设置以发出标志，然后当我们返回到用户模式时，我们检查标志并进行上下文切换。
让我们将其与具有抢占式内核的Linux2.6进行比较。
我们不能只取2.4内核，将set_need_resched（升旗）改为schedule（）（重新调度的指令执行），所以在Linux内核2.6中有一个计数器抢占计数，每次在spin_lock（）上增加，在spin_unlock（）上减少。
实际上，这个字段“preempt_count”决定是否可以抢占内核。例如，在从时钟中断返回时，如果条件：
(current->need_resched == 1) && (current->preempt_count == 0)
如果为true，则内核执行上下文切换。
问题是为什么Linux2.6的内核在持有spinlock类型的锁时防止抢占。
如果内核不阻止抢占，会发生什么情况？你能给我一个尽可能详细的具体例子吗？
谢谢您。
最佳答案
你读过诸如互斥锁或信号量之类的可睡眠锁吗？
在他们的情况下，如果锁不能被获取，线程可以让自己进入睡眠状态，例如，释放它的优先级，以便锁所有者（如果正在睡眠）能够更快地完成工作。特别是，想要获取锁的线程可能运行在锁所有者计划继续运行的cpu上。
另一方面，对于自旋锁，假设没有人睡觉-这意味着，特别是繁忙的等待（即停留在CPU上）不会阻止锁所有者。如果锁被锁着，主人就在某处跑。但假设它睡着了。这将意味着等待线程将浪费时间纺纱，因为业主无法回到工作。只有当调度程序确定它足够时，它才会被抢占，但是在服务生和所有者之间没有建立关系。所以特别可能是服务员会回到CPU上继续忙着等待，而锁的主人仍然没有机会运行。
所以至少这是一个巨大的性能问题。实际上，它只会导致在高负载下的livelocks，而内核无法向前推进。
关于linux - linux 2.6调度和抢占-preempt_count使用，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48038191/