Multithreading-Konzepte sind Teil des Hungers

Willkommen zu Teil 2 unserer Multithreading-Serie! In Teil 1 haben wir Atomizität und Unveränderlichkeit untersucht.

In diesem Teil werden wir tiefer eintauchen, um Aushungerung zu verstehen, da es für Ingenieure von wesentlicher Bedeutung ist, weil es Fairness und Systemleistung gewährleistet. Durch das Erkennen von Hungerrisiken können Ingenieure Systeme entwerfen, die Fairness priorisieren, eine Ressourcenmonopolisierung verhindern und sicherstellen, dass alle Threads die nötige CPU-Zeit und Ressourcen erhalten, um optimal zu funktionieren.

Das endlose Warten in Spielelobbys

Stellen Sie sich vor, Sie spielen ein Online-Multiplayer-Spiel und versuchen, einer Lobby für einen beliebten Spielmodus beizutreten, beispielsweise einen Teamkampf. Sie warten schon eine Weile in der Lobby, aber jedes Mal, wenn ein Spiel beginnt, wird eine neue Gruppe von Spielern mit schnellerem Internet oder höherem Fähigkeitsranking priorisiert und vor Ihnen zum Spiel hinzugefügt. Man sieht immer wieder Spiele, die immer wieder beginnen, aber man scheint nie reinzukommen!

Technisch gesehen befinden Sie sich in der Warteschlange, aber da andere Spieler mit schnelleren Reaktionszeiten oder höheren Rängen immer zuerst in die Spiele einsteigen, bleiben Sie auf unbestimmte Zeit in der Lobby. Obwohl Sie über ein perfekt funktionierendes System verfügen, wird Ihnen die Chance zum Spielen verwehrt, da der Matchmaking-Algorithmus andere zu Unrecht priorisiert.

1. Hunger

Hunger ist eine Situation, in der einem Prozess ständig der Zugriff auf die Ressourcen verweigert wird, die er zum Fortfahren benötigt, obwohl diese Ressourcen verfügbar sind. Der Prozess bleibt in einem Wartezustand, da Prozesse mit höherer Priorität oder andere Ressourcenzuweisungsrichtlinien ihn daran hindern, die erforderlichen Ressourcen zu erhalten. Im Gegensatz zu Deadlock sind die Ressourcen nicht völlig unverfügbar, aber der Prozess kann aufgrund unfairer Planung nicht auf sie zugreifen.

2. Ursachen

• Prioritätsumkehr: Wenn ein Prozess mit höherer Priorität auf eine Ressource wartet, die von einem Prozess mit niedrigerer Priorität gehalten wird, wird dem Prozess mit niedrigerer Priorität möglicherweise CPU-Zeit entzogen, während andere Prozesse mit höherer Priorität haben Es kommen immer wieder Prozesse an.

• Richtlinien zur Ressourcenzuweisung: Einige Planungsalgorithmen bevorzugen möglicherweise bestimmte Prozesse (normalerweise solche mit höheren Prioritäten), was dazu führt, dass Prozessen mit niedrigerer Priorität selten Ressourcen zugewiesen werden.

• Schlecht konzipierte Algorithmen: Wenn der Ressourcenzuweisungsalgorithmus nicht ausgewogen oder fair ist, kann es dazu führen, dass bestimmte Prozesse ständig übersehen werden.

• Hoher Ressourcenbedarf: Wenn einige Prozesse übermäßig viele Ressourcen benötigen, können sie andere Prozesse aushungern lassen, indem sie diese Ressourcen monopolisieren.

• Lange Wartezeiten: Prozesse, die häufig unterbrochen werden oder sich im Wettbewerb um begrenzte Ressourcen befinden, können unter Umständen ausfallen.

3. Hunger verhindern

• ReentrantLock mit Fairness verwenden

Javas ReentrantLock bietet eine Option zur Durchsetzung von Fairness. Durch die Verwendung des Konstruktors ReentrantLock mit dem Argument true können wir sicherstellen, dass Threads die Sperre nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ (FCFS) erhalten, wodurch ein Aushungern verhindert wird.

private final Lock lock = new ReentrantLock(true); // Fair lock

• Verwendung von Semaphore für eine faire Ressourcenteilung

Ein Semaphor wird verwendet, um den Zugriff auf eine begrenzte Anzahl von Ressourcen zu steuern. Durch die Verwendung eines Semaphors mit aktivierter Fairness können wir sicherstellen, dass Threads Berechtigungen in einer fairen Reihenfolge erhalten und so ein Aushungern vermeiden.

private final Semaphore sp = new Semaphore(1, true); // Fair semaphore

Der Semaphor (1, true) ist ein Semaphor mit nur einer Genehmigung und aktivierter Fairness.

• Vermeidung von Hungersnöten im Producer-Consumer-Problem (mit BlockingQueue)

Bei traditionellen Produzenten-Konsumenten-Problemen kann es zu Hungersnöten kommen, wenn der Produzent den Konsumenten überfordert oder wenn den Konsumenten der Zugriff auf die gemeinsam genutzte Ressource verweigert wird. BlockingQueue verhindert dies, da es automatisch die Synchronisierung zwischen Produzenten und Konsumenten übernimmt. Sowohl der Produzent als auch der Verbraucher werden blockiert, wenn die Warteschlange voll bzw. leer ist. Dies sorgt für ein ausgewogenes Verhältnis zwischen beiden und verhindert, dass das eine das andere überwältigt, wodurch ein Hungertod vermieden wird.

• Verwendung von Javas ForkJoinPool für eine faire Aufgabenplanung

In Szenarien, in denen mehrere Aufgaben gespalten und verbunden werden, bietet ForkJoinPool in Java eine Möglichkeit, die Arbeit gerecht auf die Threads zu verteilen. Es gewährleistet Arbeitsdiebstahl und verhindert das Aushungern weniger aktiver Threads. ForkJoinPool von Java verwaltet die Aufgabenaufteilung und -verteilung effizient und stellt sicher, dass kein Thread für Arbeit ausgehungert wird. Dies wird mithilfe eines Work-Stealing-Algorithmus erreicht, bei dem inaktive Threads Aufgaben von ausgelasteten Threads stehlen, um einen reibungslosen Ablauf zu gewährleisten

4. Wie das Betriebssystem Hunger verhindert

Betriebssysteme (OS) verwenden verschiedene Techniken, um eine Hungersnot zu vermeiden – eine Situation, in der bestimmten Prozessen oder Threads über längere Zeiträume notwendige Ressourcen (wie CPU-Zeit, Speicher oder E/A-Zugriff) verweigert werden, weil Aufgaben mit höherer Priorität dominieren. Hier sind einige der häufigsten Methoden, mit denen ein Betriebssystem Hungersnot verhindert:

No.	Method	Description	Prevents Starvation By
1	Aging	Gradually increases priority of waiting processes.	Prevents long waits by adjusting priority based on wait time.
2	Round-Robin Scheduling	Allocates CPU time in a fixed cyclic order.	Ensures all processes get CPU time, avoiding starvation.
3	Completely Fair Scheduler	Allocates CPU based on fairness, independent of priority.	Ensures fair distribution of CPU time.
4	Priority Boosting	Temporarily raises the priority of starved processes holding important resources.	Prevents priority inversion and ensures high-priority tasks get needed resources.
5	Multilevel Feedback Queues	Dynamically adjusts process priorities based on behavior.	Promotes long-waiting processes to higher-priority queues.
6	Semaphores with Fairness	Ensures fair access to resources through FIFO queues.	Prevents low-priority tasks from being perpetually blocked by higher-priority tasks.
7	Fair Resource Allocation	Distributes system resources like CPU and memory based on process demand and need.	Prevents resource-hogging processes from starving others.
8	Fair I/O Scheduling	Prioritizes I/O requests to ensure timely completion for all processes.	Prevents disk I/O starvation for processes making low-priority requests.

Durch die Implementierung dieser Strategien können Betriebssysteme sicherstellen, dass kein Prozess oder Thread auf unbestimmte Zeit unter Ressourcenmangel leidet, was eine gerechtere und effizientere Nutzung der Systemressourcen fördert.

Wichtige Erkenntnisse für Softwareentwickler

• Starvation ist ein Fortschrittsproblem, bei dem einem Prozess weiterhin der Zugriff auf eine Ressource verweigert wird, dies jedoch nicht unbedingt dazu führt, dass andere Prozesse sie in einem Deadlock-Zyklus blockieren. Die Ursache liegt oft in einer unfairen Planung oder Ressourcenzuteilung.
• Hunger passiert, obwohl die benötigte Ressource verfügbar ist, aber nie die Chance hat, sie zu erwerben.
• Starvation tritt auch dann auf, wenn im System kein Deadlock vorliegt.
• Aushungern kann ein Nebeneffekt der Deadlock-Verhinderung sein (z. B. Priorisierung bestimmter Prozesse, um Deadlocks zu vermeiden). Daher ist es wichtig, Fairness mit Strategien zur Deadlock-Vermeidung in Einklang zu bringen.

Referenz

Ein großes Dankeschön an die Online-Dokumentation, die Community und alle verfügbaren Ressourcen, die diesen Artikel ermöglicht haben.

1. Multithreading-Konzepte Teil 1: Atomarität und Unveränderlichkeit
2. Stackoverflow
3. Infografiken

Das obige ist der detaillierte Inhalt vonMultithreading-Konzepte sind Teil des Hungers. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!