tarch::multicore::native Namespace Reference

Functions
void	spawnAndWaitAsTaskLoop (const std::vector< tarch::multicore::Task * > &tasks)
	Map onto native tasking.

Function Documentation

spawnAndWaitAsTaskLoop()

void tarch::multicore::native::spawnAndWaitAsTaskLoop

(

const std::vector< tarch::multicore::Task * > &

tasks

)

Map onto native tasking.

Native mapping of a task loop onto a SYCL/oneTBB loop.

Run over the tasks and issue native tasks. If the tasks spawn, in return, further subtasks, these will either end up in a thread-local queue or will be mapped onto native tasks. The behaviour here depends on decisions within tarch::multicore::spawnTask() guided by the orchestration. If the subtasks enqueue tasks into the thread-local queue, they will remain there. This routine does not touch the thread-local queue.

The responsibility for the pointers in tasks is handed over to the runtime of choice, i.e. you don't have to delete them.

OpenMP mapping of a task loop onto a task loop

In OpenMP 6 and newer, we should use transparent tasks, as we want to expose task dependencies which do not stem from siblings. If OpenMP 6 is not supported, then we should disable the corresponding syntax.

NVIDIA

NVIDIA's nvc++ does not support taskloops. We have contacted their R&D and they confirmed that they only implement a subset of OpenMP, and the taskloop is not on the list of features that they want to support.

Implementation and bugs

See discussion in the context of the other taskloop: It is important to label tasks as shared even though I think copying should be fine as a copy degenerates to a shallow copy.

You are not allowed to call this routine for an empty task set. The empty task set means that the taskloop construct becomes nop. The subsequent taskwait hence synchronises on one logical level above within the task hierarchy, which is not what we want.

Parameters

tasks

Set of tasks. Is guaranteed to be non-empty.

In TBB, the convenient way to model fork-join parallelism is the creation of a task group. We can then assign all tasks to that task group and eventually wait for all of its tasks to terminate.

Each task within the task group (aka BSP thread - though these logical threads are internally mapped onto lightweight tasks) can spawn additional tasks. As part of the enclave concept, we don't have to wait for these children tasks at the end of the BSP section. Therefore, the BSP tasks enqueue their new children into a separate task group/arena (see spawnTask()) and `‘forget’' them.

Task arenas and task priorities

I do not explicitly submit the new task group into a task arena, i.e. I use the task arena of the surrounding task. Peano uses nested parallelism. We therefore might submit spawnAndWaitAsTaskLoop() for different areas with different priorities.

This realisation remark clarifies that we do not consider task priorities here.

If we worked with a task arena explicitly, we would have to write

::tbb::task_group taskGroup;
for (auto& p : tasks) {
  defaultTaskArena.execute( [&]{
    taskGroup.run([&tasks, p]() -> void {
      while (p->run()) {
        tarch::multicore::Core::getInstance().yield();
      }
      delete p;
    });
  });
}
 
defaultTaskArena.execute( [&]{
  taskGroup.wait();
});

See also

spawnTask()

Definition at line 113 of file Tasks.cpp.

References assertion.

Referenced by tarch::multicore::spawnAndWait().

Here is the caller graph for this function: