Fix T76553: Blender Freezes When Playing Back Animation

In some cases blender could freeze. When threads are blocked (waiting for other tasks completion) the scheduler can let the thread perform a different task. If this task wants a write-lock for something that was read-locked in the stack a dead lock will happen.

For task pools every task is isolated. For range tasks the inner loop will be isolated. The implementation is limited as isolation in TBB uses functors which are tricky to add to a C API. We decided to start with a simple and adapt were we need to.

During testing we came to this setup as it was reliable (we weren't able to let it freeze or crash) and didn't had noticeable performance impact.

Reviewed By: Brecht van Lommel

Differential Revision: https://developer.blender.org/D7688
This commit is contained in:
Jeroen Bakker 2020-05-11 10:16:29 +02:00
parent 36d9f7e375
commit 08ac4d3d71
Notes: blender-bot 2023-02-14 10:21:11 +01:00
Referenced by issue #88598, Task isolation in task pool causes deadlock.
Referenced by issue #76553, Dragging in the timeline causes Blender to freeze
3 changed files with 16 additions and 7 deletions

View File

@ -114,7 +114,7 @@ class Task {
/* Execute task. */
void operator()() const
{
run(pool, taskdata);
tbb::this_task_arena::isolate([this] { run(pool, taskdata); });
}
};

View File

@ -89,11 +89,13 @@ struct RangeTask {
void operator()(const tbb::blocked_range<int> &r) const
{
TaskParallelTLS tls;
tls.userdata_chunk = userdata_chunk;
for (int i = r.begin(); i != r.end(); ++i) {
func(userdata, i, &tls);
}
tbb::this_task_arena::isolate([this, r] {
TaskParallelTLS tls;
tls.userdata_chunk = userdata_chunk;
for (int i = r.begin(); i != r.end(); ++i) {
func(userdata, i, &tls);
}
});
}
void join(const RangeTask &other)

View File

@ -25,6 +25,7 @@
#include "BLI_utildefines.h"
#include "BLI_math_base.h"
#include "BLI_threads.h"
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
@ -177,7 +178,11 @@ static Mesh *modifyMesh(ModifierData *md, const ModifierEvalContext *UNUSED(ctx)
BLI_assert(false);
break;
}
/* TODO(jbakker): Dualcon crashes when run in parallel. Could be related to incorrect
* input data or that the library isn't thread safe. This was identified when changing the task
* isolations during T76553. */
static ThreadMutex dualcon_mutex = BLI_MUTEX_INITIALIZER;
BLI_mutex_lock(&dualcon_mutex);
output = dualcon(&input,
dualcon_alloc_output,
dualcon_add_vert,
@ -188,6 +193,8 @@ static Mesh *modifyMesh(ModifierData *md, const ModifierEvalContext *UNUSED(ctx)
rmd->hermite_num,
rmd->scale,
rmd->depth);
BLI_mutex_unlock(&dualcon_mutex);
result = output->mesh;
MEM_freeN(output);
}