classe ara::per::ReadWriteAccessor

La classe ara::per::ReadWriteAccessor combine les interfaces de ReadAccessor et WriteAccessor afin de permettre la lecture et l'écriture de données de fichiers dans l'AUTOSAR Adaptive Platform via un objet commun. Une instanciation directe via le constructeur par défaut n'est pas autorisée, car celui-ci est explicitement supprimé [SWS_PER_00462]. Lors de la destruction de l'instance, le destructeur déclaré comme noexcept garantit une totale sécurité face aux exceptions, mais est expressément spécifié comme n'étant pas sûr pour les threads et requiert donc un accès synchronisé [SWS_PER_00598].

plus ›

Contexte

La classe ara::per::ReadWriteAccessor constitue, dans le module per (Persistency) de l'AUTOSAR Adaptive Platform, l'interface centrale pour à la fois lire et écrire des données de fichiers. Elle regroupe les fonctionnalités des accès en lecture et en écriture séparés en combinant les capacités des classes de base ReadAccessor et WriteAccessor. La déclaration de la classe s'effectue via le fichier d'en-tête ara/per/read_write_accessor.h [SWS_PER_00462].

Dans l'architecture des types, ReadWriteAccessor est définie par héritage multiple comme sous-classe de ReadAccessor ainsi que de WriteAccessor, et marquée avec l'identificateur final. Cela empêche toute dérivation ultérieure par les développeurs d'applications et garantit que la sémantique d'accès combinée demeure inchangée. Par conséquent, les deux classes de base spécialisées agissent comme partenaires d'interaction, dont les contrats d'interface communs sont projetés sur une couche d'accès unifiée pour les fichiers.

Diagramme de contexte : hiérarchie d'héritage et relation de rôles entre ReadWriteAccessor, ReadAccessor et WriteAccessor. Sources : [SWS_PER_00462], [SWS_PER_00598]

Cycle de vie

Le cycle de vie d'une instance de ara::per::ReadWriteAccessor est soumis à des règles structurelles strictes. Conformément à [SWS_PER_00462], le constructeur par défaut sans paramètre est explicitement supprimé (ReadWriteAccessor() = delete;). Une création directe sans contexte ni paramètre est donc interdite. D'un point de vue architectural (interprétation), les instances de cette classe devraient typiquement être fournies par des fonctions de gestion de niveau supérieur ou des mécanismes de création du sous-système de persistance dès qu'un fichier est ouvert pour un fonctionnement combiné en lecture et en écriture. Question Q-9b390ab33102d524 (ouverte)

La libération de l'instance s'effectue via le destructeur ~ReadWriteAccessor(), qui est déclaré comme final et noexcept [SWS_PER_00598]. La clôture du cycle de vie de l'objet requiert une attention particulière quant à la concurrence : le destructeur est explicitement classé dans la spécification comme non sûr pour les threads (« not thread-safe ») [SWS_PER_00598]. Le logiciel appelant doit ainsi garantir qu'aucune opération parallèle de lecture ou d'écriture n'a lieu sur la même instance pendant la destruction de l'objet. Selon l'interprétation, le destructeur devrait être responsable de la fermeture des descripteurs de fichiers ouverts ainsi que du nettoyage des états internes restants lors de la sortie ordonnée de la portée. Question Q-49e2fdfd53789afd (ouverte)

Concernant la propriété, l'objet réside typiquement dans la portée locale du composant utilisateur ou est géré via des structures de pointeurs. Une modification et une destruction simultanées n'étant pas sécurisées, une instance (interprétation) ne doit vraisemblablement pas être partagée sans protection entre des contextes d'exécution concurrents. Question (ouverte)

Scénarios d'erreur

Les situations d'erreur lors de la manipulation de ara::per::ReadWriteAccessor se manifestent aussi bien au moment de la compilation qu'à l'exécution par des préconditions et postconditions spécifiques. Une précondition statique essentielle est l'interdiction de l'instanciation par défaut : le constructeur sans paramètre étant supprimé, toute tentative de construction directe entraîne une erreur de compilation immédiate [SWS_PER_00462]. Cela empêche l'existence dans le système d'objets accesseurs non initialisés ou invalides.

En ce qui concerne le niveau d'exception, la classe offre une sécurité contre les exceptions garantie lors de la destruction : le destructeur est défini comme noexcept et spécifié comme sûr vis-à-vis des exceptions (« exception safe ») [SWS_PER_00598]. Cela garantit que, même en cas d'erreurs lors des opérations de nettoyage, aucune exception C++ n'est propagée vers l'extérieur, maintenant ainsi un déroulement de pile (stack unwinding) sûr.

Un scénario d'erreur critique à l'exécution résulte de l'absence de sécurité des threads du destructeur selon [SWS_PER_00598]. Si l'objet est détruit alors qu'un autre thread exécute encore des opérations de lecture ou d'écriture, cela conduit à un comportement indéfini ou à des incohérences de données. Le respect des préconditions liées aux threads incombe donc entièrement à la conception du système appelant.