butex_wait超时无法唤醒

[eddie74748]

Describe the bug (描述bug)
bthread中调用butex_wait方法在参数abstime很小的情况下出现无法唤醒

To Reproduce (复现方法)
真实场景暂时无法复现，阅读代码中发现有这个可能，也通过手动改代码构造场景复现过

Expected behavior (期望行为)

Versions (各种版本)
OS: centos 7
Compiler:gcc 4.8
brpc: master
protobuf:2.4.1

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

在butex_wait方法中
https://github.com/brpc/brpc/blob/master/src/bthread/butex.cpp

代码641行中的erase_from_butex_and_wakeup有定时器在timer_thread中触发
代码655行中的wait_for_butex由下一个bthread在worker线程中调用

理论上来说，上述两个函数的执行时序没有办法保证的，
而如果erase_from_butex_and_wakeup在wait_for_butex前执行，那么调用butex_wait方法的bthread将永远无法唤醒。

[jamesge]

wait_for_butex中对这些情况有处理，重点看看应用代码吧

[jamesge]

ps：看下有没有自定义timer回调可能会阻塞全局的TimerThread

[eddie74748]

butex_wait 并没有自定义的回调，只是等待mutex直到有信号或者超时。
目前，设计了一个测试场景。

1. bthread A中调用 butex_wait() 设置1s超时。
2. 修改butex_wait源代码 ：在g->set_remained(wait_for_butex, &&bbw)；之前添加一句：std::this_thread:::sleep_for(2s);如此构造的原因是确保erase_from_butex_and_wakeup在Timer线程中被先执行。
3. A 这个bthread将永远都不会被唤醒。

这个测试中修改源码当然是不合理的，但是我比较疑惑的是，只要erase_from_butex_and_wakeup这个超时函数在wait_for_butex之前被执行，这个场景就会出现。那么框架是如何保证erase_from_butex_and_wakeup永远不会早于wait_for_butex被执行呢？从可构造测试场景来看，这并不是一个强保证。

[hairet]

butex_wait 并没有自定义的回调，只是等待mutex直到有信号或者超时。
目前，设计了一个测试场景。

1. bthread A中调用 butex_wait() 设置1s超时。
2. 修改butex_wait源代码 ：在g->set_remained(wait_for_butex, &&bbw)；之前添加一句：std::this_thread:::sleep_for(2s);如此构造的原因是确保erase_from_butex_and_wakeup在Timer线程中被先执行。
3. A 这个bthread将永远都不会被唤醒。

这个测试中修改源码当然是不合理的，但是我比较疑惑的是，只要erase_from_butex_and_wakeup这个超时函数在wait_for_butex之前被执行，这个场景就会出现。那么框架是如何保证erase_from_butex_and_wakeup永远不会早于wait_for_butex被执行呢？从可构造测试场景来看，这并不是一个强保证。

如果不考虑2个点：
1.butex_wait总是预期有butex_wake去唤醒
2.butex_wait的abstime一般不会传一个精度这么小的超时（如果有，其实定时器本身也不一定能支持这么高的精度）。换句话说，如果不是故意在源码里sleep,或者remain有卡顿，你的erase_from_butex_and_wakeup比wait_for_butex先执行的情况不会发生。

正确性来说，我觉得你说的是对的，只要erase_from_butex_and_wakeup先执行且没有butex_wake，该bthread就是无法唤醒的

[hexssh]

butex_wait 并没有自定义的回调，只是等待mutex直到有信号或者超时。
目前，设计了一个测试场景。

1. bthread A中调用 butex_wait() 设置1s超时。
2. 修改butex_wait源代码 ：在g->set_remained(wait_for_butex, &&bbw)；之前添加一句：std::this_thread:::sleep_for(2s);如此构造的原因是确保erase_from_butex_and_wakeup在Timer线程中被先执行。
3. A 这个bthread将永远都不会被唤醒。

这个测试中修改源码当然是不合理的，但是我比较疑惑的是，只要erase_from_butex_and_wakeup这个超时函数在wait_for_butex之前被执行，这个场景就会出现。那么框架是如何保证erase_from_butex_and_wakeup永远不会早于wait_for_butex被执行呢？从可构造测试场景来看，这并不是一个强保证。

如果不考虑2个点：
1.butex_wait总是预期有butex_wake去唤醒
2.butex_wait的abstime一般不会传一个精度这么小的超时（如果有，其实定时器本身也不一定能支持这么高的精度）。换句话说，如果不是故意在源码里sleep,或者remain有卡顿，你的erase_from_butex_and_wakeup比wait_for_butex先执行的情况不会发生。

正确性来说，我觉得你说的是对的，只要erase_from_butex_and_wakeup先执行且没有butex_wake，该bthread就是无法唤醒的

如果不是故意在源码里sleep,或者remain有卡顿，你的erase_from_butex_and_wakeup比wait_for_butex先执行的情况不会发生。
上面这个条件正常情况下确实是这样的，但是，线程是有时间片的，假如A这个线程在调用g->set_remained(wait_for_butex, &&bbw)之前由于时间片到期，而发生切换，又由于系统中存在大量的线程，那么A这个线程再次轮到时间片的时候是否就可能是毫秒级了，毫秒级的话就已经可以触发超时了。
当然，这是非常极限和极端的情况，但是不排除这种可能把。

[hairet]

butex_wait 并没有自定义的回调，只是等待mutex直到有信号或者超时。
目前，设计了一个测试场景。

1. bthread A中调用 butex_wait() 设置1s超时。
2. 修改butex_wait源代码 ：在g->set_remained(wait_for_butex, &&bbw)；之前添加一句：std::this_thread:::sleep_for(2s);如此构造的原因是确保erase_from_butex_and_wakeup在Timer线程中被先执行。
3. A 这个bthread将永远都不会被唤醒。

这个测试中修改源码当然是不合理的，但是我比较疑惑的是，只要erase_from_butex_and_wakeup这个超时函数在wait_for_butex之前被执行，这个场景就会出现。那么框架是如何保证erase_from_butex_and_wakeup永远不会早于wait_for_butex被执行呢？从可构造测试场景来看，这并不是一个强保证。

如果不考虑2个点：
1.butex_wait总是预期有butex_wake去唤醒
2.butex_wait的abstime一般不会传一个精度这么小的超时（如果有，其实定时器本身也不一定能支持这么高的精度）。换句话说，如果不是故意在源码里sleep,或者remain有卡顿，你的erase_from_butex_and_wakeup比wait_for_butex先执行的情况不会发生。
正确性来说，我觉得你说的是对的，只要erase_from_butex_and_wakeup先执行且没有butex_wake，该bthread就是无法唤醒的

如果不是故意在源码里sleep,或者remain有卡顿，你的erase_from_butex_and_wakeup比wait_for_butex先执行的情况不会发生。
上面这个条件正常情况下确实是这样的，但是，线程是有时间片的，假如A这个线程在调用g->set_remained(wait_for_butex, &&bbw)之前由于时间片到期，而发生切换，又由于系统中存在大量的线程，那么A这个线程再次轮到时间片的时候是否就可能是毫秒级了，毫秒级的话就已经可以触发超时了。
当然，这是非常极限和极端的情况，但是不排除这种可能把。

是的，我觉得有可能

[jamesge]

这个问题在我本地复现了，原因是bthread在被queue进butex前，是没有container字段的，从而导致erase_from_butex_and_wakeup并没有修改waiter_state。但container这套逻辑和butex_requeue混合在一起还是相当复杂的，目前没有看到特别可信简单的改法。考虑到这个问题在实际场景中发生的可能性很低，这个问题暂时就不修复了。

[stale]

This issue has been automatically marked as stale because it's inactive for a long time. It will be closed if no further activity occurs, reopen if you have further ideas. Thank you for your contributions! 由于很久没有活跃，此Issue已被自动标记为过期。之后几天仍无变化的话将会被关闭，若你有新想法则可重新打开。感谢你的贡献!