hairet opened a new issue #707: 关于bthread task精准调度signal的疑问，请务必看一下 URL: https://github.com/apache/incubator-brpc/issues/707 **Describe the bug (描述bug)** 现在一个具体的TaskGroup在入了rq或者remote_queue之后，会根据no_signal开关决定是否立即signal 该TaskGroup对应的work线程，或者还是等待bthread_flush再执行。 有一个问题是TaskGroup里的signal实现如下 https://github.com/apache/incubator-brpc/blob/master/src/bthread/task_control.cpp  start_index是基于pthread_id计算出来的 一般非只要是worker执行bthread_start_background等，必然signal里的start_index找到的pl跟目标task_group的_pl = &c->_pl[butil::fmix64(pthread_numeric_id()) % TaskControl::PARKING_LOT_NUM];是对应的 但是如果是普通pthread，此时会走bthread::start_from_non_worker，此时对某个选出的task_group执行signal的线程的线程id并不等于，该task_group所属work线程的线程id,即signal的pl和对应work wait的pl可能不一致，则此时不是精准通知 我不太确定这种情况，对bthread调度的影响，看起来就是随机延时？因为大部分时候就4个pl,只要持续有调度（以及steal的存在，以及任何一个signal都会唤醒目标work把queue的任务都做完，并且去steal），所以一般在高qps场景，这种不精准的signal影响也不大。 **To Reproduce (复现方法)** **Expected behavior (期望行为)** 问题大约如上描述，简单来说就是，当一个普通pthread调用bthread_start_background，其就是把一个bthread任务丢给了一个work里的task_group里的remote_queue,然后取一个pl发signal,但是由于取pl的算法基于调用方线程id来算，则可能不是同一个pl **Versions (各种版本)** OS: Compiler: brpc: protobuf: **Additional context/screenshots (更多上下文/截图)**
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
