From: Paolo Bonzini <pbonzini@redhat.com>
To: qemu-devel@nongnu.org
Cc: armbru@redhat.com, kwolf@redhat.com
Subject: [PATCH 5/5] monitor: do not use mb_read/mb_set
Date: Thu, 18 May 2023 12:18:23 +0200 [thread overview]
Message-ID: <20230518101823.992158-6-pbonzini@redhat.com> (raw)
In-Reply-To: <20230518101823.992158-1-pbonzini@redhat.com>
Instead of relying on magic memory barriers, document the pattern that
is being used. It is the one based on Dekker's algorithm, and in this
case it is embodied as follows:
enqueue request; sleeping = true;
smp_mb(); smp_mb();
if (sleeping) kick(); if (!have a request) yield();
qatomic_mb_set() can be kept---but it will be shortly renamed to
qatomic_set_mb() to clarify that the write occurs _before_ the
barrier, just in the right column of the pseudocode above.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
monitor/qmp.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/monitor/qmp.c b/monitor/qmp.c
index 9ec28be2ee10..aee8ce4cf006 100644
--- a/monitor/qmp.c
+++ b/monitor/qmp.c
@@ -39,13 +39,16 @@
* coroutine never gets scheduled a second time when it's already
* scheduled (scheduling the same coroutine twice is forbidden).
*
- * It is true if the coroutine is active and processing requests.
- * Additional requests may then be pushed onto mon->qmp_requests,
- * and @qmp_dispatcher_co_shutdown may be set without further ado.
- * @qmp_dispatcher_co_busy must not be woken up in this case.
+ * It is true if the coroutine will process at least one more request
+ * before going to sleep. Either it has been kicked already, or it
+ * is active and processing requests. Additional requests may therefore
+ * be pushed onto mon->qmp_requests, and @qmp_dispatcher_co_shutdown may
+ * be set without further ado. @qmp_dispatcher_co must not be woken up
+ * in this case.
*
- * If false, you also have to set @qmp_dispatcher_co_busy to true and
- * wake up @qmp_dispatcher_co after pushing the new requests.
+ * If false, you have to wake up @qmp_dispatcher_co after pushing new
+ * requests. You also have to set @qmp_dispatcher_co_busy to true
+ * before waking up the coroutine.
*
* The coroutine will automatically change this variable back to false
* before it yields. Nobody else may set the variable to false.
@@ -230,15 +233,18 @@ static QMPRequest *monitor_qmp_dispatcher_pop_any(void)
{
for (;;) {
/*
- * busy must be set to true again by whoever
- * rescheduled us to avoid double scheduling
+ * To avoid double scheduling, busy is true on entry to
+ * monitor_qmp_dispatcher_co(), and must be set again before
+ * aio_co_wake()-ing it.
*/
- assert(qatomic_mb_read(&qmp_dispatcher_co_busy) == true);
+ assert(qatomic_read(&qmp_dispatcher_co_busy) == true);
/*
* Mark the dispatcher as not busy already here so that we
* don't miss any new requests coming in the middle of our
* processing.
+ *
+ * Clear qmp_dispatcher_co_busy before reading request.
*/
qatomic_mb_set(&qmp_dispatcher_co_busy, false);
@@ -364,6 +370,9 @@ void coroutine_fn monitor_qmp_dispatcher_co(void *data)
void qmp_dispatcher_co_wake(void)
{
+ /* Write request before reading qmp_dispatcher_co_busy. */
+ smp_mb__before_rmw();
+
if (!qatomic_xchg(&qmp_dispatcher_co_busy, true)) {
aio_co_wake(qmp_dispatcher_co);
}
--
2.40.1
prev parent reply other threads:[~2023-05-18 10:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 10:18 [PATCH 0/5] qmp: cleanup QMP dispatcher coroutine Paolo Bonzini
2023-05-18 10:18 ` [PATCH 1/5] monitor: cleanup detection of qmp_dispatcher_co shutting down Paolo Bonzini
2023-05-18 10:18 ` [PATCH 2/5] monitor: cleanup fetching of QMP requests Paolo Bonzini
2023-05-18 10:18 ` [PATCH 3/5] monitor: introduce qmp_dispatcher_co_wake Paolo Bonzini
2023-05-18 10:18 ` [PATCH 4/5] monitor: extract request dequeuing to a new function Paolo Bonzini
2023-05-18 10:18 ` Paolo Bonzini [this message]
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=20230518101823.992158-6-pbonzini@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).