【发布时间】：2019-07-22 09:22:47
【问题描述】：
thread1：锁定、休眠、解锁； thread2：加锁、解锁；
但是thread2永远无法获取锁，thread1反复获取锁。
我在Ubuntu 16.04(gcc 5.4)下尝试了很多次
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, NULL);
std::thread t1([&mutex]() {
while (true) {
pthread_mutex_lock(&mutex);
std::cerr << "thread 1" << std::endl;
sleep(1);
pthread_mutex_unlock(&mutex);
}
});
std::thread t2([&mutex]() {
while (true) {
pthread_mutex_lock(&mutex);
std::cerr << "thread 2" << std::endl;
pthread_mutex_unlock(&mutex);
}
});
t1.join();
t2.join();
线程 1 线程 1 线程 1 线程 1 线程 1 线程 1 线程 1 ...
【问题讨论】：
-
请发布一个完整的示例，其他人可以使用它来尝试重现您的结果。
-
听起来像是正常的饥饿问题。如果没有看到一些现实的minimal reproducible example，就很难说出它为什么会发生。
-
另外，考虑到您使用
std::thread和 lambda，为什么不改用标准 C++ 锁定原语？ -
但是thread2永远无法获得锁的现象也很奇怪 -- 真的，真的不是。想想如果
sleep不存在会发生什么——你会期望看到thread 1的长期运行和thread 2的长期运行，而不是交替thread 1 thread 2 thread 1 thread 2，因为线程2 只会在以下情况下获得控制权它会在 thread1 释放它的确切瞬间尝试锁定，反之亦然——因此，一旦线程获得锁定，它将倾向于反复重新锁定它。sleep只是使线程 2大大不太可能在正确的时间尝试锁定。 -
@trentcl ：是的，但假设调度程序是默认的
SCHED_OTHER并且没有手动调整友好度，只有人为的示例实际上不会产生。诚然，由于临界区 inside 的睡眠，这可能是一个人为的例子，希望这是从来没有人真正做过的事情。
标签： c multithreading locking mutex