struct ara::core::PoolOptions

The structure ara::core::PoolOptions is used to configure pool-based memory resources according to std::pmr::pool_options. It allows limiting the maximum number of blocks per chunk via max_blocks_per_chunk [SWS_CORE_00027] and specifying the maximum pool block size via largest_required_pool_block [SWS_CORE_00028]. As a simple data aggregate, the structure is populated prior to initialization of the memory resource and passed to its constructor. Interpretation: Since no intrinsic validation takes place, developers must ensure that the configured threshold values do not overwhelm the physical RAM. Question (open)

more ›

Context

The data structure ara::core::PoolOptions provides configuration parameters for memory-pool-based resources in module core of the AUTOSAR Adaptive Platform. It serves the targeted control of allocation behavior and is based on the C++ standard functionality of std::pmr::pool_options. The structure is included via header <ara/core/memory_resource.h> and interacts closely with pool memory resources that hold contiguous chunks and blocks for recurring memory requests.

In safety-critical and near-real-time systems, the limitation and predictability of dynamic memory operations are essential. In this context, ara::core::PoolOptions assumes the role of a decoupler between application-specific capacity requirements and the internal management of memory pools. Via the structure, developers can define the maximum number of blocks that may be grouped within a chunk [SWS_CORE_00027] and which maximum block size still has to be serviced via the specialized pools [SWS_CORE_00028]. Application software that instantiates memory resources uses these options to avoid excessive fragmentation and to deterministically control allocation limits.

Lifecycle

As a simple configuration type (struct), ara::core::PoolOptions has a lightweight lifecycle without complex internal state transitions. Creation typically takes place as a local stack object or as a static configuration constant prior to the instantiation of the associated memory resource. Upon instantiation, the two attributes max_blocks_per_chunk [SWS_CORE_00027] and largest_required_pool_block [SWS_CORE_00028] are initialized by default with the value 0.

Interpretation: A value of 0 is likely to signal to the receiving memory resource that platform-specific default limits should take effect. Question (open) Since it is a pure value object, ara::core::PoolOptions owns no resources in the sense of RAII and executes no cleanup actions upon destruction. The lifecycle of the structure is usually coupled to the creation phase of the memory resource: once the options have been passed to the pool resource, the resource retains the parameters internally, allowing the PoolOptions object itself to be safely destroyed or reused.

Regarding concurrency, the structure itself provides no inherent synchronization mechanism. Concurrent read accesses to an unmodified PoolOptions object are thread-safe, whereas simultaneous modifications must be synchronized externally. However, since the object is primarily configured prior to being passed, write access generally no longer takes place after initialization.

Usage Path

The primary use case encompasses defining allocation limits and forwarding them to a memory-managing component. First, the caller creates an instance of ara::core::PoolOptions and sets the desired parameters. Via max_blocks_per_chunk, the upper bound for blocks per chunk is defined [SWS_CORE_00027], while largest_required_pool_block defines the upper limit for allocations that are still to be covered by the pool [SWS_CORE_00028].

Subsequently, the populated structure is passed to the constructor of a corresponding pool memory resource. The memory resource reads the configured values and configures its internal pools accordingly. If memory requests arrive during runtime, the resource decides based on the previously configured thresholds whether the request can be serviced from a pool or must be forwarded to a higher-level upstream resource. Interpretation: It can be assumed that requests exceeding largest_required_pool_block are typically delegated directly to the upstream memory manager. Question (open)

Sequence diagram: Typical procedure for configuring a pool memory resource via PoolOptions. Sources: [SWS_CORE_00027], [SWS_CORE_00028].

Error Scenarios

Since ara::core::PoolOptions is defined as a simple data aggregate (struct), creating or populating the fields throws no C++ exceptions and returns no error codes. Potential error conditions arise only during the interpretation of the values by the receiving memory resource.

Interpretation: If unrealistic values are configured — for example, an extremely large value for max_blocks_per_chunk [SWS_CORE_00027] or for largest_required_pool_block [SWS_CORE_00028] —, this can cause the downstream memory resource to hit system limits when allocating chunks and trigger out-of-memory conditions. Question (open) A prerequisite for stable operation is therefore careful coordination of the two parameters with the physically available RAM and the expected load profile of the application. If the values remain at 0, it is up to the target resource to use robust default sizes.