[Qemu-devel] Re: [PATCH V4 2/3] qemu: Generic task offloading framework: threadlets

[Paolo Bonzini <pbonzini@redhat.com>]

>>> +        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.

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

>>> +/**
>>> + * 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);
>>> +    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.

I guess we decided flush isn't really useful at all.  Might as well 
leave it out of v5 and implement it later, so the barrier and 
complicated exit condition are now unnecessary.

Thanks,

Paolo