docs:aem

RTLib Abstract Execution Model

RTLib

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:

  • A resource-aware execution model, to enable the possibility of configuring itself according to the assigned computing resources
  • A profiling support (e.g., performance counters instrumentation, performance monitoring APIs)

From the developer perspective, to be integrated with the BarbequeRTRM, an application must fit in the RTLib Abstract Execution Model.

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:

  • Different code
  • Different resource usage requirements

Execution Contexts of the same application MUST be independent, since the BarbequeRTRM does not take into account task inter-dependency

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 BbqueEXC. 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.

Please note that Resource Management support comes for free: you don't need to implement anything other that the code of your application. You don't even need to know the BarbequeRTRM internals. Implementing the AEM member functions is just a matter of moving your application's existing code into the functions and therefore making the application's execution stick with the RTLib execution model. Such process is quite straightforward; give a look at out tutorial Creating a new integrated application

 Abstract Execution Model

  • onSetup

Initialization code. Here you should perform mallocs, variables initializations and so on

  • onConfigure

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.

  • onSuspend

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.

  • onRun

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.

  • onMonitor

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.

  • onRelease

Optional, but recommended member function. This should eventually contain cleanup stuff (e.g. free mallocs).

The setup and release methods (onSetup, onRelease) are called once during the execution of an application. The configure method (onConfigure) is called each time the application receives a new AWM; Therefore, usually, the AEM can be thought of as the following loop:

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:

[START]
onSetup → onConfigure → onRun → onMonitor → (onConfigure if needed) → onRun → onMonitor … → onRelease
[STOP]

Next tutorial: The Recipes

docs/aem.txt · Last modified: 2015/11/17 12:31 by slibutti

Page Tools