Figure 4.1: async function execution

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (UML 2.x Sequence Diagram) mit kombiniertem Fragment (opt-Block / Schleife [0..N times]).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_EXP_ARARustApplications.
• Technischer Zweck: Spezifikation des kooperativen, zustandsbasierten asynchronen Ausführungsmodells (Pull-/Poll-basiertes Modell) für Rust-basierte Adaptive Applications (AA) im Kontrast zum klassischen, ereignisgesteuerten C++-Modell (ara::core::Future / std::future).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • Main: Aufrufender Thread / übergeordneter Ausführungskontext der Applikation.
  • async function: Aufgerufene asynchrone Funktion, compiler-seitig transformiert in eine diskrete Zustandsmaschine (State Machine).
  • Future: Instanz des Traits core::future::Future, kapselt den aktuellen Zustand, lokale Variablen und den Program Counter/Yield-Offset.
  • Executor: Asynchrone Task-Laufzeitumgebung (Runtime Scheduler), zuständig für Task-Multiplexing und Fortschrittstrigger.
• Schnittstellen & Operationen:
  • Call function → Immediately return Future: Synchrone Initialisierungsphase ohne Start der Funktionslogik.
  • spawn(Future) / await or block_on: Registrierung der Task beim Scheduler bzw. Blockieren/Suspendieren des aufrufenden Kontextes.
  • poll: Treiberschnittstelle (core::future::Future::poll(&mut Context<'_>)).
  • Rückgabewerte: Varianten des Enums core::task::Poll:
    • Pending: Kooperativer Rückzug (Yield), Operation noch unvollständig.
    • Ready(value): Terminierung der Zustandsmaschine mit Ergebnisübergabe.
• Beziehungen & Kardinalitäten:
  • 1:1-Zuordnung zwischen Aufruf der async function und erzeugtem Future-Objekt.
  • 1:N-Beziehung zwischen Executor und poll-Aufrufen (0..N Zyklen im opt-Fragment bis zum Eintreffen von Ready).

3. Dynamisches Verhalten & Sequenzablauf

1. Lazy Creation (Verzögerte Ausführung):
   • Main ruft die async function synchron auf.
   • Die Funktion generiert die Future-Struktur zur Speicherung der lokalen Variablen und Zustände.
   • Kritische Eigenschaft: Die eigentliche Funktionslogik startet nicht (function does _not_ start executing). Das Future-Objekt wird unmittelbar an Main zurückgegeben.
2. Scheduler-Übergabe:
   • Main delegiert die Ausführung via spawn(Future) an den Executor und übergibt die Kontrolle via await oder block_on.
3. Kooperative Polling-Schleife (opt [0..N times]):
   • Executor ruft poll auf dem Future auf.
   • Erstaufruf: Einstieg am Kopf der Funktion.
   • Folgeaufrufe: Wiedereinstieg am exakten Punkt des letzten await.
   • Bei unvollendeten E/A- oder Rechenoperationen unterbricht die Funktion via await und signalisiert Pending an den Executor zurück (Thread bleibt nicht-blockierend für andere Tasks frei).
4. Terminierung & Teardown:
   • Ein finaler poll-Aufruf führt die Funktion bis zum return.
   • Rückgabe von Ready(value) an den Executor; die Future-Ressourcen werden deallokiert.
   • Der Executor propagiert den Endwert value an Main.

4. Normative Relevanz & Entwickler-Hinweise

• Pull- vs. Push-Semantik: Im Gegensatz zu C++ ARA (ara::core::Promise/Future), bei denen asynchrone Berechnungen typischerweise unmittelbar eager im Hintergrund anlaufen, ist Rusts Future rein lazy. Wird ein Rückgabewert einer async fn nicht gepollt (#[must_use]), findet keinerlei Ausführung oder Fortschritt statt.
• Echtzeit- und Blockierverbot: Innerhalb einer async function dürfen keine synchron blockierenden Systemrufe (z. B. POSIX pthread_mutex_lock, blockierendes Socket-Read, sleep) verwendet werden. Sie blockieren den gesamten Thread-Pool des Executor und verletzen das deterministische Scheduling der Adaptive Platform.
• Speicherlayout & ASIL-Konformität: Die durch den Rust-Compiler erzeugte State Machine besitzt eine feste Größe, benötigt zur Compile-Zeit jedoch bekannte Größen (Sized). Rekursive async-Pfade oder dynamische Trait-Objekte (Box<dyn Future>) erfordern dynamische Allokationen auf dem Heap, die in deterministischen Safety-Kontexten (ISO 26262) strikt vermieden oder über statische Allokatoren gekapselt werden müssen.
• Integration mit Execution Management (EM): Der Executor bildet die Brücke zwischen dem AUTOSAR AP OS/EM-Threading-Modell und den kooperativen Rust-Tasks. Prioritäten und CPU-Affinitäten müssen auf Ebene der Worker-Threads des Executors im ARXML-Manifest konfiguriert werden.