classe ara::core::UnsynchronizedPoolResource

La déclaration du constructeur de copie comme supprimé (=delete) dans ara::core::UnsynchronizedPoolResource selon [SWS_CORE_00046] empêche toute duplication d'une instance de pool. Pour la création d'objets, des constructeurs spécifiques sont disponibles à la place, par exemple sans arguments [SWS_CORE_00063], avec indication d'une ressource mémoire en amont [SWS_CORE_00064], avec PoolOptions [SWS_CORE_00068] ou avec les deux paramètres [SWS_CORE_00067].

Les conditions-cadres suivantes s'appliquent à l'utilisation et au comportement à l'exécution :

• Appel et traitement des erreurs : une tentative de copie est rejetée comme une erreur dès la compilation par le compilateur. Les erreurs d'allocation lors de l'utilisation ultérieure de la mémoire via do_allocate n'entraînent pas d'exceptions, mais renvoient nullptr [SWS_CORE_00058], tandis que les erreurs de libération dans do_deallocate sont silencieusement ignorées [SWS_CORE_00059].
• Concurrence : les opérations de mémoire individuelles sur l'instance sont déclarées non sûres pour les threads [SWS_CORE_00058], [SWS_CORE_00059]. Interprétation : la suppression du constructeur de copie devrait assurer la responsabilité exclusive des blocs de mémoire gérés et éviter des états incohérents lors d'une utilisation parallèle ou d'une libération anticipée via release [SWS_CORE_00065]. Question Q-d97dd87dddb2379d (ouverte)
• Interaction : la restriction correspond à l'opérateur d'assignation [SWS_CORE_00047], également supprimé. Le destructeur de la classe n'est pas virtuel [SWS_CORE_00062], tandis que des vérifications d'identité peuvent être effectuées via do_is_equal [SWS_CORE_00060].

L'opérateur d'affectation par copie de ara::core::UnsynchronizedPoolResource est explicitement déclaré comme supprimé (=delete) conformément à [SWS_CORE_00047]. L'affectation d'une instance à une autre est ainsi syntaxiquement exclue et conduit dès la compilation à une erreur de compilation. Conjointement avec le constructeur de copie [SWS_CORE_00046], lui aussi supprimé, cela garantit que les instances de la classe de ressources ne peuvent être ni copiées ni dupliquées par affectation. Interprétation : ceci devrait empêcher que des blocs de mémoire internes et des informations de gestion ne soient référencés plusieurs fois ou désalloués de manière erronée. Question Q-75cee08bebc61976 (ouverte)

Les nouvelles instances sont créées à la place via les constructeurs fournis, par exemple sans paramètre via [SWS_CORE_00063], avec une ressource amont via [SWS_CORE_00064] ou en indiquant PoolOptions via [SWS_CORE_00067] ou [SWS_CORE_00068]. La ressource amont liée peut être interrogée via [SWS_CORE_00056] et les options de configuration via [SWS_CORE_00057]. La mémoire gérée peut être explicitement libérée avec [SWS_CORE_00065] avant que la durée de vie ne prenne fin avec le destructeur non virtuel [SWS_CORE_00062].

Les affectations étant exclues par [SWS_CORE_00047], les instances doivent être transmises par référence ou par pointeur si nécessaire. Il convient de noter ici que les allocations via [SWS_CORE_00058] et les désallocations via [SWS_CORE_00059] sont spécifiées comme non sûres pour les threads. Si une demande de mémoire échoue, aucune exception n'est levée, mais nullptr est renvoyé [SWS_CORE_00058] ; les erreurs lors de la désallocation sont ignorées silencieusement [SWS_CORE_00059].

Utilisation

La méthode upstream_resource() de la classe ara::core::UnsynchronizedPoolResource renvoie de manière synchrone un pointeur vers la MemoryResource parente [SWS_CORE_00056]. L'appel est sans paramètre et déclaré comme const. L'inclusion et les déclarations de types s'effectuent via le fichier d'en-tête #include "ara/core/memory_resource.h" [SWS_CORE_00056].

Gestion des erreurs

