Figure 9.19: Interfaces for memory resources

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellenspezifikation der C++ Native API.
• Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_SWArchitecture (R24-11), Functional Cluster Core (ara::core).
• Technischer Zweck: Modellierung des Speichermanagement-Frameworks basierend auf dem C++ Polymorphic Memory Resource (PMR)-Muster (äquivalent zu C++17 std::pmr). Ziel ist die Entkopplung von Allokationsstrategien von Containertypen zur Gewährleistung deterministischer, fragmentierungsfreier und auditierbarer Speicherverwaltung für echtzeit- und sicherheitskritische Adaptive Applications (ASIL-Konformität).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• «aapFunctionalCluster» Core: Realisierendes Basissystem (ara::core), das die grundlegenden Laufzeit- und Datenstruktur-Schnittstellen der Adaptive Platform bereitstellt.
• «aapAPI, aapNativeInterface» MemoryResource: Abstrakte polymorphe Basisklasse für Speicherressourcen nach dem Non-Virtual Interface (NVI)-Muster:
  • Public Interface (+): allocate(), deallocate(), is_equal()
  • Private Virtual Hooks (-): do_allocate(), do_deallocate(), do_is_equal()
• «aapAPI, aapNativeInterface» SynchronizedPoolResource: Thread-sichere Pool-Allokator-Klasse zur Verwaltung fester Blockgrößenklassen. Synchronisiert gleichzeitige Allokationen über interne Mutex-Mechanismen.
  • Operationen: # do_allocate(), # do_deallocate(), # do_is_equal(), + options(), + release(), + upstream_resource()
• «aapAPI, aapNativeInterface» UnsynchronizedPoolResource: Nicht thread-sichere Variante der Pool-Ressource mit identischer Schnittstelle, optimiert für minimale Latenz ohne Synchronisations-Overhead im Single-Thread- oder Thread-Local-Betrieb.
• «aapAPI, aapNativeInterface» MonotonicBufferResource: Linearer Allokator (Scratchpad/Arena). Allokiert Speicher fortlaufend aus einem internen Puffer; einzelne Freigaben sind wirkungslos.
  • Operationen: # do_allocate(), # do_deallocate(), # do_is_equal(), + release(), + upstream_resource()

Beziehungen & Vererbung

• Generalisierung (durchgezogener Pfeil, geschlossene Hohlspitze): SynchronizedPoolResource, UnsynchronizedPoolResource und MonotonicBufferResource erben öffentlich von MemoryResource und überschreiben die Hooks (do_*).
• Realisierung / Bereitstellung (gestrichelte Pfeile, geschlossene Hohlspitzen): Der Functional Cluster Core implementiert und exponiert die Schnittstelle MemoryResource sowie deren drei konkrete Spezialisierungen als Plattform-API.

3. Dynamisches Verhalten & Sequenzablauf

NVI-Allokationsablauf (synchron)

1. Aufruf: Applikation oder PMR-fähiger Container ruft public MemoryResource::allocate(bytes, alignment) auf.
2. Dispatch: Die Basisklasse leitet den Aufruf ohne weitere Logik an die polymorphe Implementierung do_allocate() der abgeleiteten Klasse weiter.
3. Ausführung je Allokatortyp:
   • MonotonicBufferResource: Verschiebt internen Offset-Zeiger. Reicht der lokale Puffer nicht aus, wird neuer Speicherblock via upstream_resource()->allocate() bezogen.
   • SynchronizedPoolResource: Akquiriert internen Lock, sucht passenden Chunk im zuständigen Größenpool (Größenordnung via options()), allokiert bei Bedarf neue Chunks via upstream_resource(), gibt Lock frei.
   • UnsynchronizedPoolResource: Führt dieselbe Pool-Logik ohne Locking aus.
4. Deallokation:
   • Aufruf von deallocate(ptr, bytes, alignment) delegiert an do_deallocate().
   • Bei MonotonicBufferResource ist do_deallocate() ein No-Op (keine unmittelbare Fragmentierung oder Freigabe).
   • Bei Pool-Ressourcen wird der Block in die Freiliste des jeweiligen Pools zurückgehängt.
5. Bulk-Reset:
   • Aufruf von release() deallokiert den gesamten verwalteten Speicherblock geschlossen über die upstream_resource().

4. Normative Relevanz & Entwickler-Hinweise

• ASIL- & Echtzeit-Restriktionen: Der unkontrollierte Einsatz des globalen Heaps (malloc/new) zur Laufzeit ist in ASIL-Kontexten verboten. Entwickler müssen für deterministische Ausführungszeiten Pool- oder Monotonic-Ressourcen vorkonfigurieren.
• Upstream-Chaining: Jede Subklasse kapselt eine Referenz auf eine übergeordnete upstream_resource(). Entwickler können Allokatoren hierarchisch schachteln (z. B. MonotonicBufferResource auf einem statisch im BSS/Data-Segment allokierten std::byte-Array ohne OS-Syscalls).
• Concurrency-Regeln:
  • UnsynchronizedPoolResource darf unter keinen Umständen thread-übergreifend geteilt werden (Data Race, undefiniertes Verhalten).
  • SynchronizedPoolResource verursacht Locking-Overhead und kann Priority Inversion hervorrufen, wenn Threads unterschiedlicher Echtzeitprioritäten denselben Pool nutzen.
• Lebenszyklus-Management: Bei Verwendung von MonotonicBufferResource werden Destruktoren einzelner Objekte bei deallocate() nicht automatisch über Speicherfreigaben getrackt. Der gesamte Speicher bleibt bis zum Aufruf von release() oder der Zerstörung der Ressourcen-Instanz belegt.