butex_wake_all support nosignal flag

[yanglimingcn]

butex_wake*的需求 #1749

[wwbmmm]

exchange是不是也要传nosignal参数进去

[yanglimingcn]

exchange是希望调度的，所以应该是默认signal的，此外exchange也没有nosignal的参数

[wwbmmm]

exchange的时候会挂起原来的bthread，这里nosignal的含义是是否立即调度原来的bthread，可以给exchange加个参数。就像bthread_start_urgent也可以传nosignal。

[yanglimingcn]

如果在TaskGroup::exchange的参数变成 TaskGroup::exchange(TaskGroup** pg, bthread_t next_tid, bool nosched, bool nosignal) 把nosched的逻辑放到exchange里面，整个代码逻辑能更简单些。但是exchange的本意就是要切换协程，不知道这样是否合理。

[wwbmmm]

如果在TaskGroup::exchange的参数变成 TaskGroup::exchange(TaskGroup** pg, bthread_t next_tid, bool nosched, bool nosignal) 把nosched的逻辑放到exchange里面，整个代码逻辑能更简单些。但是exchange的本意就是要切换协程，不知道这样是否合理。

exchange本意是切换协程，加上nosched参数不太合理。但是nosignal参数是有意义的。

[yanglimingcn]

已经按照你的建议修改了，这样代码清晰很多

[yanglimingcn]

nosched参数是不是可以去掉了，如果nosignal是true，就不要调用exchange，而是调用ready_to_run
另外，我觉得exchange里面的nosignal=true会有问题，因为当前协程切出去了，再次回来需要一个flush，这个flush不知道谁去执行。这和其它地方的nosignal不一样，其它地方都是本协程唤醒其它协程，最后执行一次flush

[wwbmmm]

nosched参数是不是可以去掉了，如果nosignal是true，就不要调用exchange，而是调用ready_to_run 另外，我觉得exchange里面的nosignal=true会有问题，因为当前协程切出去了，再次回来需要一个flush，这个flush不知道谁去执行。这和其它地方的nosignal不一样，其它地方都是本协程唤醒其它协程，最后执行一次flush

你的意思是只需要支持nosched=true && nosignal=true 和 nosched=false && nosignal=false这两种场景是吗？
如果暂时没有nosched=true && nosignal=false和nosched=false && nosignal=true这两种场景的需求，也可以先去掉nosched参数。将来有需求再添加

[yanglimingcn]

nosched参数是不是可以去掉了，如果nosignal是true，就不要调用exchange，而是调用ready_to_run 另外，我觉得exchange里面的nosignal=true会有问题，因为当前协程切出去了，再次回来需要一个flush，这个flush不知道谁去执行。这和其它地方的nosignal不一样，其它地方都是本协程唤醒其它协程，最后执行一次flush

你的意思是只需要支持nosched=true && nosignal=true 和 nosched=false && nosignal=false这两种场景是吗？ 如果暂时没有nosched=true && nosignal=false和nosched=false && nosignal=true这两种场景的需求，也可以先去掉nosched参数。将来有需求再添加

嗯，这个需求最初的意思其实是让当前协程不被切换出去，尽量把一些事情处理完了，再统一去调度其他的协程。我再发出一版，辛苦你再Review一下。

[MrGuin]

nosched参数是不是可以去掉了，如果nosignal是true，就不要调用exchange，而是调用ready_to_run 另外，我觉得exchange里面的nosignal=true会有问题，因为当前协程切出去了，再次回来需要一个flush，这个flush不知道谁去执行。这和其它地方的nosignal不一样，其它地方都是本协程唤醒其它协程，最后执行一次flush

no_signal 为 true，不调用 exchange，ready_to_run* 会传递 no_signal 参数，被唤醒的 bthread 不就无法被及时调度了吗？
我们有同样的场景，不希望当前执行 butex_wake 的 bthread 被 exchange 转去执行被唤醒的 bthread，所以使用了这个 feature，现在观察到被唤醒的 bthread 从唤醒到被调度执行会有上百毫秒的延迟，因为现在的实现 no_signal 传递给了 ready_to_run*，导致无法被及时调度处理。

[MrGuin]

现在我这里每次 butex_wake 后主动调 bthread_flush 解决了不能及时调度的问题。
我看了下上下文，感觉当前的 no_signal 的实现针对场景是消费者 bthread 批量 butex_wake，然后再一次 bthread_flush，no_signal 参数不希望被调度，顺带也不会把当前 bthread 给 exchange 过去。但如果消费者无法批量去 butex_wake 最后统一 flush 的话，就只能传 no_signal 参数然后手动去 bthread_flush 了。
比如我们是 braft 状态机 on_apply 线程，每次修改状态机然后唤醒等待在 butex 上的 RPC线程，因为每个 raft group 的 on_apply 是严格串行的，是性能瓶颈，所以我们不希望它在唤醒别人的时候被切走，所以传了 no_signal，但被唤醒的 RPC bthread 也是要及时调度执行的，不然会影响 RPC 服务的 responsiveness。如果只是要达到不让当前调用 butex_wake 的线程被 exchange 走的效果，只能 no_signal 然后 bthread_flush，感觉不够优雅。
@wwbmmm 佬怎么看呢？

[wwbmmm]

只能 no_signal 然后 bthread_flush，感觉不够优雅

虽然不够优雅，但能解决问题吧，再加参数的话感觉这个接口也太复杂了。