/* Page prose (de) */
"WrappingUp" = "# Zusammenfassung\n\nDiese beiden Werkzeuge beantworten zwei verschiedene Fragen, und zu wissen, welche du gerade stellst, ist der größte Teil der Schlacht: Eine Gruppe fragt \"wann ist diese ganze Runde fertig?\", ein Semaphor fragt \"wie viele dürfen gleichzeitig laufen?\" Beide belohnen sorgfältige Buchführung und bestrafen Nachlässigkeit mit Hängern, Abstürzen und Deadlocks. Halte die Gleichgewichtsregeln unten griffbereit.\n\n* Eine **`DispatchGroup`** verfolgt eine Menge von Aufgaben und löst aus, wenn sie alle fertig sind; ein **`DispatchSemaphore`** begrenzt, wie viele gleichzeitig auf eine Ressource zugreifen.\n* Die beiden **lassen sich kombinieren**: Verwende einen Semaphor, um zu begrenzen, wie viele gleichzeitig laufen, und eine Gruppe, um zu erfahren, wann die ganze Runde fertig ist, genau die Kombination, die das Espresso-Beispiel verwendet hat.\n* `notify(queue:)` führt einen Callback aus, wenn die Gruppe sich leert, und **blockiert nie**. Bevorzuge es. `wait()` blockiert den aufrufenden Thread, halte es also vom Hauptthread fern.\n* **Fallstrick:** unausgeglichenes `enter`/`leave` **hängt** entweder (zu wenige leaves) oder **stürzt ab** (zu viele); ein `wait()` ohne passendes `signal()` legt alle dahinter mit einem Deadlock lahm. `defer { group.leave() }` / `defer { sem.signal() }` direkt danach ist das sichere Muster.\n* **Fallstrick:** Dutzende semaphor-blockierte Aufgaben auf eine globale Warteschlange zu werfen kann den Thread-Pool von GCD aushungern. Für starke Drosselung verhält sich eine kleine dedizierte Warteschlange (oder, später, strukturierte Nebenläufigkeit) besser.\n* **Fallstrick:** Ein Semaphor begrenzt, *wie viele* gleichzeitig laufen, nicht *welche* als Nächste läuft: Verlass dich nicht auf die Reihenfolge, in der Aufgaben Genehmigungen erhalten.\n* Mit einer Zahl von 1 wirkt ein Semaphor wie ein Lock, aber es gibt sicherere, schwerer zu vergessende Werkzeuge, und Actors werden dies vollständig ersetzen.\n\n---\n\n## Als Nächstes\n\nDas nächste Kapitel ist [Gefahren der Nebenläufigkeit](Concurrency%20Hazards.playgroundchapter/Overview): der Data Race, den du im Zähler-Beispiel erahnt hast, dazu Deadlock und Prioritätsinversion, was schiefgeht, wenn gemeinsamer Zustand und Blockieren aufeinandertreffen, und wie du darüber nachdenkst.\n\n[Zurück](@previous)  |  Seite 8 von 8";
