Re: [Qemu-devel] [PATCH 1/2] coroutine: introduce coroutines

[Jamie Lokier <jamie@shareable.org>]

Stefan Hajnoczi wrote:
> On Thu, May 12, 2011 at 10:51 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > On 2011-05-11 12:15, Stefan Hajnoczi wrote:
> >> From: Kevin Wolf <kwolf@redhat.com>
> >>
> >> Asynchronous code is becoming very complex.  At the same time
> >> synchronous code is growing because it is convenient to write.
> >> Sometimes duplicate code paths are even added, one synchronous and the
> >> other asynchronous.  This patch introduces coroutines which allow code
> >> that looks synchronous but is asynchronous under the covers.
> >>
> >> A coroutine has its own stack and is therefore able to preserve state
> >> across blocking operations, which traditionally require callback
> >> functions and manual marshalling of parameters.
> >>
> >> Creating and starting a coroutine is easy:
> >>
> >>   coroutine = qemu_coroutine_create(my_coroutine);
> >>   qemu_coroutine_enter(coroutine, my_data);
> >>
> >> The coroutine then executes until it returns or yields:
> >>
> >>   void coroutine_fn my_coroutine(void *opaque) {
> >>       MyData *my_data = opaque;
> >>
> >>       /* do some work */
> >>
> >>       qemu_coroutine_yield();
> >>
> >>       /* do some more work */
> >>   }
> >>
> >> Yielding switches control back to the caller of qemu_coroutine_enter().
> >> This is typically used to switch back to the main thread's event loop
> >> after issuing an asynchronous I/O request.  The request callback will
> >> then invoke qemu_coroutine_enter() once more to switch back to the
> >> coroutine.
> >>
> >> Note that coroutines never execute concurrently and should only be used
> >> from threads which hold the global mutex.  This restriction makes
> >> programming with coroutines easier than with threads.  Race conditions
> >> cannot occur since only one coroutine may be active at any time.  Other
> >> coroutines can only run across yield.
> >
> > Mmh, is there anything that conceptually prevent fixing this limitation
> > later on? I would really like to remove such dependency long-term as
> > well to have VCPUs operate truly independently on independent device models.
> 
> The use case that has motivated coroutines is the block layer.  It is
> synchronous in many places and definitely not thread-safe.  Coroutines
> is a step that solves the "synchronous" part of the problem but does
> not tackle the "not thread-safe" part.
> 
> It is possible to move from coroutines to threads but we need to
> remove single-thread assumptions from all the block layer code, which
> isn't a small task.  Coroutines does not prevent us from making the
> block layer thread-safe!

Keeping in mind that you may have to do some of the work even with
coroutines.  If the code is not thread safe, it may contain
assumptions that certain state does not change when it makes blocking
I/O calls, which stops being true once you have coroutines and replace
the I/O calls with async calls.  But at least the checking can be
confined to those places in the code.

It's quite similar to the Linux BKL - scheduling points have to be
checked but nowhere else does.  And, like the BKL, it could be "pushed
down" in stages over a long time period, to convert the coroutine code
over to concurrent threads over time, rather than in a single step.

By the end, even with full concurrency, there is still some potential
for coroutines, and/or async calls, to be useful for performance
balancing.

-- Jamie