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

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com> [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