Re: [PATCH] thread-pool: signal condition variable while holding lock
Daniel P. Berrangé <[email protected]>
| Newsgroups | org.nongnu.qemu-trivial,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Mar 30, 2026 at 04:01:04PM +0300, 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; > } Doesn't this order mean that when the signal wakes up the waiting thread, that thread will get temporarily re-blocked waiting for 'lock' to be released by the original thread too. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|