The Resource Viewpoint covers resource management, resource ownership, and resource utilization. This architectural viewpoint frames the following concerns:
resource management policy
resource ownership
resource utilization
Views
The following traceable architectural views explain the memory management policies, event management, and other resources:
SAS_QP_MEM
SAS_QP_MEM : General memory allocation policy
Model Kind
The composite structure diagram in Figure SAS-MEM shows a snapshot of memory after the startup of QP/C++ Application. This dynamic view illustrates the memory allocation policy in QP/C++ Framework.
Figure SAS-MEM: Memory allocation in QP/C++ Framework and QP/C++ Application.
QP/C++ Framework allocates (statically) only the following kinds of objects, whose sizes are known at compile-time:
An array of pointers to Active Objects managed by the framework (array act[] in Figure SAS-MEM [1])
An array of event-pools of different block-sizes (array EvtPool[] in Figure SAS-MEM [4])
A pointer to "subscriber list" for publish-subscribe (pointer subscrList[] in Figure SAS-MEM [5])
A pointer to to a software tracing buffer (pointer QS_txBuf[] in Figure SAS-MEM [6])
other, similar objects known at compile-time
QP/C++ Application is responsible for allocation of the following objects:
Active Object instances (see ActB_inst and ActA_inst in Figure SAS-MEM [1A,1B]). Note that the sizes of Active Objects depend on the attributes added during subclassing and customizing the QActive or QMActive base classes.
event-queue buffers for Active Objects (Figure SAS-MEM [2A,2B]). Note that the event-queue control structure (eQueue attribute) is known at compile-time and is part of the QActive base class. However, the size of the queue buffer depends on the needs of the specific Active Object and therefore is allocated by the application.
thread stacks, if needed (Figure SAS-MEM [3A,3B]). Note that the thread control structure (thread attribute) is known at compile-time and is part of the QActive base class. However, the size of the thread stack depends on the needs of the specific Active Object and therefore is allocated by the application. (NOTE: the thread stack allocation policy depends on the real-time kernel chosen for QP/C++ Framework. Some kernels don't need per-thread stacks at all. Some kernels need the stacks, but pre-allocate them internally. In those cases QP/C++ Application might not need to allocate the per-stack stacks);
event-pool buffers, if used (Figure SAS-MEM [4A,4B,4C]). Event pools are part of the QP/C++ Framework event memory management feature. QP/C++ Application can allocate the up to compile-time-configured number of event pools of different block-sizes. The event-pool control structure is known at compile-time (see array EvtPool[] in Figure SAS-MEM [4]), but the size of the event-pool buffers depends on the application needs and therefore is allocated by the application.
publish-subscribe lists (Figure SAS-MEM [5A]). If the publish-subscribe feature is used, QP/C++ Application needs to provide the subscribe-list buffer, whose size depends on the number of events that can be published.
tracing-buffers (Figure SAS-MEM [6A]). If the software tracing feature is used, QP/C++ Application needs to provide the tracing buffer, whose size depends on the volume of software tracing data produced.
Note
QP/C++ Framework's memory allocation policy leaves it up to QP/C++ Application how it allocates its objects. In particular, this freedom allows QP/C++ Application to use any allocation scheme, including allocating the object statically (preferred) or even from the standard heap (not recommended). Also, QP/C++ Application might choose the memory type for allocating various objects. For example, QP/C++ Application might choose to allocate event-pools in special memory regions (e.g., shared memory).
Backward Traceability
SRS_QP_NF_13 : All services provided by QP/C++ must NOT use the standard heap.
Forward Traceability
SAS_QP_FUSA_02 : Error detecting codes mechanisms to protect critical variables.
Model Kind
The composite structure diagram in Figure SAS-EMM illustrates how QP/C++ Framework manages the event memory. The diagram shows a snapshot in time including an Active Object's event-queue buffer as well as the events in memory.
Figure SAS-EMM: Event memory management in QP/C++ Framework.
Description
In order to uniformly treat all types of events, the Active Object event-queue stores only pointers to event instances. These pointers can point to immutable and mutable events located in event-pools as well as Time Events located typically inside Active Objects. QP/C++ Framework manages the memory for event-queues, queue-buffers, and event-instances as illustrated in a scenario shown in Figure SAS-EMM and described below:
Figure SAS-EMM [1A]: Active Object instance allocated by QP/C++ Application has an internal event-queue (the control structure);
Figure SAS-EMM [2A]: The external queue-buffer (allocated by QP/C++ Application) holds pointers to events. The used queue entries are highlighted.
Figure SAS-EMM [4A]: The event-pool buffer holds dynamically allocated mutable events. The used pool entries are highlighted. Two of the event-queue entries point to events in the "small" pool (event-pool with a "small" block-size).
Figure SAS-EMM [4B]: Another event-pool buffer holds dynamically allocated mutable events. The used pool entries are highlighted. One of the event-queue entries points to an event in the "medium" pool (event-pool with a "medium" block-size).
Figure SAS-EMM [5A]: One of the event-queue entries points to an Time Event instance (allocated inside the Active Object instance).
Backward Traceability
SRS_QP_EMM_00 : QP/C++ Framework shall support immutable events.
SRS_QP_EMM_10 : QP/C++ Framework shall support mutable events.
SRS_QP_TM_00 : QP/C++ Framework shall support Time Events.
Forward Traceability
SAS_QP_FUSA_02 : Error detecting codes mechanisms to protect critical variables.
