Figure 6.14: Future

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Formale C++-Klassenschnittstellendeklaration (Header-Code-Spezifikation) der Template-Klasse ara::com::Future<T>.
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), Subsystem Communication Management (ara::com), Method Call Pattern.
• Funktionale Einordnung: Repräsentiert das konsumierende Leseende (Consumer/Client) eines asynchronen Methodenaufrufs. Es kapselt den geteilten Zustand (Shared State), dessen schreibendes Gegenstück (ara::com::Promise<T>) auf Anbieter- bzw. Binding-Ebene liegt, und synchronisiert Resultats- oder Ausnahmeübergaben zwischen Producer und Consumer.

2. Komponenten, Entitäten & Schnittstellen

• Klassendefinition: Template Future<T> (Werteklasse für asynchrone Rückgaben des Typs T).
• Ressourcen- und Lifecycle-Management (Move-Only Semantics):
  • Copy-Operationen explizit unterbunden: Future(const Future&) = delete;, operator=(const Future&) = delete;.
  • Move-Semantik garantiert Allokations- und Eigentümertransfer ohne Exceptions: Future(Future&&) noexcept;, operator=(Future&&) noexcept; (im Code mit Kommentar /** movable */ deklariert).
• Standardisierte C++11/C++14-Schnittstellen (std::future-kompatibel):
  • T get(): Synchrone Entnahme des Werts; blockiert bis zur Bereitstellung. Invalidiert den internen Shared State für Folgeabfragen.
  • bool valid() const: Prüft, ob die Instanz mit einem Shared State assoziiert ist.
  • void wait() const: Blockiert den Aufruferthread bis zum Eintreffen von Daten oder Fehlern.
  • template<class Rep, class Period> FutureStatus wait_for(const std::chrono::duration<Rep,Period>& timeout_duration) const: Relatives, zeitbegrenztes Warten mit Statusrückgabe (FutureStatus::ready, timeout).
  • template<class Clock, class Duration> FutureStatus wait_until(const std::chrono::time_point<Clock,Duration>& abs_time) const: Absolutes Frist-Warten.
• Erweiterte Asynchronie-Schnittstellen (angelehnt an C++ Concurrency TS N3857):
  • template <typename F> auto then(F&& func) -> Future<decltype(func(*this))>: Registrierung einer Continuation. Nimmt ein Callable func entgegen, welches das dereferenzierte Future (*this) als Parameter erhält. Erzeugt ein neues Folge-Future für Verkettungen.
  • bool is_ready() const: Nicht-blockierende Statusabfrage zur Prüfung auf Vorhandensein eines Ergebnisses oder einer Exception.

3. Dynamisches Verhalten & Sequenzablauf

• Synchroner Abrufpfad (Polling / Blocking):
  1. Client initiiert RPC-Aufruf via Proxy und erhält sofort Future<T>.
  2. Client ruft is_ready() (zyklischer Check) oder wait() / wait_for() / wait_until() auf.
  3. Nach Transition in den Zustand ready ruft der Client get(). Der Rückgabewert wird gemovt/kopiert; der interne Zustand wird detacht.
• Reaktiver Pfad (Event-driven Continuation via then):
  1. Client registriert Lambda/Funktor via then(F&& func).
  2. Ausführungskontext von func:
     • Bereits fertig: Wird unmittelbar im Kontext des then()-Aufrufs ausgeführt.
     • Noch ausstehend: Wird im Kontext des Produzenten (Promise::set_value(), Promise::set_exception()) oder durch einen Thread-Pool des Middleware-Bindings ausgeführt.
  3. Invariante: Beim Eintritt in func ist is_ready() == true; ein darin abgesetztes get() blockiert garantiert nicht mehr.
• Fehler- und Abbruchpfad:
  • Schlägt der Remote-Methodenaufruf fehl, persistiert das Binding eine Exception im Shared State.
  • is_ready() wird true.
  • Der Aufruf von get() re-triggert die gespeicherte Exception im Kontext des abrufenden Threads.

4. Normative Relevanz & Entwickler-Hinweise

• Thread-Safety & Deadlock-Vermeidung: Da der Ausführungskontext von then() nicht deterministisch auf den Aufrufer-Thread festgelegt ist, dürfen Continuations keine ungeschützten lokalen Thread-Ressourcen capturen und keine rekursiven Locks auf Mutexe anfordern, die im Producer-Kontext gehalten werden.
• Single-Consumer-Restriktion: Durch das Löschen des Copy-Konstruktors kann ein Future nicht auf mehrere Threads parallel verteilt werden (std::shared_future-Semantik wird hier nicht bereitgestellt). Für Multiple-Consumer-Szenarien muss das Ergebnis manuell nach get() propagiert werden.
• Spezifikatorische Evolution (R17-03 / R17-10 vs. Folge-Releases):
  • In den Releases R17-03 und R17-10 stützt sich das Fehlerkonzept primär auf C++-Exceptions (Promise::set_exception).
  • Architektur-Hinweis für Adaptive-Entwickler: In späteren Releases (ab R18-03 bzw. R19-11) wurde das Exception-basierte Modell durch ara::core::Result<T, E> abgelöst. ara::core::Future arbeitet seither weitgehend exception-frei und liefert Typen wie ara::core::Result<T> zurück, um den Safety-Anforderungen (MISRA C++:2008 / AUTOSAR C++14 Rule A15-0-X bezüglich Determinismus im Stack-Unwinding) zu genügen.