处理异步任务时使用 await 与使用 ContinueWith 有何不同？

Question

Here's what I mean:

public Task<SomeObject> GetSomeObjectByTokenAsync(int id)
    {
        string token = repository.GetTokenById(id);
        if (string.IsNullOrEmpty(token))
        {
            return Task.FromResult(new SomeObject()
            {
                IsAuthorized = false
            });
        }
        else
        {
            return repository.GetSomeObjectByTokenAsync(token).ContinueWith(t =>
            {
                t.Result.IsAuthorized = true;
                return t.Result;
            });
        }
    }

Above method can be awaited and I think it closely resembles to what the T ask-based A synchronous P attern suggests doing? (The other patterns I know of are the APM and EAP patterns.)

Now, what about the following code:

public async Task<SomeObject> GetSomeObjectByToken(int id)
    {
        string token = repository.GetTokenById(id);
        if (string.IsNullOrEmpty(token))
        {
            return new SomeObject()
            {
                IsAuthorized = false
            };
        }
        else
        {
            SomeObject result = await repository.GetSomeObjectByTokenAsync(token);
            result.IsAuthorized = true;
            return result;
        }
    }

The key differences here are that the method is async and it utilizes the await keywords - so what does this change in contrast to the previously written method? I know it can too - be awaited. Any method returning Task can for that matter, unless I'm mistaken.

I'm aware of the state machine created with those switch statements whenever a method is labeled as async , and I'm aware that await itself uses no thread - it doesn't block at all, the thread simply goes to do other things, until it's called back to continue execution of the above code.

But what's the underlying difference between the two methods, when we invoke them using the await keyword? Is there any difference at all, and if there is - which is preferred?

EDIT: I feel like the first code snippet is preferred, because we effectivelyelide the async/await keywords, without any repercussions - we return a task that will continue its execution synchronously, or an already completed task on the hot path (which can be cached).

Answer 1

The async / await mechanism makes the compiler transform your code into a state machine. Your code will run synchronously until the first await that hits an awaitable that has not completed, if any.

In the Microsoft C# compiler, this state machine is a value type, which means it will have a very small cost when all await s get completed awaitables, as it won't allocate an object, and therefore, it won't generate garbage. When any awaitable is not completed, this value type is inevitably boxed. ¹

Note that this doesn't avoid allocation of Task s if that's the type of awaitables used in the await expressions.

With ContinueWith , you only avoid allocations (other than Task ) if your continuation doesn't have a closure and if you either don't use a state object or you reuse a state object as much as possible (eg from a pool).

Also, the continuation is called when the task is completed, creating a stack frame, it doesn't get inlined. The framework tries to avoid stack overflows, but there may be a case where it won't avoid one, such as when big arrays are stack allocated.

The way it tries to avoid this is by checking how much stack is left and, if by some internal measure the stack is considered full, it schedules the continuation to run in the task scheduler. It tries to avoid fatal stack overflow exceptions at the cost of performance.

Here is a subtle difference between async / await and ContinueWith :

• async / await will schedule continuations in SynchronizationContext.Current if any, otherwise in TaskScheduler.Current ²

• ContinueWith will schedule continuations in the provided task scheduler, or in TaskScheduler.Current in the overloads without the task scheduler parameter

To simulate async / await 's default behavior:

.ContinueWith(continuationAction,
    SynchronizationContext.Current != null ?
        TaskScheduler.FromCurrentSynchronizationContext() :
        TaskScheduler.Current)

To simulate async / await 's behavior with Task 's .ConfigureAwait(false) :

.ContinueWith(continuationAction,
    TaskScheduler.Default)

Things start to get complicated with loops and exception handling. Besides keeping your code readable, async / await works with any awaitable .

Your case is best handled with a mixed approach: a synchronous method that calls an asynchronous method when needed. An example of your code with this approach:

public Task<SomeObject> GetSomeObjectByTokenAsync(int id)
{
    string token = repository.GetTokenById(id);
    if (string.IsNullOrEmpty(token))
    {
        return Task.FromResult(new SomeObject()
        {
            IsAuthorized = false
        });
    }
    else
    {
        return InternalGetSomeObjectByTokenAsync(repository, token);
    }
}

internal async Task<SomeObject> InternalGetSomeObjectByToken(Repository repository, string token)
{
    SomeObject result = await repository.GetSomeObjectByTokenAsync(token);
    result.IsAuthorized = true;
    return result;
}

---

In my experience, I've found very few places in application code where adding such complexity actually pays off the time to develop, review and test such approaches, whereas in library code any method can be a bottleneck.

The only case where I tend elide tasks is when a Task or Task<T> returning method simply returns the result of another asynchronous method, without itself having performed any I/O or any post-processing.

YMMV.

---

1. When building for Release, the compiler generates structs.

   When building for Debug, the compiler generates classes to allow edit-and-continue on async code.

2. Unless you use ConfigureAwait(false) or await on some awaitable that uses custom scheduling.

Answer 2

By using ContinueWith you are using the tools that where available before the introduction of the async / await functionality with C# 5 back at 2012. As a tool it is verbose, not easily composable, and requires extra work for unwrapping AggregateException s and Task<Task<TResult>> return values (you get these when you pass asynchronous delegates as arguments). It offers few advantages in return. You may consider using it when you want to attach multiple continuations to the same Task , or in some rare cases where you can't use async / await for some reason (like when you are in a method with out parameters ).

---

Update: I removed the misleading advice that the ContinueWith should use the TaskScheduler.Default to mimic the default behavior of await . Actually the await by default schedules its continuation using TaskScheduler.Current .

Answer 3

Difference between await and ContinueWith

Methods that perform asynchronous operations don't need to use await if:

There is only one asynchronous call inside the method. The asynchronous call is at the end of the method. Catching/handling exception that may happen within the Task is not necessary.

public Task<SomeObject> GetSomeObjectByTokenAsync(int id)
    {
        string token = repository.GetTokenById(id);
        if (string.IsNullOrEmpty(token))
        {
            return Task.FromResult(new SomeObject()
            {
                IsAuthorized = false
            });
        }
        else
        {
            return repository.GetSomeObjectByTokenAsync(token).ContinueWith(t =>
            {
                t.Result.IsAuthorized = true;
                return t.Result;
            });
        }
    }

If GetSomeObjectByTokenAsync has the same signature as GetSomeObjectByTokenAsync (returning a Task), the method can be simplified:

public Task<SomeObject> GetSomeObjectByToken(int id)
{
    string token = repository.GetTokenById(id);
    if (string.IsNullOrEmpty(token))
    {
        return new SomeObject()
        {
            IsAuthorized = false
        };
    }
    else
    {
        SomeObject result = repository.GetSomeObjectByTokenAsync(token);
        result.IsAuthorized = true;
        return result;
    }
}

In this case, the method doesn't need to be marked async, even though it's preforming an asynchronous operation. The Task returned by GetSomeObjectByTokenAsync is passed directly to the calling method, where it will be awaited.

Returning the Task instead of awaiting it, changes the exception behavior of the method, as it won't throw the exception inside the method which starts the task but in the method which awaits it.