C# Task: Task.Run, WhenAll, WhenAny, Abbruch und Threads

Ein Task ist ein Objekt, das für laufende Arbeit steht. Sie läuft vielleicht auf einem Thread des Thread-Pools, wartet auf einen Timer oder auf eine Netzwerkantwort; in jedem Fall kannst du fragen, ob sie fertig ist, ihr Ergebnis holen, auf sie warten oder weitere Arbeit an sie anhängen. async und await sind die Sprachsyntax über Tasks. Diese Seite behandelt die Task-API selbst und Threads.

Task.Run: Arbeit im Thread-Pool

Task.Run nimmt ein Lambda und reiht es in den Thread-Pool ein, eine Menge von Threads, die .NET vorhält, damit nicht für jeden Auftrag ein neuer erzeugt wird. Es gibt einen Task zurück oder einen Task<T>, wenn das Lambda einen Wert zurückgibt.

using System;
using System.Threading.Tasks;

class Program
{
    static int CountPrimes(int max)
    {
        int count = 0;
        for (int n = 2; n <= max; n++)
        {
            bool prime = true;
            for (int d = 2; d * d <= n; d++)
            {
                if (n % d == 0) { prime = false; break; }
            }
            if (prime) count++;
        }
        return count;
    }

    static void Main()
    {
        Task<int> task = Task.Run(() => CountPrimes(200000));
        Console.WriteLine("Started, completed yet: " + task.IsCompleted);

        int primes = task.Result;   // blocks until the task finishes
        Console.WriteLine("Primes up to 200,000: " + primes);
        Console.WriteLine("Status: " + task.Status);
    }
}

Ausgabe:

Started, completed yet: False
Primes up to 200,000: 17984
Status: RanToCompletion

Result blockiert den aufrufenden Thread, bis der Task fertig ist. Im Main eines Konsolenprogramms ist das akzeptabel, aber in async-Code würdest du int primes = await task; schreiben, das wartet, ohne zu blockieren. Dasselbe gilt für task.Wait() bei einem Task ohne Ergebnis.

Task.Run ist für CPU-lastige Arbeit: Berechnungen, die einen Kern beschäftigen. Für I/O, etwa das Lesen einer Datei oder den Aufruf einer Web-API, nimm die async-Methode, die die Bibliothek bereits bietet (File.ReadAllTextAsync, HttpClient.GetStringAsync), und warte sie direkt mit await ab. Solange die I/O läuft, hält ein abgewarteter async-Aufruf gar keinen Thread fest; sie in Task.Run zu verpacken bringt also nichts und fügt nur einen Umweg über den Thread-Pool hinzu. Einen Pool-Thread blockiert dagegen Task.Run um einen synchronen, blockierenden Aufruf wie File.ReadAllText: Dieser Thread wartet untätig, bis Festplatte oder Netzwerk antworten.

Mehrere Tasks gleichzeitig: WhenAll

Teile unabhängige Arbeit in Tasks auf, starte sie alle und kombiniere die Ergebnisse mit Task.WhenAll. Auf einem Rechner mit mehreren Kernen laufen die Teile parallel.

using System;
using System.Linq;
using System.Threading.Tasks;

class Program
{
    static long SumRange(int from, int to)
    {
        long sum = 0;
        for (int i = from; i < to; i++) sum += i % 7;
        return sum;
    }

    static void Main()
    {
        int chunks = 4, size = 5000000;

        Task<long>[] parts = Enumerable.Range(0, chunks)
            .Select(c => Task.Run(() => SumRange(c * size, (c + 1) * size)))
            .ToArray();

        long[] results = Task.WhenAll(parts).Result;
        Console.WriteLine("Parts: " + string.Join(", ", results));
        Console.WriteLine("Total: " + results.Sum());
    }
}

Ausgabe:

Parts: 14999995, 14999999, 15000003, 15000000
Total: 59999997

Jeder Teil arbeitet auf seinem eigenen Bereich und gibt seine eigene Summe zurück, die Tasks teilen also nichts und brauchen kein Locking. WhenAll gibt die Ergebnisse in der Reihenfolge der Tasks zurück, egal wie die Threads zufällig fertig wurden. Wenn Tasks gemeinsamen Zustand aktualisieren müssen, siehe lock.

