class apext::sm::PowerStateInterface

Die Schnittstelle koordiniert als OS-Wrapper die Energiezustände zwischen dem State Management und dem Betriebssystem ([SWS_SM_71000]). Das State Management registriert über sie vorab Callback-Handler für Aufwachereignisse und leitet konkrete Zustandsanforderungen an das Betriebssystem weiter ([SWS_SM_71001]). Nach erfolgter Reaktivierung lässt sich die Handler-Registrierung im OS-Wrapper wieder aufheben. Als wesentliche funktionale Randbedingung gilt, dass sämtliche Methodenaufrufe nicht threadsicher sind und daher vom Aufrufer zwingend serialisiert werden müssen.

mehr ›

Kontext

Die C++-Klasse apext::sm::PowerStateInterface fungiert als funktionale Schnittstelle des Moduls State Management zur Koordination von Energiezuständen mit dem Betriebssystem ([SWS_SM_71000], SWS StateManagement §C.1.2 „Class: PowerStateInterface“). In der Systemarchitektur übernimmt sie die Rolle eines OS-Wrappers, der Anforderungen des State Managements an das darunterliegende Betriebssystem weiterleitet und Rückmeldungen empfängt. An der Gesamtinteraktion sind drei Kernkomponenten beteiligt: das State Management als koordinierende Instanz, die Klasse PowerStateInterface als Vermittler sowie das Host-Betriebssystem, welches die hardwarenahe Energieverwaltung ausführt ([SWS_SM_71001]).

Kontextdiagramm: Koordination von Energiezuständen und Aufwachsignalen zwischen State Management, OS-Wrapper und Betriebssystem. Quellen: [SWS_SM_71000], [SWS_SM_71001], [SWS_SM_71003].

Lebenszyklus

Die Erzeugung und Zerstörung von Instanzen der Klasse PowerStateInterface ist in den Spezifikationsdokumenten nicht über explizite Fabrikmethoden geregelt. Die Instanziierung dürfte der Interpretation nach durch das State Management während dessen Initialisierungsphase erfolgen, um den OS-Wrapper bereitzustellen. Frage Q-15bde6ce044e9bc3 (offen) Für die Einbindung der Klasse ist der Header apext/sm/power_state_interface.h vorgesehen ([SWS_SM_71001], SWS StateManagement §C.1.2.1.1 „Member Functions“).

Hinsichtlich des internen Zustands verwaltet das Objekt die Registrierung eines Handlers für Aufwachereignisse. Dieser Zustand bleibt aktiv, bis der Handler explizit wieder entfernt wird ([SWS_SM_71005]). Bezüglich der Nebenläufigkeit sind alle Mitgliedsfunktionen als nicht threadsicher (not-threadsafe) eingestuft ([SWS_SM_71001], [SWS_SM_71003], [SWS_SM_71005]). Das aufrufende State Management muss daher eigenverantwortlich sicherstellen, dass Aufrufe an eine Instanz strikt serialisiert werden und keine ungeschützten parallelen Zugriffe aus mehreren Threads stattfinden.

Nutzungspfad

Ein typischer Nutzungspfad zur Steuerung von Energiezuständen und zur Entgegennahme von Aufwachsignalen vollzieht sich in mehreren aufeinander abgestimmten Schritten:

• Handler-Registrierung: Vor der Einleitung eines Energiesparzustands registriert das State Management mittels RegisterWakeUpHandler eine Callback-Funktion vom Typ apext::sm::WakeUpHandler im OS-Wrapper ([SWS_SM_71003], SWS StateManagement §C.1.2.1.1.1 „RegisterWakeUpHandler“). Dadurch wird festgelegt, wie das State Management über nachfolgende Aufwachvorgänge in Kenntnis gesetzt wird.
• Zustandsanforderung: Anschließend ruft das State Management die Methode SetPowerState mit dem gewünschten Zielzustand apext::sm::PowerState auf ([SWS_SM_71001], SWS StateManagement §C.1.2.1.1.2 „SetPowerState“). Das Interface leitet diese Anforderung unmittelbar an das Betriebssystem weiter. Die technische Umsetzung des Übergangs erfolgt vermutlich plattformspezifisch im Betriebssystem. Frage Q-29345b74ba3bedf2 (offen)
• Aufwachbenachrichtigung: Erkennt das Betriebssystem ein Aufwachereignis, wird die Benachrichtigung an den OS-Wrapper gemeldet. Dieser führt den zuvor registrierten WakeUpHandler aus. Der Aufruf dürfte der Interpretation nach asynchron im Ausführungskontext des Reaktivierungsvorgangs erfolgen. Frage (offen)
• Handler-Deregistrierung: Sobald der Aufwachprozess abgeschlossen ist oder das State Management keine weiteren Benachrichtigungen benötigt, wird der registrierte Callback über UnregisterWakeUpHandler aus dem OS-Wrapper entfernt ([SWS_SM_71005], SWS StateManagement §C.1.2.1.1.3 „UnregisterWakeUpHandler“).

Sequenzdiagramm: Typischer Ablauf der Handler-Registrierung, Zustandsweiterleitung an das Betriebssystem und Deregistrierung. Quellen: [SWS_SM_71001], [SWS_SM_71003], [SWS_SM_71005].

Fehlerszenarien

Die Schnittstellenmethoden RegisterWakeUpHandler, SetPowerState und UnregisterWakeUpHandler besitzen den Rückgabetyp void und definieren keine spezifischen Fehlerrückgabecodes ([SWS_SM_71001], [SWS_SM_71003], [SWS_SM_71005]). Sämtliche Funktionen sind als noexcept deklariert und garantieren vollständige Ausnahme-Sicherheit (exception safe).

Fehlerhafte Systemzustände können primär aus Verletzungen von Vorbedingungen entstehen. Hierzu zählt die Verletzung der geforderten Threadsicherheit durch ungeschützte parallele Methodenaufrufe. Des Weiteren muss das State Management als Vorbedingung für RegisterWakeUpHandler sicherstellen, dass das übergebene Funktionsobjekt gültig ist und bis zur Aufhebung durch UnregisterWakeUpHandler im Speicher verbleibt ([SWS_SM_71003], [SWS_SM_71005]).