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(a)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