From 42494bfb69443b4044390b6f6d43512cb130226d Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Sun, 28 Apr 2024 18:59:57 +0530 Subject: [PATCH] Add a comment about task execution. --- include/deal.II/base/thread_management.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/include/deal.II/base/thread_management.h b/include/deal.II/base/thread_management.h index ced549d103..da68b4520a 100644 --- a/include/deal.II/base/thread_management.h +++ b/include/deal.II/base/thread_management.h @@ -948,6 +948,25 @@ namespace Threads // tbb::task_group, and then here wait for the single task // associated with that task group. // + // This also makes sense from another perspective. Imagine that + // we allow at most N threads, and that we create N+1 tasks in such + // a way that the first N all wait for the (N+1)st task to finish. + // (See the multithreading/task_17 test for an example.) If they + // all just sit in their std::future::wait() function, nothing + // is ever going to happen because the scheduler sees that N tasks + // are currently running and is never informed that all they're + // doing is wait for another task to finish. What *needs* to + // happen is that the wait() or join() function goes back into + // the scheduler to make sure the scheduler knows that these + // tasks are not actually using CPU time on the thread they're + // working on, and that it is time to run other tasks on the + // same thread -- this is the way we can eventually get that + // (N+1)st task executed, which then unblocks the other N threads. + // (Note that this also implies that multiple tasks can be + // executing on the same thread at the same time -- not + // concurrently, of course, but with one executing and the others + // currently waiting for other tasks to finish.) + // // If we get here, we know for a fact that atomically // (because under a lock), no other thread has so far // determined that we are finished and removed the -- 2.39.5