/* Page prose (de) */
"TasksAreNotThreads" = "# Aufgaben sind keine Threads\n\nEs gibt eine Überzeugung, die fast jeder Entwickler mitbringt, und es lohnt sich, sie jetzt zu verlernen, denn alles oben Genannte hängt davon ab: **eine Aufgabe zu erstellen erzeugt keinen Thread.**\n\nEin **Thread** ist eine teure Ressource, die dem Betriebssystem gehört; er ist das, was tatsächlich Instruktionen ausführt, und deine Maschine hat nur eine Handvoll Kerne, um sie darauf auszuführen. Eine **Aufgabe** ist nur eine Arbeitseinheit, die *du* beschrieben hast. Die beiden haben überhaupt nicht dieselbe Größe: du kannst Tausende von Aufgaben erstellen, aber es wird immer nur eine kleine Anzahl von Threads geben.\n\nAlso unterhält Swift einen kleinen **kooperativen Thread-Pool** (ungefähr **einen Thread pro CPU-Kern**) und *multiplext* deine Aufgaben darauf. Viele Aufgaben wechseln sich auf ein paar Threads ab. Du bestimmst nicht, welchen Thread; das System plant die Arbeit für dich und nutzt die **Priorität** jeder Aufgabe als Hinweis, was zuerst auszuführen ist (mehr zur Priorität im Kapitel [Tasks und Abbruch](Tasks%20and%20Cancellation.playgroundchapter/Overview)).\n\nGenau deshalb ist die Suspendierung wichtig. Wenn eine Aufgabe auf ein `await` trifft und aussetzt, **gibt sie ihren Thread an den Pool zurück**, und irgendeine andere Aufgabe schnappt sich diesen Thread und kommt voran. Wenn das Ergebnis deiner Aufgabe bereit ist, wird sie auf *irgendeinem* Pool-Thread fortgesetzt, der als nächstes frei ist, was ein **anderer** Thread sein kann als der, auf dem sie startete. (Deshalb sagt \"später auf irgendeinem Thread fortgesetzt\" oben *irgendeinem*.)\n\n```\nThe pool has ~4 threads. You made 100 tasks.\n\nTask A runs on thread 2 ──await──▶ suspends, releases thread 2\n                                       │\nTask B grabs thread 2 and runs ◀───────┘\n   ...\nTask A's result is ready ──▶ resumes on whatever thread is free (maybe thread 0)\n```\n\nDie Erkenntnis: stell dir nicht vor, dass hinter jedem `Task { }` ein frischer Thread aus dem Boden schießt. Male dir ein paar beschäftigte Threads aus, die viele Aufgaben untereinander weiterreichen, wobei jede Aufgabe ihren Thread jedes Mal loslässt, wenn sie `await` macht.\n\n> **Das klassische Modell hatte ein anderes Temperament.** GCD läuft ebenfalls auf einem Thread-Pool, aber wenn du seine Threads *blockierst* (ein `sync`-Warten, ein Semaphor, ein `Thread.sleep`), neigt GCD dazu, **mehr** Threads zu erzeugen, um das auszugleichen, ein Problem namens **Thread-Explosion**, das sich zu Dutzenden von Threads aufblähen kann, die um dieselben Kerne kämpfen. Der moderne Pool weigert sich bewusst: er bleibt bei etwa der Kernanzahl gedeckelt und verlässt sich darauf, dass Aufgaben *aussetzen* (`await`) statt zu *blockieren*. Dieser eine Unterschied (aussetzen, nicht blockieren) ist ein großer Teil davon, *warum* das moderne Modell existiert, und warum der Aufruf einer blockierenden API wie `Thread.sleep` innerhalb einer Aufgabe ein Fehler ist (das Kapitel [Tasks und Abbruch](Tasks%20and%20Cancellation.playgroundchapter/Overview) zeigt eine, die einen Thread als Geisel hält).\n\n[Zurück](@previous)  |  Seite 4 von 8  |  [Weiter: Await innerhalb eines Async-Kontexts](@next)";
