|
From: | Paolo Bonzini |
Subject: | Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock |
Date: | Mon, 2 May 2022 15:15:35 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
On 5/2/22 10:02, Emanuele Giuseppe Esposito wrote:
Are you saying rdlock isn't necessary in the main loop because nothing can take the wrlock while our code is executing in the main loop?Yes, that's the idea. If I am not mistaken (and I hope I am not), only the main loop currently modifies/is allowed to modify the graph. The only case where currently we need to take the rdlock in main loop is when we have the case simplified_flush_callback(bs) { for (child in bs) bdrv_flush(child->bs); } some_function() { GLOBAL_STATE_CODE(); /* assume bdrv_get_aio_context(bs) != qemu_in_main_thread() */ bdrv_flush(bs); co = coroutine_create(bdrv_get_aio_context(bs)) qemu_coroutine_enter(co, simplified_flush_callback) }
This is correct, but it is very unsafe as long as bdrv_flush(bs) is allowed to run both in coroutine context and outside. So we go circling back to the same issue that was there in the stackless coroutine experiment, i.e. functions that can run both in coroutine context and outside.
This issue is fundamentally one of unclear invariants, and reminds me a lot of the problems with recursive mutexes.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |