Peano

Searching...

No Matches

Spawned node. More...

#include <dynamic_task_graph_spawned_node.h>

Collaboration diagram for tbb::dynamic_task_graph_spawned_node:

[legend]

Public Types
enum class	State { Submitted , Spawned , Complete }

Public Member Functions
	dynamic_task_graph_spawned_node (const dynamic_task_graph_node &task_specification, dynamic_task_graph &task_graph)
	Create a new task node in the graph.

	dynamic_task_graph_spawned_node (const dynamic_task_graph_spawned_node &)=delete
	You cannot copy a spawned node.

void	incoming_task_has_terminated ()

void	run ()
	Run the task.

Private Attributes
std::atomic< State >	_state

std::function< void()>	_functor

tbb::spin_mutex	_semaphore

dynamic_task_graph &	_task_graph

int	_number_of_in_dependencies

std::vector< std::shared_ptr< dynamic_task_graph_spawned_node > >	_out_dependency

Friends
class	dynamic_task_graph

Detailed Description

Spawned node.

This class is only used internally within the task graph lib and not to be used directly by users. Users create instances of dynamic_task_graph_node. Once they put this node into a task_graph instance, it is tied to a new instance of spawned_task_graph_node.

Memory/heap management

As long as a task graph is alive, users might use it to introduce new task dependencies. So we have to ensure that the memory location is absolutely unique. Notably, we may not encounter a situation where a user submits a task A, this task is processed immediately, then creates a task B and a task C which depends on A (but not B). So B may never ever end up at the same memory location as A.

To avoid this, we work exclusively with smart pointers referencing spawned nodes.

Definition at line 46 of file dynamic_task_graph_spawned_node.h.

Member Enumeration Documentation

◆ State

enum class tbb::dynamic_task_graph_spawned_node::State

strong

Enumerator
Submitted
Spawned
Complete

Definition at line 50 of file dynamic_task_graph_spawned_node.h.

Constructor & Destructor Documentation

◆ dynamic_task_graph_spawned_node() [1/2]

tbb::dynamic_task_graph_spawned_node::dynamic_task_graph_spawned_node	(	const dynamic_task_graph_node &	task_specification,
		dynamic_task_graph &	task_graph )

Create a new task node in the graph.

Creating a new task node means that we have to "invert" the edges in the underlying graph: An instance of task_specification knows which task are incoming. For the actual task graph, we need the outgoing tasks.

The default spawned task has one incoming dependency, i.e. is not ready. You have to manually decrease the counter after construction once all dependencies are in place.

Definition at line 11 of file dynamic_task_graph_spawned_node.cpp.

References __TBB_TRACE_TASK_CREATE.

◆ dynamic_task_graph_spawned_node() [2/2]

tbb::dynamic_task_graph_spawned_node::dynamic_task_graph_spawned_node ( const dynamic_task_graph_spawned_node & )

delete

You cannot copy a spawned node.

Member Function Documentation

◆ incoming_task_has_terminated()

void tbb::dynamic_task_graph_spawned_node::incoming_task_has_terminated ( )

Definition at line 24 of file dynamic_task_graph_spawned_node.cpp.

Referenced by tbb::dynamic_task_graph::put().

Here is the caller graph for this function:

◆ run()

void tbb::dynamic_task_graph_spawned_node::run ( )

Run the task.

This is the actual routine which hands the task over to TBB's runtime. The system is allowed to invoke it if and only if the task is ready, i.e. has no pending incoming dependencies anymore.

Algorithm steps

Invoke the functor, i.e. do the actual task calculations. Note that other tasks still might add further outgoing dependencies at this point.
Create our own smart pointer to the underlying instance of dynamic_tsak_graph_spawned_node. We will remove it from the list of spawned tasks next, which means it could be destroyed at this point. We still have to tidy it up however, so better to hold our own smart pointer.

Remove the task from the set of spawned tasks. Noone should use this task after that anymore.
Lock the task, as we now will change things. In theory, this should not be necessary, but someone might still hold a pointer to this task and try to alter it while we sort out the outgoing dependencies and ramp up the task.
Inform all outgoing tasks that we are done.