std::this_thread::yield 只是一个提示会有问题吗？答案

【问题标题】：Can std::this_thread::yield being just a hint be problematic?std::this_thread::yield 只是一个提示会有问题吗？
【发布时间】：2013-01-18 15:40:04
【问题描述】：

我和同事讨论了一个假设问题，当人们想用 std::atomic_flag 实现自旋锁互斥锁，但也不是将自旋锁实现为 while(true) 而是作为一个

while(true)
{
     cnt=0;
     while (cnt<yieldAfterTries)
     {
        //try to get lock
        cnt++;
     }
     std::this_thread::yield();

     // if got lock do work and then break;
}

基本上的想法是，即使线程具有实时优先级，线程也不能“在很长一段时间内”阻塞其他线程，因为它会在一段时间后屈服……但是当我看到 std::yield 的规范我很惊讶这是一个建议，而不是强制性的。

为实现提供提示以重新安排线程，允许其他线程运行。

http://en.cppreference.com/w/cpp/thread/yield

那会有问题吗？

【问题讨论】：

没有。如果您的程序依赖于sched_yield 或this_thread::yield 或类似的正确性，那么它已经损坏了。
@JonathanWakely 那么问题是尝试自旋锁块的高优先级线程能否无限期地阻塞其他低优先级线程（其中一个持有锁）......我想这是一个关于调度程序的问题。 :)
是的，它是关于调度程序的，而 C++ 无法指定这一点，因此它实际上不能要求 yield() 提供任何比它作为提示更强大的东西。

标签： c++ c++11 stdthread stdatomic

【解决方案1】：

我编写的代码与您的代码非常相似，并测量了在高争用条件下调用yield 的影响。我发现以这种方式使用yield 有利于整体系统吞吐量。

实际规范与您引用的内容在精神上没有什么不同，但这里是 30.3.2 [thread.thread.this] 第 2 和第 3 段的确切规范：

void this_thread::yield() noexcept;

效果：为实现提供重新安排的机会。

同步：无。

如果实现将yield 实现为无操作（例如），这只会影响代码的性能，而不影响正确性。即使没有yield，失败的自旋锁最终也会被抢占。但它也更有可能不必要地占用 CPU，从而降低整体系统性能。

【讨论】：

嗨，很好的答案，顺便说一句，关于你的实现（如果你想让它成为严肃的程序代码）我记得很久以前看过一些麻省理工学院的讲座，他们提到有一个公式可以计算多久如果您的上下文切换需要时间 X，您应该自旋锁定。不幸的是，IDK 确切地知道那是什么视频剪辑，但如果您有兴趣，您可以尝试谷歌搜索或询问可能知道的人。
@NoSenseEtAl：感谢您的提示。事实上，我已经把它变成了严肃的生产代码（llvm.org/svn/llvm-project/libcxx/trunk/src/memory.cpp 搜索“__sp_mut::lock()”）。在这个应用程序中，自旋锁不是通用的。它正在做一些非常具体的事情。最佳旋转计数是通过计时器和测试凭经验确定的。成本曲线的最小值是一个相对平缓的“桶”。 IE。接近最低点就足够了。
如果你感到无聊：youtube.com/course?list=ECD2AE32F507F10481 :D 当他们进入 cilk 时会有点无聊，但一般的东西很酷。
对于后代，Howard Hinnant 是 c++11 的、和多线程实用程序的首席设计师和作者。可以肯定地说，他编写了一些“严肃的生产代码”。

【解决方案2】：

自旋锁将被操作系统调度程序自动抢占，从而使此代码变得不必要。当一个线程占用了它的时间时，操作系统将自动切换到另一个线程。这就是为什么 yield 是一个提示。例如，在 Linux 中的完全公平调度中，对 yield 的调用通常会导致不必要的上下文切换，因为调度试图纠正一个线程没有得到公平的时间份额。

你尝试获取自旋锁不会阻塞任何东西，只有持有自旋锁会导致其他东西阻塞。

【讨论】：