sched_yield（）系统调用和实时调度策略

我想知道如何将Linux内核中的调度机制用于多线程，我发现

sched_yield（）

系统调用可以将当前线程发送到进程队列的末尾。由于

SCHED_OTHER

是默认的计划程序策略，因此本手册不建议在使用

SCHED_OTHER

时使用此系统调用，因为它旨在与实时计划策略（）一起使用，并且未指定

SCHED_OTHER

：

sched_yield（）用于实时调度策略（即sched_FIFO或sched_RR）。将sched_yield（）与不确定的调度策略（如sched_OTHER）一起使用是未指定的，很可能意味着您的应用程序设计被破坏

但是，我从RedHat文档中看到，

sched_yield（）

不应用于实时任务：

sched_yield系统调用由允许其他线程运行的线程使用。通常，当使用sched_yield时，线程可能会转到运行队列的末尾，需要很长时间才能再次调度，或者可以立即重新调度，从而在CPU上创建一个繁忙的循环。调度器能够更好地确定何时以及是否有其他线程想要运行。避免在任何RT任务上使用sched_yield

那么我应该如何使用

sched_yield（）

系统调用呢？这对

SCHED_OTHER

或

SCHED_FIFO

策略会有什么影响？据我所知，使用

SCHED_FIFO

策略，除非

SCHED_yield（）

，否则线程不会被中断，然后第二个请求的线程将被处理，除非它结束，而第一个线程将在处理完所有线程队列后继续（具有FIFO行为）

此外，由于每个量子都会部分处理所有线程，因此此系统调用将如何处理

SCHED_RR

策略

问题是“收益率”几乎没有定义。它的定义实际上是关于实时行为的单个队列，以及具有优先级的实时调度器

但这个“定义”与实际使用几乎毫无关系。有各种各样的随机人使用它，有些人可能用它来锁定，而有些人则用它来做其他事情

sched_yield（）

基本上是历史垃圾。即使对于定义的用法，它也常常是错误的，因为时间已经从很久以前的“我们一次只运行一件事情”开始向前移动。如果您的RT系统实际上有多个并发线程（而不是局限于一个专用CPU），那么即使在那里，它也不是真正定义良好的。但至少在那里你可以假装它是

---

它只是意味着不要在循环中使用它作为睡眠的替代品。你应该重新设计你的应用程序，改为事件驱动。这将有助于你编辑你的问题，并描述你的线程是如何组织的（例如，N-worker模型或异构线程）。通常，每个线程都应该在输入队列上等待[事件]。将工作描述符出列，对其进行操作，为数据处理管道的_下一个_阶段形成描述符，并将其排入下一个线程。我已经做过很多这样做的R/T嵌入式系统，包括

SCHED_RR

，具有不同的优先级和保证的延迟/吞吐量，并且从未使用过

SCHED_yield

。这样做意味着对整个线程模型的错误设计。