WhenAny und Timeouts

Task.WhenAny ist fertig, wenn der erste seiner Tasks fertig ist, und gibt diesen Task zurück. Die eigentliche Arbeit gegen Task.Delay antreten zu lassen ergibt einen Timeout:

using System;
using System.Threading.Tasks;

class Program
{
    static async Task<string> QueryServerAsync(string name, int ms)
    {
        await Task.Delay(ms);
        return name + " answered after " + ms + " ms";
    }

    static async Task RunAsync()
    {
        Task<string> fast = QueryServerAsync("fast mirror", 100);
        Task<string> slow = QueryServerAsync("main server", 800);
        Task<string> first = await Task.WhenAny(fast, slow);
        Console.WriteLine(await first);

        Task<string> work = QueryServerAsync("report service", 2000);
        Task timeout = Task.Delay(300);
        if (await Task.WhenAny(work, timeout) == timeout)
        {
            Console.WriteLine("Timed out after 300 ms");
        }
    }

    static void Main()
    {
        RunAsync().GetAwaiter().GetResult();
    }
}

Ausgabe:

fast mirror answered after 100 ms
Timed out after 300 ms

WhenAny gibt den gewinnenden Task selbst zurück, nicht sein Ergebnis, du wartest ihn also erneut ab, um den Wert zu bekommen (oder die Exception, wenn er gescheitert ist). Beachte, dass die verlierenden Tasks weiterlaufen; WhenAny stoppt sie nicht. Um die langsame Arbeit wirklich zu stoppen, brich sie wie unten gezeigt mit einem Token ab. Ab .NET 6 drückt await work.WaitAsync(TimeSpan.FromMilliseconds(300)) denselben Timeout in einem Aufruf aus.

Fortsetzungen mit ContinueWith

Vor await bestand der Weg, Code nach einem fertigen Task auszuführen, in ContinueWith. In älterem Code begegnet es dir noch:

using System;
using System.Threading.Tasks;

class Program
{
    static void Main()
    {
        Task<int> load = Task.Run(() => 21);

        Task<string> report = load
            .ContinueWith(t => t.Result * 2)
            .ContinueWith(t => "Report total: " + t.Result);

        Console.WriteLine(report.Result);
    }
}

Ausgabe:

Report total: 42

Jede Fortsetzung bekommt den vorherigen Task und läuft, wenn er fertig ist. await tut dasselbe mit viel weniger Aufwand, behandelt Exceptions natürlich und kehrt in den richtigen Kontext zurück, nimm es also in neuem Code. ContinueWith läuft auch, wenn der vorherige Task gescheitert ist oder abgebrochen wurde, älterer Code muss also t.IsFaulted prüfen oder TaskContinuationOptions übergeben, um nicht .Result auf einem gescheiterten Task aufzurufen.

Abbruch mit CancellationToken

Tasks werden kooperativ abgebrochen. Eine CancellationTokenSource gibt einen Token aus; der Code, der die Arbeit erledigt, prüft den Token und stoppt sich selbst. Nichts wird gewaltsam abgebrochen.

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task<int> ProcessOrdersAsync(int count, CancellationToken token)
    {
        int done = 0;
        for (int i = 0; i < count; i++)
        {
            token.ThrowIfCancellationRequested();   // stop between items
            await Task.Delay(100, token);           // pass the token on
            done++;
        }
        return done;
    }

    static async Task RunAsync()
    {
        using (var cts = new CancellationTokenSource())
        {
            cts.CancelAfter(350);                   // cancel in 350 ms
            try
            {
                int n = await ProcessOrdersAsync(10, cts.Token);
                Console.WriteLine("Processed " + n);
            }
            catch (OperationCanceledException)
            {
                Console.WriteLine("Cancelled before finishing all 10 orders");
            }
        }

        using (var cts = new CancellationTokenSource())
        {
            int n = await ProcessOrdersAsync(3, cts.Token); // never cancelled
            Console.WriteLine("Processed " + n);
        }
    }

    static void Main()
    {
        RunAsync().GetAwaiter().GetResult();
    }
}

Ausgabe:

Cancelled before finishing all 10 orders
Processed 3

