- 主题:经典死锁
没人这么用吧！
【 在 z16166 的大作中提到: 】
: 除了这种交叉加锁，
: void Foo()
: {
: ...................
--
FROM 221.218.60.*
有成功的吗？
【 在 z16166 的大作中提到: 】
: 你的意思是这么用的不是人吗？哈哈
:
--
FROM 221.218.60.*
失败了找你去解决的吧。
【 在 z16166 的大作中提到: 】
: 那只能说明您老用得少
: 1、std::scoped_lock就是用来解决交叉加锁的，先try_lock试探一下。当然，不加双锁最好了
: 2、拿着锁去join那些可能会请求锁的线程的，我看到不止3起了。
: ...................
--
FROM 221.218.60.*
用eventfd等吧，每个线程结束前写一下eventfd，主线程为每个线程设置eventfd，加到epoll里，然后等待epoll。
【 在 z16166 的大作中提到: 】
: 除了这种交叉加锁，
: void Foo()
: {
: ...................
--
FROM 221.218.60.*
【 在 z16166 的大作中提到: 】
: 那只能说明您老用得少
: 1、std::scoped_lock就是用来解决交叉加锁的，先try_lock试探一下。当然，不加双锁最好了
: 2、拿着锁去join那些可能会请求锁的线程的，我看到不止3起了。
: ...................
}
//设置分离线程
ret=pthread_attr_setdetachstate(&attr,PTHREAD_CREATE_DETACHED);
........
ret=pthread_create(&pthread_id,&attr,thread_work,&Conn);
主线程就不用管子线程的事情啦！
--
FROM 221.218.60.*
【 在 z16166 的大作中提到: 】
: .dll/.so里不能有野线程。试想一下dll被unload后，那个野线程还在跑的话。
:
https://www.newsmth.net/nForum/#!article/CPlusPlus/431596
这里边说了关于动态模块的管理。
--
FROM 221.218.60.*
不要在单例中调用线程，而是在线程中调用单例。
【 在 z16166 的大作中提到: 】
: 场景是dll中按需启、停某些单例的功能，这些单例中有开线程。
:
--
FROM 221.218.60.*
你愿意怎么办就怎么办吧。
反正，我给你看了那个动态模块热插拔管理。
不需要模块内部关心什么线程协程。
管理也是非常简单，被管理者与管理者没有什么耦合。
而且在大多数时间没有锁，只有一个引用计数管着。
线程与模块也是无关的，此时在某模块，彼时在另一模块。
模块的变更与线程无关。只看引用计数。
用C的线程，管理C++的模块。写模块的，不用管环境，专注你的业务。
【 在 z16166 的大作中提到: 】
: 在类中开线程，可以给线程lambda传递this指针，比较方便访问类的private member
: 解决办法是有的，除了上面说的用小锁，
: 另一个办法是拿着锁，move到临时变量里，放掉锁，再join线程
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*
粒度是so。
为了简便管理，要求每个模块一个so一个入口，完成一个单一功能。
如果需要许多模块协同工作，一般情况就在客户端处理，把问题分成很多步骤，串行或并行的各个部分，按次序发给服务器，然后再合并处理，就是所谓的map-reduce方法。
服务器框架处理线程协程连接池负载均衡容错交易完整性等等乱七八糟的，挺费神的问题。
业务人员就是一方面写客户端完成流程，另一方面写模块完成具体操作。他们只需要了解各层的借口规范，了解线程安全协程安全的要求即可。
【 在 z16166 的大作中提到: 】
: 您那个动态加载没啥问题，是常见手法，要看锁的粒度是到dll/so，还是到dll/so导出的每个接口。
: 有个userspace RCU，借鉴的linux kernel的搞法，专门解决read-copy-update场景的需求，貌似也可以用来更新这个dll/so导出的接口指针表。
:
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*