Windows 10下std::this_thread::yield无法触发上下文切换问题求助

Windows 和 Linux 对 std::this_thread::yield() 的实现逻辑存在差异：

• Linux 下的 yield() 对应 sched_yield()，会触发调度器重新选择就绪队列中的线程，哪怕是刚从 mutex 等待状态转为就绪状态的线程，也能获得调度机会。
• Windows 下的 yield() 底层调用 SwitchToThread()，它只让当前线程放弃剩余时间片，但仅当系统中存在已处于就绪状态的线程时才会触发切换。当你的线程释放 mutex 后，等待该 mutex 的线程会从等待状态转为就绪状态，但Windows调度器不会立即优先调度这个刚就绪的线程——尤其是当前线程释放mutex后马上调用yield，此时它仍处于就绪状态，调度器可能继续让它执行，导致它再次抢到mutex，形成“独占”的情况。

而 sleep_for(1ms) 会让当前线程进入休眠状态（离开就绪队列），此时调度器不得不选择其他就绪线程，所以能看到预期的交替执行效果。

无需sleep的解决方案 #

1. 用条件变量替代自旋逻辑（最优解） #

你的代码本质是在等待done状态变化，这种场景最适合用条件变量，既避免空轮询浪费CPU，又能让线程在条件满足时被精准唤醒，从根源解决调度问题：

#include <condition_variable>

// 类成员变量
std::mutex mtx;
std::condition_variable cv;
bool done = false;

void MyClass::do()
{
    std::unique_lock<std::mutex> lock(mtx);
    // 等待done变为true，期间会自动释放mutex，被唤醒时重新检查条件
    cv.wait(lock, [this]{ return done; });
    // 执行后续逻辑...
}

// 当需要触发done状态时（比如其他线程中）
void MyClass::set_done()
{
    std::lock_guard<std::mutex> lock(mtx);
    done = true;
    cv.notify_all(); // 唤醒所有等待的线程
}

这种方式下，线程不会无意义地轮询和调用yield，只有当条件真正变化时才会被唤醒执行，跨平台行为一致。

2. 调整mutex的获取时机（适配现有逻辑） #

如果不想大幅修改核心逻辑，可避免线程释放mutex后立即再次尝试获取：

void MyClass::do()
{
    {
        std::unique_lock<std::mutex> lock(mtx);
        while (!done)
        {
            ... // 原有逻辑
        }
    }
    // 这里不调用yield，让调度器自然选择下一个执行线程
    // 若必须保留主动让出逻辑，Windows下可直接调用SwitchToThread()（注意跨平台性）
}

不过这种方式仍存在轮询的CPU浪费，不如条件变量优雅。

3. 使用原子变量优化轮询 #

如果done状态不需要和其他共享资源绑定，可将done改为原子变量，减少mutex的持有时间，让其他线程更易获取锁：

#include <atomic>

// 类成员变量
std::mutex mtx;
std::atomic<bool> done = false;

void MyClass::do()
{
    while (!done.load(std::memory_order_acquire))
    {
        std::unique_lock<std::mutex> lock(mtx);
        ... // 原有需要mutex保护的逻辑
    }
}

这种方式下，线程在轮询done时不会持有mutex，其他线程能更顺利地获取锁，调度器也更容易切换线程。

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