我有点懵了,这么做会被卡住吗?线程玩的熟的帮忙看看。

weixi2864 2023-05-26 12:04:24

class Threadpool {

std::atomic_bool isPoolRunning_;

std::mutex taskQueMtx_; 

std::condition_variable notEmpty_;

...

}

 

析构函数

Threadpool::~Threadpool() {
isPoolRunning_ = false;
notEmpty_.notify_all();
std::unique_lock<std::mutex> lock(taskQueMtx_);
②exitCond_.wait(lock, [&]()-> bool { return threads_.size() == 0; });
}

 

线程函数

void Threadpool::threadFunc(int threadid)
{
auto lastTime = std::chrono::high_resolution_clock().now();

while(isPoolRunning_) {
③std::shared_ptr<Task> task;
//获取到任务,顺利释放锁
{
//要操作线程队列,先获取锁
④std::unique_lock<std::mutex> lock(taskQueMtx_);
std::cout << "tid=" << std::this_thread::get_id() << " 尝试获取任务" << std::endl;

......

}

 

有一套多线程的代码

我感觉退出的时候有互锁的可能性

主线程:到析构了①首先抢夺了锁

然后②陷入等待,但是锁没有释放

 

这时候如果子线程正好跑到③的位置

那是不是到④就互锁了?

 

百思不得其解,哪个高手帮着解释一下

关键是这玩意跑的很好,从来就没出过问题

给本帖投票

...全文
117 8 打赏 收藏 转发到动态 举报
写回复
用AI写文章
8 条回复
切换为时间正序
请发表友善的回复…
发表回复
于扶摇 2023-05-28
  • 打赏
  • 举报
回复

在析构函数中,线程pool在等待所有子线程退出时一直持有taskQueMtx_的锁,这会导致在子线程尝试获取任务时无法获取到锁,从而导致互锁的情况。为了避免这种情况,可以使用线程安全的等待所有子线程退出的方式,例如使用std:🧵:join_all()函数等待所有子线程退出。这样可以避免在等待过程中一直持有锁的情况,从而避免互锁问题。

weixi2864 2023-05-28
  • 举报
回复
@于扶摇 谢谢回复 我理解也是会卡住 关键这段代码一直在生产环境使用 从没有卡过。。。
weixi2864 2023-05-28
  • 举报
回复
@于扶摇 谢谢回复 我理解也是会卡住 关键这段代码一直在生产环境使用 从没有卡过。。。
weixin_47033079 2023-05-28
  • 打赏
  • 举报
回复

常在c用多线程处理数据,没在c++用过,但原理应该差不多。看你的程序只有一个锁,在一个线程上锁后其他线程无法使用这个锁,所以应该不会有冲突。

weixi2864 2023-05-28
  • 举报
回复
@weixin_47033079 谢谢回答 冲突到没发生 析构的线程和任务的线程肯定不同 但是析构的阻塞掉了 我感觉任务线程有可能卡在④上啊,这块是不是应该会有风险,即使是运气最差的情况下
weixin_47033079 2023-05-29
  • 举报
回复
@weixi2864 4这个位置不会卡,它会等1这个位置的锁解锁后才可以对锁进行操作,即使它们属于不同线程也会等待。
weixi2864 2023-05-29
  • 举报
回复
@weixin_47033079 但是有可能出现互锁呢 1等4 4等1
1条回复

69,433

社区成员

发帖
与我相关
我的任务
社区描述
C语言相关问题讨论
社区管理员
  • C语言
  • 花神庙码农
  • 架构师李肯
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