class ara::core::MemoryResource

Die Elementfunktion allocate der Klasse ara::core::MemoryResource dient der Allokation von linearem Speicher mit vorgegebener Bytegröße und Ausrichtung [SWS_CORE_06503]. Sie orientiert sich an der C++-Standardschnittstelle [mem.res], weicht jedoch in der Ausnahmebehandlung maßgeblich ab [SWS_CORE_06503].

Verwendung und Parameter

Der Aufruf erfolgt synchron über die Parameter bytes (Anzahl der anzufordernden Bytes) und das optionale alignment, welches standardmäßig auf alignof(std::max_align_t) gesetzt ist [SWS_CORE_06503]. Der Rückgabewert ist mit dem Attribut [[nodiscard]] versehen, weshalb der gelieferte Zeiger vom Typ void* im Aufrufer zwingend ausgewertet werden muss [SWS_CORE_06503].

Fehlerbehandlung und Exception-Sicherheit

Im Gegensatz zum Standardverhalten wirft die Funktion im Fehlerfall keine Ausnahme des Typs std::bad_alloc, sondern ist als noexcept deklariert und gilt als ausnahmesicher (exception safe) [SWS_CORE_06503]:

• Erfolg: Liefert einen gültigen Zeiger auf den allokierten Speicherbereich gemäß [mem.res] [SWS_CORE_06503].
• Fehlschlag: Schlägt die Speicherzuweisung fehl, gibt die Funktion stattdessen nullptr zurück [SWS_CORE_06503]. Der Aufrufer muss das Ergebnis daher stets explizit auf einen Nullzeiger prüfen.

Nebenläufigkeit und Zusammenspiel

Die Funktion ist als nicht threadsicher (not thread-safe) spezifiziert [SWS_CORE_06503]. Parallele Aufrufe auf derselben Instanz von MemoryResource erfordern folglich eine externe Synchronisation durch den Aufrufer. Dieses fehlertolerante, ausnahmefreie Muster findet sich konsistent in weiteren Speicherkomponenten von AUTOSAR Adaptive: So nutzt ara::core::PolymorphicAllocator::allocate denselben Ansatz ohne Exceptions [SWS_CORE_06547], und auch die spezielle Instanz NullMemoryResource signalisiert Speichererschöpfung durch Rückgabe von nullptr [SWS_CORE_06563].

Die Funktion deallocate der Klasse ara::core::MemoryResource dient der Freigabe von Speicherbereichen gemäß [SWS_CORE_06504]. Die Verwendung folgt grundsätzlich dem Standardverhalten aus [mem.res], weist jedoch spezifische Abweichungen auf. Der Aufruf erfolgt synchron über die Signatur void deallocate(void *p, std::size_t bytes, std::size_t alignment=max_align) noexcept, wobei der Zeiger p auf den freizugebenden Block, die Größe bytes sowie optional das Alignment übergeben werden [SWS_CORE_06504].

Hinsichtlich des Fehlerverhaltens ist die Funktion als noexcept und exceptionsicher (exception safe) spezifiziert [SWS_CORE_06504]. Schlägt die Freigabe fehl, werden Fehler stillschweigend ignoriert (errors will be silently ignored) [SWS_CORE_06504]. Es werden keine Exceptions geworfen und keine Fehlermeldungen über DET oder DEM ausgegeben.

Bezüglich der Nebenläufigkeit ist die Funktion ausdrücklich als nicht threadsicher (not thread-safe) eingestuft [SWS_CORE_06504]. Gleichzeitige Zugriffe auf dieselbe Ressourcen-Instanz müssen daher vom Aufrufer extern synchronisiert werden.

Im Zusammenspiel mit dem Allokatorkonzept korrespondiert diese Funktion mit der typisierten Schnittstelle deallocate der Klasse ara::core::PolymorphicAllocator aus [SWS_CORE_06548], welche ähnliche Abweichungen bezüglich noexcept und stillschweigender Fehlerbehandlung aufweist.

Die rein virtuelle Methode do_allocate der Klasse ara::core::MemoryResource dient der Allokation von Speicherblöcken mit vorgegebener Bytegröße und Ausrichtung [SWS_CORE_06566]. Als Parameter übernimmt sie die Anzahl der Bytes (bytes) sowie das geforderte Alignment (alignment). Bei erfolgreicher Zuweisung liefert sie synchron einen Zeiger vom Typ void * auf den reservierten Speicherbereich zurück [SWS_CORE_06566].

In Bezug auf die Fehlerbehandlung weicht die Funktion gezielt vom regulären C++-Standard ab: Sie ist als noexcept deklariert und wirft bei Fehlschlägen keine std::bad_alloc-Ausnahme, sondern liefert stattdessen nullptr zurück [SWS_CORE_06566]. Aufrufer müssen das Allokationsergebnis daher stets auf einen Nullzeiger prüfen.

Hinsichtlich der Nebenläufigkeit ist die Methode als not thread-safe spezifiziert [SWS_CORE_06566]. Parallele Aufrufe über dieselbe Instanz bedürfen einer externen Synchronisation, sofern die abgeleitete Implementierung keinen eigenen Schutz vorsieht. Aufgrund der privaten Sichtbarkeit dürfte der Aufruf durch Nutzer typischerweise indirekt über die übergeordnete Schnittstelle der Basisklasse erfolgen. Frage Q-5cbdabf121ed4550 (offen)

Im Zusammenspiel der Speicherverwaltung bildet die Methode das direkte Gegenstück zu do_deallocate, welches für die Freigabe des allokierten Speichers zuständig ist und Fehler stillschweigend ignoriert [SWS_CORE_06567]. Die Vergleichsfunktion do_is_equal prüft darüber hinaus, ob zwei Ressourceninstanzen bezüglich Allokation und Freigabe zueinander kompatibel sind [SWS_CORE_06568].

Die rein virtuelle Elementfunktion do_deallocate der Klasse ara::core::MemoryResource (deklariert in ara/core/memory_resource.h) dient gemäß [SWS_CORE_06567] der Freigabe zuvor reservierten Speichers. Sie nimmt den Zeiger p auf den Speicherbereich sowie dessen Größe bytes und geforderte Ausrichtung alignment entgegen. Die Semantik entspricht grundsätzlich dem C++-Standard [mem.res], weist jedoch zwei maßgebliche adaptive-spezifische Abweichungen auf [SWS_CORE_06567].

Erstens ist die Funktion als noexcept deklariert und garantiert Ausnahme-Sicherheit (exception safe) [SWS_CORE_06567]. Zweitens werden etwaige Fehler während der Freigabe stillschweigend ignoriert, sodass fehlgeschlagene Operationen weder Fehlermeldungen auslösen noch den Programmfluss unterbrechen dürfen [SWS_CORE_06567].

Hinsichtlich der Nebenläufigkeit ist do_deallocate als not thread-safe spezifiziert und besitzt private Sichtbarkeit [SWS_CORE_06567]. Als Implementierungsdetail einer polymorphen Speicherressource dürfte sie synchron über die übergeordnete öffentliche Aufrufschnittstelle ausgeführt werden. Frage Q-3f97e122ee7fb281 (offen) Konkurrierende Freigaben auf derselben Ressource müssen von ableitenden Klassen bei Bedarf eigenständig synchronisiert werden.

Im Modul core bildet die Funktion das Gegenstück zur Allokation do_allocate [SWS_CORE_06566], welche im Fehlerfall nullptr anstelle einer Exception liefert. Der Vergleich mit anderen Ressourcen erfolgt über die Methode do_is_equal [SWS_CORE_06568], die im Gegensatz zur Deallokation explizit als thread-safe definiert ist.

Die rein virtuelle Elementfunktion do_is_equal wird im Header #include "ara/core/memory_resource.h" im Namensraum von ara::core::MemoryResource deklariert ([SWS_CORE_06568]). Sie dient gemäß der C++-Spezifikation [mem.res] dem synchronen Vergleich der aktuellen Speicherressource mit einer übergebenen Referenz const MemoryResource &other auf Gleichheit ([SWS_CORE_06568]). Da die Methode mit privater Sichtbarkeit (private) definiert ist, dürfte ihr Aufruf als Implementierungsdetail polymorph über die öffentliche Schnittstelle der Klasse ara::core::MemoryResource abgewickelt werden ([SWS_CORE_06568]). Frage Q-cbe02f652b43d6ec (offen)

Hinsichtlich Ausführung und Fehlersicherheit ist do_is_equal als exception safe sowie noexcept deklariert ([SWS_CORE_06568]). Sie darf demnach unter keinen Umständen Ausnahmen werfen und signalisiert das Ergebnis direkt über den booleschen Rückgabewert ([SWS_CORE_06568]). Zudem ist die Methode als thread-safe spezifiziert, sodass abgeleitete Implementierungen auch bei nebenläufigen Vergleichen Thread-Sicherheit gewährleisten müssen ([SWS_CORE_06568]).

Im Zusammenspiel mit den übrigen virtuellen Methoden der Speicherverwaltung komplettiert do_is_equal das Trio der Anpassungspunkte abgeleiteter Ressourcenklassen ([SWS_CORE_06568]). Während die Speicherzuweisung do_allocate im Fehlerfall nullptr liefert ([SWS_CORE_06566]) und do_deallocate Fehler stillschweigend ignoriert ([SWS_CORE_06567]), sind beide Funktionen im Gegensatz zu do_is_equal als nicht threadsicher (not thread-safe) ausgewiesen ([SWS_CORE_06566], [SWS_CORE_06567]). Dies unterstreicht die besondere Anforderung an do_is_equal, nebenläufige Ressourcenvergleiche abzusichern ([SWS_CORE_06568]).