All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Arun R Bharadwaj <arun@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets
Date: Fri, 15 Oct 2010 07:56:24 -0700	[thread overview]
Message-ID: <4CB86B98.9070007@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTimYnqEJ0ryB-NYH=X5nRSm9bhB3sf2_MwL4TX3=@mail.gmail.com>

On 10/15/2010 2:52 AM, Stefan Hajnoczi wrote:
> On Thu, Oct 14, 2010 at 10:17 PM, Venkateswararao Jujjuri (JV)
> <jvrao@linux.vnet.ibm.com> wrote:
>> On 10/14/2010 2:02 AM, Stefan Hajnoczi wrote:
>>> On Wed, Oct 13, 2010 at 4:31 PM, Arun R Bharadwaj
>>>> +static void *threadlet_worker(void *data)
>>>> +{
>>>> +    ThreadletQueue *queue = data;
>>>> +
>>>> +    qemu_mutex_lock(&(queue->lock));
>>>> +    while (1) {
>>>> +        ThreadletWork *work;
>>>> +        int ret = 0;
>>>> +
>>>> +        while (QTAILQ_EMPTY(&(queue->request_list)) &&
>>>> +               (ret != ETIMEDOUT)) {
>>>> +            ret = qemu_cond_timedwait(&(queue->cond),
>>>> +                                        &(queue->lock), 10*100000);
>>>> +        }
>>>> +
>>>> +        assert(queue->idle_threads != 0);
>>>> +        if (QTAILQ_EMPTY(&(queue->request_list))) {
>>>> +            if (queue->cur_threads > queue->min_threads) {
>>>> +                /* We retain the minimum number of threads */
>>>> +                break;
>>>> +            }
>>>> +        } else {
>>>> +            work = QTAILQ_FIRST(&(queue->request_list));
>>>> +            QTAILQ_REMOVE(&(queue->request_list), work, node);
>>>> +
>>>> +            queue->idle_threads--;
>>>> +            qemu_mutex_unlock(&(queue->lock));
>>>> +
>>>> +            /* execute the work function */
>>>> +            work->func(work);
>>>> +
>>>> +            qemu_mutex_lock(&(queue->lock));
>>>> +            queue->idle_threads++;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    queue->idle_threads--;
>>>> +    queue->cur_threads--;
>>>> +    qemu_mutex_unlock(&(queue->lock));
>>>> +
>>>> +    return NULL;
>>>> +}
>>>> +
>>>> +static void spawn_threadlet(ThreadletQueue *queue)
>>>> +{
>>>> +    QemuThread thread;
>>>> +
>>>> +    queue->cur_threads++;
>>>> +    queue->idle_threads++;
>>>> +
>>>> +    qemu_thread_create(&thread, threadlet_worker, queue);
>>>> +}
>>>> +
>>>> +/**
>>>> + * submit_threadletwork_to_queue: Submit a new task to a private queue to be
>>>> + *                            executed asynchronously.
>>>> + * @queue: Per-subsystem private queue to which the new task needs
>>>> + *         to be submitted.
>>>> + * @work: Contains information about the task that needs to be submitted.
>>>> + */
>>>> +void submit_threadletwork_to_queue(ThreadletQueue *queue, ThreadletWork *work)
>>>> +{
>>>> +    qemu_mutex_lock(&(queue->lock));
>>>> +    if (queue->idle_threads == 0 && queue->cur_threads < queue->max_threads) {
>>>> +        spawn_threadlet(queue);
>>>> +    }
>>>> +    QTAILQ_INSERT_TAIL(&(queue->request_list), work, node);
>>>> +    qemu_mutex_unlock(&(queue->lock));
>>>> +    qemu_cond_signal(&(queue->cond));
>>>
>>> Worker thread signalling and spawning has race conditions.  See my
>>> previous email:
>>>
>>> "There are race conditions here:
>>>
>>> 1. When a new threadlet is started because there are no idle threads,
>>> qemu_cond_signal() may fire a blank because the threadlet isn't inside
>>> qemu_cond_timedwait() yet.  The result, the work item is deadlocked
>>> until another thread grabs more work off the queue.  If I'm reading
>>> the code correctly this bug is currently present!
>>
>> Moving QTAILQ_INSERT_TAIL() ahead of spawn_threadlet() should take care of this
>> issue
>> right?
> 
> I didn't read the code correctly.  queue->lock is already held by
> submit_threadletwork_to_queue() until after QTAILQ_INSERT_TAIL().
> threadlet_worker() will only enter its main loop once it acquires
> queue->lock.  Therefore the queue definitely has the work before the
> spawned thread begins processing.
> 
> The work is on the queue when threadlet_worker() enters its main loop,
> so it will not need to wait on queue->cond but can process work
> immediately.  There is no spawn race condition.

Correct...I too missed that. :)

JV

> 
> Stefan

  reply	other threads:[~2010-10-15 14:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-13 15:30 [Qemu-devel] v5 [PATCH 0/3] qemu: Threadlets: A generic task offloading framework Arun R Bharadwaj
2010-10-13 15:31 ` [Qemu-devel] [PATCH 1/3] Introduce threadlets Arun R Bharadwaj
2010-10-14  9:02   ` Stefan Hajnoczi
2010-10-14 21:17     ` Venkateswararao Jujjuri (JV)
2010-10-15  9:52       ` Stefan Hajnoczi
2010-10-15 14:56         ` Venkateswararao Jujjuri (JV) [this message]
2010-10-15 14:42     ` [Qemu-devel] " Paolo Bonzini
2010-10-14  9:15   ` [Qemu-devel] " Stefan Hajnoczi
2010-10-14  9:19     ` Gleb Natapov
2010-10-14 16:16     ` Avi Kivity
2010-10-14 21:32       ` Venkateswararao Jujjuri (JV)
2010-10-17  8:57         ` Avi Kivity
2010-10-18 10:47           ` Arun R Bharadwaj
2010-10-18 12:29             ` Avi Kivity
2010-10-15  8:05       ` Stefan Hajnoczi
2010-10-13 15:31 ` [Qemu-devel] [PATCH 2/3] Make paio subsystem use threadlets Arun R Bharadwaj
2010-10-13 15:31 ` [Qemu-devel] [PATCH 3/3] Add helper functions for virtio-9p to " Arun R Bharadwaj
  -- strict thread matches above, loose matches on Subject: below --
2010-10-13 16:44 [Qemu-devel] [PATCH 0/3]: Threadlets: A generic task offloading framework Arun R Bharadwaj
2010-10-13 16:47 ` [Qemu-devel] [PATCH 1/3]: Introduce threadlets Arun R Bharadwaj
2010-10-19 17:42 [Qemu-devel] v6: [PATCH 0/3]: Threadlets: A generic task offloading framework Arun R Bharadwaj
2010-10-19 17:42 ` [Qemu-devel] [PATCH 1/3] Introduce threadlets Arun R Bharadwaj
2010-10-19 18:36   ` Balbir Singh
2010-10-19 21:00     ` Venkateswararao Jujjuri (JV)
2010-10-20  2:26       ` Balbir Singh
2010-10-19 21:36     ` Anthony Liguori
2010-10-20  2:22       ` Balbir Singh
2010-10-20  3:46         ` Venkateswararao Jujjuri (JV)
2010-10-20 13:05           ` Balbir Singh
2010-10-20 13:13         ` Anthony Liguori
2010-10-20  3:19       ` Venkateswararao Jujjuri (JV)
2010-10-20  8:16   ` Stefan Hajnoczi
2010-10-21 12:10 [Qemu-devel] [PATCH 0/3]: v7: Threadlets: A generic task offloading framework Arun R Bharadwaj
2010-10-21 12:10 ` [Qemu-devel] [PATCH 1/3] Introduce threadlets Arun R Bharadwaj
2010-10-22  7:02   ` Balbir Singh
2010-10-26 14:14 [Qemu-devel] v8: [PATCH 0/3] Threadlets: A generic task offloading framework Arun R Bharadwaj
2010-10-26 14:14 ` [Qemu-devel] [PATCH 1/3] Introduce threadlets Arun R Bharadwaj
2010-10-26 19:31   ` Blue Swirl
2010-11-01 13:40   ` Anthony Liguori
2010-11-05  6:48     ` Arun R Bharadwaj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CB86B98.9070007@linux.vnet.ibm.com \
    --to=jvrao@linux.vnet.ibm.com \
    --cc=arun@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.