QP/C++ Real-Time Event Framework 8.1.5
QP/C++ Real-Time Event Framework 8.1.5
Architectural viewpoint: Resource management in QP/C++ Framework.
Purpose
The Resource Viewpoint covers resource management, resource ownership, and resource utilization.
Architectural Views
This architectural viewpoint frames the following views:
The following traceable architectural views explain the memory management policies, event management, and other resources:
Model Kind
The composite structure diagram in Figure SAS-MEM shows a snapshot of memory after the startup of the QP/C++ Application. This dynamic view illustrates the policies of managing various resources and memory in the QP/C++ Framework component.
Architectural view: General QP/C++ Framework component memory allocation policy.
QP/C++ Framework component's memory allocation policy is to minimize the use and size of the internal objects and to apply exclusively static allocation for these objects. The policy intentionally leaves it up to the QP/C++ Application to allocate any other objects, allowing the QP/C++ Application to freely use any allocation scheme, including allocating the object statically (preferred) or even from the standard heap (not recommended). This also allows the QP/C++ Application to choose the memory type for allocating various objects. For example, the QP/C++ Application might choose to allocate event-pools in special memory regions (e.g., shared memory, special DMA memory, etc.).
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Active Object memory allocation policy and responsibilities.
QP/C++ Framework component pre-allocates (statically) only an array of pointers to Active Objects managed by the framework (array act[] in Figure SAS-MEM [1]). The size of the array, called also "Active Object registry," is configured at compile-time, but cannot exceed 64 Active Objects.
The QP/C++ Application is responsible for the allocation of the 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.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Event queue allocation policy and responsibilities.
Forward Traceability (truncated to 1 level(s))
Architectural view: Active Object stack allocation policy and responsibilities.
If the underlying real-time kernel requires a separate stack space for each Active Object thread (Figure SAS-MEM [3A,3B]), these stacks must be allocated by the QP/C++ Application. Note that the thread control block (thread attribute) is part of the QActive base class and is known at compile-time. 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 the QP/C++ Framework component. Some kernels don't need per-thread stacks at all. Some kernels need the stacks, but pre-allocate them internally. In those cases, the QP/C++ Application might not need to allocate the per-thread stacks.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Event pool allocation policy and responsibilities.
QP/C++ Framework component pre-allocates (statically) only an array of event-pools of different block-sizes (array EvtPool[] in Figure SAS-MEM [4]). The size of the array is configured at compile-time, but cannot exceed 15 event pools.
The QP/C++ Application is responsible for the allocation of the event pool memory buffers event pools (Figure SAS-MEM [4A,4B,4C]) of different block-sizes. The size of the event-pool buffers depends on the application's needs and therefore is allocated by the application.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Subscription lists allocation policy and responsibilities.
QP/C++ Framework component statically allocates only a pointer to "subscriber list" for publish-subscribe (pointer subscrList[] in Figure SAS-MEM [5])
The QP/C++ Application is responsible for the allocation of the 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.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Software tracing buffers allocation policy and responsibilities.
The QP/C++ Framework component statically allocates the internal ring buffer control blocks for the tracing transmit buffer and receive buffer.
The QP/C++ Application is responsible for the allocation of the tracing-buffers (Figure SAS-MEM [6A]). The QP/C++ Application needs to provide the tracing buffer, whose size depends on the volume of software tracing data produced.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Event management policy in QP/C++ Framework.
Model Kind
The composite structure diagram in Figure SAS-EMM illustrates how the QP/C++ Framework component manages the events. The diagram shows a snapshot in time, including an Active Object's event-queue buffer as well as the various events in memory.
Description
To uniformly treat all types of events, the Active Object event-queue stores only pointers to event instances. These pointers can point to immutable events located in ROM and mutable events located in event-pools, as well as Time Events located typically inside Active Objects. QP/C++ Framework component 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 [3A]: One of the event-queue entries points to an immutable event instance (allocated in ROM).
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
Forward Traceability (truncated to 1 level(s))