With DAGDA, there are two ways to manage the asynchronous data
transfers, depending of the data usage:
- With end-of-transfer control: DAGDA maintains a reference to
the transfer thread. It only releases this reference after a call
to the corresponding waiting function. The client developer should
always use these functions, that's why a data ID is only returned
by the “dagda_wait_*” and
“dagda_wait_data_ID” functions.
- Without end-of-transfer control: The data is loaded from/to
the DAGDA hierarchy without the possibility to wait for the end
of the transfer. These functions should only be called from an
agent plugin scheduler, a SeD plugin scheduler or a SeD if the
data transfer without usage of the data is one of the objectives
of the called service. The data adding functions without control
should be used very carefully because there is no way to be sure
the data transfer is achieved or even started.
With asynchronous transfers, the user should take care of the data
lifetime because DAGDA does not duplicate the data pointed by the
passed pointer. For example, if the program uses a local variable
reference to add a data to the DAGDA hierarchy and goes out of the
variable scope, a crash could occured because the data pointer could
be freed by the system before DAGDA has finished to read it.
Subsections
The DIET Team - Mer 29 nov 2017 15:13:36 EST