Fournit une ressource mémoire de pool sûre pour les threads pour l’allocation et la libération efficaces de blocs de mémoire.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 8c6c1308f3f6ProvenanceQuestions ouvertes (3)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
Fournit une ressource mémoire de pool sûre pour les threads pour l’allocation et la libération efficaces de blocs de mémoire.
La classe ara::core::SynchronizedPoolResource fournit une ressource mémoire sûre pour les threads, qui gère les allocations via des pools internes et demande de la mémoire supplémentaire auprès d’une ressource amont de niveau supérieur ([SWS_CORE_00030]). Contrairement au standard C++, l’allocation de mémoire ne lève pas d’exception en cas d’échec, mais renvoie à la place nullptr ([SWS_CORE_00061]). Les opérations de copie sont totalement interdites, tandis que les opérations de déplacement sont explicitement prises en charge. De plus, le destructeur n’est pas virtuel, raison pour laquelle les instances ne doivent pas être libérées de manière polymorphe via un pointeur de classe de base.
Contexte
La classe ara::core::SynchronizedPoolResource fournit une ressource mémoire sûre pour les threads pour l’AUTOSAR Adaptive Platform au sein du module core. Elle repose sur le concept de std::pmr::synchronized_pool_resource selon le standard C++ [mem.res.pool] et dérive publiquement de la classe de base MemoryResource. Sa tâche principale consiste à gérer des blocs de mémoire via des pools internes par classes de taille, afin de traiter des allocations récurrentes de façon efficace et concurrente. Si la réserve interne est insuffisante, l’instance obtient des blocs de mémoire plus grands auprès d’une ressource mémoire amont de niveau supérieur ([SWS_CORE_00038]).
Parmi les partenaires d’interaction typiques figurent des threads concurrents d’une application qui demandent des allocations, la SynchronizedPoolResource en tant que gestionnaire de pool intermédiaire, ainsi qu’une MemoryResource sous-jacente en tant que source amont. Toutes les fonctions centrales d’accès et de gestion telles que do_allocate, do_deallocate, options et release sont conçues pour être sûres pour les threads ([SWS_CORE_00061], [SWS_CORE_00041], [SWS_CORE_00039], [SWS_CORE_00037]).
Diagramme de contexte : interaction entre threads d’application concurrents, la ressource de pool et la source de mémoire amont. Sources : [SWS_CORE_00030], [SWS_CORE_00038].
Cycle de vie
L’instanciation de SynchronizedPoolResource peut s’effectuer via plusieurs surcharges de constructeur. Si des options d’allocation (PoolOptions) ainsi qu’une ressource amont sont disponibles, l’initialisation garantit une sécurité d’exception complète et est déclarée comme noexcept ([SWS_CORE_00030]). En outre, il existe des constructeurs sans paramètre ([SWS_CORE_00031]), avec un pointeur amont unique ([SWS_CORE_00032]) ou avec de simples options de pool ([SWS_CORE_00033]). Interprétation : si aucun pointeur amont n’est transmis, l’implémentation a probablement recours à une ressource mémoire standard spécifique à la plateforme. Question Q-5dafb414672249dc (ouverte)
Concernant les relations de possession, la classe exclut strictement la copie : le constructeur de copie ([SWS_CORE_00034]) tout comme l’opérateur d’assignation par copie ([SWS_CORE_00036]) sont supprimés (=delete). Contrairement au standard ISO C++17, AUTOSAR définit toutefois explicitement une sémantique de déplacement pour cette classe : un constructeur de déplacement ([SWS_CORE_00043]) et un opérateur d’assignation par déplacement ([SWS_CORE_00044]) sont chacun disponibles sous forme de noexcept=default.
Un aspect central de la destruction réside dans la divergence par rapport au comportement standard : le destructeur ~SynchronizedPoolResource() est explicitement non virtuel ([SWS_CORE_00035]). Interprétation : comme le destructeur n’est pas virtuel, une destruction polymorphe via un pointeur de la classe de base MemoryResource* devrait conduire à un comportement indéfini ; les instances doivent donc toujours être détruites via leur type concret. Question Q-5add73880279b024 (ouverte) L’appel de release() permet en outre de restituer l’intégralité de la mémoire allouée à la ressource amont, tandis que l’objet ressource reste intact ([SWS_CORE_00037]).
Parcours d'utilisation
Le déroulement typique comprend l’initialisation, l’allocation et la libération répétées de blocs de mémoire ainsi que le nettoyage final :
Initialisation : l’application crée l’instance en indiquant des paramètres de configuration et une ressource mémoire de niveau supérieur ([SWS_CORE_00030]). Les paramètres actifs peuvent être interrogés via options() ([SWS_CORE_00039]), le pointeur amont via upstream_resource() ([SWS_CORE_00038]).
Allocation de mémoire : les demandes de mémoire sont traitées de manière protégée via do_allocate ([SWS_CORE_00061]). Interprétation : l’appel dans le code d’application ne s’effectue généralement pas directement via la méthode protégée do_allocate, mais via l’interface publique héritée allocate de la classe de base MemoryResource. Question Q-1542a47cdff73dfb (ouverte)
Contrôle d’identité :do_is_equal permet de déterminer si deux ressources mémoire sont équivalentes entre elles ([SWS_CORE_00042]).
Libération : les zones de mémoire individuelles sont renvoyées au pool via do_deallocate ([SWS_CORE_00041]). Si nécessaire, toute la mémoire de tous les pools peut être restituée de manière groupée à la ressource amont via release() ([SWS_CORE_00037]).
L’AUTOSAR Adaptive Platform s’écarte délibérément des conventions d’exception du standard C++ pour la gestion des erreurs :
Erreur d’allocation : alors qu’ISO C++ prévoit la levée de std::bad_alloc en cas d’épuisement, do_allocate est défini dans AUTOSAR comme noexcept. Si aucun bloc de mémoire approprié ne peut être fourni, la méthode renvoie obligatoirement à la place un pointeur nul (nullptr) ([SWS_CORE_00061]). Les appelants doivent donc vérifier chaque valeur de retour d’allocation par rapport à nullptr.
Erreur de désallocation : la méthode do_deallocate est également noexcept. Si une erreur survient lors de la restitution d’un bloc de mémoire, celle-ci est silencieusement ignorée selon la spécification ([SWS_CORE_00041]).
Risques de construction : alors que le constructeur avec options et ressource amont est sûr vis-à-vis des exceptions ([SWS_CORE_00030]), les constructeurs sans indication amont ou sans options sont classifiés comme non sûrs vis-à-vis des exceptions (« not exception safe ») ([SWS_CORE_00031], [SWS_CORE_00032], [SWS_CORE_00033]). Interprétation : si la mise à disposition interne des structures de gestion de pool échoue pour ces constructeurs, la création de l’objet peut échouer. Question (ouverte)
Ce guide de classe résume la spécification d’ara::core::SynchronizedPoolResource pour AUTOSAR Adaptive Release R25-11.
except for the following deviations: 1. The function is noexcept 2. The function returns nullptr instead of (potentially) throwing a std::bad_alloc exception ≙ std::bad_alloc
As per corresponding usage in [mem.res.pool] except for the following deviations: 1. The function is noexcept 2. The function returns nullptr instead of (potentially) throwing a std::bad_alloc exception
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : d6b2e58cc49aProvenanceQuestions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
Utilisation et sémantique d'allocation
La fonction membre do_allocate de la classe ara::core::SynchronizedPoolResource issue du fichier d'en-tête #include "ara/core/memory_resource.h" sert à l'allocation de zones de mémoire avec la taille en octets bytes et l'alignement alignment spécifiés [SWS_CORE_00061]. En cas de succès, l'appel synchrone renvoie conformément à [mem.res.pool] un pointeur valide du type void* vers le bloc de mémoire alloué [SWS_CORE_00061].
Traitement des erreurs et déviations
En ce qui concerne le comportement face aux erreurs, l'implémentation dévie explicitement des exigences de [mem.res.pool] : la méthode est déclarée comme noexcept et ne lève aucune exception std::bad_alloc[SWS_CORE_00061]. En cas d'échec de la demande d'allocation, le pointeur renvoyé est au contraire impérativement nullptr[SWS_CORE_00061]. Les appelants doivent par conséquent obligatoirement vérifier si la valeur de retour est un pointeur nul afin d'intercepter de manière fiable les erreurs d'allocation.
Concurrence et interaction
La fonction est spécifiée comme exception safe et, contrairement à d'autres ressources mémoire, comme thread-safe[SWS_CORE_00061]. En raison de sa visibilité protected, elle devrait principalement faire office en pratique de redéfinition interne de l'interface de base purement virtuelle do_allocate issue de ara::core::MemoryResource[SWS_CORE_06566]. Question Q-95ba181693426bfc (ouverte) Tandis que ara::core::SynchronizedPoolResource sécurise l'accès concurrentiel [SWS_CORE_00061], des implémentations comparables comme ara::core::UnsynchronizedPoolResource::do_allocate[SWS_CORE_00058] et ara::core::MonotonicBufferResource::do_allocate[SWS_CORE_06569] sont définies comme not thread-safe.
Ce texte a été généré par un système d'IA sur la base de la spécification AUTOSAR Adaptive R25-11.
As per corresponding usage in [mem.res.pool] except for the following deviations: 1. The function is noexcept 2. If unsuccessful: errors will be silently ignored
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : b07cac0de0a1ProvenanceQuestions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
La fonction membre protégée do_deallocate de la classe ara::core::SynchronizedPoolResource sert à libérer une zone mémoire préalablement allouée conformément à [SWS_CORE_00041]. Son appel s'effectue de manière synchrone et attend comme paramètres un pointeur p vers la zone mémoire, la taille bytes en octets ainsi que l'alignement de mémoire alignment. Étant donné que la fonction membre est déclarée avec la visibilité protected, elle n'est probablement pas appelée directement dans le code d'application normal, mais exécutée via l'interface publique de désallocation de la classe de base supérieure ara::core::MemoryResource ([SWS_CORE_06567]). Question Q-badea921c907c214 (ouverte)
Concernant le traitement des erreurs et le comportement vis-à-vis des exceptions, la spécification définit deux déviations obligatoires par rapport au standard :
La fonction est déclarée comme noexcept et est totalement sûre vis-à-vis des exceptions (exception safe) ([SWS_CORE_00041]).
Si la désallocation ne devait pas réussir, les erreurs survenues sont ignorées silencieusement ([SWS_CORE_00041]). Il n'y a ni levée d'une exception ni renvoi d'un code d'erreur.
Dans le domaine de la concurrence, l'implémentation dans ara::core::SynchronizedPoolResource se distingue par le fait qu'elle est explicitement spécifiée comme thread-safe (thread-safe) ([SWS_CORE_00041]). Elle est ainsi adaptée à un appel concurrentiel depuis plusieurs threads. En cela, elle se distingue fondamentalement des ressources apparentées ara::core::UnsynchronizedPoolResource ([SWS_CORE_00059]) et ara::core::MonotonicBufferResource ([SWS_CORE_06570]), qui sont classées comme non thread-safe.
Ce texte a été généré par une IA sur la base de la spécification AUTOSAR R25-11.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : c89ab0c97360ProvenanceQuestions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
La fonction membre protégée do_is_equal vérifie l'égalité d'une instance de ara::core::SynchronizedPoolResource avec une autre ressource mémoire [SWS_CORE_00042]. Elle surcharge la méthode purement virtuelle de la classe de base issue de ara::core::MemoryResource[SWS_CORE_06568] conformément à la spécification des ressources de pool dans [mem.res.pool].
Utilisation et interface : Une référence vers un autre objet ara::core::MemoryResource est transmise en paramètre (const MemoryResource &other). La valeur de retour de type bool indique si les deux ressources sont équivalentes. Interprétation : en raison de la visibilité protected, la fonction n'est pas appelée directement dans le flux applicatif régulier, mais est exécutée via la méthode de comparaison publique de la classe de base. Question Q-29fb2980d1241fae (ouverte)
Traitement des erreurs et sécurité : La méthode est déclarée avec l'identifiant noexcept et spécifiée comme exception safe[SWS_CORE_00042]. Ni exceptions ni codes d'erreur spécifiques ne surviennent. L'exécution est synchrone.
Concurrence : Conformément à [SWS_CORE_00042], do_is_equal est spécifié comme thread-safe, de sorte que des comparaisons simultanées sur plusieurs threads sont autorisées sans synchronisation externe supplémentaire.
Interaction : La fonction constitue le pendant thread-safe de l'implémentation dans ara::core::UnsynchronizedPoolResource[SWS_CORE_00060]. De même, ara::core::MonotonicBufferResource fournit une surcharge correspondante, qui est également désignée comme noexcept[SWS_CORE_06571].
Ce texte a été généré par une IA sur la base de la spécification AUTOSAR Adaptive R25-11.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 4714ac548826ProvenanceQuestions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
La fonction membre options de la classe ara::core::SynchronizedPoolResource renvoie de manière synchrone les paramètres de type PoolOptions configurés pour la ressource mémoire [SWS_CORE_00039]. L'appel s'effectue sans paramètre sur une instance de la classe et est déclaré via l'en-tête ara/core/memory_resource.h[SWS_CORE_00039]. Selon la spécification, le comportement s'oriente sur [mem.res.pool][SWS_CORE_00039], ce qui peut être interprété comme une référence aux ressources de pool de la norme C++. Question Q-9abfddc2cf8dc88c (ouverte)
En matière de traitement des erreurs et de sécurité vis-à-vis des exceptions, la méthode est déclarée comme noexcept et considérée comme entièrement sûre vis-à-vis des exceptions (exception safe) [SWS_CORE_00039]. Aucun code d'erreur spécifique ni message à destination de DET ou DEM n'existe pour cette fonction d'interrogation.
Concernant la concurrence, la méthode est spécifiée comme const ainsi qu'expressément comme sûre pour les threads (thread-safe) [SWS_CORE_00039]. Elle peut donc être appelée en parallèle et en toute sécurité à partir de plusieurs threads sans mesure de synchronisation supplémentaire au niveau de l'utilisateur.
Dans le cadre de l'interaction au sein de ara::core, [SWS_CORE_00057] fournit l'équivalent non synchronisé : pour ara::core::UnsynchronizedPoolResource, il existe une fonction options de même nom et de même signature avec une sémantique identique conformément à [mem.res.pool].
Ce texte a été généré par une IA et sert d'aide d'orientation à l'utilisation.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 32c426df4959ProvenanceQuestions ouvertes (1)
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
La fonction membre synchrone release() appartient à la classe ara::core::SynchronizedPoolResource et est fournie via le fichier d'en-tête #include "ara/core/memory_resource.h"[SWS_CORE_00037]. Elle possède la signature void release () noexcept;, ne prend aucun paramètre et n'a aucune valeur de retour. La sémantique fonctionnelle se conforme à l'utilisation correspondante dans [mem.res.pool][SWS_CORE_00037], libérant ainsi la mémoire gérée par la ressource mémoire.
Concernant le traitement des erreurs, la fonction est déclarée comme sûre face aux exceptions (exception safe) et noexcept[SWS_CORE_00037]. Aucune exception C++ ne se produit ; les codes d'erreur spécifiques ou les rapports d'erreurs via DET ou DEM ne sont pas définis dans le cadre de la spécification.
En ce qui concerne la concurrence, l'opération est explicitement spécifiée comme sûre au niveau des threads (thread-safe) [SWS_CORE_00037]. Un appel simultané depuis plusieurs threads sur la même instance de ressource devrait donc être autorisé sans verrous supplémentaires côté application. Question Q-3da3b45ca2070b3e (ouverte)
En interaction, le comportement de la méthode fonctionnellement identique dans ara::core::UnsynchronizedPoolResource[SWS_CORE_00065], qui référence également [mem.res.pool] et est désignée comme noexcept ainsi que thread-safe, correspond à cela. En revanche, la fonction release() analogue de ara::core::MonotonicBufferResource[SWS_CORE_06530] n'est pas thread-safe (not thread-safe) selon la spécification, bien qu'elle soit également soumise à la garantie noexcept.
Ce texte a été créé par une IA et se base exclusivement sur les données de spécification d'AUTOSAR R25-11.
GÉNÉRÉ PAR IAnon vérifiéModèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 6f69b7b33ad7Provenance
traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand
Utilisation
La fonction membre upstream_resource() de la classe ara::core::SynchronizedPoolResource renvoie un pointeur vers la ressource mémoire sous-jacente en amont (MemoryResource*) conformément à [SWS_CORE_00038]. L'appel s'effectue de manière synchrone et nécessite l'inclusion du fichier d'en-tête #include "ara/core/memory_resource.h"[SWS_CORE_00038]. La fonction ne prend aucun paramètre d'entrée et sert de simple inspecteur pour l'unité supérieure de gestion de la mémoire.
Gestion des erreurs et sécurité vis-à-vis des exceptions
La méthode est déclarée comme noexcept et classée conformément à la spécification comme sûre vis-à-vis des exceptions (exception safe) [SWS_CORE_00038]. Un échec de l'interrogation ou le déclenchement d'exceptions est exclu ; il n'existe pas de codes d'erreur pour cet appel.
Concurrence et restrictions
La fonction est spécifiée comme const ainsi qu'explicitement comme sûre pour les threads (thread-safe) [SWS_CORE_00038]. Elle peut ainsi être appelée simultanément depuis plusieurs contextes d'exécution sans synchronisation externe supplémentaire.
Interaction
Le concept d'une ressource mémoire en amont est mis à disposition de façon cohérente à travers différentes implémentations de pools de mémoire d'AUTOSAR Adaptive Core :
Dans ara::core::UnsynchronizedPoolResource, la méthode fonctionnellement identique [SWS_CORE_00056] fournit également un pointeur vers la ressource en amont, mais s'adresse à des scénarios de pools non synchronisés de manière interne.
Dans ara::core::MonotonicBufferResource, il existe avec [SWS_CORE_06531] un pendant correspondant, qui est également spécifié comme noexcept ainsi que thread-safe.
Cette note d'utilisation a été générée automatiquement à partir du payload AUTOSAR.
gemini-3.8-flash-low· 2026-10-13 · Original allemand