How does Task of T differ from Task, and what should you know about getting its result safely?

1. What await does with a Task<T>

int x = await GetCountAsync();

becomes (simplified):

TaskAwaiter<int> awaiter = GetCountAsync().GetAwaiter();
if (!awaiter.IsCompleted)
{
    // store state, register continuation, return to caller
}
int x = awaiter.GetResult();   // returns Result, or rethrows the original exception

TaskAwaiter<T>.GetResult() validates the task's final state: RanToCompletion → value; Faulted → rethrow first exception via ExceptionDispatchInfo; Canceled → throw TaskCanceledException.

2. Why blocking can deadlock

// WinForms/WPF button handler, or old ASP.NET
var data = LoadAsync().Result;      // blocks the UI thread

async Task<string> LoadAsync()
{
    await Task.Delay(100);           // continuation wants to resume on the UI thread
    return "done";                   // ...which is blocked waiting for us -> deadlock
}

ASP.NET Core has no SynchronizationContext, so it usually doesn't deadlock there, but it still blocks a pool thread per call, which leads to starvation under load.

3. TaskCompletionSource<T> rules

var tcs = new TaskCompletionSource<Reply>(TaskCreationOptions.RunContinuationsAsynchronously);

using CancellationTokenRegistration reg = ct.Register(() => tcs.TrySetCanceled(ct));
_pending[id] = tcs;
await SendAsync(request, ct);
Reply reply = await tcs.Task;      // completed when the matching response arrives

The non-generic TaskCompletionSource (.NET 5+) is the result-less version for pure signals.

4. Cached completed tasks

• Task.CompletedTask is a singleton.
• The async method builder caches some completed Task<T> instances for common results (e.g. Task<bool> true/false, small int values in some versions, null for reference types). Otherwise each synchronously completing call allocates.
• Never rely on task reference identity.

5. Reading Result safely after WhenAll

Task<User> u = GetUserAsync(id);
Task<Order[]> o = GetOrdersAsync(id);
await Task.WhenAll(u, o);
return new Profile(u.Result, o.Result);   // fine: both are complete; no blocking

Or just await u again: awaiting a completed task is cheap and keeps exception shapes consistent.

6. Version notes

7. Try it yourself

1. Run the code example and compare exception types from await, .Result and GetResult().
2. In a WPF or WinForms app, call .Result on an async method from a button click and observe the deadlock; fix it with await.
3. Create a TaskCompletionSource without the async-continuations flag, complete it inside a lock, and log which thread the continuation runs on.
4. Benchmark Task.FromResult vs Task.Run vs ValueTask for a cache hit with BenchmarkDotNet.
5. Try Task<object> o = Task.FromResult("x"); and read the compiler error; then write an adapter.

Task<int> failing = Task.Run<int>(() => throw new InvalidOperationException("boom"));

try { await failing; }
catch (Exception ex) { Console.WriteLine($"await: {ex.GetType().Name}"); }          // InvalidOperationException

try { _ = failing.Result; }
catch (Exception ex) { Console.WriteLine($".Result: {ex.GetType().Name}"); }        // AggregateException

try { _ = failing.GetAwaiter().GetResult(); }
catch (Exception ex) { Console.WriteLine($"GetResult: {ex.GetType().Name}"); }      // InvalidOperationException

// Bridging a callback API with TaskCompletionSource<T>.
static Task<string> DownloadAsync(LegacyClient client)
{
    var tcs = new TaskCompletionSource<string>(TaskCreationOptions.RunContinuationsAsynchronously);
    client.Completed += (_, text) => tcs.TrySetResult(text);
    client.Failed += (_, ex) => tcs.TrySetException(ex);
    client.Start();
    return tcs.Task;
}

Console.WriteLine(await DownloadAsync(new LegacyClient()));

public sealed class LegacyClient
{
    public event EventHandler<string>? Completed;
    public event EventHandler<Exception>? Failed;
    public void Start() => ThreadPool.QueueUserWorkItem(_ =>
    {
        Thread.Sleep(50);
        Completed?.Invoke(this, "payload");
    });
}