La fonction est spécifiée comme noexcept ainsi que exception safe [SWS_CORE_00056]. Elle ne lève aucune exception et ne signale ni codes d'erreur spécifiques ni événements DET ou DEM. Si l'initialisation préalable via des constructeurs échoue, ceux-ci ne sont en partie pas sûrs vis-à-vis des exceptions [SWS_CORE_00063], tandis que l'interrogation elle-même reste toujours exempte d'erreurs.

Concurrence et restrictions

La méthode upstream_resource() est explicitement classée comme thread-safe [SWS_CORE_00056]. Cela contraste avec les routines d'allocation internes do_allocate() [SWS_CORE_00058] et do_deallocate() [SWS_CORE_00059], qui sont spécifiées comme not thread-safe. De plus, le constructeur de copie et l'opérateur d'affectation de la classe sont supprimés [SWS_CORE_00046], [SWS_CORE_00047].

Interaction

La méthode interagit étroitement avec les constructeurs de UnsynchronizedPoolResource, auxquels une MemoryResource parente peut éventuellement être transmise [SWS_CORE_00064], [SWS_CORE_00067]. Interprétation : le pointeur renvoyé devrait pointer précisément vers l'instance de MemoryResource définie lors de l'instanciation. Question Q-aefbc7d0f7d085d1 (ouverte) D'autres propriétés de la ressource de pool peuvent être interrogées via options() [SWS_CORE_00057], tandis que la mémoire allouée peut être libérée via release() [SWS_CORE_00065].

Utilisation

La fonction membre options() de la classe ara::core::UnsynchronizedPoolResource sert à interroger de manière synchrone la configuration du pool de mémoire [SWS_CORE_00057]. La méthode est déclarée dans #include "ara/core/memory_resource.h", n'attend aucun paramètre d'entrée et renvoie une instance du type PoolOptions par valeur [SWS_CORE_00057]. En tant que fonction qualifiée const, elle ne modifie pas l'objet et se comporte conformément à la spécification dans [mem.res.pool] [SWS_CORE_00057].

Gestion des erreurs et sécurité vis-à-vis des exceptions

L'interface est définie comme noexcept et garantit une sécurité totale face aux exceptions (exception safe) [SWS_CORE_00057]. Aucune exception n'est levée et il n'existe aucune valeur de retour d'erreur ; la récupération des options réussit toujours sans erreur.

Concurrence et restrictions

Dans la spécification, options() est désignée comme sûre pour les threads (thread-safe) [SWS_CORE_00057]. Cela contraste avec les fonctions d'allocation de la même classe telles que do_allocate [SWS_CORE_00058] et do_deallocate [SWS_CORE_00059], qui ne sont explicitement pas sûres pour les threads. La méthode peut donc être exécutée de manière concurrente pour interroger l'état.

Interaction

Les PoolOptions renvoyées reflètent probablement les paramètres avec lesquels la ressource de pool a été paramétrée via les constructeurs correspondants [SWS_CORE_00067], [SWS_CORE_00068], ou représentent les options par défaut lors de l'utilisation de constructeurs par défaut [SWS_CORE_00063], [SWS_CORE_00064]. Question Q-19fa8ad6e3e6b1c6 (ouverte) En plus de options(), la fonction upstream_resource() est également disponible pour l'inspection [SWS_CORE_00056], tandis que les opérations de copie de la ressource sont empêchées par des opérateurs supprimés [SWS_CORE_00046], [SWS_CORE_00047].

Utilisation

La méthode do_allocate de la classe ara::core::UnsynchronizedPoolResource alloue de la mémoire pour la taille en octets (bytes) et l'alignement (alignment) demandés [SWS_CORE_00058]. Interprétation : la méthode étant spécifiée avec une visibilité protégée (protected), elle ne devrait pas, en fonctionnement normal, être appelée directement par le code applicatif, mais indirectement via l'interface d'allocation de la classe de base. Question Q-5a702813496f8071 (ouverte) La déclaration s'effectue via le fichier d'en-tête #include "ara/core/memory_resource.h" [SWS_CORE_00058].

Gestion des erreurs

À la différence du comportement standard selon [mem.res.pool], la fonction est déclarée comme noexcept et ne lève aucune exception telle que std::bad_alloc [SWS_CORE_00058] lors d'erreurs d'allocation. Au lieu de cela, elle renvoie impérativement nullptr en cas d'échec [SWS_CORE_00058]. Le code appelant doit par conséquent toujours vérifier explicitement si le résultat est un pointeur nul.

