Genau ein Prozess kann zu einem bestimmten Zeitpunkt auf einem Prozessor (Kern) laufen.

Die Anzahl der vorhandenen Prozesse muss genau der Anzahl der Prozessoren (Kerne) entsprechen.

Alle Prozesse laufen gleichzeitig, daher ist kein Scheduling erforderlich.

Es gibt mehr Prozesse als Prozessoren (Kerne), daher können nicht alle gleichzeitig ausgeführt werden.

Kontra: Sie bieten weniger direkte Kontrolle über einzelne Threads als bei der manuellen Verwaltung.

Thread-Pools können nicht für Hintergrundaufgaben verwendet werden.

Pro: Sie verhindern, dass in einer Warteschlange liegende Aufgaben unter hoher Last warten müssen.

Sie werden häufig für Hintergrund- oder Worker-Aufgaben eingesetzt.

Pro: Sie beseitigen den wiederholten Overhead durch das Erstellen/Beenden von Threads.

Kontra: Wenn alle Worker-Threads ausgelastet sind, müssen neue Aufgaben warten, bis ein Thread frei wird.

Kontra: Sie erfordern dennoch, dass für jede neue Aufgabe ein eigener Thread erstellt wird.

Der Systemaufruf execve ersetzt den aufrufenden Prozess durch den aufgerufenen Prozess.

Der Systemaufruf fork erstellt einen Klon des aufrufenden Prozesses.

Nach einem fork erhält der Kindprozess eine eindeutige Prozess-ID (PID).

Der Systemaufruf fork führt direkt einen Befehl aus.

Der Systemaufruf execve erstellt einen Kindprozess.

Interrupts blockieren die CPU für jeglichen Code, bis das Betriebssystem sie explizit neu startet.

Polling ist in Bezug auf Effizienz immer Interrupts überlegen.

Interrupts können jederzeit auftreten und machen das System asynchron.

Die Häufigkeit und Dauer der ISR-Ausführung kann das Gesamttiming beeinflussen.

Länger laufende ISRs können die Antwortzeiten eines Systems verschlechtern.

Die Bearbeitungszeit von ISRs sollte minimiert werden, um die Aufgabenplanung möglichst wenig zu stören.

Interrupts sind grundsätzlich synchron, da sie nur zu vorab definierten Zeiten vom OS ausgelöst werden.

Fairness

Maximierung der CPU-Auslastung ist das Hauptziel interaktiver Systeme.

Minimierung der Antwortzeiten ist ein wesentliches Ziel.

Das Einhalten strikter Deadlines ist das Hauptziel.

Bereitstellung von Proportionalität, d. h. die Erfüllung der Nutzererwartungen an die Systemleistung.

Threads sind weniger ressourcenintensiv als Prozesse, da sie keine separaten Ressourcen oder Adressräume besitzen.

Threads benötigen keine Ressourcen, um zu funktionieren.

Threads teilen Ressourcen und Adressraum mit ihrem Elternprozess, wodurch sie weniger ressourcenintensiv sind als vollständige Prozesse.

Threads arbeiten vollständig unabhängig von ihrem Elternprozess.

Befehlszeilenargumente

Informationen über den Prozesskontext

Speicheradresse der aktuell ausgeführten oder nächsten Anweisung

Name der ausführbaren Datei

Anzahl der Benutzerinteraktionen (wie oft hat der Benutzer den Prozess in den Vordergrund geholt)

Browser-Cookies

Zeitstempel des Prozessstarts

Auf dem Heap angelegte Speicherobjekte

An Funktionsaufrufe übergebene Parameter

Rückgabewert der Funktionen

Prozess-ID

Sicherheitsattribute (z. B. Berechtigungen)

Dateideskriptoren oder Ressourcen-Handles

Lokale Variablen der Funktionen

Die Ausführung einer ISR sollte möglichst kurz gehalten werden; umfangreichere Aufgaben sollten an einen OS-Prozess delegiert werden.

Interrupts können nur zu festen, vom OS definierten Zeitpunkten auftreten.

ISRs sind immer normale Benutzerprozesse.

Interrupts können auch ohne Betriebssystem funktionieren.

Polling ist eine Alternative zu Interrupts, aber oft weniger effizient.

Der OS-Scheduler muss einen Interrupt genehmigen, bevor er behandelt wird.

ISRs (Interrupt Service Routines) werden nicht wie normale OS-Threads geplant.