Detached Task

Programme müssen oft mehrere Dinge gleichzeitig tun. Ein Chat-Programm zeigt eine Nachricht an und schickt gleichzeitig eine Empfangsbestätigung an den Server. Man kann solche Nebenarbeiten als eigene Aufgabe starten, die parallel läuft. Wenn das Programm danach nicht mehr nachfragt, ob diese Aufgabe fertig wurde oder fehlgeschlagen ist, spricht man von einem Detached Task. Wörtlich heißt das « abgekoppelte Aufgabe »: sie ist gestartet, aber vom Rest des Ablaufs losgelöst. Der Gegensatz ist eine Aufgabe, auf deren Ergebnis das Programm ausdrücklich wartet.

Warum Entwickler Aufgaben abkoppeln

Der Grund ist Geschwindigkeit, genauer: gefühlte Geschwindigkeit. Wenn du in einer App auf « Senden » tippst, soll die Nachricht sofort erscheinen. Ob der Server sie schon bestätigt hat, interessiert dich in diesem Moment nicht. Also koppelt man die Serverkommunikation ab und zeigt die Nachricht direkt an. Die Bedienung bleibt flüssig, weil niemand auf das Netzwerk wartet.

Der Preis dafür ist Kontrollverlust. Wenn eine abgekoppelte Aufgabe abstürzt, merkt das oft niemand. Es gibt keine Stelle im Programm, die den Fehler auffängt und weitermeldet. In der Fachsprache heißt so etwas ein verschluckter Fehler. Das Ergebnis sind Bugs, die nur manchmal auftreten und schwer zu finden sind.

Besonders ärgerlich ist der Fall, dass die Aufgabe gar nicht fertig wird. Wird die App geschlossen, bevor die Bestätigung raus ist, ist sie einfach verloren. Die Nachricht steht dann auf deinem Bildschirm, aber der Server weiß nichts davon. Deshalb gilt die Regel: alles, was wirklich passieren muss, koppelt man nicht ab.

Was beim Abkoppeln technisch passiert

Ein Programm arbeitet normalerweise Schritt für Schritt. An einer Stelle sagt der Code: starte diese Arbeit nebenbei. Das System legt daraufhin eine neue Aufgabe an und schiebt sie in eine Warteschlange. Der ursprüngliche Ablauf geht in derselben Zeile weiter, ohne Pause.

Entscheidend ist, was mit dem sogenannten Handle passiert. Ein Handle ist so etwas wie ein Abholschein für das Ergebnis der Aufgabe. Wer den Schein behält, kann später nachfragen: bist du fertig, hat es geklappt? Wer ihn wegwirft, hat einen Detached Task erzeugt. Die Aufgabe läuft dann weiter, aber niemand kann sie noch abbrechen oder ihr Ergebnis lesen.

Eine passende Analogie ist ein Brief ohne Rückschein. Du wirfst ihn ein und gehst weiter. Er kommt wahrscheinlich an, aber du erfährst es nie sicher. Ein Detached Task ist genau dieser Brief. Manche Programmiersprachen warnen deshalb ausdrücklich, wenn man ein Handle ungenutzt liegen lässt. In der Sprache Swift muss man sogar ausdrücklich « Task.detached » schreiben, damit klar ist, dass das Abkoppeln Absicht war.

Detached Tasks in Apps und in KI-Diensten

Im Alltag begegnen dir abgekoppelte Aufgaben ständig, ohne dass du sie siehst. Nutzungsstatistiken, die eine App an den Hersteller schickt, laufen praktisch immer so. Das Gleiche gilt für Vorschaubilder, die im Hintergrund geladen werden, oder für Protokolldateien. Bei all diesen Dingen ist es nicht schlimm, wenn einmal etwas verloren geht.

Auch KI-Dienste nutzen das Prinzip. Wenn ein Chatbot antwortet, wird das Gespräch oft nebenbei protokolliert und bewertet. Diese Nebenarbeit darf die Antwort nicht verzögern, also wird sie abgekoppelt. Ähnlich läuft das Erzeugen von Bildern: der Auftrag wird abgeschickt, das Ergebnis erscheint später von selbst.

In technischen Nachrichten tauchen Detached Tasks meist als Fehlerursache auf. Typisch ist die Meldung, dass Daten unter hoher Last verloren gingen. Häufig steckt dahinter eine Aufgabe, die niemand überwacht hat. Ein verbreiteter Irrtum ist übrigens, dass abgekoppelte Aufgaben schneller rechnen. Sie rechnen genauso lange, nur eben unbeobachtet.