/* Page prose (de) */
"Overview" = "# Actors\n\nErinnerst du dich an das Bank-Desaster mit den Schalternummern aus dem Kapitel [Gefahren der Nebenläufigkeit](Concurrency%20Hazards.playgroundchapter/Overview): viele Kassierer, die gleichzeitig Einzahlungen auf einen einzigen gemeinsamen Kontostand buchen, und die Summe kommt *falsch* heraus, Geld verschwindet einfach. Das war ein **Data Race**: zwei Aufgaben, die denselben Speicher gleichzeitig lesen und schreiben und sich gegenseitig in die Quere kommen. Damals hast du es von Hand behoben, indem du jede Änderung durch eine serielle Warteschlange geleitet und gehofft hast, es nie zu vergessen. Dieses Kapitel stellt das moderne Werkzeug vor, das diese Behebung automatisch macht und vom Compiler erzwingen lässt: den **Actor**.\n\n---\n\n## Was du lernst\n\n* Was ein **Actor** ist und wie er veränderlichen Zustand schützt, indem er nur eine Aufgabe nach der anderen hineinlässt.\n* Warum ein Aufruf in einen Actor von außen `await` braucht, der Code *innerhalb* des Actors aber synchron läuft, und wofür `nonisolated` da ist.\n* **Reentrancy**: wie ein Actor über ein `await` hinweg wieder betreten werden kann, den subtilen Fehler, den das verursacht, und wie du dich dagegen absicherst.\n* Ein erster Blick auf **`Sendable`**: die Regel dafür, was sicher über Actor- und Aufgabengrenzen hinweg weitergereicht werden kann.\n\nBlättere um, und lass uns dem Fehler in seiner einfachsten Form noch einmal begegnen.\n\nSeite 1 von 7  |  [Weiter: Ein Actor lässt eine Aufgabe nach der anderen herein](@next)";
