From e27a91c9e3fccf52d39afb23c6dbdff117adfd5f Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Fri, 3 Mar 2017 16:40:38 +0200 Subject: Refrain from working own queue when trying to lock target This can easily lead to deadlock. --- build2/algorithm.cxx | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) 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_one) + ? optional (scheduler::work_none) : nullopt)); if (l.target == nullptr) -- cgit v1.1