Was ist Starvation (Hunger) im Kontext der Multithread-Programmierung?

Zustand, in dem ein oder mehrere Goroutines (Threads, Prozesse) niemals auf eine Ressource (z. B. einen Mutex, einen Kanal) zugreifen, die sie benötigen, um ihre Ausführung fortzusetzen, während andere Goroutines ständig auf diese Ressource zugreifen. Dies geschieht aufgrund unfairer Planung oder ineffizienter Synchronisationsmechanismen wie Prioritäten oder übermäßiges Halten von Sperren.

Beispiel:

package main

import (
	"fmt"
	"sync"
	"time"
)

var (
	mu      sync.Mutex
	counter int
)

func worker(id int) {
	for {
		mu.Lock() // Ressource (counter) schützen
		// Hier kann Hunger auftreten, wenn andere Goroutines
		// ständig das Mutex erfassen und lange halten.
		counter++
		fmt.Printf("Arbeiter %d hat den Zähler auf %d erhöht\n", id, counter)
		time.Sleep(10 * time.Millisecond) // Arbeit simulieren
		mu.Unlock()
		// Kleine Verzögerung hinzufügen, damit der Scheduler wechseln kann
		time.Sleep(1 * time.Millisecond)
	}
}

func main() {
	for i := 0; i < 5; i++ {
		go worker(i)
	}

	// Das Programm läuft unendlich,
	// aber einige Worker können Hunger leiden
	// abhängig vom Scheduler und der Last.
	select {}
}

Um Hunger zu minimieren, werden angewandt:

• Faire Sperren (fair locks): Garantieren, dass Threads in der Reihenfolge ihres Antrags Zugriff erhalten.
• Zufälligkeit: Einführung von Zufälligkeit bei der Auswahl des Threads, der Zugriff auf die Ressource erhält.
• Timeouts: Festlegung von Zeitlimits für das Warten auf eine Ressource.
• Vermeidung von Prioritätsinversion: Vermeiden von Situationen, in denen ein hochpriorisierter Prozess auf einen niedrigpriorisierten wartet.

In Go garantieren Standard-Mutexe keine Fairness, was zu Hunger unter bestimmten Bedingungen führen kann.