class ara::per::ReadWriteAccessor

Die Klasse ara::per::ReadWriteAccessor kombiniert die Schnittstellen von ReadAccessor und WriteAccessor, um das Lesen und Schreiben von Dateidaten in der AUTOSAR Adaptive Platform über ein gemeinsames Objekt zu ermöglichen. Eine direkte Instanziierung über den Standardkonstruktor ist nicht zulässig, da dieser explizit gelöscht ist [SWS_PER_00462]. Beim Zerstören der Instanz garantiert der als noexcept deklarierte Destruktor vollständige Ausnahme-Sicherheit, ist jedoch ausdrücklich nicht threadsicher spezifiziert und erfordert daher einen synchronisierten Zugriff [SWS_PER_00598].

mehr ›

Kontext

Die Klasse ara::per::ReadWriteAccessor stellt im Modul per (Persistency) der AUTOSAR Adaptive Platform die zentrale Schnittstelle dar, um Dateidaten sowohl zu lesen als auch zu schreiben. Sie bündelt die Funktionalitäten des getrennten Lese- und Schreibzugriffs, indem sie die Fähigkeiten der Basisklassen ReadAccessor und WriteAccessor zusammenführt. Die Klassendeklaration erfolgt über die Header-Datei ara/per/read_write_accessor.h [SWS_PER_00462].

In der Typarchitektur ist ReadWriteAccessor über Mehrfachvererbung als Unterklasse von ReadAccessor sowie WriteAccessor definiert und mit dem Bezeichner final markiert. Dies verhindert eine weitere Ableitung durch Anwendungsentwickler und stellt sicher, dass die kombinierte Zugriffssemantik unverändert bleibt. Als Interaktionspartner fungieren folglich die beiden spezialisierten Basisklassen, deren gemeinsame Schnittstellenverträge auf eine einheitliche Zugriffsschicht für Dateien projiziert werden.

Kontextdiagramm: Vererbungshierarchie und Rollenbeziehung zwischen ReadWriteAccessor, ReadAccessor und WriteAccessor. Quellen: [SWS_PER_00462], [SWS_PER_00598]

Lebenszyklus

Der Lebenszyklus einer Instanz von ara::per::ReadWriteAccessor unterliegt strengen strukturellen Vorgaben. Gemäß [SWS_PER_00462] ist der parameterlose Standardkonstruktor explizit gelöscht (ReadWriteAccessor() = delete;). Eine direkte Erzeugung ohne Kontext oder Parameter ist daher unzulässig. Aus architektonischer Sicht (Interpretation) dürften Instanzen dieser Klasse typischerweise durch übergeordnete Verwaltungsfunktionen oder Erzeugungsmechanismen des Persistenz-Subsystems bereitgestellt werden, sobald eine Datei für den kombinierten Lese- und Schreibbetrieb geöffnet wird. Frage Q-9b390ab33102d524 (offen)

Die Freigabe der Instanz erfolgt über den Destruktor ~ReadWriteAccessor(), der als final und noexcept deklariert ist [SWS_PER_00598]. Das Beenden des Objektlebenszyklus erfordert besondere Beachtung hinsichtlich der Nebenläufigkeit: Der Destruktor ist in der Spezifikation explizit als nicht threadsicher („not thread-safe“) eingestuft [SWS_PER_00598]. Die aufrufende Software muss somit garantieren, dass während der Zerstörung des Objekts keine parallelen Lese- oder Schreibvorgänge auf derselben Instanz stattfinden. Nach der Interpretation dürfte der Destruktor beim geordneten Verlassen des Gültigkeitsbereichs für das Schließen geöffneter Dateideskriptoren sowie das Bereinigen verbleibender interner Zustände verantwortlich sein. Frage Q-49e2fdfd53789afd (offen)

Hinsichtlich des Besitzverhältnisses liegt das Objekt typischerweise im lokalen Gültigkeitsbereich der anwendenden Komponente oder wird über Zeigerstrukturen verwaltet. Da eine gleichzeitige Modifikation und Zerstörung nicht abgesichert ist, darf eine Instanz (Interpretation) vermutlich nicht ungeschützt zwischen nebenläufigen Ausführungskontexten geteilt werden. Frage (offen)

Fehlerszenarien

Fehlersituationen im Umgang mit ara::per::ReadWriteAccessor manifestieren sich sowohl zur Übersetzungszeit als auch zur Laufzeit durch spezifische Vor- und Nachbedingungen. Eine wesentliche statische Vorbedingung ist das Verbot der Standardinstanziierung: Da der parameterlose Konstruktor gelöscht ist, führt jeder Versuch einer direkten Konstruktion zu einem sofortigen Übersetzungsfehler [SWS_PER_00462]. Hierdurch wird verhindert, dass uninitialisierte oder ungültige Accessor-Objekte im System existieren.

Hinsichtlich des Ausnahmeniveaus bietet die Klasse beim Abbau eine garantierte Ausnahme-Sicherheit: Der Destruktor ist als noexcept definiert und als ausnahmesicher („exception safe“) spezifiziert [SWS_PER_00598]. Dies stellt sicher, dass selbst bei Fehlern während der Aufräumarbeiten keine C++-Ausnahmen nach außen propagiert werden, wodurch ein sicheres Stack-Unwinding gewährleistet bleibt.

Ein kritisches Fehlerszenario zur Laufzeit resultiert aus der fehlenden Threadsicherheit des Destruktors gemäß [SWS_PER_00598]. Wird das Objekt zerstört, während ein anderer Thread noch Lese- oder Schreiboperationen ausführt, führt dies zu undefiniertem Verhalten oder Dateninkonsistenzen. Die Einhaltung der threadbezogenen Vorbedingungen obliegt daher vollständig dem aufrufenden Systementwurf.