diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2018-02-03 10:39:34 -0500 |
---|---|---|
committer | Fam Zheng <famz@redhat.com> | 2018-02-08 09:22:03 +0800 |
commit | 5261dd7b0106a88c9b323607136b1dfa1d7db689 (patch) | |
tree | 6463067b5849821f9639f5a3b5bcfd70513ac57c /stubs/ram-block.c | |
parent | 1a957cf9c4637abe4b7d67a91312a2565306641e (diff) |
coroutine-lock: make qemu_co_enter_next thread-safe
qemu_co_queue_next does not need to release and re-acquire the mutex,
because the queued coroutine does not run immediately. However, this
does not hold for qemu_co_enter_next. Now that qemu_co_queue_wait
can synchronize (via QemuLockable) with code that is not running in
coroutine context, it's important that code using qemu_co_enter_next
can easily use a standardized locking idiom.
First of all, qemu_co_enter_next must use aio_co_wake to restart the
coroutine. Second, the function gains a second argument, a QemuLockable*,
and the comments of qemu_co_queue_next and qemu_co_queue_restart_all
are adjusted to clarify the difference.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20180203153935.8056-5-pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Diffstat (limited to 'stubs/ram-block.c')
0 files changed, 0 insertions, 0 deletions