
在C++多线程编程里,当我们遇到一个线程需要等待某个条件满足才能继续执行的情况,std::condition_variable就是那个常常被我们请出来的“协调员”。它不是一个独立的锁,而是一个与std::mutex协同工作的工具,主要职责是让线程在特定条件下进入休眠状态,直到另一个线程发出信号唤醒它。简单来说,它解决了“等待”这个难题,避免了无谓的忙等待,让线程更高效地利用CPU资源。
解决方案要在C++中有效地使用条件变量,核心思想是将其与互斥锁(std::mutex)结合起来,共同管理共享数据的访问和线程间的通知。最经典的场景莫过于生产者-消费者模型。
#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>
#include <chrono> // For std::chrono::milliseconds
std::mutex mtx; // 互斥锁,保护共享数据
std::condition_variable cv; // 条件变量,用于线程间通信
std::queue<int> data_queue; // 共享数据队列
const int MAX_QUEUE_SIZE = 5; // 队列最大容量
// 生产者线程
void producer() {
for (int i = 0; i < 10; ++i) {
std::unique_lock<std::mutex> lock(mtx); // 锁定互斥量
// 等待队列不满。如果队列已满,生产者线程在此处等待
// wait()会自动释放锁并阻塞,被唤醒后会重新获取锁
cv.wait(lock, [&]{ return data_queue.size() < MAX_QUEUE_SIZE; });
data_queue.push(i); // 生产数据
std::cout << "Producer produced: " << i << ". Queue size: " << data_queue.size() << std::endl;
lock.unlock(); // 提前释放锁,让消费者有机会竞争
cv.notify_one(); // 通知一个等待中的消费者线程
std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟生产耗时
}
std::cout << "Producer finished." << std::endl;
}
// 消费者线程
void consumer() {
for (int i = 0; i < 10; ++i) {
std::unique_lock<std::mutex> lock(mtx); // 锁定互斥量
// 等待队列不空。如果队列为空,消费者线程在此处等待
cv.wait(lock, [&]{ return !data_queue.empty(); });
int data = data_queue.front(); // 消费数据
data_queue.pop();
std::cout << "Consumer consumed: " << data << ". Queue size: " << data_queue.size() << std::endl;
lock.unlock(); // 提前释放锁,让生产者有机会竞争
cv.notify_one(); // 通知一个等待中的生产者线程
std::this_thread::sleep_for(std::chrono::milliseconds(150)); // 模拟消费耗时
}
std::cout << "Consumer finished." << std::endl;
}
// int main() {
// std::thread prod_thread(producer);
// std::thread cons_thread(consumer);
// prod_thread.join();
// cons_thread.join();
// std::cout << "All threads finished." << std::endl;
// return 0;
// } 这个例子里,std::unique_lock确保了对data_queue的独占访问。cv.wait()是关键:它会在条件不满足时释放锁并让当前线程休眠,直到被notify_one()或notify_all()唤醒,并重新获取锁。传入的lambda表达式(谓词)是防止虚假唤醒和“丢失的唤醒”的关键。
条件变量究竟解决了哪些痛点?它和互斥量有什么不同?说实话,刚接触多线程的时候,我常常会把互斥量和条件变量的概念搞混,或者觉得互斥量是不是就够用了。但深入下去,你会发现它们俩是完全不同的角色,却又密不可分。互斥量(std::mutex)的核心职责是保护共享资源,确保在任何时刻只有一个线程能访问它,避免数据竞争。它就像一道门,一次只能进出一个人。
但光有门还不够。设想一个场景:一个线程A需要处理某个数据,但这个数据还没准备好。如果线程A只是傻傻地用一个循环去不断检查数据是否准备好(也就是所谓的“忙等待”),那它就会白白消耗CPU资源,效率极低。这就是互斥量解决不了的痛点——线程间的协作与等待。
条件变量(std::condition_variable)就是来解决这个问题的。它提供了一种机制,让一个线程可以在某个条件不满足时主动挂起(休眠),释放互斥锁,等待其他线程通知它条件已经满足。一旦条件满足,被通知的线程就会被唤醒,重新尝试获取互斥锁,然后继续执行。这就像是门旁边的一个呼叫器:数据没准备好,你就按一下呼叫器,然后去休息,等数据准备好了,有人会按呼叫器通知你。
HyperWrite
AI写作助手帮助你创作内容更自信
54
查看详情
所以,它们的不同点很明显:
- 互斥量:解决资源访问冲突问题,保证原子性。
- 条件变量:解决线程等待与通知问题,实现线程间的协作。
它们之所以要配合使用,是因为条件变量在等待时需要释放互斥锁,这样其他线程才能进入临界区改变条件。被唤醒的线程也需要重新获取互斥锁,才能安全地检查条件并访问共享数据。没有互斥锁的保护,条件变量的等待和通知机制就毫无意义,甚至会引入新的数据竞争问题。我个人觉得,理解它们的这种“共生”关系,是掌握C++多线程同步的关键一步。
使用std::condition_variable时有哪些常见的陷阱和最佳实践?在使用std::condition_variable时,虽然它功能强大,但确实有些地方稍不注意就可能踩坑。我总结了几点,也算是自己摸索过程中吃过亏的地方。
-
虚假唤醒(Spurious Wakeups):这是最常见的陷阱之一。条件变量的wait()方法有时可能会在没有notify_one()或notify_all()调用时被唤醒。这听起来有点反直觉,但确实会发生,而且是标准允许的行为。
- 最佳实践:始终使用谓词(predicate)。cv.wait(lock, []{ return condition; }); 这种形式是强烈推荐的。wait方法会在被唤醒后,自动重新检查谓词。如果谓词仍然为false,它会再次释放锁并进入等待状态。这确保了线程只在真正需要时才继续执行,有效规避了虚假唤醒带来的问题。
-
“丢失的唤醒”(Lost Wakeups):如果一个notify_one()或notify_all()调用发生在wait()方法被调用之前,那么这个唤醒信号就可能被“丢失”了,导致本应被唤醒的线程永远等待下去。这通常发生在条件已经满足,但等待线程还没来得及进入wait状态的时候。
-
最佳实践:
- 在改变条件后立即调用notify_one()或notify_all()。虽然理论上可以在解锁互斥量后调用notify,但在互斥量保护
-
最佳实践:
以上就是如何在C++中使用条件变量_C++多线程同步之条件变量的详细内容,更多请关注知识资源分享宝库其它相关文章!
相关标签: 工具 ai c++ ios red 循环 Lambda 线程 多线程 大家都在看: C++中this指针在类成员函数中是如何工作的 C++内存泄漏检测工具使用技巧 C++工厂模式与抽象工厂区别解析 C++开发环境配置调试工具使用技巧 使用vcpkg为C++项目管理依赖库的具体步骤是什么






发表评论:
◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。