Figure 7.3: minimal state machine of a task

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm (State Machine Diagram) zur Darstellung des minimalen Task-Lebenszyklus.
• Technischer Zweck: Definition des normativen Referenz-Zustandsautomaten für Tasks im Rahmen des AUTOSAR Adaptive Platform (AP) Operating System Interface (AUTOSAR_AP_SWS_OperatingSystemInterface) und der ARTI-Tracing-Schnittstelle (AUTOSAR Run-Time Interface).
• Architektur-Einordnung: Ein Task bildet die kleinste durch das Betriebssystem schedulbare Einheit (analog zu Threads unter POSIX/OS-Ebene). Das Diagramm harmonisiert heterogene OS-Implementierungen (z. B. Linux, QNX, PikeOS), indem es eine einheitliche Abstraktion für Run-Time-Tracing, Scheduling-Analyse und Profiling bereitstellt.

2. Komponenten, Entitäten & Schnittstellen

• Zustände (States):
  • Non-existent: Pseudo-Initialzustand vor der Allokation/Instanziierung des Tasks durch das OS.
  • Ready: Der Task ist ausführungsbereit und befindet sich in der Scheduling-Warteschlange des Kernels.
  • Running: Der Task belegt aktuell eine CPU-Core-Ressource und führt Instruktionen aus.
  • Waiting: Der Task ist blockiert und wartet auf ein externes Ereignis, eine OS-Ressource (z. B. Semaphor, Mutex, Condition Variable) oder einen anderen Thread; er ist nicht schedulbar.
  • Terminated: Finaler Zustand; der Task hat die Ausführung beendet und Ressourcen werden freigegeben.
• Transitionstrigger / Trace-Punkte:
  • Create: Übergang von Non-existent nach Ready (Task-Erzeugung).
  • Schedule: Zuweisung von CPU-Rechenzeit an den Task (Ready → Running bzw. Self-Transition Running → Running).
  • Preempt: Verdrängung des Tasks durch einen höherpriorisierten Task oder Ablauf des Time-Slices (Running → Ready).
  • Wait: Blockierender Aufruf oder Warten auf OS-Synchronisationsobjekte (Running → Waiting).
  • Release: Eintreffen des erwarteten Events / Entsperren des Synchronisationsobjekts (Waiting → Ready).
  • Terminate: Beendigung des Tasks (Running → Terminated).

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierung & Dispatching:
  1. Non-existent $\xrightarrow{\text{Create}}$ Ready: Das OS instanziiert den Task-Kontrollblock und reiht den Task in die Ready-Queue ein.
  2. Ready $\xrightarrow{\text{Schedule}}$ Running: Der Scheduler wählt den Task aus; Kontextwechsel auf die CPU.
• Laufzeit-Scheduling & Verdrängung:
  • Running $\xrightarrow{\text{Preempt}}$ Ready: Preemption durch Prioritätsinversion-Auflösung, höherpriore Threads oder Round-Robin-Zeitscheibenablauf.
  • Running $\xrightarrow{\text{Schedule}}$ Running: Self-Transition; signalisiert Scheduling-Ereignisse ohne Zustandswechsel (z. B. Quell-/Zielkernwechsel bei SMP-Migration oder Erneuerung des Scheduling-Budgets).
• Blockierung & Reaktivierung:
  • Running $\xrightarrow{\text{Wait}}$ Waiting: Eintritt in den blockierenden Wartezustand durch Synchronisationsprimitive (POSIX pthread_mutex_lock, pthread_cond_wait, Semaphore).
  • Waiting $\xrightarrow{\text{Release}}$ Ready: Reaktivierung nach Event-Eintreffen. Ein direkter Übergang von Waiting nach Running ist ausgeschlossen; der Task muss stets über Ready die Scheduler-Warteschlange passieren.
• Terminierung:
  • Running $\xrightarrow{\text{Terminate}}$ Terminated: Geordnetes Beenden (pthread_exit, Rücksprung der Task-Funktion) oder Abbruch.

4. Normative Relevanz & Entwickler-Hinweise

• ARTI-Tracing-Konformität:
  • Die Trace-Events zwischen Ready und Running (Schedule, Preempt) sind für konforme AP-OS-Adaptionen zwingend verpflichtend (mandatory).
  • Für Betriebssysteme, die nicht explizit zwischen Ready und Waiting differenzieren (oder deren Kernel-Hooks dies nicht isolieren), sind die ARTI-Trace-Events für den Waiting-Zustand optional.
• Trace-Decoder & Profiler-Implementierung:
  • Trace-Analysewerkzeuge müssen tolerant gegenüber schwach geordneten Declarations/Log-Outputs sein, da Erzeugung, Modifikation und Destruktion in Multicore-/Multiprozess-Umgebungen nicht zwingend strikt synchron serialisiert erfasst werden.
• Einschränkungen für Plattform- & OS-Integratoren:
  • Direkte Übergänge wie Waiting → Running sind semantisch unzulässig und führen bei ARTI-Validatoren zu Protokollverletzungen.
  • POSIX-Thread-Zustände der zugrundeliegenden OS-Schicht müssen deterministisch auf diese minimale Zustandsmenge abgebildet werden.