Peano

Searching...

No Matches

Abstract super class for a job. More...

#include <Task.h>

Inheritance diagram for tarch::multicore::Task:

[legend]

Public Member Functions
	Task (int taskType, int priority)
	Construct task.

virtual	~Task ()

int	getTaskType () const

int	getPriority () const

void	setPriority (int priority)
	Set priority.

virtual bool	canFuse () const

virtual bool	run ()=0

virtual bool	fuse (const std::list< Task * > &otherTasks, int targetDevice=Host)
	Fuse multiple tasks.

virtual std::string	toString () const

Static Public Attributes
static constexpr int	DefaultPriority = 1024

static constexpr int	Host = -1

static constexpr int	DontFuse = -1

Protected Attributes
const int	_taskType

int	_priority

Detailed Description

Abstract super class for a job.

Definition at line 21 of file Task.h.

Constructor & Destructor Documentation

◆ Task()

tarch::multicore::Task::Task	(	int	taskType,
		int	priority )

Construct task.

Task types and task numbers

Eachtask in Peano has to have a task type. All tasks that do the same, i.e. are of the same type, should have the same task type integer marker. Peano's tarch can use multiple tasks of the same type and fuse/batch them into one task call. However, if you don't want Peano to even thing about task fusion, pass in DontFuse as argument for the type.

It is totally up to the user to manage the task type numbers. Peano for example offers a factory mechanism peano4::parallel::getTaskType() to create task types, which Peano applications should use. However, the generation of the task types is not baked into the tarch.

Some codes also have task numbers. They need this, if they have to identify tasks uniquely. Applications for that are task dependencies or tasks that are offloaded to other ranks. For the latter tasks, we have to match data sent back by another rank to the task that would have produced these results locally. Anyway, task numbers are not baked into the generic interface, as we don't need them for all tasks all the time, and I want to avoid that the construction of unique task numbers becomes too expensive. If you should need unique task numbers, I recommend you use reserveTaskNumber().

Parameters

taskType	Unique task (type) number for this task. Pass in DontFuse if you don't want this task to be fused.
priority	Integer value that indicates what priority you want to assign a task. Value has to be non-negative. Use DefaultPriority if there is no bespoke priority.

Definition at line 25 of file Task.cpp.

References assertion2.

◆ ~Task()

virtual tarch::multicore::Task::~Task ( )

virtual

Definition at line 68 of file Task.h.

Member Function Documentation

◆ canFuse()

bool tarch::multicore::Task::canFuse ( ) const

virtual

Returns: true if the taskType is not DontFuse.

Definition at line 31 of file Task.cpp.

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

Here is the caller graph for this function:

◆ fuse()

bool tarch::multicore::Task::fuse	(	const std::list< Task * > &	otherTasks,
		int	targetDevice = Host )

virtual

Fuse multiple tasks.

Fuse the task with a list of further tasks. The routine is guaranteed to be called only for tasks with the same taskType. So if you carefully distinguish your tasks, you can downcast all the arguments, as you might know the real type.

This operation is invoked on a task. However, it is also given N=otherTasks.size further tasks of the same type. You have two options now:

You can process the N tasks in one rush. In this case, the original task, i.e. the object on which fuse() is called, remains intact and has not been processed yet. You have to return true.
You can process the N+1 tasks in one rush, i.e. all tasks from otherTasks and the task represented by the actual object on which fuse is called. In this case, you return false, as the task on which fuse has been called can be destroyed straightaway by the runtime.

No matter which route you follow, you always have to delete all the tasks stores within otherTasks, as these have to be processed by fuse().

Default implementation

My default implementation executes all the passed tasks and then returns the original task back, i.e. this one is not executed. This is the first execution pattern described above.

Memory ownership

See above: fuse() has to delete all the instances within otherTasks. The calling routine does not have to delete anything there anymore. But it has to destroy the owning object, i.e. the object on which is has called fuse(), manually no matter whether we return true or false.

Returns: Is the present task still to be executed or can the runtime destroy it straightaway?

Parameters

otherTasks	List of tasks to fuse and process. Will all have the same type as the present object. It is the tasks responsibility to get these tasks done. So either span some new tasks or handle them straightaway.
targetDevice	On which device should the task be processed? A negative number means local host anything greater or equal to zero denotes an accelerator.

Definition at line 42 of file Task.cpp.

References assertion, and run().

Referenced by tarch::multicore::native::processFusedTask().

Here is the call graph for this function: