欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 房产 > 建筑 > 《线程池:Linux平台编译线程池动态库发生的死锁问题》

《线程池:Linux平台编译线程池动态库发生的死锁问题》

2025/3/20 16:23:17 来源:https://blog.csdn.net/2202_75924820/article/details/146380042  浏览:    关键词:《线程池:Linux平台编译线程池动态库发生的死锁问题》

关于如何编译动态库可以移步《Linux:动态库动态链接与静态库静态链接》-CSDN博客

我们写的线程池代码是闭源的,未来想提供给别人使用,只需要提供so库和头文件即可。

系统默认库文件路径为:

usr/lib usr/loacl/lib

系统默认头文件路径为:

usr/include usr/local/include

g++ -fPIC -shared threadpool.cpp -o libtbpool.so -std=c++17sudo mv libtbpool.so /usr/local/lib
sudo mv threadpool.h /usr/local/includeg++ 线程池测试项目.cpp -ltdpool -lpthread//修改/ect/ld.so.conf.d/
//将库文件路径放进/ect/ld.so.conf.d/
//ldconfig更新缓存路径即可

在windows下运行好好的程序,在Linux下怎么又会发生死锁呢?

gdb attatch 线程id

info threads:查看当前程序所有线程信息,包括线程ID、线程状态等。看到四个线程好像都在阻塞等待“in __lll_lock_wait”。

thread 5进入五号线程,bt查看线程5堆栈信息。

thread 3进入3号线程,bt查看线程3堆栈信息。

可以看到,在post()函数里notify_all()阻塞了。也就是在线程在Result得到返回结果之后,唤醒notify_all()用户接收线程执行完任务的返回值的时候阻塞了。

// 实现一个信号量类
class Semaphore
{
public:Semaphore(int limit = 0):resLimit_(limit){}// 获取一个信号量资源void wait(){// 等待信号量有资源,没有资源,会阻塞当前线程std::unique_lock<std::mutex> lock(mtx_);cond_.wait(lock, [&]()->bool {return resLimit_ > 0; });resLimit_--;}// 增加一个信号量资源void post(){std::unique_lock<std::mutex> lock(mtx_);resLimit_++;cond_.notify_all();}private:int resLimit_;// 初始信号量资源个数std::mutex mtx_;std::condition_variable cond_;
};

来分析一下原因。

Linux上,这些Result对象也是局部对象,是要析构的!

执行任务也是需要花费时间的,但是主线程提交完任务,它才不管任务有没有执行完呢。出了作用域Result对象就析构了。

Result对象会调用它自己的析构函数析构。

Result对象成员变量就要析构,问题出现在Semaphore上,来看一下Semaphore的析构函数,也是默认的,那么mutex和condition_variable也会默认析构。

既然问题出现在cond这个条件变量上,我们来看一下cond系统是怎么实现的。

可以看到在VS下,条件变量析构会释放相应的资源的。

所以Result对象接收完任务的返回值,然后调用Result的sem信号量的sem_.post()函数,但是Result对象出了作用域以后就析构了,Semaphore也就析构了,所以在调用sem_.post()的时候,cond已经析构了,cond_.notify_all()这里啥也没做,不会阻塞,任务正常结束。

那么,我们猜测Linux下g++的库,条件变量析构没有释放相应的资源。

可以看到,Linux下条件变量的析构函数没有做任何事情。

Result对象出了作用域以后,就析构了,Semaphore也要析构,mutex和condition_variable变量也要析构,但是g++库里condtition_variable没有做任何事情,使用了一个已经出了生命周期的对象。

改起来也很简单:

// 实现一个信号量类
class Semaphore
{
public:Semaphore(int limit = 0):resLimit_(limit),isExit_(false){}~Semaphore(){isExit_ = true;}// 获取一个信号量资源void wait(){if(isExit_)true;// 等待信号量有资源,没有资源,会阻塞当前线程std::unique_lock<std::mutex> lock(mtx_);cond_.wait(lock, [&]()->bool {return resLimit_ > 0; });resLimit_--;}// 增加一个信号量资源void post(){if(isExit_)true;std::unique_lock<std::mutex> lock(mtx_);resLimit_++;cond_.notify_all();}private:std::atomic_bool isExit_;int resLimit_;// 初始信号量资源个数std::mutex mtx_;std::condition_variable cond_;
};

再去测试就没什么问题了。这样就解决了线程池在Linux下死锁的问题。 

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

热搜词