和tensorflow一起使用可能导致的死锁问题

[zgaze]

Describe the bug (描述bug)
和tensorflow一起使用有概率会死锁。 准备来说并不确定是brpc的bug。
但是使用公司内部rpc，相同的行为并不会发生死锁，因此比较大概率是brpc的bthread带来的影响。

现象和描述
用法：
1、rpc的接口里面调用tf的session run。设置了tf的超时时间，这个是tf主线程，应该是个bthread
2、tf应该是有自己的线程池处理本次pv。
3、tf的图节点有一个异步节点。 在这个异步节点 我使用brpc的DynamicPartitionChannel 请求下游多个节点，有设置超时时间。由rpc的回调触发tf的回调done。
现象：
1、死锁的线程只有一个栈(并没有bthread直接相关的栈)。是rpc的线程（bthread），在等待tf结果返回。 等于是这些工作线程死锁了，并不能继续对外提供服务。

syscall部分内核栈如下：
[] futex_wait_queue_me+0xc6/0x130
[] futex_wait+0x17b/0x280
[] do_futex+0x106/0x5a0
[] SyS_futex+0x80/0x180
[] system_call_fastpath+0x1c/0x21
[] 0xffffffffffffffff

2、brpc请求下游（在tf框架里，应该是pthread线程）出现了多个超时，1分钟后rpc线程里面tf开始大量报超时（报超时是正常的）。然后死锁（不能wait到超时了）。
3、线上多台服务，只有一两台有这个请求，稳定运行两周后偶现。

tensorflow 使用nsync库来实现同步。比如 condition_variable，不确定它是否会跟bthread冲突。

很愿意配合排查，任何建议都欢迎。

Expected behavior (期望行为)

Versions (各种版本)
OS:
Compiler: gcc 4.9.2
brpc: 1.2.0
protobuf: 3.8

Additional context/screenshots (更多上下文/截图)

[TousakaRin]

可以参考这里的FAQ：https://github.com/apache/brpc/blob/master/docs/cn/bthread.md
看起来是在锁内进行rpc导致worker被用光。

[zgaze]

可以参考这里的FAQ：https://github.com/apache/brpc/blob/master/docs/cn/bthread.md 看起来是在锁内进行rpc导致worker被用光。

是说 访问下游RPC导致占用了全部pthread，导致io没有worker来处理了吗？ 感觉不太像：
1、访问下游RPC是在tf的线程池里面做的，并且是异步rpc。
2、并且没有发现有线程阻塞在read等api上

所有的线程都很正常，除了io线程在等待tf返回或者超时。 个人感觉 最大的可能性就是bthread和github.com/google/nsync 有概率冲突。导致wait不能返回。
1、32core机器，33个线程都阻塞在了nsync::nsync_mu_semaphore_p_with_deadline。这应该是32个bthread，按照我对bthread的了解，它应该在阻塞时候让出cpu给其他任务，不会完全阻塞该pthread。 比较大的可能是nsync实现的同步原语，没有能将cpu让出来。 （对两个库都了解不多，算猜测）
2、就算业务代码有问题等，那么io线程里tf等待超时也应该能正常返回，不会一直阻塞在wait超时。

[chenBright]

我理解，（worker上）pthread锁内挂起bthread（rpc、bthread_usleep、butex等）的逻辑是有问题的，会很容易导致死锁。例如这个场景下：

一个worker线程执行bthread的时候加了pthread锁，然后挂起了。在该bthread释放pthread锁之前，该worker线程继续调度其他bthread（逻辑与前面的bthread一样），加了同一把pthread锁。在同一个pthread中连续加两次会死锁，逐渐地其他worker也加这把pthread锁，最后所有worker就阻塞在pthread锁上了。

[zgaze]

我理解，（worker上）pthread锁内挂起bthread（rpc、bthread_usleep、butex等）的逻辑是有问题的，会很容易导致死锁。例如这个场景下：

一个worker线程执行bthread的时候加了pthread锁，然后挂起了。在该bthread释放pthread锁之前，该worker线程继续调度其他bthread（逻辑与前面的bthread一样），加了同一把pthread锁。在同一个pthread中连续加两次会死锁，逐渐地其他worker也加这把pthread锁，最后所有worker就阻塞在pthread锁上了。

