class ara::core::UnsynchronizedPoolResource

The declaration of the copy constructor as deleted (=delete) in ara::core::UnsynchronizedPoolResource according to [SWS_CORE_00046] prevents any duplication of a pool instance. For object creation, specific constructors are available instead, such as without arguments [SWS_CORE_00063], with specification of an upstream memory resource [SWS_CORE_00064], with PoolOptions [SWS_CORE_00068], or with both parameters [SWS_CORE_00067].

The following boundary conditions apply to usage and runtime behavior:

• Invocation and error handling: An attempt to copy is already rejected by the compiler as an error at compile time. Allocation errors during subsequent memory usage via do_allocate do not result in exceptions, but return nullptr [SWS_CORE_00058], while deallocation errors in do_deallocate are silently ignored [SWS_CORE_00059].
• Concurrency: Individual memory operations on the instance are declared not thread-safe [SWS_CORE_00058], [SWS_CORE_00059]. Interpretation: Deleting the copy constructor likely ensures exclusive responsibility for the managed memory blocks and prevents inconsistent states during concurrent usage or premature release via release [SWS_CORE_00065]. Question Q-d97dd87dddb2379d (open)
• Interaction: The restriction corresponds to the likewise deleted assignment operator [SWS_CORE_00047]. The destructor of the class is non-virtual [SWS_CORE_00062], while identity checks can be performed via do_is_equal [SWS_CORE_00060].

The copy assignment operator of ara::core::UnsynchronizedPoolResource is explicitly declared as deleted (=delete) according to [SWS_CORE_00047]. Assigning one instance to another is thus syntactically excluded and leads to a compiler error already at compile time. Together with the likewise deleted copy constructor [SWS_CORE_00046], this ensures that instances of the resource class can neither be copied nor duplicated by assignment. Interpretation: This is likely intended to prevent internal memory blocks and management information from being referenced multiple times or incorrectly deallocated. Question Q-75cee08bebc61976 (open)

New instances are created instead via the provided constructors, for example without parameters via [SWS_CORE_00063], with an upstream resource via [SWS_CORE_00064], or specifying PoolOptions via [SWS_CORE_00067] or [SWS_CORE_00068]. The associated upstream resource can be queried via [SWS_CORE_00056] and the configuration options via [SWS_CORE_00057]. Managed memory can be explicitly deallocated with [SWS_CORE_00065] before the lifetime ends with the non-virtual destructor [SWS_CORE_00062].

Since assignments are precluded by [SWS_CORE_00047], instances must be passed by reference or pointer if needed. It should be noted here that allocations via [SWS_CORE_00058] and deallocations via [SWS_CORE_00059] are specified as not thread-safe. If a memory request fails, no exception is thrown, but nullptr is returned [SWS_CORE_00058]; deallocation errors are silently ignored [SWS_CORE_00059].

use

The method upstream_resource() of class ara::core::UnsynchronizedPoolResource synchronously returns a pointer to the upstream MemoryResource [SWS_CORE_00056]. The call is parameterless and declared as const. Inclusion and type declarations are provided via the header file #include "ara/core/memory_resource.h" [SWS_CORE_00056].

Error handling

The function is specified as noexcept as well as exception safe [SWS_CORE_00056]. It throws no exceptions and reports neither specific error codes nor DET or DEM events. If preceding initialization via constructors fails, those are in part not exception safe [SWS_CORE_00063], whereas the query itself always remains error-free.

Concurrency and Limitations

The method upstream_resource() is explicitly classified as thread-safe [SWS_CORE_00056]. This is in contrast to the internal allocation routines do_allocate() [SWS_CORE_00058] and do_deallocate() [SWS_CORE_00059], which are specified as not thread-safe. In addition, the copy constructor and assignment operator of the class are deleted [SWS_CORE_00046], [SWS_CORE_00047].

Interaction

