clase ara::per::ReadWriteAccessor

La clase ara::per::ReadWriteAccessor combina las interfaces de ReadAccessor y WriteAccessor para permitir la lectura y escritura de datos de archivo en AUTOSAR Adaptive Platform a través de un objeto común. No está permitida la instanciación directa mediante el constructor por defecto, ya que este está explícitamente eliminado [SWS_PER_00462]. Al destruir la instancia, el destructor declarado como noexcept garantiza total seguridad frente a excepciones; no obstante, está especificado expresamente como no seguro para subprocesos, por lo que requiere un acceso sincronizado [SWS_PER_00598].

más ›

Contexto

La clase ara::per::ReadWriteAccessor representa en el módulo per (Persistency) de AUTOSAR Adaptive Platform la interfaz central para leer y escribir datos de archivo. Agrupa las funcionalidades de acceso de lectura y escritura independientes combinando las capacidades de las clases base ReadAccessor y WriteAccessor. La declaración de la clase se efectúa a través del archivo de cabecera ara/per/read_write_accessor.h [SWS_PER_00462].

En la arquitectura de tipos, ReadWriteAccessor se define mediante herencia múltiple como subclase de ReadAccessor y WriteAccessor, y está marcada con el identificador final. Esto impide una mayor derivación por parte de los desarrolladores de aplicaciones y asegura que la semántica de acceso combinada permanezca inalterada. Como interlocutores actúan, en consecuencia, las dos clases base especializadas, cuyos contratos de interfaz comunes se proyectan sobre una capa de acceso unificada para archivos.

Diagrama de contexto: Jerarquía de herencia y relación de roles entre ReadWriteAccessor, ReadAccessor y WriteAccessor. Fuentes: [SWS_PER_00462], [SWS_PER_00598]

Ciclo de vida

El ciclo de vida de una instancia de ara::per::ReadWriteAccessor está sujeto a estrictas especificaciones estructurales. Según [SWS_PER_00462], el constructor por defecto sin parámetros está explícitamente eliminado (ReadWriteAccessor() = delete;). Por tanto, no se permite una creación directa sin contexto ni parámetros. Desde una perspectiva arquitectónica (interpretación), es de suponer que las instancias de esta clase sean proporcionadas habitualmente por funciones de gestión de nivel superior o mecanismos de creación del subsistema de persistencia en cuanto se abre un archivo para operación combinada de lectura y escritura. Pregunta Q-9b390ab33102d524 (abierta)

La liberación de la instancia se realiza mediante el destructor ~ReadWriteAccessor(), declarado como final y noexcept [SWS_PER_00598]. La finalización del ciclo de vida del objeto requiere especial atención respecto a la concurrencia: El destructor está catalogado explícitamente en la especificación como no seguro para subprocesos («not thread-safe») [SWS_PER_00598]. El software llamador debe garantizar, por tanto, que durante la destrucción del objeto no se produzcan operaciones paralelas de lectura o escritura en la misma instancia. Según la interpretación, es de suponer que el destructor sea responsable de cerrar los descriptores de archivo abiertos y de limpiar los estados internos restantes al salir ordenadamente del ámbito. Pregunta Q-49e2fdfd53789afd (abierta)

En cuanto a la relación de propiedad, el objeto reside habitualmente en el ámbito local del componente cliente o se gestiona mediante estructuras de punteros. Dado que la modificación y destrucción simultáneas no están protegidas, una instancia (interpretación) presumiblemente no debe compartirse sin protección entre contextos de ejecución concurrentes. Pregunta (abierta)

Escenarios de error

Las situaciones de error en el manejo de ara::per::ReadWriteAccessor se manifiestan tanto en tiempo de compilación como en tiempo de ejecución mediante precondiciones y poscondiciones específicas. Una precondición estática fundamental es la prohibición de la instanciación por defecto: Al estar eliminado el constructor sin parámetros, cualquier intento de construcción directa genera un error inmediato de compilación [SWS_PER_00462]. Con ello se evita que existan en el sistema objetos de acceso no inicializados o no válidos.

En lo relativo al nivel de excepciones, la clase ofrece una seguridad frente a excepciones garantizada durante el desmantelamiento: El destructor está definido como noexcept y especificado como seguro frente a excepciones («exception safe») [SWS_PER_00598]. Esto asegura que, incluso en caso de errores durante las tareas de limpieza, no se propaguen excepciones de C++ hacia el exterior, garantizando así un desenrollado de pila seguro.

Un escenario de fallo crítico en tiempo de ejecución resulta de la falta de seguridad para subprocesos del destructor según [SWS_PER_00598]. Si el objeto se destruye mientras otro hilo aún ejecuta operaciones de lectura o escritura, esto da lugar a un comportamiento indefinido o a inconsistencias en los datos. El cumplimiento de las precondiciones relativas a los hilos recae, por tanto, enteramente en el diseño del sistema llamador.