On Thu, Dec 02, 2010 at 09:43:12AM +0800, Hu Tao wrote:
> On Wed, Dec 01, 2010 at 05:26:27PM +0000, Daniel P. Berrange wrote:
> > From: Hu Tao <hutao@xxxxxxxxxxxxxx>
> >
> > * src/util/threadpool.c, src/util/threadpool.h: Thread pool
> > implementation
> > * src/Makefile.am: Build thread pool
> > ---
> > src/Makefile.am | 1 +
> > src/util/threadpool.c | 178 +++++++++++++++++++++++++++++++++++++++++++++++++
> > src/util/threadpool.h | 23 ++++++
> > 3 files changed, 202 insertions(+), 0 deletions(-)
> > create mode 100644 src/util/threadpool.c
> > create mode 100644 src/util/threadpool.h
> > +static void virThreadPoolWorker(void *opaque)
> > +{
> > + virThreadPoolPtr pool = opaque;
> > +
> > + virMutexLock(&pool->mutex);
> > +
> > + while (1) {
> > + while (!pool->quit &&
> > + !pool->jobList) {
> > + pool->freeWorkers++;
> > + if (virCondWait(&pool->cond, &pool->mutex) < 0) {
> > + pool->freeWorkers--;
> > + break;
> > + }
> > + pool->freeWorkers--;
> > + }
> > +
> > + if (pool->quit)
> > + break;
> > +
> > + virThreadPoolJobPtr job = pool->jobList;
> > + pool->jobList = pool->jobList->next;
> > + job->next = NULL;
> > +
> > + virMutexUnlock(&pool->mutex);
> > + (pool->jobFunc)(job->data, pool->jobOpaque);
>
> This could race if jobFunc does something with jobOpaque unless jobFunc
> is aware of this and provides a lock to protect jobOpaque.
Yes, it is up to jobFunc to provide locking on jobOpaque if
it needs to do so for thread safety.
Regards,
Daniel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list