那么，总结来说。bthread+pthread线程池是有风险的，只要里面使用了bthread就会导致死锁。
我能想到的解决方案有：
1、pthread内部只使用pthread，不使用bthread，brpc client也使用pthread的。 那么目前：要做异步的pthread的使用DynamicPartitionChannel 的client，能否从bthread快速切换到pthread ？
2、处理请求不使用bthread，而使用pthread。比如：-usercode_in_pthread。 因为等待tf结果算是一个同步操作，那么可能需要比较大的线程池。

rpc的回调能否不使用bthread？

如果有其他更好的解决方案，欢迎补充。

[chenBright]

嗯，只有在brpc worker线程上才有问题吧。bthread的锁在pthread（非worker）上实际上是futex，应该没这个问题吧。

[chenzhangyi]

这个问题是tensorflow在有自己的线程池(cpu device带来的). 然后在rpc的worker线程内等计算结束，把所有的worker都阻塞住了。这个和是不是跑在bthread关系不大。 对这个问题而言，最简单的是限制下max concurrency。

[zgaze]

这个问题是tensorflow在有自己的线程池(cpu device带来的). 然后在rpc的worker线程内等计算结束，把所有的worker都阻塞住了。这个和是不是跑在bthread关系不大。 对这个问题而言，最简单的是限制下max concurrency。

如果是你说的这个问题，那么1、我只能 实现tf的异步 session run，然后用brpc的异步。 2、或者加pthread数量。3、 或者使用-usercode_in_pthread。

更建议那种方式呢？

[gexiaonie]

比较好奇你在TF里面是如何使用brpc的？看你的栈信息使用的DirectSession，DirectSession不是单机本地训练吗？应该不会走rpc呀？还是你们基于DirectSession做了一些特殊逻辑处理？
另外，栈信息看不出brpc相关的东西。可以在gdb里面把所有线程的栈打印出来，命令: taas bt

[zgaze]

比较好奇你在TF里面是如何使用brpc的？看你的栈信息使用的DirectSession，DirectSession不是单机本地训练吗？应该不会走rpc呀？还是你们基于DirectSession做了一些特殊逻辑处理？ 另外，栈信息看不出brpc相关的东西。可以在gdb里面把所有线程的栈打印出来，命令: taas bt

是单机的，只是为tf提供一个rpc接口。类似于 tensorflow service。 用户访问http接口，进行单机的tf计算，然后返回结果。

其他的栈我看了，没有异常。 只有33个线程阻塞在了DirectSession的wait上。此时，图的op里面用brpc调用的下游，因为是异步，但是没有bthread来处理回调，所以应该是堆积在了队列里（猜测，等后续复现，我会用gdb打印出内存内容看）。

"在rpc的worker线程内等计算结束，把所有的worker都阻塞住了 " 这个结论我觉得是正确的。 所以我现在正寻找解决方案。
不知道把"等计算结束"改成异步的，是不是能彻底解决这个问题。

另外我其实想知道。brpc对这种需要长时间的io的。如果不异步，是不是也会出现把worker线程打满的问题。 比如worker都陷入了同步的read。

[gexiaonie]

你的场景大概是: 本身是一个brpc服务，然后调用tf的，而tf里面有部分op是请求下游的rpc服务？这个场景的核心问题就是DirectSession::Run会使用pthread同步机制，阻塞当前的pthread。导致bthread的worker线程被卡住，bthread无法切换走。qps一高，就有可能导致bthread的线程池全部被占用，但是TF的RPC Op还等着处理，就导致死锁了。感觉可以这样解决: 新建一个pthread线程池，将session::run丢到这个新建的线程池处理（当然使用异步的方式）。这样就不会导致bthread worker线程卡死的问题了。

[zgaze]

你的场景大概是: 本身是一个brpc服务，然后调用tf的，而tf里面有部分op是请求下游的rpc服务？这个场景的核心问题就是DirectSession::Run会使用pthread同步机制，阻塞当前的pthread。导致bthread的worker线程被卡住，bthread无法切换走。qps一高，就有可能导致bthread的线程池全部被占用，但是TF的RPC Op还等着处理，就导致死锁了。感觉可以这样解决: 新建一个pthread线程池，将session::run丢到这个新建的线程池处理（当然使用异步的方式）。这样就不会导致bthread worker线程卡死的问题了。

非常感谢。 这个思路我之前有，但是不确定能不能解决这个问题。
这个问题我关闭，感谢几位的热情支持 。另外，我觉得brpc可以提供一个utils类，来支撑这样的场景。感觉还是挺常见的。

[solesoul123]

同样遇到了这个问题，请问后续有排查到具体原因吗