7.11. Memory Model

7.11.1. Introduction

Connext Cert is designed for use in real-time systems and uses a predictable and deterministic memory manager to ensure that memory growth is not unbounded, OS memory fragmentation is eliminated and memory usage can be determined a-priori. The advantage with this design is that proper operation is ensured as soon as steady state has been reached. However, it also places an additional burden on the system designer to properly configure each resource-limit. The purpose of this document is to describe all resource-limits in Connext Cert, what the behavioral impact is, and what the impact on memory usage is.

7.11.2. Dynamic Memory Allocation

Connext Cert allocates heap memory to create internal data-structures. It is important to know that Connext Cert manages memory allocated from the system heap using its own internal memory management, and only returns memory allocated from the system back to the system when something is deleted. That is, if an application never deletes anything, no memory is returned to the system.

As a rule of thumb, in Connext Cert the only APIs that allocate heap memory are:

And the only APIs that free memory are:

The Connext Cert user is supposed to use API function which allocate memory only during system initialization. This avoid to run into situations where a resource can not be allocated after the initialization phase.

Connext Cert does not support dynamically allocating resources beyond the initial configuration. That is, all resource limits must be finite. This restriction may be removed in a future version.

7.11.3. Resource Limits

All resource-limits in Connext Cert are specified in a Qos policy or property. The figure below illustrates where the various resource-limits are applied, and the section Resource Limits describes each user-adjustable resource limit in more detail. All numbers in blue correspond to a resource limit.

../_images/MicroMemoryMap.png