关于条件变量wait操作中锁的作用

condition_variable::wait的锁

在看C++ Concurrency in Action 6.2.3节的线程安全队列时,其对condition_variable的使用与常规用法有点不同,我对condition_variable::wait中锁的作用产生了疑惑:它究竟是保护的谁?于是找到了 C++ notify_one之前应不应该加锁问题探讨 这篇文章,解决了我的疑惑。

文中例子用到了单元测试框架gtest,先安装一下:

git clone https://github.com/google/googletest.git
cd googletest
cmake .
make

编译成功的话会在lib目录下生成libgmock.a,libgmock_main.a,libgtest.a,libgtest_main.a,头文件在include/gtest下,如果想要安装到系统目录,用root用户执行make install,会将头文件拷贝到/usr/local/include/gtest,将库文件拷贝到/usr/local/lib。

然后运行文中的例子:

#include <thread>
#include <mutex>
#include <condition_variable>
#include <gtest/gtest.h>

bool flag = false;
std::mutex m;
std::condition_variable cv;

void Prod(void)
{
	std::unique_lock<std::mutex> lk(m);
	cv.wait(lk, []{ return flag; }); // #3
}
void Cons(void)
{
	flag = true;
	cv.notify_one();
}
TEST(notify_test, T01)
{
	flag = false; // #1
	std::thread tProd(Prod);
	std::thread tCons(Cons);
	tProd.join();
	tCons.join();
}

int main(int argc, char *argv[])
{
	flag = false; // #2
	testing::InitGoogleTest(&argc, argv);
	return RUN_ALL_TESTS();
}

可执行程序用参数--gtest_repeat=-1运行,意为一直重复执行下去。大概执行几百到几千次,进程就会卡住。
语句3等价于

while(!flag)
{
	cv.wait(lk); // #4
}

考虑下面描述的情况:线程tProd判断!flag条件成立,准备wait;线程tCons置flag为true,并notify;线程tProd进入wait阻塞。这样就导致了signal丢失,线程tProd无法唤醒。
可以在语句4之前添加一个等待std::this_thread::sleep_for(std::chrono::milliseconds(100));让这个现象变得很明显,这样几乎每次都会出现卡住的情况了。

另外如果去掉语句1,无论语句2存在与否,都没有出现卡住的情况,不知是什么原因。

要解决掉这个问题,只需要在Cons中修改flag时给加上锁:

void Prod(void)
{
	std::unique_lock<std::mutex> lk(m);
	while(!flag)
	{
		// 此时Cons拿不到锁,就不可能设置flag,也就不可能notify
		std::this_thread::sleep_for(std::chrono::milliseconds(100));
		cv.wait(lk);
	}
}
void Cons(void)
{
	{
		std::lock_guard<std::mutex> lk(m);
		flag = true;
	}
	cv.notify_one();
}

所以wait的锁,保护的是条件,notify的时候不需要加锁,但一定要在条件设置上以后调用。

再回过头来看看void condition_variable::wait(std::unique_lock<std::mutex>& lock);的描述:atomically unlocks lock, blocks the current executing thread, and adds it to the list of threads waiting on *this.
如果解锁和阻塞操作不是原子的又会怎么样?解锁后,到进入阻塞的这段时间内,如果别的线程拿到了锁并notify了一个信号,此次信号会丢失。

线程安全队列

C++ Concurrency in Action 6.2.3节一步一步实现了线程安全队列。

开始封装了std::queue,使用一个互斥量对数据队列进行保护。

为了使用细粒度锁,用链表实现了一个单线程队列,维护头尾两个指针,从尾部push,头部pop。因为头尾指针两个数据项,便使用两个互斥量来保护头指针和尾指针。
当队列中只有一个元素时,头尾指针相同,head->next和tail->next是同一个对象,这个对象需要保护。

然后添加了一个无数据的虚节点,这个节点永远在队列的最后,用来分离头尾指针能访问的节点。同时将节点的数据类型从T换成了std::shared_ptr<T>,push的时候也可先分配内存,加锁后只需调用shared_ptr的移动构造,虚节点中的数据是未初值化的shared_ptr。

再然后为了支持wait_and_pop,添加了条件变量,但是代码是有问题的,本质上就是上节提到的问题,stackoverflow上有描述 fine-grained locking queue in c++
问题复现代码如下:

#include <gtest/gtest.h>
threadsafe_queue<int> q;
TEST(queue_test, T01)
{
	std::thread a([]{q.wait_and_pop();});
	std::thread b([]{q.push(10);});
	a.join();
	b.join();
}
int main(int argc, char *argv[])
{
	testing::InitGoogleTest(&argc, argv);
	return RUN_ALL_TESTS();
}
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值