The method interacts closely with the constructors of UnsynchronizedPoolResource, to which an upstream MemoryResource can optionally be passed [SWS_CORE_00064], [SWS_CORE_00067]. Interpretation: The returned pointer is expected to point precisely to the instance of MemoryResource specified during instantiation. Question Q-aefbc7d0f7d085d1 (open) Further properties of the pool resource can be queried via options() [SWS_CORE_00057], while allocated memory can be released via release() [SWS_CORE_00065].

use

The member function options() of class ara::core::UnsynchronizedPoolResource serves to synchronously query the memory pool configuration [SWS_CORE_00057]. The method is declared in #include "ara/core/memory_resource.h", expects no parameters, and returns an instance of type PoolOptions by value [SWS_CORE_00057]. As a const-qualified function, it does not modify the object and behaves according to the specification in [mem.res.pool] [SWS_CORE_00057].

Error Handling and Exception Safety

The interface is defined as noexcept and guarantees complete exception safety (exception safe) [SWS_CORE_00057]. No exceptions are thrown and no error return values exist; retrieving the options always succeeds without errors.

Concurrency and Limitations

In the specification, options() is designated as thread-safe (thread-safe) [SWS_CORE_00057]. This contrasts with allocation functions of the same class such as do_allocate [SWS_CORE_00058] and do_deallocate [SWS_CORE_00059], which are explicitly not thread-safe. The method can thus be executed concurrently for state inspection.

Interaction

The returned PoolOptions likely reflect the parameters with which the pool resource was parameterized via corresponding constructors [SWS_CORE_00067], [SWS_CORE_00068], or represent the default options when using default constructors [SWS_CORE_00063], [SWS_CORE_00064]. Question Q-19fa8ad6e3e6b1c6 (open) In addition to options(), the function upstream_resource() is also available for inspection [SWS_CORE_00056], while copying operations of the resource are prevented by deleted operators [SWS_CORE_00046], [SWS_CORE_00047].

use

The method do_allocate of class ara::core::UnsynchronizedPoolResource allocates memory for the requested byte size (bytes) and alignment (alignment) [SWS_CORE_00058]. Interpretation: Since the method is specified with protected visibility (protected), it would typically not be called directly by application code in regular operation, but indirectly via the allocation interface of the base class. Question Q-5a702813496f8071 (open) The declaration is provided via the header file #include "ara/core/memory_resource.h" [SWS_CORE_00058].

Error handling

In contrast to the standard behavior according to [mem.res.pool], the function is declared as noexcept and does not throw an exception such as std::bad_alloc [SWS_CORE_00058] upon allocation failures. Instead, it mandatorily returns nullptr in case of failure [SWS_CORE_00058]. Calling code must therefore always explicitly check the result for null pointers.

Concurrency and Limitations

The function is classified as not thread-safe [SWS_CORE_00058]. Concurrent calls on the same instance of UnsynchronizedPoolResource are not permitted without external synchronization. The copy constructor and assignment operator of the class are deleted (delete), so instances cannot be copied ([SWS_CORE_00046], [SWS_CORE_00047]).

Interaction

For memory deallocation, the counterpart do_deallocate exists, which is likewise designed to be protected, noexcept, and not thread-safe, and silently ignores errors [SWS_CORE_00059]. Internally, the pool uses the upstream resource configured during instantiation ([SWS_CORE_00056], [SWS_CORE_00064], [SWS_CORE_00067]). With release(), the memory obtained from the pool can be deallocated in bulk [SWS_CORE_00065].

use

