/* Page prose (de) */
"Overview" = "# Gefahren der Nebenläufigkeit\n\nDu hast Arbeit mit Warteschlangen vom Hauptthread verlagert, mit Dispatch Groups auf ganze Stapel gewartet und den Zugriff mit Semaphoren rationiert. Jetzt kommen die scharfen Kanten. In dem Moment, in dem zwei Arbeitsstücke gleichzeitig denselben Wert berühren, taucht eine neue Klasse von Fehlern auf: einer, der jeden Test auf deiner Maschine besteht, ausgeliefert wird und dann bei einem von tausend Nutzern eine Zahl beschädigt. Stell dir eine Bank mit Nummernschaltern vor: ein einziger geteilter Kontostand, eine Reihe von Kassierern, alle greifen gleichzeitig in die Schublade. Dieses Kapitel handelt davon, was schiefgeht, wenn sie sich nicht abstimmen, und von den klassischen Werkzeugen, die sie sicher machen.\n\n---\n\n## Was du lernst\n\n* Was eine **Race Condition** und ein **Data Race** sind, und wie du eine erkennst, indem du Code liest.\n* Warum Races **nichtdeterministisch** sind (in den meisten Läufen richtig, in manchen falsch) und deshalb so brutal schwer zu reproduzieren.\n* Zwei klassische Lösungen: Schreibvorgänge durch eine **serielle Warteschlange** kanalisieren, oder eine **nebenläufige Warteschlange mit einer `.barrier`** verwenden (das Leser-Schreiber-Muster).\n* Was ein **Deadlock** ist, und der Einzeiler-Fehler, der eine App für immer einfriert.\n* Was **Prioritätsinversion** ist, in einfachen Worten.\n* Eine Checkliste, um über Thread-Sicherheit nachzudenken, ohne irgendetwas auszuführen.\n\nWenn du bereit bist, blättere zur nächsten Seite, und wir zerbrechen absichtlich den geteilten Kontostand einer Bank.\n\nSeite 1 von 9  |  [Weiter: Der Data Race](@next)";
