From 335274192e3d6c78e58ad2123dbdb7a384f3988b Mon Sep 17 00:00:00 2001 From: Sergey Sharybin Date: Tue, 10 May 2016 15:43:03 +0200 Subject: [PATCH] Revert "Task scheduler: Avoid mutex lock in number manipulation functions" Appears mutex was guarateeing number of tasks is not modified at moments when it's not expected. Removing those mutexes resulted in some hard-to-catch locks where worker thread were waiting for work by all the tasks were already done. This reverts commit a1d8fe052ccd8945f14be5a50bd5af581b89c643. --- source/blender/blenlib/intern/task.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/source/blender/blenlib/intern/task.c b/source/blender/blenlib/intern/task.c index a62ba734a3c..b47931cdde9 100644 --- a/source/blender/blenlib/intern/task.c +++ b/source/blender/blenlib/intern/task.c @@ -230,21 +230,28 @@ static void task_free(TaskPool *pool, Task *task, const int thread_id) static void task_pool_num_decrease(TaskPool *pool, size_t done) { + BLI_mutex_lock(&pool->num_mutex); + BLI_assert(pool->num >= done); - atomic_sub_z((size_t*)&pool->num, done); + pool->num -= done; atomic_sub_z(&pool->currently_running_tasks, done); - atomic_add_z((size_t*)&pool->done, done); + pool->done += done; - if (pool->num == 0) { + if (pool->num == 0) BLI_condition_notify_all(&pool->num_cond); - } + + BLI_mutex_unlock(&pool->num_mutex); } static void task_pool_num_increase(TaskPool *pool) { - atomic_add_z((size_t*)&pool->num, 1); + BLI_mutex_lock(&pool->num_mutex); + + pool->num++; BLI_condition_notify_all(&pool->num_cond); + + BLI_mutex_unlock(&pool->num_mutex); } static bool task_scheduler_thread_wait_pop(TaskScheduler *scheduler, Task **task)