From: Paolo Bonzini <pbonzini@redhat.com>
To: David Engraf <david.engraf@sysgo.com>, qemu-devel@nongnu.org
Cc: Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu_mutex_iothread_locked not correctly synchronized
Date: Tue, 24 Nov 2015 16:54:39 +0100 [thread overview]
Message-ID: <5654883F.9050509@redhat.com> (raw)
In-Reply-To: <565485A0.5090902@sysgo.com>
On 24/11/2015 16:43, David Engraf wrote:
> Commit afbe70535ff1a8a7a32910cc15ebecc0ba92e7da introduced the function
> qemu_mutex_iothread_locked to avoid recursive locking of the iothread
> lock. The iothread_locked variable uses the __thread attribute which
> results in a per thread storage location whereas the qemu_global_mutex
> is not thread specific. This leads to race conditions because the
> variable is not in sync between threads.
Frankly, this makes no sense. You're modifying the
qemu_mutex_iothread_locked function to return whether _some_ thread has
taken the mutex, but the function tells you whether _the calling_ thread
has taken the mutex (that's the point about recursive locking). This
breaks the callers of qemu_mutex_iothread_locked completely.
The variable need not be in sync between the different threads; each
thread only needs to know about itself. The current code works because:
1) the iothread mutex is not locked before qemu_mutex_lock_iothread
2) the iothread mutex is not locked after qemu_mutex_lock_iothread
3) qemu_cond_wait doesn't matter because the thread does not run during
a qemu_cond_wait.
> I triggered this problem reproducible on a Windows machine whereas Linux works fine.
What are the symptoms, and what is your Windows compiler?
Paolo
next prev parent reply other threads:[~2015-11-24 15:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 15:43 [Qemu-devel] [PATCH] qemu_mutex_iothread_locked not correctly synchronized David Engraf
2015-11-24 15:54 ` Paolo Bonzini [this message]
2015-11-25 9:08 ` David Engraf
2015-11-25 12:31 ` [Qemu-devel] [PATCH v2] " David Engraf
2015-11-25 13:26 ` Paolo Bonzini
2015-11-25 14:04 ` David Engraf
2015-11-25 14:36 ` Paolo Bonzini
2015-11-25 15:48 ` David Engraf
2015-11-25 16:16 ` Paolo Bonzini
2015-11-26 9:12 ` David Engraf
2015-11-26 11:25 ` Stefan Weil
2015-11-26 14:26 ` David Engraf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5654883F.9050509@redhat.com \
--to=pbonzini@redhat.com \
--cc=david.engraf@sysgo.com \
--cc=famz@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.