Linux 为什么 `std：：this_thread：：yield()` 比 `std：：this_thread：：sleep_for(0s)` 慢 10 倍

发布于06月16日

只是在测试这两个小程序，

#include <thread>

int main()
{
    for (int i = 0; i < 10000000; i++)
    {
        std::this_thread::yield();
    }

    return 0;
}

以及:

#include <thread>
#include <chrono>

int main()
{
    using namespace std::literals;

    for (int i = 0; i < 10000000; i++)
    {
        std::this_thread::sleep_for(0s);
    }

    return 0;
}

我在我的系统上获得了各自的时间(Ubuntu 22.04LTS，内核版本5.19.0-43-Generic)，

./a.out  0,33s user 1,36s system 99% cpu 1,687 total

以及:

./a.out  0,14s user 0,00s system 99% cpu 0,148 total

为什么std::this_thread::yield()比std::this_thread::sleep_for(0s)慢10倍？

注:g++和clang++之间的时序相似.

编辑:正如答案中指出的，这是对STL实现的优化，调用sleep(0)实际上要慢300倍(50us对150 ns).

推荐答案

快速浏览一下this_thread::sleep_for比source

template<typename _Rep, typename _Period>
inline void
sleep_for(const chrono::duration<_Rep, _Period>& __rtime)
{
    if (__rtime <= __rtime.zero())
      return;
    ...

因此sleep_for(0s)什么都不做，实际上您的测试程序使用0.0s的系统时间，基本上是一个完全在用户空间运行的空循环(事实上，我怀疑如果您使用优化进行编译，则使用it will be completely removed)

On the other hand, yield calls^* sched_yield which in turns will call schedule() in kernel space, thus at least executing some logic to check if there is another thread to schedule.

我相信你的0.33s的用户空间时间基本上是系统调用开销.

^{*_{实际上跳到__libcpp_thread_yield，然后调用sched_yield，至少在Linux上}}