/* Page prose (de) */
"ReasoningAboutThreadSafety" = "# Wie man über Thread-Sicherheit nachdenkt\n\nEine Checkliste, die du im Kopf durchgehen kannst, bevor du überhaupt **Run** drückst:\n\n* **Finde den geteilten veränderlichen Zustand.**  \nJedes `var` (eine Eigenschaft, eine eingefangene Variable, eine Sammlung), das von mehr als einer Aufgabe gleichzeitig erreichbar ist. Kein geteilter *und* veränderlicher Zustand, kein Data Race. (Unveränderlich oder nicht geteilt ist automatisch sicher.)\n* **Frage, wer schreibt.**  \nWenn alle nur lesen, ist alles in Ordnung. Die Gefahr beginnt mit dem ersten nebenläufigen Schreiber.\n* **Suche die Lesen-dann-Schreiben-Lücke.**  \n`x += 1`, \"prüfen dann handeln\", \"ein Dictionary lesen dann aktualisieren\". Alles, was einen Wert liest und später darauf basierend schreibt, hat eine Lücke, die eine andere Aufgabe beschädigen kann.\n* **Benenne die Koordination.**  \nZeige für jedes Stück geteilten veränderlichen Zustands auf das *eine* Ding, das den Zugriff serialisiert: eine serielle Warteschlange, eine Barriere, einen Semaphor, (später) einen Actor. Wenn du es nicht benennen kannst, nimm an, dass es ein Race ist.\n* **Ziehe es vor, es zu verstecken.**  \nWickle den Zustand und seine Koordination in einen Typ (wie `Account` zuvor), sodass Aufrufer den rohen Wert nicht berühren oder das Sperren vergessen können.\n\nHier schlägt Nachdenken das Ausführen, denn dem Ausführen kann man nicht trauen: ein Race, das in deinem Editor unsichtbar ist, kann auf dem älteren iPhone von jemand anderem ein Absturz sein.\n\n[Zurück](@previous)  |  Seite 8 von 9  |  [Weiter: Zusammenfassung](@next)";
