gpt4 book ai didi

c++ - 释放锁时的线程调度

转载 作者:搜寻专家 更新时间:2023-10-31 01:27:23 26 4
gpt4 key购买 nike

解锁互斥锁时,我的期望是调度程序会检查当前尝试锁定该互斥锁的其他线程,然后执行其中一个等待线程。我写了一个测试程序(见下面的代码),有 2 个线程都试图在循环中获取相同的互斥锁并做一些工作(休眠 1 毫秒)。不同之处在于,一个线程 t1 在解锁和尝试重新获取互斥量之间等待了一小段时间,而另一个线程 t2 则没有。我期望两个线程获取互斥体的次数大致相同。但是,在 Windows 上,t1 通常只获取一次互斥锁,而另一个线程则获取数百次。在 linux 上,行为是不同的,两个线程使用 t2 完成工作大约是两倍。为什么 Windows 上的 t1 几乎从不获取互斥量?我必须如何修改代码才能做到这一点?

示例代码:

#include <iostream>
#include <thread>
#include <mutex>
#include <atomic>

using namespace std;

int main()
{
mutex m;
atomic<bool> go(false);
int t1Counter = 0, t2Counter = 0;

thread t1([&] {
while(!go);
while(go) {
this_thread::sleep_for(100us);
lock_guard<mutex> lg(m);
this_thread::sleep_for(1ms);
++t1Counter;
}
});
thread t2([&] {
while(!go);
while(go) {
lock_guard<mutex> lg(m);
this_thread::sleep_for(1ms);
++t2Counter;
}
});

go = true;
this_thread::sleep_for(1s);
go = false;
t1.join();
t2.join();

cout << t1Counter << " " << t2Counter << endl;
}

最佳答案

在 Windows 上,std::mutex 是使用 slim reader/writer lock 实现的。这个锁实现是不公平的(意味着它不保证等待线程获取锁的顺序)。 Windows 不久前放弃了公平锁,因为 Microsoft 认为锁护航是比线程饥饿更严重的问题。

您可以在 Microsoft 文档上阅读更多关于 slim reader/writer locks 的信息:Slim Reader/Writer (SRW) Locks

Joe Duffy 也发表了关于公平与锁定车队问题的博文:Anti-convoy locks in Windows Server 2003 SP1 and Windows Vista

关于c++ - 释放锁时的线程调度,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53434834/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com