SNIP_ADAPTIVE_CAN_FIGURE_Figure_7_18

Figure 7.18: Worker Pool Usage If the number of required container elements exceeds the number of workers (threads) in the deterministic worker pool, Execution Management can use the worker pool several times sequentially (with unrestricted interleaving), which shall be transparent to the user of the worker pool. T o achieve Data Determinism, the parallel workers need to satisfy certain implementation properties, e.g. no exchange of data is allowed between the instances of the runnable object which are processed by the workers. For details see [10]. Other, more complex solutions which allow interaction between the workers would be possible, but they increase complexity , reduce utilization and transparency , and are error-prone regarding the deterministic behavior. The worker pool runs within the process context of the caller of this API. It is designed as part of Execution Management to guarantee the deterministic behavior by incorporating it in the ara::exec::DeterministicClient::WaitForActivation cycle. An example for the implementation of a ara::exec::WorkerRunnable can be found in [10]. The aim is to abstract the data processing as far as possible, irrespective of the actual number of available threads. Example: a job with N similar sub-jobs (e.g. N Kalman-filters). The job is assigned to the worker pool by calling ara::exec::