diff mbox

[1/3] kvm tools: Lock job_mutex before signalling

Message ID 1304170225-4859-1-git-send-email-levinsasha928@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sasha Levin April 30, 2011, 1:30 p.m. UTC
Locking mutex before signalling to prevent unexpected
scheduling.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
 tools/kvm/threadpool.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Comments

Pekka Enberg May 1, 2011, 7:10 a.m. UTC | #1
On Sat, 2011-04-30 at 16:30 +0300, Sasha Levin wrote:
> Locking mutex before signalling to prevent unexpected
> scheduling.
> 
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>

Yeah, I think we need to do this but the changelog is not really
adequate for this kind of change. Care to elaborate more why it's
needed?

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sasha Levin May 1, 2011, 7:43 a.m. UTC | #2
On Sun, 2011-05-01 at 10:10 +0300, Pekka Enberg wrote:
> On Sat, 2011-04-30 at 16:30 +0300, Sasha Levin wrote:
> > Locking mutex before signalling to prevent unexpected
> > scheduling.
> > 
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> 
> Yeah, I think we need to do this but the changelog is not really
> adequate for this kind of change. Care to elaborate more why it's
> needed?
> 

By holding the mutex while signaling, we can expect predictable
scheduling between the worker threads. This will make debugging various
thread pool related issues much easier (and maybe solve some obscure
bugs too).
diff mbox

Patch

diff --git a/tools/kvm/threadpool.c b/tools/kvm/threadpool.c
index c584ec7..700c08f 100644
--- a/tools/kvm/threadpool.c
+++ b/tools/kvm/threadpool.c
@@ -166,5 +166,7 @@  void thread_pool__signal_work(void *job)
 		thread_pool__job_info_push_locked(job);
 	mutex_unlock(&jobinfo->mutex);
 
+	mutex_lock(&job_mutex);
 	pthread_cond_signal(&job_cond);
+	mutex_unlock(&job_mutex);
 }