Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets

[Balbir Singh]

* Venkateswararao Jujjuri (JV) <address@hidden> [2010-10-19 14:00:24]:

> > 
> > In the case that we just spawned the threadlet, the cond_signal is
> > spurious. If we need predictable scheduling behaviour,
> > qemu_cond_signal needs to happen with queue->lock held.
> > 
> > I'd rewrite the function as 
> > 
> > /**
> >  * 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);
> >     } else {
> >         qemu_cond_signal(&(queue->cond));
> >     }
> >     QTAILQ_INSERT_TAIL(&(queue->request_list), work, node);
> >     qemu_mutex_unlock(&(queue->lock));
> > }
> > 
> This looks fine to me. may be more cleaner than the previous one..but 
> functionally
> not much different.
>

It potentially does better at avoiding the spurious wakeup problem
(reduces the window). In another email I mentioned the man page says

"however, if predictable scheduling behavior is required, then that
mutex shall be locked by the thread calling pthread_cond_broadcast()
or pthread_cond_signal()"
 
-- 
        Three Cheers,
        Balbir