如何正确使用sched_yield()及在Linux各调度策略下的行为

首先需要明确：你看到的两份文档的“矛盾”根本不是规则冲突，本质是二者站的维度、提醒的边界完全不一样，没有非黑即白的对错。
下面是不同调度策略下的内核实际执行逻辑：

• SCHED_OTHER（CFS公平调度，系统默认策略）
  早年2.6.23之前的老内核里，sched_yield()在CFS下的实现非常粗暴：不管当前CPU运行队列有没有同优先级的可运行任务，直接把当前线程的虚拟运行时间拉到整个队列的最末尾，强行给其他线程让路。
  现代内核（2.6.33及之后）早就改了逻辑：现在CFS对sched_yield()的处理是，只有当当前CPU的运行队列里真的存在同优先级的可运行实体时，才会把当前线程移到队列末尾；如果队列里没有其他可运行任务，sched_yield()会直接返回，当前线程甚至不会触发上下文切换，会继续在CPU上跑。
  这也是man页说“SCHED_OTHER下行为未定义”的根源：POSIX标准从来没有给CFS下的sched_yield()定过统一的行为规范，不同内核版本的实现完全不一样，手册自然会提醒你不要在非实时场景下依赖这个接口的固定行为。
• SCHED_FIFO（实时先入先出调度）
  首先要纠正你之前的理解偏差：SCHED_FIFO的核心规则是高优先级任务无条件抢占低优先级任务，同优先级的任务一旦拿到CPU，除非主动阻塞、任务退出、或者被更高优先级任务抢占，否则会一直占着CPU运行——不是“除非主动调用sched_yield()否则不被中断”，中断它的只能是更高优先级的实时任务，这是硬实时系统的确定性基础。
  同优先级队列下，sched_yield()的行为是完全确定的：当前运行的任务会被直接移到同优先级可运行队列的末尾。
  这里再纠正你的另一个误解：不是让出去之后次位的线程会一直跑到整个队列所有任务处理完才轮到最初的线程，而是只要它前面排着的同优先级任务都阻塞、跑完了，它就会立刻拿到CPU继续跑；如果调用sched_yield()的时候，同优先级队列里根本没有其他可运行的任务，它会被立刻重新调度执行，根本不会等。
  红帽实时指南反对在SCHED_FIFO任务里用这个接口，本质是反对滥用：如果你没有明确判断队列状态，随便在实时代码里调用sched_yield()，要么触发毫无意义的上下文切换增加延迟，要么在队列空的时候直接被调度回来形成忙循环，完全破坏实时性的可预测性——但它并不是说这个接口在SCHED_FIFO下的行为是错的。man页说这个接口最初是为实时策略设计的，指的是当你明确知道同优先级队列里有等着运行的兄弟任务，刻意要做对等协作切换的场景，这正是接口的设计初衷，和红帽说的“别滥用”完全不冲突。
• SCHED_RR（实时轮询调度）
  同优先级队列下的sched_yield()行为和SCHED_FIFO下完全一致：当前任务会立刻被移到同优先级可运行队列的末尾，同时它当前还没用完的时间片会被直接清空。
  这和时间片自然耗尽的效果有区别：时间片用完的时候，下一个拿到CPU的任务会拿到完整的新时间片；而调用sched_yield()让出CPU的任务，等重新排回队头时，也会拿到一个完整的新时间片，不会接着上次没跑完的时间片继续算。同样如果队列里没有其他可运行任务，它会立刻被重新调度，没有任何等待。

• man 2 sched_yield()的描述是POSIX标准层面的边界提醒：这个接口的设计目标是“为等待在同优先级队列的其他线程让出运行权”，最早就是给实时调度策略做的，而SCHED_OTHER的公平调度逻辑本来就是内核基于虚拟运行时间自行判断调度顺序的，从来没有给sched_yield()定过跨版本的固定行为，所以手册才会提醒你在非实时场景下不要依赖这个接口，通常意味着你的应用设计有缺陷——比如靠主动调用sched_yield()来做线程同步，而不是用内核同步原语。
• 红帽企业版实时指南的描述是生产环境的最佳实践提醒：实时系统的核心要求是低抖动、高确定性，如果你把sched_yield()当通用的“让其他任务跑”的工具随便用在实时代码路径上，根本达不到预期的让路效果，反而会增加不必要的延迟，所以指南才会说实时任务应该避免无差别使用这个接口。两边说的根本不是一回事。

• 绝对不推荐的使用场景：
  • 把这个接口用在自旋等待、锁等待这类通用同步逻辑里，指望靠调用它来让其他持有锁的线程获得CPU——这种场景应该用futex、信号量这类内核同步原语，或者用架构对应的暂停指令，用sched_yield()只会平白增加上下文切换开销，甚至形成忙循环。
  • 实时任务里在没有明确判断同优先级队列状态的情况下，随意调用这个接口做无目的的让出——这种用法完全破坏实时系统的确定性。
• 可以使用的合理场景：
  • 在SCHED_FIFO/RR的同优先级任务组里，你明确知道另一个同优先级的兄弟任务正等在可运行队列上，需要做严格的协作式顺序轮询，这时候调用sched_yield()让出运行权，是完全符合接口最初设计意图的用法。

内容的提问来源于stack exchange，提问作者Hugo Haldi