Figure 7.15: Worker Pool Usage

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Ausführungs- und Nebenläufigkeitsdiagramm (Concurrency & Data-Partitioning Pattern).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Execution Management (ara::exec), Themenbereich Deterministic Execution.
• Funktionaler Zweck: Visualisierung des deterministischen Parallelisierungsmusters für datenparallele Verarbeitung. Ein Arbeitsvolumen (Container) wird über einen Iterationsmechanismus in disjunkte Datensätze zerlegt und in synchronisierten Batches auf einen vorab initialisierten Worker-Pool verteilt, um Berechnungen ohne Laufzeit-Threadallokation deterministisch auszuführen.

2. Komponenten, Entitäten & Schnittstellen

• parameter object (container):
  • Linearer, indexierbarer Datencontainer (z. B. Array, Vector oder contiguous Memory Buffer), der die zu verarbeitenden Nutzdaten hält.
• iterator:
  • Traversierungs- und Partitionierungslogik. Segmentiert den Datencontainer in disjunkte Teilsätze (Slices/Batches) entsprechend der Dimensionierung des Worker-Pools.
• 1st set of container elements / 2nd set of container elements:
  • Sequenzielle Partitionen des Containers. Jedes Element eines Sets wird exakt einem dedizierten Worker zugewiesen (Kardinalität 1:1 pro Durchlauf).
• worker pool:
  • Ausführungsumgebung bestehend aus einer fest konfigurierten Anzahl von Ausführungseinheiten (hier: 4 Worker-Threads). Diese sind während der Initialisierungsphase erzeugt und an den Prozess gebunden.
• worker:
  • Homogene, blockierungsfreie Worker-Threads innerhalb des Pool-Kontexts.
• worker runnable object:
  • Instanziertes Funktionsobjekt (Callable/Funktor), das den auszuführenden Algorithmus kapselt. Es wird referentiell an alle Worker übergeben (Kardinalität 1:N).

3. Dynamisches Verhalten & Sequenzablauf

1. Aufteilung (Partitioning): Der iterator zerlegt den Gesamtcontainer anhand der Worker-Pool-Kapazität (N = 4) in sequenzielle Ausführungswellen.
2. Phase 1 (1st set):
   • Die ersten 4 Elemente des Containers (1st set) werden parallel an die 4 Worker übergeben.
   • Jeder Worker bindet das gemeinsame worker runnable object an sein zugewiesenes Containerelement und führt die Nutzlogik synchron aus.
3. Synchronisationsbarriere (Barrier/Join):
   • Das System wartet am Ende der ersten Welle auf den Abschluss aller 4 Worker-Instanzen, um Zustandskonsistenz und zeitlichen Determinismus zu garantieren.
4. Phase 2 (2nd set):
   • Der Iterator rückt vor; die nächsten 4 Elemente (2nd set) werden in die frei gewordenen Worker eingespeist.
   • Ausführung des worker runnable object auf der zweiten Tranche.
5. Abschluss: Nach Erreichen des Container-Endes erfolgt der Rücksprung an den aufrufenden Task/Thread des deterministischen Clients.

4. Normative Relevanz & Entwickler-Hinweise

• Reentrancy & Thread-Safety: Das worker runnable object muss strikt thread-sicher und seiteneffektfrei sein. Es darf keinen ungeschützten gemeinsamen Zustand (Shared Mutable State) modifizieren; der Zugriff muss auf das jeweils übergebene Container-Element isoliert bleiben.
• Lock-Freiheit (Deterministic Execution): Innerhalb des worker runnable object sind blockierende OS-Primitive (Mutexes, Semaphoren, Condition Variables, dynamische Heap-Allokationen) unzulässig, da sie Scheduling-Jitter und Inversionen hervorrufen und den Determinismus brechen.
• Ressourcenkonfiguration (Execution Manifest): Die Größe des Worker-Pools wird zur Entwurfs-/Integrationszeit im Manifest deklariert und an CPU-Cores/Cgroups gepinnt (Core Affinity). Zur Laufzeit finden keine dynamischen Thread-Erzeugungen statt.
• Speicher- und Cache-Lokalität: Die Aufteilung über den Iterator sollte auf Alignment und Cache-Line-Größen (False Sharing vermeiden) optimiert sein, wenn Worker auf zusammenhängenden Speicherbereichen schreiben.