On 21/04/21 10:53, Vladimir Sementsov-Ogievskiy wrote:
Good point. Emanuele, can you work on ProgressMeter and
SharedResource? AioTaskPool can also be converted to just use CoQueue
instead of manually waking up coroutines.
That would be great.
I have one more question in mind:
Is it effective to use CoMutex here? We are protecting only some fast
manipulations with data, not io path or something like that. Will simple
QemuMutex work better? Even if CoMutex doesn't have any overhead, I
don't think than if thread A wants to modify task list, but mutex is
held by thread B (for similar thing), there is a reason for thread A to
yield and do some other things: it can just wait several moments on
mutex while B is modifying task list..
Indeed even CoQueue primitives count as simple manipulation of data,
because they unlock/lock the mutex while the coroutine sleeps. So
you're right that it would be okay to use QemuMutex as well
The block copy code that Emanuele has touched so far is all coroutine
based. I like using CoMutex when that is the case, because it says
implicitly "the monitor is not involved". But we need to see what it
will be like when the patches are complete.
Rate limiting ends up being called by the monitor, but it will have its
own QemuMutex so it's fine. What's left is cancellation and
block_copy_kick; I think that we can make qemu_co_sleep thread-safe with
an API similar to Linux's prepare_to_wait, so a QemuMutex wouldn't be
needed there either.
Paolo
