qemu: Threadlets: A generic task offloading framework

Signed-off-by Gautham R Shenoy<[email protected]>

---
  qemu-thread.c |   23 +++++++++++++++++++++++
  qemu-thread.h |    9 +++++++++
  2 files changed, 32 insertions(+), 0 deletions(-)

qemu-thread.c +23 -0

index 3923db7..7c445b6 100644
@@ -161,3 +161,26 @@ int qemu_thread_equal(QemuThread *thread1, QemuThread *thread2)
     return pthread_equal(thread1->thread, thread2->thread);
  }
 
+void qemu_barrier_init(QemuBarrier *barr1, int nr_threads)
+{
+    int err;
+
+    err = pthread_barrier_init(&barr1->barr, NULL, nr_threads);
+
+    if (err) {
+        error_exit(err, __func__);
+    }
+}
+
+int qemu_barrier_wait(QemuBarrier *barr1)
+{
+    int ret;
+
+    ret = pthread_barrier_wait(&barr1->barr);
+
+    if (ret != 0&&  ret != PTHREAD_BARRIER_SERIAL_THREAD) {
+        error_exit(ret, __func__);
+    }
+
+    return ret;
+}

qemu-thread.h +9 -0

index 5ef4a3a..b3d36e0 100644
@@ -15,9 +15,14 @@ struct QemuThread {
      pthread_t thread;
  };
 
+struct QemuBarrier {
+    pthread_barrier_t barr;
+};
+
  typedef struct QemuMutex QemuMutex;
  typedef struct QemuCond QemuCond;
  typedef struct QemuThread QemuThread;
+typedef struct QemuBarrier QemuBarrier;
 
  void qemu_mutex_init(QemuMutex *mutex);
  void qemu_mutex_lock(QemuMutex *mutex);

@@ -31,10 +36,14 @@ void qemu_cond_broadcast(QemuCond *cond);
  void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex);
  int qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex, uint64_t msecs);
 
+void qemu_barrier_init(QemuBarrier *barr, int nr_threads);
+
  void qemu_thread_create(QemuThread *thread,
                         void *(*start_routine)(void*),
                         void *arg);
  void qemu_thread_signal(QemuThread *thread, int sig);
  void qemu_thread_self(QemuThread *thread);
  int qemu_thread_equal(QemuThread *thread1, QemuThread *thread2);
+
+int qemu_barrier_wait(QemuBarrier *barr);
  #endif

Quoted 1 line · Gautham R Shenoy

Signed-off-by Gautham R Shenoy<[email protected]>

I don't see barrier being used and I don't think it ought to be used. threadlets are meant provide a means to execute a synchronous function asynchronously. It should never be necessary to synchronize threadlets using a barrier.

+ * Generalization based on posix-aio emulation code.

These should be (at least for now) block-obj-$(CONFIG_POSIX).

