class ara::shwa::Buffer

Die Klassenvorlage dient der Verwaltung mehrdimensionaler Speicherpuffer für die sichere Hardwarebeschleunigung in der Adaptive Platform SWS_SafeHardwareAcceleration §7.1 „High Level Design of Safe Hardware Acceleration in an Adaptive Platform“. Da alle Standard-, Kopier- und Verschiebeoperationen gelöscht sind, erfolgt die Erzeugung ausschließlich über statische Factory-Methoden wie [AP_SWS_SHWA_00209] als exklusiv gehaltener Zeiger. Über konfigurierbare Eigenschaften und Allokatoren lässt sich der Speicher anpassen, während Lesezugriffe auf Eigenschaften nicht threadsicher ausgelegt sind. Fehlgeschlagene Speicherreservierungen werden über definierte Fehlercodes an den Aufrufer zurückgemeldet.

mehr ›

Kontext

Die Template-Klasse ara::shwa::Buffer bildet im Modul Safe Hardware Acceleration (SHWA) der Adaptive Platform eine zentrale Abstraktion zur Kapselung und Verwaltung von mehrdimensionalen Speicherbereichen. Wie in der Systemarchitektur dargelegt, interagieren Adaptive Applications sowie funktionale Cluster typischerweise mit einer Kombination aus mehreren Warteschlangen (Queues), Beschleunigergeräten (Devices) und Puffern (SWS_SafeHardwareAcceleration §7.1 „High Level Design of Safe Hardware Acceleration in an Adaptive Platform“). Puffer stellen dabei den Speicher zur Verfügung, der für Beschleunigungsoperationen auf Host- oder Device-Ebene benötigt wird, und können optional durch anwendungsspezifische Allokatoren ([AP_SWS_SHWA_00210]) oder Host-Datenzeiger konfiguriert werden.

Kontextdiagramm: Einbettung des Puffers in das funktionale Zusammenspiel von Anwendungen, Geräten, Warteschlangen und Allokatoren. Quellen: SWS_SafeHardwareAcceleration §7.1 „High Level Design of Safe Hardware Acceleration in an Adaptive Platform“, [AP_SWS_SHWA_00210].

Lebenszyklus

Der Lebenszyklus einer Pufferinstanz unterliegt strengen semantischen Einschränkungen. Zur Gewährleistung eindeutiger Besitzverhältnisse sind sowohl der Standardkonstruktor ([AP_SWS_SHWA_00202]) als auch Kopierkonstruktor ([AP_SWS_SHWA_00203]) und Kopierzuweisungsoperator ([AP_SWS_SHWA_00204]) gelöscht. Ebenso sind der Verschiebekonstruktor ([AP_SWS_SHWA_00205]) und der Verschiebezuweisungsoperator ([AP_SWS_SHWA_00206]) explizit gelöscht. Interpretation: Dies dürfte verhindern, dass Pufferressourcen oder Hardwarebeziehungen unkontrolliert im Speicher dupliziert oder versetzt werden. Frage Q-dcabd66fa9f3ec2a (offen)

Die Erzeugung erfolgt daher ausschließlich über statische Factory-Methoden der Überladungsfamilie Create, die im Erfolgsfall einen std::unique_ptr<Buffer> gekapselt in einem ara::core::Result zurückliefern. Dabei stehen verschiedene Konstruktionspfade zur Verfügung:

• Erzeugung mit Pufferbereich und optionaler Eigenschaftsliste: thread-safe ([AP_SWS_SHWA_00209]).
• Erzeugung mit Pufferbereich, dediziertem Allokator und Eigenschaftsliste: thread-safe ([AP_SWS_SHWA_00210]).
• Erzeugung auf Basis bestehender Host-Datenzeiger mit Pufferbereich: thread-safe sowohl für modifizierbare Zeiger ([AP_SWS_SHWA_00211]) als auch für konstante Datenzeiger ([AP_SWS_SHWA_00213]).
• Erzeugung mit konstantem Host-Datenzeiger, Pufferbereich und Allokator: thread-safe ([AP_SWS_SHWA_00214]).
• Direkte Erzeugung allein über einen Allokator: nicht thread-safe ([AP_SWS_SHWA_00212]).

Der Besitz verbleibt nach erfolgreicher Erzeugung beim aufrufenden Kontext via std::unique_ptr. Die Zerstörung des Objekts bei Ablauf des Smart-Pointers dürfte den zugrundeliegenden Speicherbereich über den jeweiligen Allokator automatisch freigeben. Frage Q-aa2b5642b8527803 (offen)

Nutzungspfad

Ein typischer Nutzungspfad beginnt mit der Allokation und Initialisierung des Puffers über eine der thread-safe Factory-Methoden wie [AP_SWS_SHWA_00209]. Nach erfolgreicher Instanziierung kann die Anwendung überprüfen, ob spezifische Eigenschaften für diesen Puffer hinterlegt sind, indem sie HasProperty<PropertyT>() aufruft ([AP_SWS_SHWA_00215]). Ist die gewünschte Eigenschaft vorhanden, kann ihr konkreter Wert synchron über GetProperty<PropertyT>() ausgelesen werden ([AP_SWS_SHWA_00216]). Es ist zu beachten, dass sowohl HasProperty als auch GetProperty als nicht thread-safe deklariert sind; nebenläufige Abfragen am selben Pufferobjekt müssen daher anwendungsseitig synchronisiert werden.

Sequenzdiagramm: Typische Abfolge bei Instanziierung über die Factory und anschließender Eigenschaftsabfrage. Quellen: [AP_SWS_SHWA_00209], [AP_SWS_SHWA_00215], [AP_SWS_SHWA_00216].

Fehlerszenarien

Sämtliche Factory- und Inspektionsmethoden sind mit noexcept deklariert und bieten uneingeschränkte Ausnahme-Sicherheit (exception safe). Fehler werden über das ara::core::Result signalisiert:

• Schlägt bei einem Aufruf von Create die Speicherallokation auf Host- oder Beschleunigerseite fehl, wird der Fehler ShwaErrorCode::kMemoryNotAllocated zurückgegeben ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210], [AP_SWS_SHWA_00211], [AP_SWS_SHWA_00212], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Als Rollback-Semantik ist hierbei ShwaErrorCode::kRuntime definiert.
• Wird über GetProperty<PropertyT>() eine Eigenschaft abgefragt, die vom Puffer oder der Plattform nicht unterstützt wird, liefert das Resultat den Fehlercode ShwaErrorCode::kFeatureNotSupported ([AP_SWS_SHWA_00216]). Zur Vermeidung dieses Fehlers empfiehlt sich die Vorabprüfung mittels HasProperty<PropertyT>() ([AP_SWS_SHWA_00215]).