Der Token wird durch jede Schicht nach unten gereicht, und async-APIs wie Task.Delay, HttpClient und Datenbankaufrufe akzeptieren ihn ebenfalls, ein Abbruch stoppt sie also mitten im Warten. Fang OperationCanceledException ab; die TaskCanceledException, die manche APIs werfen, leitet davon ab. CancellationTokenSource ist IDisposable, daher das using.

Thread gegenüber Task

Ein Thread ist ein Thread des Betriebssystems, den du selbst erzeugst. Er ist schwerer: Jeder hat seinen eigenen Stack (unter Windows standardmäßig 1 MB), das Starten dauert messbar, und er gibt dir weder Ergebnis noch Exception-Behandlung.

using System;
using System.Threading;

class Program
{
    static void Main()
    {
        int result = 0;
        var worker = new Thread(() =>
        {
            Thread.Sleep(100);
            result = 6 * 7;
        });
        worker.Start();
        Console.WriteLine("Thread started");
        worker.Join();          // wait for it to finish
        Console.WriteLine("Result: " + result);
    }
}

Ausgabe:

Thread started
Result: 42

Greif nur zu Thread, wenn du etwas brauchst, das der Pool nicht bietet: eine lang laufende Schleife, die nie einen Pool-Thread ausleihen soll, eine bestimmte Priorität oder ein Single-Threaded Apartment für COM. Für lang laufende Tasks bekommt Task.Factory.StartNew(work, TaskCreationOptions.LongRunning) einen eigenen Thread und behält die Task-API.

Parallel.For und Parallel.ForEach

Für „mach das mit jedem Element und nutze alle Kerne“ ist System.Threading.Tasks.Parallel einfacher, als Tasks von Hand zu erzeugen. Es teilt den Bereich auf Threads auf und kehrt zurück, wenn alle Durchläufe fertig sind:

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static void Main()
    {
        int[] sizes = { 120, 340, 90, 410, 275, 60 };
        long totalPixels = 0;

        Parallel.For(0, sizes.Length, i =>
        {
            long pixels = (long)sizes[i] * sizes[i];      // "process" image i
            Interlocked.Add(ref totalPixels, pixels);      // thread-safe add
            Console.WriteLine("image " + i + " on thread " + Thread.CurrentThread.ManagedThreadId);
        });

        Console.WriteLine("Total pixels: " + totalPixels);
    }
}

Beispielausgabe:

image 4 on thread 7
image 3 on thread 6
image 5 on thread 8
image 0 on thread 1
image 1 on thread 4
image 2 on thread 5
Total pixels: 385425

Die Zeilen pro Bild erscheinen in der Reihenfolge, in der die Threads sie ausgeführt haben, und die Thread-IDs variieren von Lauf zu Lauf; nur die Summe steht fest. Das liegt in der Natur paralleler Schleifen: Durchläufe dürfen nicht von der Reihenfolge der anderen abhängen, und jeder gemeinsame Zustand braucht Synchronisierung (hier Interlocked.Add). Parallel.ForEach tut dasselbe über jede Collection, und .NET 6 fügt Parallel.ForEachAsync für async-Rümpfe hinzu.

Häufige Fehler

• .Result oder .Wait() in async-Code. Blockiert einen Thread und kann in UI-Apps Deadlocks verursachen; nimm stattdessen await.
• Den ursprünglichen Exception-Typ um .Result herum abfangen. Fehlschläge kommen in eine AggregateException verpackt an; await packt sie aus.
• Fire and Forget. Task.Run(...) ohne Abwarten oder Speichern des Tasks verliert seine Exceptions.
• Task.Run um I/O. Um eine async-Methode fügt es nur einen Umweg über den Thread-Pool hinzu; um eine blockierende Methode wie File.ReadAllText belegt es einen Pool-Thread für die gesamte Wartezeit. Warte die async-I/O-Methode direkt ab.
• Den Token ignorieren. Einen CancellationToken zu übergeben bewirkt nichts, wenn die Arbeit ihn nicht prüft.
• Nicht synchronisierter gemeinsamer Zustand in parallelem Code. Nimm Interlocked, lock oder gib jedem Task seine eigenen Daten.