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@cn.fujitsu.com>
* 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