Revert "Task scheduler: Avoid mutex lock in number manipulation functions"
authorSergey Sharybin <sergey.vfx@gmail.com>
Tue, 10 May 2016 13:43:03 +0000 (15:43 +0200)
committerSergey Sharybin <sergey.vfx@gmail.com>
Tue, 10 May 2016 13:43:03 +0000 (15:43 +0200)
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

index a62ba734a3c3f1c1dc53eb696523e0996b3c2a5d..b47931cdde9043ed1e8d43390c4d1afdf311c4ea 100644 (file)
@@ -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)