Re: [PATCH] thread-pool: signal condition variable while holding lock

On 3/30/26 15:01, Stepan Popov wrote:
> Move qemu_cond_signal() inside the critical section protected by pool->lock.
> Signaling while holding the lock imposes more predictable scheduling behavior.
> 
> Signed-off-by: Stepan Popov <[email protected]>
> ---
>   util/thread-pool.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/util/thread-pool.c b/util/thread-pool.c
> index 8f8cb38d5c..8e55aefd07 100644
> --- a/util/thread-pool.c
> +++ b/util/thread-pool.c
> @@ -265,8 +265,8 @@ BlockAIOCB *thread_pool_submit_aio(ThreadPoolFunc *func, void *arg,
>           spawn_thread(pool);
>       }
>       QTAILQ_INSERT_TAIL(&pool->request_list, req, reqs);
> -    qemu_mutex_unlock(&pool->lock);
>       qemu_cond_signal(&pool->request_cond);
> +    qemu_mutex_unlock(&pool->lock);
>       return &req->common;
>   }

In this code, in the past even very small changes had big impact on 
performance.  So, without some measurement I am wary of taking this change.

What is "more predictable scheduling behavior" is unclear, too.  If 
thead_pool_submit_aio() is preempted between qemu_cond_signal() and 
qemu_mutex_unlock(), then not only the waiting thread cannot start the 
work, but the mutex is taken and no one else can submit other requests.

Paolo