/* Page prose (de) */
"PriorityInversion" = "# Prioritätsinversion, kurz gefasst\n\nZurück im Kapitel [GCD-Grundlagen](GCD%20Fundamentals.playgroundchapter/Overview) hast du die **Quality of Service (QoS)** kennengelernt: den Prioritätshinweis (`.userInteractive`, `.utility`, `.background`, ...), der dem System sagt, wie dringend die Arbeit einer Warteschlange ist.\n\n**Prioritätsinversion** ist, wenn eine Aufgabe hoher Priorität feststeckt und auf eine Ressource wartet, die eine Aufgabe niedriger Priorität hält, sodass die \"wichtige\" Arbeit faktisch mit der Geschwindigkeit der \"unwichtigen\" Arbeit läuft. Stell dir vor, ein `.background`-Kassierer schnappt sich den Lock des Kontobuchs und wird dann von CPU-Zeit ausgehungert, weil das System mit anderen Dingen beschäftigt ist. Ein `.userInteractive`-Kassierer braucht nun genau diesen Lock und kann ihn nicht bekommen. Die dringende Aufgabe wartet auf die faule. Die Prioritäten sind *invertiert*.\n\nNormalerweise behebst du das nicht von Hand: GCD und die moderne Laufzeit führen **Prioritätsspende** durch, die den Halter mit niedriger Priorität vorübergehend anhebt, damit er fertig werden und die Ressource freigeben kann. Was du *tun* kannst, um Ärger zu vermeiden: Teile nicht einen einzigen Lock oder eine serielle Warteschlange über völlig verschiedene QoS-Stufen hinweg, und halte die Arbeit innerhalb jedes kritischen Abschnitts kurz, sodass niemand eine geteilte Ressource länger hält, als er muss.\n\n[Zurück](@previous)  |  Seite 7 von 9  |  [Weiter: Über Thread-Sicherheit nachdenken](@next)";
