structure ara::core::PoolOptions

La structure ara::core::PoolOptions sert à configurer des ressources de mémoire basées sur des pools selon std::pmr::pool_options. Elle permet de limiter le nombre maximal de blocs par chunk via max_blocks_per_chunk [SWS_CORE_00027] ainsi que de définir la taille maximale de bloc du pool via largest_required_pool_block [SWS_CORE_00028]. En tant que simple agrégat de données, la structure est renseignée avant l’initialisation de la ressource de mémoire et transmise à son constructeur. Interpretation : comme aucune validation propre n’a lieu, les développeurs doivent s’assurer que les valeurs de seuil configurées ne surchargent pas la mémoire vive physique. Question (ouverte)

plus ›

Contexte

La structure de données ara::core::PoolOptions fournit des paramètres de configuration pour les ressources basées sur des pools de mémoire dans le module core de l’AUTOSAR Adaptive Platform. Elle sert au pilotage ciblé du comportement d’allocation et s’oriente sur la fonctionnalité standard C++ de std::pmr::pool_options. La structure est incluse via l’en-tête <ara/core/memory_resource.h> et interagit étroitement avec les ressources de mémoire de pool, lesquelles maintiennent des chunks et des blocs contigus pour les demandes de mémoire récurrentes.

Dans les systèmes critiques pour la sécurité et proches du temps réel, la limitation et la prévisibilité des opérations de mémoire dynamique sont essentielles. Dans ce contexte, ara::core::PoolOptions joue le rôle d’un découpleur entre les exigences de capacité spécifiques à l’application et la gestion interne des pools de mémoire. Grâce à cette structure, les développeurs peuvent définir le nombre maximal de blocs pouvant être regroupés au sein d’un chunk [SWS_CORE_00027] ainsi que la taille maximale de bloc devant encore être traitée par les pools spécialisés [SWS_CORE_00028]. Les logiciels applicatifs qui instancient des ressources de mémoire utilisent ces options pour éviter une fragmentation excessive et contrôler les limites d’allocation de manière déterministe.

Cycle de vie

En tant que type de configuration simple (struct), ara::core::PoolOptions possède un cycle de vie léger sans transitions d’état internes complexes. La création s’effectue typiquement sous la forme d’un objet local sur la pile ou d’une constante de configuration statique avant l’instanciation de la ressource de mémoire associée. Lors de l’instanciation, les deux attributs max_blocks_per_chunk [SWS_CORE_00027] et largest_required_pool_block [SWS_CORE_00028] sont initialisés par défaut avec la valeur 0.

Interpretation : une valeur de 0 devrait signaler à la ressource de mémoire réceptrice que les limites standard spécifiques à la plateforme doivent s’appliquer. Question (ouverte) Comme il s’agit d’un pur objet valeur, ara::core::PoolOptions ne détient aucune ressource au sens du RAII et n’exécute aucune action de nettoyage lors de sa destruction. Le cycle de vie de la structure est habituellement couplé à la phase de création de la ressource de mémoire : dès que les options ont été transmises à la ressource de pool, la ressource conserve les paramètres en interne, de sorte que l’objet PoolOptions lui-même peut être détruit ou réutilisé sans danger.

En ce qui concerne la concurrence, la structure elle-même ne propose aucun mécanisme de synchronisation inhérent. Les accès concurrents en lecture à un objet PoolOptions non modifié sont sûrs du point de vue des threads, tandis que les modifications simultanées doivent être synchronisées de manière externe. Cependant, comme l’objet est principalement configuré avant sa transmission, aucun accès en écriture n’a généralement lieu après l’initialisation.

Parcours d'utilisation

Le cas d’usage principal comprend la définition des limites d’allocation et leur transmission à un composant de gestion de la mémoire. Tout d’abord, l’appelant crée une instance de ara::core::PoolOptions et renseigne les paramètres souhaités. La borne supérieure pour les blocs par chunk est fixée via max_blocks_per_chunk [SWS_CORE_00027], tandis que largest_required_pool_block définit la limite supérieure pour les allocations qui doivent encore être couvertes par le pool [SWS_CORE_00028].

Ensuite, la structure renseignée est transmise au constructeur d’une ressource de mémoire de pool correspondante. La ressource de mémoire lit les valeurs configurées et configure ses pools internes en conséquence. Si des demandes de mémoire surviennent en cours de fonctionnement, la ressource décide, sur la base des valeurs de seuil précédemment configurées, si la demande peut être servie à partir d’un pool ou si elle doit être transmise à une ressource amont de niveau supérieur. Interpretation : il faut partir du principe que les demandes dépassant largest_required_pool_block sont typiquement déléguées directement au gestionnaire de mémoire de niveau supérieur. Question (ouverte)

Diagramme de séquence : déroulement typique de la configuration d’une ressource de mémoire de pool via PoolOptions. Sources : [SWS_CORE_00027], [SWS_CORE_00028].

Scénarios d'erreur

Comme ara::core::PoolOptions est défini comme un simple agrégat de données (struct), la création ou l’affectation des champs ne lève aucune exception C++ et ne renvoie aucun code d’erreur. Les conditions d’erreur potentielles n’apparaissent que lors de l’interprétation des valeurs par la ressource de mémoire réceptrice.

Interpretation : si des valeurs irréalistes sont configurées — par exemple une valeur extrêmement grande pour max_blocks_per_chunk [SWS_CORE_00027] ou pour largest_required_pool_block [SWS_CORE_00028] —, cela peut amener la ressource de mémoire sous-jacente à atteindre les limites du système lors de l’allocation de chunks et à déclencher des états d’épuisement de la mémoire (out-of-memory). Question (ouverte) La condition préalable à un fonctionnement stable est donc un ajustement minutieux des deux paramètres à la mémoire vive physiquement disponible et au profil de charge attendu de l’application. Si les valeurs restent à 0, il incombe à la ressource cible d’utiliser des tailles par défaut robustes.