async-work.c line 43

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+					&(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Quoted 12 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

async-work.c line 43

Quoted 6 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+					&(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

-- Jamie

Quoted 10 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

async-work.c line 43

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+					&(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Quoted 9 lines · Jamie Lokier

Quoted 8 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+        }

Quoted 5 lines

Quoted 2 lines

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Unnecessary idle threads are immediately expired as soon as the threadlet exits if ncecessary, since here

async-work.c new file +6 -0

+        queue->idle_threads++;
+
+check_exit:
+        if (queue->exit || ((queue->idle_threads > 0) &&
+            (queue->cur_threads > queue->min_threads))) {
+            /* We exit the queue or we retain minimum number of 

threads */

(quoted diff) +2 -0

+            break;
+        }

queue->idle_threads > 0 will always be true (so maybe that should be changed into an assertion: "this thread is idle, so there must be idle threads").

The min/max_threads parameters of the queue are currently immutable, so it can never happen that a thread has to be expired while it's waiting. It may well become true in the future, in which case the condvar will have to be broadcast when min_threads changes.

I may well be wrong of course. :)

Paolo

Quoted 16 lines · Paolo Bonzini

Quoted 14 lines · Jamie Lokier

Quoted 10 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

Quoted 5 lines

+ while (QTAILQ_EMPTY(&(queue->request_list))&&
+ (ret != ETIMEDOUT)) {
+ ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+ }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Quoted 2 lines

Unnecessary idle threads are immediately expired as soon as the threadlet exits if ncecessary, since here

If a threadlet is waiting to consume more work, unless we do a pthread_cancel (I dislike cancellation) it will keep waiting until it gets more work (which would mean it's not actually idle)...

Quoted 9 lines

+ queue->idle_threads++;

async-work.c new file +7 -0

+
+check_exit:
+ if (queue->exit || ((queue->idle_threads > 0) &&
+ (queue->cur_threads > queue->min_threads))) {
+ /* We exit the queue or we retain minimum number of threads */
+ break;
+ }

Quoted 3 lines

queue->idle_threads > 0 will always be true (so maybe that should be changed into an assertion: "this thread is idle, so there must be idle threads").

queue->exit could be true though so it's necessary to at least check that condition.

Quoted 20 lines · Anthony Liguori

Quoted 18 lines · Paolo Bonzini

Quoted 9 lines · Jamie Lokier

Quoted 8 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

Quoted 5 lines

+ while (QTAILQ_EMPTY(&(queue->request_list))&&
+ (ret != ETIMEDOUT)) {
+ ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+ }

Quoted 5 lines

Quoted 2 lines

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Unnecessary idle threads are immediately expired as soon as the threadlet exits if ncecessary, since here

Quoted 3 lines

If a threadlet is waiting to consume more work, unless we do a pthread_cancel (I dislike cancellation) it will keep waiting until it gets more work (which would mean it's not actually idle)...

Agreed---no cancellation, please.

BTW it's obviously okay with signaling the condition when a threadlet is submitted. But when something affects all queue's workers (flush_threadlet_queue) you want a broadcast and using expiration as a substitute is fishy.

Quoted 9 lines

Quoted 9 lines

+ queue->idle_threads++;

async-work.c new file +7 -0

+
+check_exit:
+ if (queue->exit || ((queue->idle_threads > 0) &&
+ (queue->cur_threads > queue->min_threads))) {
+ /* We exit the queue or we retain minimum number of threads */
+ break;
+ }

Quoted 6 lines

Quoted 3 lines

queue->idle_threads > 0 will always be true (so maybe that should be changed into an assertion: "this thread is idle, so there must be idle threads").

queue->exit could be true though so it's necessary to at least check that condition.

Yes, of course. The correct test should be:

  if (queue->exit || queue->cur_threads > queue->min_threads)

But queue->idle_threads will be > 0 even if coming via the goto (which should be eliminated).

Or maybe no. After flushing you still want min_threads threads to run. The correct thing then would be:

    do {
        ...
        assert (queue->idle_threads > 0);
        if (queue->exit) {
            /* Threads waiting on the barrier cannot do work.  */
            queue->idle_threads--;
            qemu_mutex_unlock(&(queue->lock));
            qemu_barrier_wait(&queue->barr);
            qemu_mutex_lock(&(queue->lock));
            queue->idle_threads++;
        }
    } while (queue->cur_threads <= queue->min_threads);

    queue->idle_threads--;
    queue->cur_threads--;
    qemu_mutex_unlock(&queue->lock);
    return NULL;

So, if min_threads were changed, broadcasting the condition would be enough to exit unwanted threads one at a time, as soon as it grabs the lock.

Paolo

Quoted 32 lines · Paolo Bonzini

Quoted 21 lines · Anthony Liguori

Quoted 19 lines · Paolo Bonzini

Quoted 16 lines · Jamie Lokier

Quoted 11 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

Quoted 5 lines

+ while (QTAILQ_EMPTY(&(queue->request_list))&&
+ (ret != ETIMEDOUT)) {
+ ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+ }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Quoted 6 lines

Quoted 2 lines

Unnecessary idle threads are immediately expired as soon as the threadlet exits if ncecessary, since here

If a threadlet is waiting to consume more work, unless we do a pthread_cancel (I dislike cancellation) it will keep waiting until it gets more work (which would mean it's not actually idle)...

Agreed---no cancellation, please.

Quoted 4 lines

BTW it's obviously okay with signaling the condition when a threadlet is submitted.  But when something affects all queue's workers (flush_threadlet_queue) you want a broadcast and using expiration as a substitute is fishy.

IMHO, there shouldn't be a need for flush_threadlet_queue.  It doesn't look used in the aio conversion and if virtio-9p needs it, I suspect something is wrong.

I would need something like flush_threadlet_queue for the vnc server. I need it in
vnc_disconnect(), vnc_dpy_resize() and vnc_dpy_cpy() so wait (and/or abort) current
encoding jobs.

Quoted 7 lines · Corentin Chary

I would need something like flush_threadlet_queue for the vnc server. I need it in
vnc_disconnect(), vnc_dpy_resize() and vnc_dpy_cpy() so wait (and/or abort) current
encoding jobs.

I'm not sure threadlets are the right thing for the VNC server.  The VNC server wants one dedicated thread.  Threadlets are a thread pool.  You could potentially use one thread per client but I doubt it would be worth it.

At any rate, flushing the full queue is overkill.  You want to wait for your specific thread to terminate and you want to block execution until that happens.  IOW, you want to join the thread.

Quoted 13 lines · Anthony Liguori

Quoted 7 lines · Corentin Chary

I would need something like flush_threadlet_queue for the vnc server. I need it in
vnc_disconnect(), vnc_dpy_resize() and vnc_dpy_cpy() so wait (and/or abort) current
encoding jobs.

I'm not sure threadlets are the right thing for the VNC server.  The VNC server wants one dedicated thread.  Threadlets are a thread pool.  You could potentially use one thread per client but I doubt it would be worth it.

Quoted 4 lines

At any rate, flushing the full queue is overkill.  You want to wait for your specific thread to terminate and you want to block execution until that happens.  IOW, you want to join the thread.

Oh right, I should have read the changelog more carefully, it's a global queue now ...

Thanks,

Signature · 2 lines

Corentin Chary
http://xf.iksaif.net

Quoted 4 lines · Paolo Bonzini

BTW it's obviously okay with signaling the condition when a threadlet is submitted. But when something affects all queue's workers (flush_threadlet_queue) you want a broadcast and using expiration as a substitute is fishy.

IMHO, there shouldn't be a need for flush_threadlet_queue. It doesn't look used in the aio conversion and if virtio-9p needs it, I suspect something is wrong.

Regards,

Anthony Liguori

Quoted 16 lines · Paolo Bonzini

Quoted 14 lines · Jamie Lokier

Quoted 10 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

async-work.c line 43

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Quoted 2 lines

Unnecessary idle threads are immediately expired as soon as the threadlet exits if ncecessary, since here

If a threadlet is waiting to consume more work, unless we do a pthread_cancel (I dislike cancellation) it will keep waiting until it gets more work (which would mean it's not actually idle)...

Quoted 4 lines

The min/max_threads parameters of the queue are currently immutable, so it can never happen that a thread has to be expired while it's waiting. It may well become true in the future, in which case the condvar will have to be broadcast when min_threads changes.

Quoted 17 lines · Anthony Liguori

Quoted 16 lines · Paolo Bonzini

Quoted 14 lines · Jamie Lokier

Quoted 10 lines · Paolo Bonzini

These should be (at least for now) block-obj-$(CONFIG_POSIX).

async-work.c line 43

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Are you sure? It looks like it also expires idle threads after a fixed amount of idle time.

Quoted 6 lines

Quoted 2 lines

Unnecessary idle threads are immediately expired as soon as the threadlet exits if ncecessary, since here

If a threadlet is waiting to consume more work, unless we do a pthread_cancel (I dislike cancellation) it will keep waiting until it gets more work (which would mean it's not actually idle)...

There's some mild abuse of the mutex/condvar going on.

As (queue->exit || queue->idle_threads > queue->min_threads) is a condition for breaking out of the loop, that condition ought to be checked in the mutex->cond_wait region, but it isn't.

It doesn't matter here because the queue is empty when queue->exit, and the idle > min_threads condition can't become true.

Putting the whole condition inside the mutex->cond_wait region, not just empty queue test, will remove the need for timed wait.

Broadcast
is still needed, or alternatively a cond_signal from each exiting thread will allow them to wake and close without a thundering herd.

Makefile.objs qobject-obj-y += qerror.o · line 13

Quoted 2 lines

Makefile.objs +2 -0

+block-obj-y += qemu-thread.o
+block-obj-y += async-work.o

These should be (at least for now) block-obj-$(CONFIG_POSIX).

async-work.c line 43

Quoted 6 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+					&(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

async-work.c line 46

Quoted 3 lines

async-work.c new file +2 -0

+        if (QTAILQ_EMPTY(&(queue->request_list)))
+            goto check_exit;

What's the reason for the goto? {...} works just as well.

Quoted 11 lines

async-work.c new file +10 -0

+/**
+ * flush_threadlet_queue: Wait till completion of all the submitted tasks
+ * @queue: Queue containing the tasks we're waiting on.
+ */
+void flush_threadlet_queue(ThreadletQueue *queue)
+{
+    qemu_mutex_lock(&queue->lock);
+    queue->exit = 1;
+
+    qemu_barrier_init(&queue->barr, queue->cur_threads + 1);

async-work.c line 133

Quoted 3 lines

async-work.c new file +3 -0

+    qemu_mutex_unlock(&queue->lock);
+
+    qemu_barrier_wait(&queue->barr);

Can be implemented just as well with queue->cond and a loop waiting for queue->cur_threads == 0. This would remove the need to implement barriers in qemu-threads (especially for Win32). Anyway whoever will contribute Win32 qemu-threads can do it, since it's not hard.

async-work.c line 186

Quoted 5 lines

async-work.c new file +4 -0

+int cancel_threadlet_common(ThreadletWork *work)
+{
+    return cancel_threadlet(&globalqueue, work);
+}

I would prefer *_threadlet to be the globalqueue function (and flush_threadlets) and queue_*_threadlet to be the special-queue function. I should have spoken earlier probably, but please consider this if there will be a v5.

Quoted 2 lines

+ * Generalization based on posix-aio emulation code.

No need to specify these as long as the original authors are attributed properly.

Quoted 4 lines

async-work.h new file +3 -0

+static inline void threadlet_queue_init(ThreadletQueue *queue,
+				    int max_threads, int min_threads)
+{

async-work.h line 56

Quoted 10 lines

async-work.h new file +10 -0

+    queue->cur_threads  = 0;
+    queue->idle_threads = 0;
+    queue->exit = 0;
+    queue->max_threads  = max_threads;
+    queue->min_threads  = min_threads;
+    QTAILQ_INIT(&(queue->request_list));
+    QTAILQ_INIT(&(queue->threadlet_work_pool));
+    qemu_mutex_init(&(queue->lock));
+    qemu_cond_init(&(queue->cond));
+}

No need to make this inline.

async-work.h line 68

Quoted 12 lines

async-work.h new file +11 -0

+extern void threadlet_submit(ThreadletQueue *queue,
+				  ThreadletWork *work);
+
+extern void threadlet_submit_common(ThreadletWork *work);
+
+extern int cancel_threadlet(ThreadletQueue *queue, ThreadletWork *work);
+extern int cancel_threadlet_common(ThreadletWork *work);
+
+
+extern void flush_threadlet_queue(ThreadletQueue *queue);
+extern void flush_common_threadlet_queue(void);

Please make the position of the verb consistent (e.g. "submit_threadlet").

Paolo

Quoted 8 lines

async-work.c line 43

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+					&(queue->lock), 10*100000);
+        }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

I think Anthony answered this one.

Quoted 10 lines

Quoted 10 lines

async-work.c new file +10 -0

+/**
+ * flush_threadlet_queue: Wait till completion of all the submitted tasks
+ * @queue: Queue containing the tasks we're waiting on.
+ */
+void flush_threadlet_queue(ThreadletQueue *queue)
+{
+    qemu_mutex_lock(&queue->lock);
+    queue->exit = 1;
+
+    qemu_barrier_init(&queue->barr, queue->cur_threads + 1);

Quoted 8 lines

async-work.c line 133

Quoted 3 lines

async-work.c new file +3 -0

+    qemu_mutex_unlock(&queue->lock);
+
+    qemu_barrier_wait(&queue->barr);

Can be implemented just as well with queue->cond and a loop waiting for queue->cur_threads == 0. This would remove the need to implement barriers in qemu-threads (especially for Win32). Anyway whoever will contribute Win32 qemu-threads can do it, since it's not hard.

That was the other option I had considered before going for barriers, for no particular reason. Now, considering that barriers are not welcome, I will implement this method.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

async-work.c new file +5 -0

+        while (QTAILQ_EMPTY(&(queue->request_list))&&
+               (ret != ETIMEDOUT)) {
+            ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+        }

Quoted 4 lines

Quoted 2 lines

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

I think Anthony answered this one.

I think he said that the code has been changed so I am right? :)

Quoted 9 lines · Paolo Bonzini

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

+ while (QTAILQ_EMPTY(&(queue->request_list))&&
+ (ret != ETIMEDOUT)) {
+ ret = qemu_cond_timedwait(&(queue->cond),
+ &(queue->lock), 10*100000);
+ }

Using qemu_cond_timedwait is a hack for not properly broadcasting the condvar in flush_threadlet_queue.

Quoted 3 lines

Quoted 1 line

I think Anthony answered this one.

I think he said that the code has been changed so I am right? :)

You're right about the condition we check in the exit path but the timedwait is needed to expire an idle thread.

Hi,

This is the v4 of the patch-series to have a generic asynchronous task offloading framework (called threadlets) within qemu.

V3 can be found here:
http://lists.gnu.org/archive/html/qemu-devel/2010-06/index.html

Changes from V3:
=====================================================================
- Did away with the qemu-thread wrappers for handling pthread_attr_t type following review comments for V3.

- Added qemu-thread wrappers for pthread_barrier_init() and pthread_barrier_wait().

- Added a flush_threadlet_queue() helper which allows the caller to wait till all the queued tasks have finished processing.

- Added a global queue that can be used by most subsystems to offload tasks. The flexibility to allow individual subsystems to create their private queue with associated thread-pool has been retained.

- Fixed the Copyrights in the newly introduced file to reflect the copyrights of the borrowed code.

- Renamed the helper functions to reflect their use. Added comments for each of the helpers.

- Typedef'd the structs to adhere to the qemu coding style.

Description
=====================================================================
This patch series decouples the asynchronous threading framework implementation from posix-aio-compat.c to implement a generic asynchronous task offloading threading framework called threadlets which can be used by other subsystems within QEMU.

Currently within QEMU, the AIO subsystem (paio) creates a bunch of asynchronous threads to offload any blocking operations so that the vcpu threads and the IO thread can go back to servicing any other guest requests.

This offloading framework can be used by subsystems such as virtio-9p, Asynchronous encoding for vnc-server, so that the vcpu thread can offload blocking operations on to the asynchronous threads and resume servicing any other guest requests. The asynchronous threads, after finishing the blocking operations can then transfer the control over to the IO thread so that the latter can handle the post_blocking_operation().

The patch series passed fsstress test without any issues.

Could it be considered for inclusion ?

---

Aneesh Kumar K.V (1):
qemu: Generic task offloading framework: threadlets

Gautham R Shenoy (2):
qemu: Add qemu-barrier support to qemu-thread framework.
qemu: Convert AIO code to use threadlets.

  Makefile.objs      |    3 +
  async-work.c       |  186 ++++++++++++++++++++++++++++++++++++++++++++++++++++
  async-work.h       |   69 +++++++++++++++++++
  posix-aio-compat.c |  152 +++++++-----------------------------------
  qemu-thread.c      |   23 ++++++
  qemu-thread.h      |    9 +++
  6 files changed, 313 insertions(+), 129 deletions(-)

create mode 100644 async-work.c
create mode 100644 async-work.h

Quoted 4 lines · Gautham R Shenoy

Hi,

This is the v4 of the patch-series to have a generic asynchronous task offloading framework (called threadlets) within qemu.

Semantically, a threadlet is identical to a QEMUBH except that a QEMUBH holds the qemu_mutex and a threadlet doesn't.

I'd suggest naming these functions similar to QEMUBH to the point where it makes sense to use the same structure. Instead of the normal qemu_bh_schedule, I'd suggest having a qemu_bh_schedule_unlocked().

Also, please introduce a short document in docs/ that gives a brief overview of how to use unlocked bottom halves especially focusing on the considerations with respect to what should and shouldn't be done in these functions.