验证Linux“__schedule“调用条件,关中断和关调度是必须的嘛?

"__schedule"函数是linux操作系统中的核心函数，就是它实现了操作系统最基本的多任务切换功能，使系统可以称之为操作系统，"__schedule"函数功不可没!

看下图，所有的引起任务切换的调用路径最终都会调用到__schedule函数，可见它在系统实现中的核心作用。

上图已经搜罗了系统里面所有所有会调用到__schedule函数的接口的父函数，只有六个地方，看起来扇入不是太多，不太像一个核心接口，实际上，从函数的双下划线标志就能大概猜到，它是一个内部接口，只供核心内部调用，所以当然它的扇入不会太大，但是他的父函数就不一样了，例如schedule接口在内核中被广泛调用，遍布整个内核，所以实际上__schedule的扇入是通过夫函数体现出来的，本身作为一个内部公共实现只供有限的几个点调用。

通过上图可以看到，在调用__schedule之前，每个父函数都会直接或者间接的调用"preeempt_diable"来设置抢占标志，禁止当前CPU上的抢占发生(schedule_idle是个例外，并非是因为他不会调用preempt_disable, 而是因为 linux的ilde任务在出生时就已经关闭了调度，具体可以看另一篇文章).

从另一个地方也可以看出来，__schedule函数在入口会直接调用schedule_debug函数

而schedule_debug会检查抢占是否已关，没关的话就会调用__schedule_bug给出内核警告，看起来还是一个比较严重的事件的！

所以可以基本确定：

规则1:环境在调用__schedule前， 必须主动关闭抢占

现在看另一条规则，先看一下__schedule的执行细节：

可以看到，__schedule函数内部，在入口处必定会调用 local_irq_disable执行关闭CPU本地中断的操作，而退出的时候，两条路径都会执行 local_irq_enable的操作，并且不是通常的"riqsave"以及"irqrestore"的禁止/恢复形式，而是关闭/打开这种方式，这和一般的驱动或者中间层的调用方式不大一样，或许这就是最核心接口的特权:).

一般来讲，一个函数应该要保证，它的入口处的状态和出口处的状态，必须要一致的。按照这样的原则，考虑到__schedule退出的时候会无条件打开中断，为了满足对称的要求，我们只能猜测，就像关闭抢占一样，环境在调用__schedule之前，必须要打开中断响应能力，以便__schedule函数返回后，状态能够一致！

事实是这样吗？

很遗憾，搭建qemu环境实测了一下，大部分场景下都是符合要求的，但是在一个点上，出现了不满足。

在schedule_debug中增加检测中断使能的逻辑

 zui

最终发现，在do_work_pending函数中，出现了在中断关闭的情况下调用schedule的情况

do_work_pending里面，一处比较没有意义的区分，如果在调用schedule之前，调用local_irq_enable也无大碍，而且最后无条件执行local_irq_disable也符合schedule之后，中断响应打开，建立临界区的语义。

也就是在这里 __schedule函数入口处和出口处的中断状态不在对称.

在这一点上，MIPS port的执行逻辑和arm 是类似的,124行，执行 jal schedule的时候，中断也是关闭的退出时就打开了，所以126行迅速执行关闭，再次检测调度条件，这一点和上面的 do_work_pending如出一辙。

如果抛去对称性的讨论，单纯看流程倒是可以理解为，保证thread_flags的获取和判断是原子的，而从内部__schedule 出来再到 678行关闭中断，这段时间中断是打开的，可以发生抢占，只是牺牲了对称性，可能linux开发者觉得，这没什么问题！看下图！

irq_disable();

.............

do {

      ....................

        schedule();----->__schedule { ............. irq_enable()};

        .................   //interrupt preempt happend!

        irq_disabe();

       ...................

}

还是i不用纠结了，软件就是折衷，凑合的过程，不要过度追求完美，甚至linux也是一样。