From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC] aio: add aio_context_acquire() and aio_context_release()
Date: Thu, 29 Aug 2013 10:26:31 +0200 [thread overview]
Message-ID: <521F05B7.9000203@redhat.com> (raw)
In-Reply-To: <1377614385-20466-1-git-send-email-stefanha@redhat.com>
Il 27/08/2013 16:39, Stefan Hajnoczi ha scritto:
> +void aio_context_acquire(AioContext *ctx)
> +{
> + qemu_mutex_lock(&ctx->acquire_lock);
> + while (ctx->owner) {
> + assert(!qemu_thread_is_self(ctx->owner));
> + aio_notify(ctx); /* kick current owner */
> + qemu_cond_wait(&ctx->acquire_cond, &ctx->acquire_lock);
> + }
> + qemu_thread_get_self(&ctx->owner_thread);
> + ctx->owner = &ctx->owner_thread;
> + qemu_mutex_unlock(&ctx->acquire_lock);
> +}
> +
> +void aio_context_release(AioContext *ctx)
> +{
> + qemu_mutex_lock(&ctx->acquire_lock);
> + assert(ctx->owner && qemu_thread_is_self(ctx->owner));
> + ctx->owner = NULL;
> + qemu_cond_signal(&ctx->acquire_cond);
> + qemu_mutex_unlock(&ctx->acquire_lock);
> +}
Thinking more about it, there is a risk of busy waiting here if one
thread releases the AioContext and tries to acquire it again (as in the
common case of one thread doing acquire/poll/release in a loop). It
would only work if mutexes guarantee some level of fairness.
If you implement recursive acquisition, however, you can make aio_poll
acquire the context up until just before it invokes ppoll, and then
again after it comes back from the ppoll. The two acquire/release pair
will be no-ops if called during "synchronous" I/O such as
/* Another thread */
aio_context_acquire(ctx);
bdrv_read(bs, 0x1000, buf, 1);
aio_context_release(ctx);
Yet they will do the right thing when called from the event loop thread.
(where the bdrv_read can actually be something more complicated such as
a live snapshot or, in general, anything involving bdrv_drain_all).
Paolo
next prev parent reply other threads:[~2013-08-29 8:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 14:39 [Qemu-devel] [RFC] aio: add aio_context_acquire() and aio_context_release() Stefan Hajnoczi
2013-08-27 15:12 ` Paolo Bonzini
2013-08-28 2:41 ` Wenchao Xia
2013-08-27 18:33 ` Alex Bligh
2013-08-28 3:25 ` Wenchao Xia
2013-08-28 8:49 ` Stefan Hajnoczi
2013-08-29 1:09 ` Wenchao Xia
2013-08-29 7:43 ` Stefan Hajnoczi
2013-09-10 19:42 ` Michael Roth
2013-09-12 8:11 ` Stefan Hajnoczi
2013-08-29 8:26 ` Paolo Bonzini [this message]
2013-08-30 9:22 ` Stefan Hajnoczi
2013-08-30 13:24 ` Paolo Bonzini
2013-08-30 14:25 ` Stefan Hajnoczi
2013-08-30 4:02 ` Wenchao Xia
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=521F05B7.9000203@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=xiawenc@linux.vnet.ibm.com \
/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).