多次唤醒等待队列，对性能影大么？

鬼鬼一哈

模拟场景：线程A睡在等待队列上，等待被唤醒，其主要负责处理所有的请求。
              线程（1~10）不停的提交请求，提交成功后，唤醒等待队列。(假设提交的很频繁)。

问题：1。正常理解是提交一个请求，就应该去唤醒等待队列。但是如果大家都添加一个请求后，就去唤醒队列。对系统性能或者负载影响大么？
         2。若新建立一个线程，专门去负责唤醒队列，唤醒条件为：如果队列中请求超过某个阈值，则立即唤醒队列；或队列不为空，且超过100ms，也去唤醒队列？


PS：大家有什么好建议？

firkraag

1. If thread A is busying on processing the pending requests(means it is running), it could not sleep on the wait queue and there is nothing affecting it with the calling of wakeups. Otherwise, it will be wakeup by the call. The penalties will be the calls of wakeup when thread A is running. Many a little makes a mickle, perhaps it will do some native effects on the performance.

2. If you want to reorder the requests quite like the block device i/o request queues do, it can be used for reference.

BTW, the wait queue and request queue are not the same one.

鬼鬼一哈

是的，如果 thread A已经是running状态，再次唤醒是没什么大影响的。
但是不确定 thread A的状态，如果有大量请求，则希望 thread A尽量少的进入睡眠状态。

firkraag

Maybe can use one flag in request queue to express whether the thread A is running.

If you mean the request queue sync problem between the process thread(eg. thread A) and submit threads, you can use two request queues: one for pending requests, while one for dispatching requests. When the dispatching queue is empty, let the thread A swaps the two pointers of the two queues and continue to process.

No need to create another wakeup thread, just compare the pending requests number in the submit threads and use timer to deal with time-out.

鬼鬼一哈

恩，我可以试试。3Q

瀚海书香

回复 1# 鬼鬼一哈
这个要看具体的业务场景了。本身内核的wake_up操作是不会影响性能的。

   

鬼鬼一哈

回复 6# 瀚海书香
恩，关键是添加请求到队列中和唤醒队列后，处理请求，会互相抢占锁。。。3Q