Figure 6.11: Fast method invocation

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit sprachdomänenübergreifender Interaktion (Rust vs. C++ über FFI/ABI-Grenzen).
• Technischer Zweck: Spezifikation des optimierten synchronen Schnelldurchlaufs (Fast Path / Immediate Completion) für Methodenaufrufe eines AUTOSAR Adaptive Service Providers (Skeleton), der in Rust implementiert ist, aber an die bestehende C++-Middleware-Architektur (ara::com) angebunden wird.
• Funktionale Einordnung: Liefert die Rust-Applikationslogik bei der ersten Auswertung unmittelbar ein fertiges Ergebnis (Poll::Ready), wird der asynchrone Rust-Task-Executor umgangen. Der Aufruf wird vollständig im Thread-Kontext des aufrufenden C++-Worker-Threads abgearbeitet, wodurch Task-Scheduling-Overheads und Kontextwechsel entfallen.

2. Komponenten, Entitäten & Schnittstellen

C++-Domäne

• Skeleton (gen): Generiertes C++-Skeleton (ara::com::internal::skeleton), das eingehende Anfragen aus der Middleware (z. B. SOME/IP, Inter-Process Communication / IPC) empfängt.
• Adapter (gen): Schnittstellenspezifisch generierter C++-Adapter; fungiert als Sprachbrücke (C-ABI / extern "C"). Verwaltet das ara::core::Promise-Objekt und liefert das zugehörige ara::core::Future zurück.
• Adapter (static): Statische C++-Brückenkomponente für plattformweite Typkonvertierungen und Hilfsfunktionen (im Fast Path nicht aktiv eingebunden).

Rust-Domäne

• Skeleton (gen): Generierte Rust-Struktur (aus dem AUTOSAR-Servicemodell), die Methoden über ein asynchrones Trait bereitstellt (async fn bzw. Rückgabetyp impl Future).
• ara crate: Laufzeit-Support-Crate für Adaptive AUTOSAR in Rust; stellt Abstraktionen für Polling, Waker-Registrierung und FFI-Übergänge bereit.
• App: Anwendungslogik des Entwicklers, die das generierte Skeleton-Trait implementiert.
• Executor: Asynchroner Rust-Task-Executor (z. B. Thread-Pool/Reactor); bleibt im Fast Path vollständig unbeteiligt (idle), da kein Poll::Pending auftritt.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Request: Das C++-Skeleton (gen) empfängt einen Remote-/IPC-Methodenaufruf.
2. Method invocation: C++-Skeleton (gen) ruft den generierten Adapter (gen) auf.
3. Create promise: Adapter (gen) instanziiert ein ara::core::Promise<T>.
4. Implementation call: Synchroner FFI-Aufruf über die Sprachgrenze an das generierte Rust-Skeleton (gen).
5. Async trait call: Rust-Skeleton (gen) ruft die Methodenimplementierung in App auf und erhält das Future-Objekt.
6. callback_poll: Rust-Skeleton (gen) initiiert über das ara crate das synchrone Polling des Futures.
7. poll: ara crate führt Future::poll(cx) direkt auf App aus.
8. Ready(result): Die App liefert sofort Poll::Ready(result) zurück (kein I/O-Warten, keine Suspension).
9. Set promise: ara crate setzt den Rückgabewert unmittelbar im C++-Promise via FFI (promise.set_value(...)).
10. Rückkehr & return future: Der Aufruf kehrt über das Rust-Skeleton (gen) zum C++-Adapter (gen) zurück. Dieser liefert das bereits erfüllte ara::core::Future an das C++-Skeleton (gen) aus, welches die Antwort serialisieren und versenden kann.

4. Normative Relevanz & Entwickler-Hinweise

• Latenz- und Allokationsoptimierung: Für Berechnungen, Cache-Hits oder rein synchrone Zustandsabfragen verhindert dieser Pfad dynamische Heap-Allokationen für Waker/Task-Deskriptoren und spart Thread-Wechsel zwischen C++-Event-Loop und Rust-Executor.
• Thread-Affinität & Blockierverbot: Der Rust-Code in App läuft im Ausführungskontext des C++-Worker-Threads. Entwickler dürfen innerhalb synchron evaluierender Methoden keine blockierenden Systemaufrufe, OS-Locks oder langlebigen Operationen ausführen, da dies den Middleware-Worker blockiert.
• Async-Trait-Design: Entwickler sollten keinen unnötigen yield- oder await-Schritt einbauen, wenn ein Ergebnis sofort berechenbar ist, um die Aktivierung des teureren Pfads über den Executor (Slow Path mit Poll::Pending und Waker-Benachrichtigung) zu vermeiden.
• Speichersicherheit an der FFI-Grenze: Die Lebensdauer des C++-Promise muss über die synchrone FFI-Grenze hinweg garantiert valide bleiben; Parameterübergaben erfolgen nach C-ABI-Layouts ohne implizite Rust-Besitzübertragung an den Executor.