/* Page prose (de) */
"OneTaskAtATime" = "# Ein Actor lässt eine Aufgabe nach der anderen herein\n\nZuerst das Problem noch einmal. Hier ist die Gestalt des Fehlers aus dem Kapitel [Gefahren der Nebenläufigkeit](Concurrency%20Hazards.playgroundchapter/Overview), in seiner einfachsten Form. Eine schlichte Klasse hält einen Kontostand, und viele nebenläufige Einzahlungen kämpfen darum:\n\n```swift\nfinal class UnsafeLedger {\n    var balance = 0\n\n    func deposit(_ amount: Int) {\n        balance += amount   // read, add, write (not atomic)\n    }\n}\n```\n\nDieses `balance += amount` sind in Wirklichkeit *drei* Schritte: den aktuellen Wert lesen, dazuaddieren, zurückschreiben. Wenn zwei Aufgaben gleichzeitig `0` lesen, schreiben beide `1`, und eine Einzahlung geht verloren. Führe tausend nebenläufige Einzahlungen aus, und du bekommst selten `1000`.\n\nIn Swift 6 hält **der Compiler dich auf**, wenn du dieses `UnsafeLedger` tatsächlich über nebenläufige Aufgaben hinweg teilen willst: eine schlichte veränderliche Klasse ist nicht sicher zu teilen, also kompiliert sie nicht. Das ist der Compiler, der dich auf das richtige Werkzeug hinweist. Das Werkzeug ist ein Actor.\n\nEin **Actor** ist ein Referenztyp, wie eine Klasse, dessen veränderlicher Zustand nur von **einer Aufgabe nach der anderen** angefasst werden kann. Der Actor serialisiert jeden Zugriff auf seinen eigenen Zustand, sodass sich das Lesen-Addieren-Schreiben von oben niemals überlappen kann. Tausche `class` gegen `actor` (und markiere, wo wir schon dabei sind, die Dinge festzuziehen, `balance` als `private(set)`, damit nur die Methoden des Actors selbst es ändern können; externer Code kann es weiterhin lesen):\n\n```swift\nactor Ledger {\n    private(set) var balance = 0\n\n    func deposit(_ amount: Int) {\n        balance += amount\n    }\n}\n```\n\nDas ist die ganze Behebung. Die `deposit`-Aufrufe sind jetzt automatisch serialisiert: solange eine Aufgabe in `deposit` ist, muss jede andere Aufgabe auf ihren Zug warten. Keine Warteschlange einzurichten, nichts zu merken. Lass es uns mit tausend nebenläufigen Einzahlungen über eine Task Group (aus dem Kapitel [Task Groups](Task%20Groups.playgroundchapter/Overview)) auf die Probe stellen.";
"OneTaskAtATime-2" = "**Sieh es laufen:** der Endstand ist **`1000`. Jedes Mal.** Führe es wieder und wieder aus; er weicht nie ab. Die tausend Einzahlungen sind alle angekommen. Vergleiche das mit der Klassen-Version, die Aktualisierungen unvorhersehbar verliert. Der Actor hat einen Race in eine Garantie verwandelt, und du hast keinen einzigen Lock geschrieben.\n\n* callout(Probier es aus): Erhöhe die Schleife auf `1...10_000` Einzahlungen. Kommt der Endstand immer noch bei jedem Durchlauf exakt richtig heraus?\n\n> Das unterscheidet sich von der Behebung mit serieller Warteschlange früher im Buch. Dort hast du *entschieden*, jeden Zugriff durch eine Warteschlange zu leiten, und nichts zwang dich, konsequent zu sein; ein einziger versehentlicher Direktzugriff führte den Race wieder ein. Ein Actor macht diesen Schutz zum Teil des Typs. Es gibt keinen Weg, `balance` zu erreichen, der die Serialisierung überspringt, und der Compiler prüft es für dich.\n\n[Zurück](@previous)  |  Seite 2 von 7  |  [Weiter: Actor-Isolation](@next)";
