class ara::per::ReadWriteAccessor

Class ara::per::ReadWriteAccessor combines the interfaces of ReadAccessor and WriteAccessor to enable reading and writing of file data in the AUTOSAR Adaptive Platform via a shared object. Direct instantiation via the default constructor is not permitted, as it is explicitly deleted [SWS_PER_00462]. Upon destroying the instance, the destructor declared as noexcept guarantees complete exception safety, but is explicitly specified as not thread-safe and therefore requires synchronized access [SWS_PER_00598].

more ›

Context

Class ara::per::ReadWriteAccessor represents the central interface in module per (Persistency) of the AUTOSAR Adaptive Platform for both reading and writing file data. It bundles the functionalities of separate read and write access by combining the capabilities of the base classes ReadAccessor and WriteAccessor. The class declaration is provided via header file ara/per/read_write_accessor.h [SWS_PER_00462].

In the type architecture, ReadWriteAccessor is defined via multiple inheritance as a subclass of ReadAccessor as well as WriteAccessor and marked with the specifier final. This prevents further derivation by application developers and ensures that the combined access semantics remain unchanged. Consequently, the two specialized base classes act as interaction partners, whose common interface contracts are projected onto a unified access layer for files.

Context diagram: Inheritance hierarchy and role relationship between ReadWriteAccessor, ReadAccessor, and WriteAccessor. Sources: [SWS_PER_00462], [SWS_PER_00598]

Lifecycle

The lifecycle of an instance of ara::per::ReadWriteAccessor is subject to strict structural requirements. According to [SWS_PER_00462], the parameterless default constructor is explicitly deleted (ReadWriteAccessor() = delete;). Direct creation without context or parameters is therefore not permitted. From an architectural perspective (interpretation), instances of this class are typically expected to be provided by higher-level management functions or creation mechanisms of the persistency subsystem as soon as a file is opened for combined read and write operations. Question Q-9b390ab33102d524 (open)

Release of the instance occurs via destructor ~ReadWriteAccessor(), which is declared as final and noexcept [SWS_PER_00598]. Terminating the object lifecycle requires special consideration regarding concurrency: The destructor is explicitly classified in the specification as not thread-safe ("not thread-safe") [SWS_PER_00598]. The calling software must thus guarantee that no concurrent read or write operations take place on the same instance during destruction of the object. According to interpretation, the destructor is likely responsible for closing opened file descriptors and cleaning up remaining internal states upon orderly exit from the scope. Question Q-49e2fdfd53789afd (open)

Regarding ownership, the object typically resides in the local scope of the consuming component or is managed via pointer structures. Since concurrent modification and destruction is not safeguarded, an instance (interpretation) presumably must not be shared unprotected between concurrent execution contexts. Question (open)

Error Scenarios

Error situations when dealing with ara::per::ReadWriteAccessor manifest both at compile time and at runtime through specific preconditions and postconditions. An essential static precondition is the prohibition of default instantiation: Since the parameterless constructor is deleted, any attempt at direct construction leads to an immediate compilation error [SWS_PER_00462]. This prevents uninitialized or invalid accessor objects from existing in the system.

Regarding the exception level, the class offers guaranteed exception safety during teardown: The destructor is defined as noexcept and specified as exception safe ("exception safe") [SWS_PER_00598]. This ensures that even in the event of errors during cleanup work, no C++ exceptions are propagated outward, thereby ensuring safe stack unwinding.

A critical error scenario at runtime results from the lack of thread safety of the destructor according to [SWS_PER_00598]. If the object is destroyed while another thread is still executing read or write operations, this leads to undefined behavior or data inconsistencies. Adherence to thread-related preconditions is therefore entirely the responsibility of the calling system design.