* Venkateswararao Jujjuri (JV) <jv...@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