The virtual member function do_deallocate is declared as protected in the scope of ara::core::UnsynchronizedPoolResource (header #include "ara/core/memory_resource.h") [SWS_CORE_00059]. It handles the synchronous deallocation of a memory block based on the passed parameters p (pointer to the memory area), bytes (size in bytes), and alignment (alignment). Interpretation: As a protected method, the call would typically occur indirectly via the public interface of the memory resource. Question Q-f4992f515c10ee01 (open)

Error handling

Compared to the standard behavior in [mem.res.pool], the function exhibits two specific deviations: It is declared as noexcept and is therefore exception safe [SWS_CORE_00059]. If deallocation fails, errors are silently ignored (errors will be silently ignored); neither an error code nor a separate error message exists.

Concurrency and Limitations

The operation is explicitly designated as not thread-safe (not thread-safe) [SWS_CORE_00059]. If memory areas of the same resource instance are deallocated from multiple threads, access must mandatorily be externally synchronized.

Interaction

The method complements do_allocate [SWS_CORE_00058], which is also specified as noexcept and not thread-safe and returns nullptr on failure. To completely release all reserved memory of the pool, the thread-safe method release is available [SWS_CORE_00065]. Instances of the class are not copyable, as the copy constructor [SWS_CORE_00046] and assignment operator [SWS_CORE_00047] are deleted.

The protected member function do_is_equal of class ara::core::UnsynchronizedPoolResource performs the equality comparison for memory resources according to [SWS_CORE_00060]. It is provided via the header ara/core/memory_resource.h. Since the method has visibility protected, it is intended for internal invocation via the base class MemoryResource ([SWS_CORE_00060]). It synchronously compares the current instance with a passed reference of type MemoryResource and returns a bool value ([SWS_CORE_00060]). According to [mem.res.pool], the comparison is likely to typically check for the identity of both resources (this == &other), as memory pools operate in isolation. Question Q-679a5e17d2e2903f (open)

The method is declared as noexcept and has the specification exception safe ([SWS_CORE_00060]). It throws no exceptions and uses no DET or DEM error messages.

With respect to concurrency, do_is_equal is classified as thread-safe ([SWS_CORE_00060]). Since it operates exclusively read-only as a const member function, it can be called concurrently by multiple threads. This contrasts with allocation operations such as do_allocate ([SWS_CORE_00058]) and do_deallocate ([SWS_CORE_00059]), which are explicitly not thread-safe.

In the interaction of memory resources, the class is neither copyable nor assignable ([SWS_CORE_00046], [SWS_CORE_00047]). Instances can be initialized via constructors such as [SWS_CORE_00063], [SWS_CORE_00064], [SWS_CORE_00067], or [SWS_CORE_00068]. Upstream memory sources can be queried using upstream_resource() ([SWS_CORE_00056]), while prior to destruction ([SWS_CORE_00062]) the allocated memory can be released using release() ([SWS_CORE_00065]).

The destructor ~UnsynchronizedPoolResource() ([SWS_CORE_00062]) terminates the lifetime of an instance of the memory class ara::core::UnsynchronizedPoolResource from header ara/core/memory_resource.h. The call is synchronous and is declared as noexcept, making the operation exception-safe ([SWS_CORE_00062]).

The semantics basically correspond to the pool usage in [mem.res.pool], but exhibit a significant deviation: the destructor is not virtual ([SWS_CORE_00062]). Interpretation: It likely follows from the non-virtuality of the destructor that instances must not be deallocated polymorphically via a base class pointer to MemoryResource. Question Q-5578b2bf008b98c5 (open)

Regarding lifecycle and interplay, the following conditions apply:

• Resource management: When the instance is destroyed, the managed memory is deallocated, analogous to explicit deallocation via release() ([SWS_CORE_00065]) towards the upstream resource ([SWS_CORE_00056]).
• Concurrency: Although the destructor itself is classified as thread-safe ([SWS_CORE_00062]), the internal allocation routines do_allocate ([SWS_CORE_00058]) and do_deallocate ([SWS_CORE_00059]) are designated as not thread-safe. Calling the destructor must therefore not occur concurrently with allocation operations of the same instance.
• Creation and copying: Instances can be constructed with or without options and upstream resource ([SWS_CORE_00063], [SWS_CORE_00064], [SWS_CORE_00067], [SWS_CORE_00068]). Copy construction and copy assignment are deleted ([SWS_CORE_00046], [SWS_CORE_00047]).

The parameterless default constructor [SWS_CORE_00063] initializes an instance of ara::core::UnsynchronizedPoolResource according to the semantics from [mem.res.pool]. Interpretation: In doing so, default pool options and a default upstream memory resource are likely used, which can later be queried via [SWS_CORE_00057] and [SWS_CORE_00056]. Question Q-d76bae1c251fa516 (open)

Regarding lifecycle and usage, the following general conditions apply:

• Copy protection and overloading: Copy constructor [SWS_CORE_00046] and assignment operator [SWS_CORE_00047] are deleted (delete). In addition to parameterless instantiation, overloaded constructors with explicit pool options or upstream resources are available ([SWS_CORE_00064], [SWS_CORE_00067], [SWS_CORE_00068]).
• Error handling and exception safety: The constructor is declared as not exception safe [SWS_CORE_00063]. During subsequent memory operation, the memory operations deviate from standard exceptions: do_allocate returns nullptr instead of an exception in the event of an error [SWS_CORE_00058], while do_deallocate silently ignores errors [SWS_CORE_00059].
• Concurrency: The constructor call itself is thread-safe [SWS_CORE_00063]. However, the subsequent allocation and deallocation operations of the created instance (do_allocate, do_deallocate) are explicitly specified as not thread-safe ([SWS_CORE_00058], [SWS_CORE_00059]).
• Resource deallocation and destruction: Allocated memory can be released via [SWS_CORE_00065]. The destructor is noexcept, but implemented non-virtually [SWS_CORE_00062].

Usage and purpose

The constructor explicit UnsynchronizedPoolResource (MemoryResource *upstream) initializes an instance of class ara::core::UnsynchronizedPoolResource from the header file #include "ara/core/memory_resource.h" according to [mem.res.pool] [SWS_CORE_00064]. Via parameter upstream, the parent memory resource is passed, which can later be queried via method upstream_resource() [SWS_CORE_00056]. A parameterless default constructor [SWS_CORE_00063] as well as overloads with PoolOptions are available as alternatives [SWS_CORE_00067], [SWS_CORE_00068].

Error Handling and Exception Behavior

Instantiation is specified as not exception safe [SWS_CORE_00064], so exceptions may occur during construction. Different rules apply to downstream memory allocations: The internal allocation function do_allocate does not throw an exception, but returns nullptr on failure [SWS_CORE_00058], while errors during do_deallocate are silently ignored [SWS_CORE_00059].

Concurrency and Limitations

The constructor call itself is considered thread-safe [SWS_CORE_00064]. Copy operations are prohibited because both the copy constructor [SWS_CORE_00046] and the assignment operator [SWS_CORE_00047] are deleted. After construction, the allocation and deallocation operations are not thread-safe [SWS_CORE_00058], [SWS_CORE_00059]. In addition, the destructor is declared as non-virtual [SWS_CORE_00062]. Allocated memory can be released prematurely via release() [SWS_CORE_00065]. Interpretation: Since a native pointer upstream is passed, the referenced upstream resource is likely required to remain valid over the entire lifetime of the pool instance. Question Q-3e6c23bae834b912 (open)

use

The member function release() belongs to the scope of class ara::core::UnsynchronizedPoolResource and is declared via the header file ara/core/memory_resource.h [SWS_CORE_00065]. The function has no input parameters and no return value (void). Its functional semantics follow the C++ standard [mem.res.pool] [SWS_CORE_00065]; the reference likely means that the function synchronously returns all memory allocated via the pool instance to the upstream memory resource (upstream_resource()) [SWS_CORE_00056]. Question Q-e0c7e00cde5d5a34 (open)

Error handling

The function is defined as noexcept as well as exception safe [SWS_CORE_00065]. It throws no exceptions during execution. Since the specification does not list any specific error codes or DET/DEM messages, no explicit error feedback via release() occurs in the event of memory deallocation errors.

Concurrency and Limitations

According to the specification, release() is classified as thread-safe [SWS_CORE_00065]. This is in contrast to the internal memory management functions of the class: Both allocation using do_allocate [SWS_CORE_00058] and deallocation via do_deallocate [SWS_CORE_00059] are explicitly classified as not thread-safe.

Interaction

The method interacts closely with other properties and requirements of UnsynchronizedPoolResource:

• Memory resources: It returns the memory to the configured upstream resource [SWS_CORE_00056] without requiring the pool object itself to be destroyed, as occurs with the destructor ~UnsynchronizedPoolResource() [SWS_CORE_00062].
• Configuration: The behavior and chunk sizes of the pool depend on the options set during instantiation [SWS_CORE_00057], [SWS_CORE_00067], [SWS_CORE_00068].
• Copy protection: Duplication of the pool is not permitted, as the copy constructor [SWS_CORE_00046] and assignment operator [SWS_CORE_00047] are deleted (delete).

The constructor [SWS_CORE_00067] initializes an instance of ara::core::UnsynchronizedPoolResource with specific pool options (opts) and an upstream memory resource (upstream). The call is synchronous and specified as noexcept, making object creation exception safe. Copying the instance is excluded, as both the copy constructor [SWS_CORE_00046] and the assignment operator [SWS_CORE_00047] are deleted (=delete).

The configured settings and upstream resources can be retrieved at runtime via options() [SWS_CORE_00057] as well as upstream_resource() [SWS_CORE_00056]. A default constructor [SWS_CORE_00063] as well as overloads that accept only upstream [SWS_CORE_00064] or opts [SWS_CORE_00068] are available as alternatives. The occupied memory can be released via release() [SWS_CORE_00065] or the destructor [SWS_CORE_00062], with the destructor being non-virtual in deviation from the standard.

Regarding concurrency, construction itself is declared thread-safe [SWS_CORE_00067]. The actual memory management functions of the instance—do_allocate [SWS_CORE_00058] and do_deallocate [SWS_CORE_00059]—are however explicitly not thread-safe (“not thread-safe”) and require external protection mechanisms upon concurrent access. Errors are handled without exceptions: Failed allocations return nullptr [SWS_CORE_00058], while deallocation errors are silently ignored [SWS_CORE_00059]. Interpretation: The passed upstream object presumably must remain valid throughout the entire lifecycle of the pool. Question Q-2439ec8f9fb8bb3e (open)

The constructor [SWS_CORE_00068] serves for the synchronous initialization of a ara::core::UnsynchronizedPoolResource specifying specific configuration parameters via the parameter opts (type PoolOptions). The behavior follows the standard [mem.res.pool] from the header file ara/core/memory_resource.h. The passed settings can be retrieved after instantiation with options() [SWS_CORE_00057], while the upstream memory manager is accessible via upstream_resource() [SWS_CORE_00056].

Regarding error handling, the function is specified as "not exception safe" [SWS_CORE_00068]. Interpretation: If the internal provision of management structures fails during instantiation, an exception is likely to be thrown, distinguishing this call from the noexcept variant [SWS_CORE_00067]. Question Q-479a016f4e0ddde7 (open) While the constructor itself is classified as "thread-safe" [SWS_CORE_00068], subsequent memory operations of the resulting instance such as do_allocate [SWS_CORE_00058] and do_deallocate [SWS_CORE_00059] are expressly "not thread-safe"; consequently, they must not be executed concurrently without protection.

In interaction with the lifecycle of the class, it should be noted that copy construction [SWS_CORE_00046] and assignment operator [SWS_CORE_00047] are deleted (delete). Allocated memory remains in the pool until it is released via release() [SWS_CORE_00065] or the object is destroyed via the non-virtual destructor [SWS_CORE_00062].