Branch: refs/heads/main
Revision: 2b2b916
Author: gbtitus
Log Message:
Merge pull request #18302 from gbtitus/rm-executeTasksInList
Reorganize and simplify the task creation interface.
(Reviewed by @ronawho and @mppf.)
We have long had two fundamental functions in the task initiation part
of the runtime tasking interface, chpl_task_addToTaskList() to create
a task and chpl_task_executeTasksInList() to help ensure that created
tasks actually get run. The latter was called in the parent when it was
waiting for child tasks of begin- and co-stmts to finish. Only the fifo
tasking layer implemented it non-vacuously. There, the thread hosting
the parent task of a parallel construct could be put to work hosting
that construct's child tasks (one after another), because the parent
task could not proceed until the construct was done anyway. This
allowed handling overload situations in which we had more tasks than
host threads to run them on, where otherwise we would have deadlocked
due to resource starvation because the threads in fifo tasking run tasks
to completion except for this parent-child wrinkle. The qthreads
tasking layer did not need this, because the qthreads that host Chapel
tasks are effectively unlimited in number and can be switched on their
worker pthreads at any yield point. (There is a limit on the number of
those worker pthreads, but not on the qthreads themselves.)
In support of this capability in the fifo tasking layer, the task-create
and task-execute functions have also had an opaque "task list" argument,
which the fifo tasking layer could use to create meta-info that allowed
the parent of a parallel construct to find the construct's children.
We have long wanted to simplify this interface. Our primary tasking
layer is qthreads, which doesn't need either the 'execute' function or
the task list argument. Those aspects of the interface were only needed
due to limitations in fifo tasking.
Here, finally remove chpl_task_executeTasksInList() and the associated
task list, rename chpl_task_addToTaskList() as chpl_task_addTask(),
and make similar changes in the module code that calls these runtime
functions and the compiler where it emits calls to the latter.
With this change in place the fifo tasking layer is subject to deadlock
if it can't get enough pthreads to run all its tasks, but given its
limited use especially at scale where this sort of situation might be
more common, we've decided this is an acceptable trade-off.
This also skips some tests for tasks=fifo because they can't behave as
desired without the parent thread helping run child tasks, and notests a
few more because that is true but they were only being run with fifo
tasking in the first place.
Modified Files:
A test/parallel/cobegin/stonea/reports.notest
A test/parallel/taskPool/figueroa/QueuedTasks.notest
A test/studies/madness/aniruddha/madchap/mytests/par-compress/test_compress.skipif
A test/studies/madness/aniruddha/madchap/mytests/par-reconstruct/test_reconstruct.skipif
A test/studies/madness/aniruddha/madchap/mytests/par-refine/test_refine.skipif
M compiler/codegen/cg-expr.cpp
M compiler/llvm/llvmDebug.cpp
M compiler/passes/parallel.cpp
M modules/internal/ChapelBase.chpl
M modules/internal/LocaleModelHelpRuntime.chpl
M runtime/include/chpl-mem-desc.h
M runtime/include/chpl-tasks.h
M runtime/src/tasks/fifo/tasks-fifo.c
M runtime/src/tasks/qthreads/tasks-qthreads.c
M test/parallel/cobegin/stonea/reports.execopts
M test/parallel/taskPool/figueroa/OneThread.skipif
M test/parallel/taskPool/figueroa/OneThreadSyncStmt.skipif
Compare: https://github.com/chapel-lang/chapel/compare/65aef75b7226...2b2b9163e36b