The Run-Time Library (RTLib) exposes the services provided by the Barbeque Run-Time Resource Manager (BarbequeRTRM) to the integrated applications. By linking the RTLib, the communication between the application and the BarbequeRTRM is completely transparent to the developer. Moreover, the application benefits from:
From the developer perspective, to be integrated with the BarbequeRTRM, an application must fit in the RTLib Abstract Execution Model.
To support the run-time reconfigurability of the applications, the RTLib provides an Abstract Execution Model (AEM). This model is provided to synchronize the execution of the application with the dynamical resource allocation enforced by BarbequeRTRM.
An application can be usually thought of as a “schedulable task”, which we call Execution Context (EXC). Each application is composed by one or more EXC, each of them implemented following the RTLib Abstract Execution Model. Each EXC can be characterized by:
Ninety-nine per cent of the time, a single Execution Context is enough for an application; all the example applications and integrated benchmarks provided with BOSP are integrated using a single EXC.
The RTLib exports the Abstract Execution Model through the
BbqueEXC(C++) base class. To instantiate an Execution Context, the application developer must implement and instantiate a class derived from
The image below provides an very detailed view of the Abstract Execution Model; however, keep in mind that “white blocks” are the only member functions you must implement.
Initialization code. Here you should perform mallocs, variables initializations and so on
Called when the BarbequeRTRM assigns the applicaiton a new Application Working Mode (AWM), i.e., the set of resources allocated for the application/EXC. The code to place here is related to whatever is required to reconfigure the application (number of threads, application parameters, data structures, …) to properly run according to resources assigned through the AWM.
There are no resources for the EXC. Its execution must be stopped. Here should be placed whatever is needed to leave the application in a safe state.
This is the entry point of our task. Here must be implemented the code to execute a computational run. We strongly suggest to keep the duration of the task in a few hundreds of milliseconds, in order to make the task interruptible with a “reasonable” time granularity. This would prevent the application from being killed by the BarbequeRTRM.
After a computational run, the application may check whether the level of QoS/performance/accuracy is acceptable or not. In the second case, some action could be taken.
Optional, but recommended member function. This should eventually contain cleanup stuff (e.g. free mallocs).
onRun → onMonitor → onRun → onMonitor …
Essentially, the application will continuously run and monitor its execution.
Note that when an application starts, it will receive an AWM; therefore, before the first onRun, it will always run onSetup and then onConfigure methods. The following loop is the most correct one:
onSetup → onConfigure → onRun → onMonitor → (onConfigure if needed) → onRun → onMonitor … → onRelease
Next tutorial: The Recipes