MADNESS 0.10.1
Public Member Functions | Public Attributes | List of all members
madness::MacroTaskOperationBase Class Reference

#include <macrotaskq.h>

Inheritance diagram for madness::MacroTaskOperationBase:
Inheritance graph
[legend]
Collaboration diagram for madness::MacroTaskOperationBase:
Collaboration graph
[legend]

Public Member Functions

 MacroTaskOperationBase ()
 
virtual ~MacroTaskOperationBase ()
 
virtual bool accumulates_own_output () const
 
virtual void cleanup ()
 release whatever the task kept across its batches, called once the queue has run
 
virtual bool handles_own_data_movement () const
 true if the task moves its operand coefficients into the subworld itself
 
virtual long owner_hint (const Batch &, const long) const
 which subworld should run this batch; -1 leaves the choice to the queue
 

Public Attributes

Batch batch
 
Cloudcloud_ptr =0
 
std::string name ="unknown_task"
 
std::shared_ptr< MacroTaskPartitionerpartitioner =0
 
Worldsubworld_ptr =0
 

Constructor & Destructor Documentation

◆ MacroTaskOperationBase()

madness::MacroTaskOperationBase::MacroTaskOperationBase ( )
inline

◆ ~MacroTaskOperationBase()

virtual madness::MacroTaskOperationBase::~MacroTaskOperationBase ( )
inlinevirtual

Member Function Documentation

◆ accumulates_own_output()

virtual bool madness::MacroTaskOperationBase::accumulates_own_output ( ) const
inlinevirtual

true if the task accumulates its own results and drains them in finalize_stage2, instead of the queue moving every batch result into the universe result itself

Reimplemented in madness::Exchange< T, NDIM >::ExchangeImpl< T, NDIM >::MacroTaskExchangeSimple.

◆ cleanup()

virtual void madness::MacroTaskOperationBase::cleanup ( )
inlinevirtual

release whatever the task kept across its batches, called once the queue has run

A task class that caches operands between its batches has to keep them in static state, since each batch is a separate task object. This is where that state must be dropped: it still refers to the subworld the batches were built in, and that subworld is destroyed after the queue finishes. Clearing it later means destroying function implementations whose world is already gone.

Reimplemented in madness::Exchange< T, NDIM >::ExchangeImpl< T, NDIM >::MacroTaskExchangeSimple.

◆ handles_own_data_movement()

virtual bool madness::MacroTaskOperationBase::handles_own_data_movement ( ) const
inlinevirtual

true if the task moves its operand coefficients into the subworld itself

Reimplemented in madness::Exchange< T, NDIM >::ExchangeImpl< T, NDIM >::MacroTaskExchangeSimple.

◆ owner_hint()

virtual long madness::MacroTaskOperationBase::owner_hint ( const Batch ,
const long   
) const
inlinevirtual

which subworld should run this batch; -1 leaves the choice to the queue

Reads whatever assignment prepare_owner_assignment computed, so the two go together: one decides the mapping for the whole partition, this one applies it per batch.

Reimplemented in OwnedTask, and madness::Exchange< T, NDIM >::ExchangeImpl< T, NDIM >::MacroTaskExchangeSimple.

Member Data Documentation

◆ batch

Batch madness::MacroTaskOperationBase::batch

◆ cloud_ptr

Cloud* madness::MacroTaskOperationBase::cloud_ptr =0

set by MacroTaskInternal::run before the task body runs, so a task that moves its own operands (see handles_own_data_movement) can fetch them from the cloud itself

◆ name

std::string madness::MacroTaskOperationBase::name ="unknown_task"

◆ partitioner

std::shared_ptr<MacroTaskPartitioner> madness::MacroTaskOperationBase::partitioner =0

◆ subworld_ptr

World* madness::MacroTaskOperationBase::subworld_ptr =0

The documentation for this class was generated from the following file: