|
| void | dumpStatistics () |
| | For debugging only.
|
| |
| void | waitForTaskToTerminateAndCopyResultOver (int number, double *destination, double &maxEigenvalue, const tarch::la::Vector< Dimensions, double > &x, const tarch::la::Vector< Dimensions, double > &h) |
| | Wait for a task and copy outcome into destination.
|
| |
| void | waitForTaskAndDiscardResult (int number, const tarch::la::Vector< Dimensions, double > &x, const tarch::la::Vector< Dimensions, double > &h) |
| | Wait for a task and copy outcome into destination.
|
| |
| void | finishedTask (int taskNumber, int numberOfResultValues, double *data, double maxEigenvalue, const tarch::la::Vector< Dimensions, double > &x, const tarch::la::Vector< Dimensions, double > &h) |
| | Usually called directly by EnclaveTask.
|
| |
| void | registerTask (int taskNumber, const ::peano4::datamanagement::CellMarker &marker) |
| | This one is only there for debugging purposes.
|
| |
Enclave bookkeeping.
The enclave bookkeeping is basically a big map which stores results of enclave tasks. Most of the documentation around enclave tasks can be found in exahype2::EnclaveTask.
The bookkeeping can be used in two ways by the underlying enclave task object: The enclave tasks can allocate data for their results on the heap, hand that heap object over to the bookkeeping, and the bookkeeping then hands out the results to the actual solver by copying it into the right place in the mesh and subsequently freeing the tasks's output.
Alternatively, we can work directly on the heap, i.e. the mesh tells us where the result should end up. In our tests, it is not always clear which variant is faster. Which is kind of a surprise. Likely it has to do with memory/cache issues.
Definition at line 42 of file EnclaveBookkeeping.h.
| void exahype2::EnclaveBookkeeping::finishedTask |
( |
int | taskNumber, |
|
|
int | numberOfResultValues, |
|
|
double * | data, |
|
|
double | maxEigenvalue, |
|
|
const tarch::la::Vector< Dimensions, double > & | x, |
|
|
const tarch::la::Vector< Dimensions, double > & | h ) |
Usually called directly by EnclaveTask.
Once this routine is called, the ownership of data passes over into the enclave bookkeeping. Basically, the enclave bookkeepting stores the passed pointer into a map and returns.
There is one exception to this: If we use optimistic time stepping, then we might run into a situation where a task overwrites a previous result. At the moment, this variant yields a warning, but in any case, the old data is first released, before we store the new pointer.
- Parameters
-
| data | Has to be device memory allocated through tarch::multicore::allocateMemory() |
| x | This marker is only there for debug reasons. In release mode, we ignore it. |
| h | This marker is only there for debug reasons. In release mode, we ignore it. |
| void exahype2::EnclaveBookkeeping::waitForTaskToTerminateAndCopyResultOver |
( |
int | number, |
|
|
double * | destination, |
|
|
double & | maxEigenvalue, |
|
|
const tarch::la::Vector< Dimensions, double > & | x, |
|
|
const tarch::la::Vector< Dimensions, double > & | h ) |
Wait for a task and copy outcome into destination.
We use waitForTaskToTerminateAndReturnResult() to obtain a handle to the task outcome. Once we get it, we have to check what to do next:
If an enclave task had been given the memory location where to dump the result directly, we simply return. In this case, the task outcome pointer and destination point to the same address.
If the task had allocated its own output data area on the heap, we copy the content from there into destination and then delete the task's memory location via
void freeMemory(void *data, MemoryLocation location, int device=accelerator::Device::HostDevice)
Free memory.
@ ManagedSharedAcceleratorDeviceMemory
To be used on host only.
- Parameters
-
| x | This marker is only there for debug reasons. In release mode, we ignore it. |
| h | This marker is only there for debug reasons. In release mode, we ignore it. |
Wait for a task result to become available.
We wait for the task to terminate, and then return the meta object which describes the task properties. It is up to the calling routine to decide what to do with the result. We might either return the data or throw it away.
The routine assumes that a task has dropped its results due to finishedTask() already. To ensure this really happens, we call tarch::multicore::waitForTask() at the start of the routine's body.
Validation
All the validation steps are realised through non-critical
- Returns
- Entry with all meta data plus a pointer to the actual task result.
- Parameters
-
| x | This marker is only there for debug reasons. In release mode, we ignore it. |
| h | This marker is only there for debug reasons. In release mode, we ignore it. |
1.10.0