ZhengweiZhu commented on issue #2888: URL: https://github.com/apache/brpc/issues/2888#issuecomment-2676253820
在builtin service（包括/brpc_metrics和/vars）中访问metric时，不论访问一维（对应VarMapWithLock）还是多维（对应MVarMapWithLock），这里都使用的是pthread mutex。在bthread（builtin service是在bthread中执行的）中使用pthread同步原语是不正确的，可能造成死锁的用法。 作者描述的这种情况造成死锁的原因可能是：处理brpc_metrics服务的bthread所在的pthread worker先占用了MVarMapWithLock 中的pthread mutex，随后在对mvar get_value时通过PassiveStatus自定义的计算函数访问了某个bthread锁并产生了yield。问题的关键在于该bthread唤醒后可能不在原先的pthread worker上，此时再去对MVarMapWithLock的pthread mutex进行解锁是undefined behavior。下一次再访问到该pthread mutex加锁时，由于锁仍被占用而导致死锁。 由于业务代码可能在PassiveStatus自定义的计算函数中确实有加锁保护的需求，通过在文档中强调避免这种写法，不是最优做法，或者很难避免这种死锁问题出现。 正确做法是VarMapWithLock以及MVarMapWithLock应该使用bthread锁来保护，原先的写法属于是bug。将锁改用bthread锁后问题应该能解决。但在bazel编译的情况下，bthread模块由于使用了bvar，编译会依赖bvar模块，而bvar模块要想使用bthread锁又需依赖bthread模块，造成循环依赖，要解决循环依赖得对相关模块结构进行重构，改动不小 😞 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
