diff options
| author | Boris Kolpackov <boris@codesynthesis.com> | 2017-03-03 16:40:38 +0200 |
|---|---|---|
| committer | Boris Kolpackov <boris@codesynthesis.com> | 2017-03-03 16:40:38 +0200 |
| commit | e27a91c9e3fccf52d39afb23c6dbdff117adfd5f (patch) | |
| tree | 43b62ab1bed764bb838d01838a7b6b1c58ea75d7 | |
| parent | 139785df3aada78f8bccdda31e310733ca4d2420 (diff) | |
Refrain from working own queue when trying to lock target
This can easily lead to deadlock.
| -rw-r--r-- | build2/algorithm.cxx | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/build2/algorithm.cxx b/build2/algorithm.cxx index e44d610..51877b3 100644 --- a/build2/algorithm.cxx +++ b/build2/algorithm.cxx @@ -502,11 +502,18 @@ namespace build2 // to continue as soon as the lock is available in order not to nest // things unnecessarily. // + // That's what we used to do but that proved to be too deadlock-prone. For + // example, we may end up popping the last task which needs a lock that we + // are already holding. A fuzzy feeling is that we need to look for tasks + // (compare their task_counts?) that we can safely work on (though we will + // need to watch out for indirections). So perhaps it's just better to keep + // it simple and create a few extra threads. + // target_lock l ( lock_impl (a, ct, task_count == nullptr - ? optional<scheduler::work_queue> (scheduler::work_one) + ? optional<scheduler::work_queue> (scheduler::work_none) : nullopt)); if (l.target == nullptr) |