BLI_task: fix case were some pool could work in more threads than allowed.

We were checking for number of tasks from given pool already active, and
then atomically increasing it if allowed - this is not correct, number
could be increased by another thread between check and atomic op!

Atomic primitives are nice, but you must be very careful with *how* you
use them... Now we atomically increase counter, check result, and if we
end up over max value, abort and decrease counter again.

Spotted by Sergey, thanks!

1 files changed, 5 insertions, 3 deletions

diff --git a/source/blender/blenlib/intern/task.c b/source/blender/blenlib/intern/task.c
index 9d4d40e1eae..436cd2b8fde 100644
--- a/source/blender/blenlib/intern/task.c
+++ b/source/blender/blenlib/intern/task.c
@@ -292,15 +292,17 @@ static bool task_scheduler_thread_wait_pop(TaskScheduler *scheduler, Task **task
 				continue;
 			}
 
-			if (pool->num_threads == 0 ||
-			    pool->currently_running_tasks < pool->num_threads)
+			if (atomic_add_z(&pool->currently_running_tasks, 1) <= pool->num_threads ||
+			    pool->num_threads == 0)
 			{
 				*task = current_task;
 				found_task = true;
-				atomic_add_z(&pool->currently_running_tasks, 1);
 				BLI_remlink(&scheduler->queue, *task);
 				break;
 			}
+			else {
+				atomic_sub_z(&pool->currently_running_tasks, 1);
+			}
 		}
 		if (!found_task)
 			BLI_condition_wait(&scheduler->queue_cond, &scheduler->queue_mutex);