parsec

parsec copied to clipboard

Description

TTG makes heavy use of of RAII (resource acquisition is initialziation) in C++. It is possible to create a parsec_data_t as part of an object inside of a device task. RAII can lead to cases where the data is destroyed at the end of the task function execution (in the destructor of the owning object) but before the task is completed by PaRSEC, so the relationship to its copies disappears. I would like to think of this as a valid case and have the PaRSEC device code handle this gracefully. For example, a copy may not have access to its original data anymore. In that case there is no need to push data back to the host and the remainder of the code handling this data copy can be skipped.

Describe the solution you'd like

Careful checks for whether copies can access their original data are needed in the task pop stage of the device code.

Describe alternatives you've considered

TTG could handle such cases outside of PaRSEC (e.g., by keeping a list of delayed data destructions) but that seems more expensive and error-prone than adding checks to PaRSEC, which should come at a negligible cost.

Either way, it should be part of the PaRSEC API description when data is allowed to disappear and from the TTG view a more lenient contract would be preferable.