Am 09.05.23 um 15:53 schrieb Kevin Wolf: > Am 09.05.2023 um 12:26 hat Fiona Ebner geschrieben: >> Am 08.05.23 um 12:40 schrieb Kevin Wolf: >>> Am 05.05.2023 um 11:35 hat Fiona Ebner geschrieben: >>>> Hi, >>>> I noticed that the bdrv_graph_co_rd_lock() and bdrv_graph_co_rd_unlock() >>>> functions use qemu_in_main_thread() as a conditional to return early. >>>> What high-level requirements ensure that qemu_in_main_thread() will >>>> evaluate to the same value during locking and unlocking? >>> >>> I think it's actually wrong. >>> >>> There are some conditions under which we don't actually need to do >>> anything for locking: Writing the graph is only possible from the main >>> context while holding the BQL. So if a reader is running in the main >>> contextunder the BQL and knows that it won't be interrupted until the >>> next writer runs, we don't actually need to do anything. >>> >>> This is the case if the reader code neither has a nested event loop >>> (this is forbidden anyway while you hold the lock) nor is a coroutine >>> (because a writer could run when the coroutine has yielded). >> >> Sorry, I don't understand the first part. If bdrv_writev_vmstate() is >> called, then, because it is a generated coroutine wrapper, >> AIO_WAIT_WHILE()/aio_poll() is used. And that is the case regardless of >> whether the lock is held or not, i.e. there is a nested event loop even >> if the lock is held? > > With "lock" you mean the graph lock here, not the BQL, right?
Oh, I actually meant the BQL. Since your "lock" refers to the graph lock, that explains my confusion :) > > These generated coroutine wrapper are a bit ugly because they behave > different when called from a coroutine and when called outside of > coroutine context: > > * In coroutine context, the caller MUST hold the lock > * Outside of coroutine context, the caller MUST NOT hold the lock > > The second requirement comes from AIO_WAIT_WHILE(), like you say. If you > hold the lock and you're not in a coroutine, you simply can't call such > functions. > > However, as bdrv_graph_co_rdlock() is a coroutine_fn, you won't usually > hold the lock outside of coroutine context anyway. But it's something to > be careful with when you have a writer lock. > Best Regards, Fiona
