Figure 6.12: Slow method invocation

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm über Sprachdomänen/FFI-Grenzen hinweg).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ara::com Interoperabilität). Spezifiziert das Zusammenspiel zwischen dem C++-basierten ara::com-Kommunikationsstack und einer in Rust implementierten Service-Applikation (AUTOSAR_AP_EXP_ARARustApplications).
• Funktionaler Zweck: Modellierung des asynchronen „Slow Path“-Aufrufmusters (Slow Method Invocation) einer Service-Methode. Zeigt die Entkopplung und Lebensdauerverwaltung, wenn eine Methodenimplementierung in Rust beim initialen poll nicht sofort fertiggestellt ist (Poll::Pending), sodass die blockierungsfreie Rückgabe eines C++-ara::core::Future sowie die Auslagerung in einen Rust-Task-Executor erforderlich werden.

2. Komponenten, Entitäten & Schnittstellen

Domäne Rust:

• Executor: Asynchroner Task-Scheduler / Runtime-Executor (z. B. tokio-/smol-ähnliches Modell in der ara-Rust-Umgebung) zur Ausführung geparkter Futures und Verarbeitung von Wake-Events.
• App: Anwendungslogik, die das vom Skeleton generierte Service-Trait mit asynchronen Methoden (async fn bzw. impl Future) implementiert.
• Skeleton (gen): Codegenerierte Rust-Abstraktionsschicht, die die FFI-Funktionen typkonform in idiomatische Rust-Interfaces (Async trait call) überführt.
• ara crate: Statische Laufzeitbibliothek (Runtime-Crate) für Rust, welche die State-Machine für Futures, Waker-Registrierungen (callback_poll), Task-Spawning und FFI-Bindungen zu C++ bereitstellt.

Domäne C++:

• Skeleton (gen): Codegenerierter C++-Service-Skeleton (aus ARXML-Interface-Definition), der eingehende Service-Requests aus der Middleware (ara::com-Binding) entgegennimmt.
• Adapter (gen): Codegenerierte C++/FFI-Brücke, übersetzt C++-Datenstrukturen in C-kompatible FFI-Aufrufe (Implementation call) und instanziiert das ara::core::Promise.
• Adapter (static): Statische C++-Support-Bibliothek/Laufzeitschicht zur Speicherung und Lebensdauerüberwachung langlebiger C++-Objekte über FFI-Grenzen hinweg.

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Eingang & Promise-Erzeugung:
   • Ein Service-Request erreicht den C++-Skeleton (gen).
   • Der Skeleton ruft Method invocation am C++-Adapter (gen) auf.
   • Adapter (gen) erzeugt ein lokales ara::core::Promise (Create promise).
2. Initialer synchroner Aufrufversuch (FFI-Übergang):
   • Adapter (gen) übergibt den Methodenaufruf via Implementation call an das Rust-Skeleton (gen).
   • Das Rust-Skeleton triggert die Anwendungslogik via Async trait call auf App.
   • Zur Überprüfung der sofortigen Verfügbarkeit leitet das Rust-Skeleton den Kontrollfluss via callback_poll an das ara crate weiter, welches poll auf der App-Future ausführt.
3. Erkennung des Slow Path (Pending):
   • App signalisiert Pending (Berechnung/Ressource noch nicht bereit).
   • Lebensdauer-Transfer: Das ara crate weist den C++-Adapter (static) an, das Promise auf den Heap zu verschieben (move promise to heap (retain)), um dessen Lebensdauer über den FFI-Aufrufrahmen hinaus zu sichern.
   • Task-Delegation: Das ara crate übergibt die Future via spawn task an den Rust-Executor.
   • Der initiale synchrone Stack-Frame kehrt über das Rust-Skeleton zum C++-Adapter (gen) zurück.
   • Adapter (gen) extrahiert das ara::core::Future aus dem Promise und gibt es mit return future synchron an den C++-Skeleton (gen) zurück. Der C++-Thread ist damit sofort wieder unblockiert.
4. Asynchrone Ausführung & Re-Polling:
   • Der Executor aktiviert den Task (Task active) im ara crate.
   • ara crate pollt die App erneut (poll).
   • Da das Ergebnis noch aussteht, registriert die App einen Waker am Executor (subscribe to wake event) und antwortet erneut mit Pending.
5. Abschluss & Ergebnis-Propagation:
   • Nach Fertigstellung der asynchronen Operation sendet der Executor ein Wake event an das ara crate.
   • ara crate führt das finale poll aus; die App antwortet mit Ready(result).
   • ara crate setzt das ausgelagerte C++-Promise (Set promise).
   • Über das gesetzte Promise wird der Wert an das korrespondierende C++-Future im C++-Subsystem signalisiert (gestrichelte Linie zum C++-Skeleton/Client).

4. Normative Relevanz & Entwickler-Hinweise

• Memory Management & FFI-Lebensdauern: Entwickler müssen beachten, dass bei Nicht-Fertigstellung im ersten Poll-Zyklus zwingend eine Heap-Allokation (move promise to heap) auf C++-Seite erfolgt. Für harte Echtzeitanforderungen (ASIL-D / deterministische Latenzen) sollte durch Cache-Warming oder Pre-computation evaluiert werden, ob der „Fast Path“ (Fertigstellung im initialen Poll ohne Heap-Move und ohne Spawn) erzwungen werden kann.
• Executor-Dimensionierung: Da jeder Slow-Call über spawn task auf dem Rust-Executor landet, muss der Executor-Threadpool bzw. die Task-Queue ausreichend dimensioniert sein, um Backpressure oder Deadlocks bei vielen parallelen Methodenaufrufen zu verhindern.
• Waker-Disziplin (Rust-Konformität): Die Applikation (App) muss dem Standard-Rust-Future-Vertrag genügen: Sie darf nur dann Pending zurückgeben, wenn der Waker korrekt am Event-Trigger/Executor registriert wurde (subscribe to wake event), andernfalls droht ein permanentes Hängen des asynchronen Aufrufs.
• Fehlerbehandlung: Fehler (z. B. ara::core::ErrorCode bzw. Rust-Result::Err) werden analog zu Ready(result) über Set promise in das C++-ara::core::Promise propagiert und materialisieren sich auf C++-Seite als fehlerhafte Future.