Concurrence et restrictions

La fonction est classée comme not thread-safe [SWS_CORE_00058]. Les appels parallèles sur la même instance de UnsynchronizedPoolResource ne sont pas autorisés sans synchronisation externe. Le constructeur de copie et l'opérateur d'assignation de la classe sont supprimés (delete), de sorte que les instances ne peuvent pas être copiées ([SWS_CORE_00046], [SWS_CORE_00047]).

Interaction

Pour la libération de mémoire, il existe le pendant do_deallocate, qui est également conçu comme protégé, noexcept et non sûr pour les threads, et qui ignore silencieusement les erreurs [SWS_CORE_00059]. Le pool utilise en interne la ressource en amont configurée lors de l'instanciation ([SWS_CORE_00056], [SWS_CORE_00064], [SWS_CORE_00067]). Avec release(), la mémoire obtenue à partir du pool peut être libérée de manière groupée [SWS_CORE_00065].

Utilisation

La fonction membre virtuelle do_deallocate est déclarée comme protected dans la portée de ara::core::UnsynchronizedPoolResource (en-tête #include "ara/core/memory_resource.h") [SWS_CORE_00059]. Elle prend en charge la désallocation synchrone d'un bloc de mémoire sur la base des paramètres transmis p (pointeur vers la zone de mémoire), bytes (taille en octets) et alignment (alignement). Interprétation : en tant que méthode protégée, l'appel devrait typiquement s'effectuer indirectement via l'interface publique de la ressource mémoire. Question Q-f4992f515c10ee01 (ouverte)

Gestion des erreurs

Par rapport au comportement standard dans [mem.res.pool], la fonction présente deux divergences spécifiques : elle est déclarée comme noexcept et donc sûre vis-à-vis des exceptions [SWS_CORE_00059]. Si la désallocation échoue, les erreurs sont ignorées silencieusement (errors will be silently ignored) ; il n'existe ni code d'erreur ni message d'erreur distinct.

Concurrence et restrictions

L'opération est explicitement désignée comme non sûre pour les threads (not thread-safe) [SWS_CORE_00059]. Si des zones de mémoire de la même instance de ressource sont libérées depuis plusieurs threads, l'accès doit impérativement être synchronisé de manière externe.

Interaction

La méthode complète do_allocate [SWS_CORE_00058], qui est également spécifiée comme noexcept et non sûre pour les threads et renvoie nullptr en cas d'échec. Afin de libérer entièrement toute la mémoire réservée du pool, la méthode sûre pour les threads release est mise à disposition [SWS_CORE_00065]. Les instances de la classe ne sont pas copiables, car le constructeur de copie [SWS_CORE_00046] et l'opérateur d'assignation [SWS_CORE_00047] sont supprimés.

La fonction membre protégée do_is_equal de la classe ara::core::UnsynchronizedPoolResource effectue la comparaison d'égalité pour les ressources mémoire conformément à [SWS_CORE_00060]. Elle est fournie via l'en-tête ara/core/memory_resource.h. Comme la méthode possède la visibilité protected, elle est prévue pour un appel interne via la classe de base MemoryResource ([SWS_CORE_00060]). Elle compare de manière synchrone l'instance actuelle avec une référence transmise de type MemoryResource et renvoie une valeur bool ([SWS_CORE_00060]). Conformément à [mem.res.pool], la comparaison devrait vérifier typiquement l'identité des deux ressources (this == &other), car les pools de mémoire agissent de manière isolée. Question Q-679a5e17d2e2903f (ouverte)

La méthode est déclarée comme noexcept et possède la spécification exception safe ([SWS_CORE_00060]). Elle ne lève aucune exception et n'utilise pas de messages d'erreur DET ou DEM.

En ce qui concerne la concurrence, do_is_equal est classée comme thread-safe ([SWS_CORE_00060]). Comme elle fonctionne exclusivement en lecture en tant que fonction membre constante, elle peut être appelée de manière concurrente par plusieurs threads. Cela s'oppose aux opérations d'allocation telles que do_allocate ([SWS_CORE_00058]) et do_deallocate ([SWS_CORE_00059]), qui ne sont explicitement pas sûres au niveau des threads.

Dans l'interaction des ressources mémoire, la classe ne peut être ni copiée ni assignée ([SWS_CORE_00046], [SWS_CORE_00047]). Les instances peuvent être initialisées via des constructeurs tels que [SWS_CORE_00063], [SWS_CORE_00064], [SWS_CORE_00067] ou [SWS_CORE_00068]. Les sources de mémoire de niveau supérieur peuvent être interrogées avec upstream_resource() ([SWS_CORE_00056]), tandis qu'avant la destruction ([SWS_CORE_00062]), la mémoire allouée peut être libérée au moyen de release() ([SWS_CORE_00065]).

Le destructeur ~UnsynchronizedPoolResource() ([SWS_CORE_00062]) met fin à la durée de vie d'une instance de la classe de mémoire ara::core::UnsynchronizedPoolResource issue de l'en-tête ara/core/memory_resource.h. L'appel s'effectue de manière synchrone et est déclaré comme noexcept, ce qui rend l'opération sûre vis-à-vis des exceptions ([SWS_CORE_00062]).

La sémantique correspond fondamentalement à l'utilisation du pool dans [mem.res.pool], mais présente une divergence essentielle : le destructeur n'est pas virtuel ([SWS_CORE_00062]). Interprétation : de la non-virtualité du destructeur, il devrait découler que les instances ne doivent pas être libérées de manière polymorphe via un pointeur de classe de base vers MemoryResource. Question Q-5578b2bf008b98c5 (ouverte)

En ce qui concerne le cycle de vie et l'interaction, les conditions suivantes s'appliquent :

• Gestion des ressources : lors de la destruction de l'instance, la mémoire gérée est libérée, de manière analogue à la libération explicite via release() ([SWS_CORE_00065]) vers la ressource parente ([SWS_CORE_00056]).
• Concurrence : bien que le destructeur lui-même soit classé comme thread-safe ([SWS_CORE_00062]), les routines d'allocation internes do_allocate ([SWS_CORE_00058]) et do_deallocate ([SWS_CORE_00059]) sont désignées comme non thread-safe. L'appel du destructeur ne doit donc pas avoir lieu simultanément avec des opérations d'allocation de la même instance.
• Création et copie : les instances peuvent être construites avec ou sans options et ressource amont ([SWS_CORE_00063], [SWS_CORE_00064], [SWS_CORE_00067], [SWS_CORE_00068]). Le constructeur de copie et l'affectation par copie sont supprimés ([SWS_CORE_00046], [SWS_CORE_00047]).

Le constructeur par défaut sans paramètre [SWS_CORE_00063] initialise une instance de ara::core::UnsynchronizedPoolResource conformément à la sémantique de [mem.res.pool]. Interprétation : des options de pool par défaut et une ressource mémoire amont par défaut devraient alors être utilisées, lesquelles peuvent être interrogées ultérieurement via [SWS_CORE_00057] et [SWS_CORE_00056]. Question Q-d76bae1c251fa516 (ouverte)

En ce qui concerne le cycle de vie et l'utilisation, les conditions-cadres suivantes s'appliquent :

• Protection contre la copie et surcharge : le constructeur de copie [SWS_CORE_00046] et l'opérateur d'affectation [SWS_CORE_00047] sont supprimés (delete). En plus de l'instanciation sans paramètre, des constructeurs surchargés avec options de pool explicites ou ressources amont sont disponibles ([SWS_CORE_00064], [SWS_CORE_00067], [SWS_CORE_00068]).
• Gestion des erreurs et sécurité vis-à-vis des exceptions : le constructeur est déclaré comme non sûr vis-à-vis des exceptions (not exception safe) [SWS_CORE_00063]. Lors du fonctionnement ultérieur de la mémoire, les opérations mémoire s'écartent des exceptions standard : en cas d'erreur, do_allocate fournit nullptr au lieu d'une exception [SWS_CORE_00058], tandis que do_deallocate ignore silencieusement les erreurs [SWS_CORE_00059].
• Concurrence : l'appel du constructeur lui-même est thread-safe [SWS_CORE_00063]. Les opérations ultérieures d'affectation et de libération de l'instance créée (do_allocate, do_deallocate) sont cependant explicitement spécifiées comme non sûres pour les threads (not thread-safe) ([SWS_CORE_00058], [SWS_CORE_00059]).
• Libération des ressources et destruction : la mémoire allouée peut être libérée via [SWS_CORE_00065]. Le destructeur est noexcept, mais implémenté de manière non virtuelle [SWS_CORE_00062].

Utilisation et finalité

Le constructeur explicit UnsynchronizedPoolResource (MemoryResource *upstream) initialise une instance de la classe ara::core::UnsynchronizedPoolResource issue du fichier d'en-tête #include "ara/core/memory_resource.h" conformément à [mem.res.pool] [SWS_CORE_00064]. Le paramètre upstream permet de transmettre la ressource de mémoire parente, qui pourra ultérieurement être interrogée via la méthode upstream_resource() [SWS_CORE_00056]. Un constructeur par défaut sans paramètre [SWS_CORE_00063] ainsi que des surcharges avec PoolOptions sont disponibles comme alternatives [SWS_CORE_00067], [SWS_CORE_00068].

Traitement des erreurs et comportement face aux exceptions

L'instanciation est spécifiée comme not exception safe [SWS_CORE_00064], de sorte que des exceptions peuvent survenir lors de la construction. Des règles différentes s'appliquent aux allocations de mémoire ultérieures : la fonction d'allocation interne do_allocate ne lève aucune exception, mais renvoie nullptr en cas d'échec [SWS_CORE_00058], tandis que les erreurs lors de do_deallocate sont ignorées silencieusement [SWS_CORE_00059].

Concurrence et restrictions

L'appel du constructeur lui-même est considéré comme thread-safe [SWS_CORE_00064]. Les opérations de copie sont empêchées, car le constructeur de copie [SWS_CORE_00046] ainsi que l'opérateur d'assignation [SWS_CORE_00047] sont supprimés. Après la construction, les opérations d'allocation et de désallocation ne sont pas thread-safe [SWS_CORE_00058], [SWS_CORE_00059]. En outre, le destructeur est déclaré non virtuel [SWS_CORE_00062]. La mémoire occupée peut être libérée prématurément via release() [SWS_CORE_00065]. Interprétation : étant donné qu'un pointeur natif upstream est transmis, la ressource en amont référencée devrait devoir rester valide pendant toute la durée de vie de l'instance de pool. Question Q-3e6c23bae834b912 (ouverte)

Utilisation

La fonction membre release() appartient à la portée de la classe ara::core::UnsynchronizedPoolResource et est déclarée via le fichier d'en-tête ara/core/memory_resource.h [SWS_CORE_00065]. La fonction n'a pas de paramètres de transmission ni de valeur de retour (void). Sa sémantique fonctionnelle se conforme à la norme C++ [mem.res.pool] [SWS_CORE_00065] ; la référence devrait signifier que la fonction restitue de manière synchrone toute la mémoire allouée via l'instance de pool à la ressource mémoire en amont (upstream_resource()) [SWS_CORE_00056]. Question Q-e0c7e00cde5d5a34 (ouverte)

Gestion des erreurs

La fonction est définie comme noexcept ainsi que comme exception safe [SWS_CORE_00065]. Elle ne lève aucune exception lors de l'exécution. Comme la spécification ne mentionne aucun code d'erreur spécifique ni message DET/DEM, aucun retour d'erreur explicite via release() n'a lieu en cas d'erreurs de libération de mémoire.

Concurrence et restrictions

Conformément à la spécification, release() est classé comme thread-safe [SWS_CORE_00065]. Cela contraste avec les fonctions internes de gestion de la mémoire de la classe : tant l'allocation au moyen de do_allocate [SWS_CORE_00058] que la désallocation via do_deallocate [SWS_CORE_00059] sont explicitement classées comme not thread-safe.

Interaction

La méthode interagit étroitement avec d'autres propriétés et exigences de UnsynchronizedPoolResource :

• Ressources mémoire : elle restitue la mémoire à la ressource en amont configurée [SWS_CORE_00056], sans que l'objet de pool lui-même doive être détruit, comme cela se produit avec le destructeur ~UnsynchronizedPoolResource() [SWS_CORE_00062].
• Configuration : le comportement et les tailles de fragments (chunks) du pool dépendent des options définies lors de l'instanciation [SWS_CORE_00057], [SWS_CORE_00067], [SWS_CORE_00068].
• Protection contre la copie : une duplication du pool n'est pas autorisée, car le constructeur de copie [SWS_CORE_00046] et l'opérateur d'assignation [SWS_CORE_00047] sont supprimés (delete).

Le constructeur [SWS_CORE_00067] initialise une instance de ara::core::UnsynchronizedPoolResource avec des options de pool spécifiques (opts) et une ressource mémoire parente (upstream). L'appel s'effectue de manière synchrone et est spécifié comme noexcept, ce qui rend la création de l'objet sûre vis-à-vis des exceptions. Une copie de l'instance est exclue, car le constructeur de copie [SWS_CORE_00046] tout comme l'opérateur d'affectation [SWS_CORE_00047] sont supprimés (=delete).

Les paramètres enregistrés et les ressources amont peuvent être lus à l'exécution via options() [SWS_CORE_00057] ainsi que upstream_resource() [SWS_CORE_00056]. Un constructeur par défaut [SWS_CORE_00063] ainsi que des surcharges acceptant exclusivement upstream [SWS_CORE_00064] ou opts [SWS_CORE_00068] sont disponibles comme alternatives. La mémoire occupée peut être libérée via release() [SWS_CORE_00065] ou le destructeur [SWS_CORE_00062], ce dernier n'étant pas virtuel, contrairement à la norme.

En ce qui concerne la concurrence, la construction elle-même est déclarée sûre pour les threads [SWS_CORE_00067]. Les fonctions de gestion de mémoire proprement dites de l'instance – do_allocate [SWS_CORE_00058] et do_deallocate [SWS_CORE_00059] – sont en revanche expressément non sûres pour les threads (« not thread-safe ») et nécessitent des mécanismes de protection externes en cas d'accès parallèle. Les erreurs sont ici traitées sans exceptions : les allocations ayant échoué renvoient nullptr [SWS_CORE_00058], tandis que les erreurs de désallocation sont silencieusement ignorées [SWS_CORE_00059]. Interprétation : l'objet upstream transmis doit probablement rester valide pendant tout le cycle de vie du pool. Question Q-2439ec8f9fb8bb3e (ouverte)

Le constructeur [SWS_CORE_00068] sert à initialiser de manière synchrone une ara::core::UnsynchronizedPoolResource en spécifiant des paramètres de configuration particuliers via le paramètre opts (type PoolOptions). Le comportement est conforme à la norme [mem.res.pool] issue du fichier d'en-tête ara/core/memory_resource.h. Les paramètres transmis peuvent être consultés après l'instanciation avec options() [SWS_CORE_00057], tandis que le gestionnaire de mémoire en amont est accessible via upstream_resource() [SWS_CORE_00056].

En matière de traitement des erreurs, la fonction est spécifiée comme non sûre vis-à-vis des exceptions (« not exception safe ») [SWS_CORE_00068]. Interprétation : en cas d'échec de la mise à disposition interne des structures de gestion lors de l'instanciation, une exception devrait être levée, ce qui différencie cet appel de la variante noexcept [SWS_CORE_00067]. Question Q-479a016f4e0ddde7 (ouverte) Alors que le constructeur lui-même est classé comme sûr au niveau des threads (« thread-safe ») [SWS_CORE_00068], les opérations de mémoire ultérieures de l'instance résultante, telles que do_allocate [SWS_CORE_00058] et do_deallocate [SWS_CORE_00059], sont expressément non sûres au niveau des threads (« not thread-safe ») ; elles ne doivent par conséquent pas être exécutées de manière concurrente sans protection.

En interaction avec le cycle de vie de la classe, il convient de noter que le constructeur de copie [SWS_CORE_00046] et l'opérateur d'assignation [SWS_CORE_00047] sont supprimés (delete). La mémoire allouée reste dans le pool jusqu'à ce qu'elle soit libérée via release() [SWS_CORE_00065] ou que l'objet soit détruit par l'intermédiaire du destructeur non virtuel [SWS_CORE_00062].