Are the await / async keywords needed under Task.Run?

Question

I have an async lambda expression wrapped under Task.Run. However, it looks like I can drop the async and await keywords and they will produce the same result.

t1 = Task.Run(() => DoSomethingExpensiveAsync());
t2 = Task.Run(() => DoSomethingExpensiveAsync());
await Task.WhenAll(t1, t2);

vs

var t1 = Task.Run(async () => await DoSomethingExpensiveAsync());
var t2 = Task.Run(async () => await DoSomethingExpensiveAsync());
await Task.WhenAll(t1, t2);

How come the compiler let me do this and what is happening behind the scene?
Is there a situation where adding them will make a difference?

Does this answer your question? [is using an an \`async\` lambda with \`Task.Run()\` redundant?](https://stackoverflow.com/questions/32591462/is-using-an-an-async-lambda-with-task-run-redundant) — janw, Feb 16 '20 at 09:41
You forgot this variation: `var t1 = Task.Run(DoSomethingExpensiveAsync);` — John Wu, Feb 16 '20 at 09:48
@JanWichelmann no the post you suggested does not answer my question. The post does not explain the technical difference. The suggested answer only tells you not to Wait an async method. — little_stone_05, Feb 16 '20 at 10:03

John Wu · Answer 1 · 2020-02-17T21:26:50.720

There are actually three variants.

var task = Task.Run(() => DoSomethingExpensiveAsync());

^ This one declares a new anonymous non-async function that calls DoSomethingExpensiveAsync() and returns its Task. The compiler compiles this anonymous function and passes it as an argument to Task.Run().

var task = Task.Run( async () => await DoSomethingExpensiveAsync() );

^ This one declares a new anonymous async function that calls DoSomethingExpensiveAsync(). It then returns an incomplete Task, waits for DoSomethingExpensiveAsync() to finish, and then signals the task as complete.

var task = Task.Run(DoSomethingExpensiveAsync);

^ This one does not declare a new anonymous function at all. A direct reference to DoSomethingExpensiveAsync will be passed as an argument to Task.Run().

All of these are valid because all three versions return a Task and therefore match the overload of Task.Run() that accepts a Func<Task>.

As a black box, all three calls will end up doing the same thing. However the first two result in a new function being compiled (although I'm not certain it wouldn't be optimized away) and the second one also results in another state machine being created for it.

The difference might be clearer if we rewrite them without using lambda expressions or anonymous functions. The following code does exactly the same thing:

//This is the same as Task.Run( () => DoSomethingExpensiveAsync());
Task Foo()
{
    return DoSomethingExpensiveAsync();
}
var task = Task.Run(Foo);

//This is the same as Task.Run(async () => await DoSomethingExpensiveAsync());
async Task Bar()
{
    return await DoSomethingExpensiveAsync();
}
var task = Task.Run(Bar);

The difference between these two is that one "elides" tasks while the other doesn't. Stephen Cleary has written a whole blog on the subject.

Which version you choose will also influence the stack trace if `DoSomethingExpensiveAsync()` returns a Faulted task due to an exception. — yaakov, Feb 17 '20 at 21:30

score 1 · Accepted Answer · answered Feb 17 '20 at 03:25

How come the compiler let me do this and what is happening behind the scene?

The overload of Task.Run that you're invoking takes a Func<Task> - that is, a Task-returning function. It doesn't matter where the Task comes from; the function just needs to return it from somewhere.

If you pass a delegate without async and await, then the delegate is just calling a Task-returning function and returns that same Task. If you pass a delegate with async and await, then the delegate calls the Task-returning function and awaits it; the actual Task returned from the delegate is created by the async keyword.

In this case, the two are semantically equivalent. Using the async/await keywords are a bit less efficient, since the compiler creates a state machine for the async delegate.

Is there a situation where adding them will make a difference?

Yes. In the general case, you should keep async and await. Only remove them in extremely simple "passthrough" situations like the one here.

score 0 · Answer 3 · answered Feb 16 '20 at 09:42

0

Your code is the same as

t1 = DoSomethingExpensiveAsync();
t2 = DoSomethingExpensiveAsync();
await Task.WhenAll( t1, t2 );

because Task.Run( Func< function ) will return a proxy of the task generated by function. There is no other Task created, and so you are awaiting the original tasks.

When you already have an async method then there is no need to use Task.Run at all.

answered Feb 16 '20 at 09:42

Sir Rufo

18,395
2
39
73

You can use `Task.Run` together with `async` method if you want to get rid of original synchronization context. – mtkachenko Feb 16 '20 at 10:12

score -1 · Answer 4 · answered Feb 16 '20 at 20:38

Without knowing what DoSomethingExpensiveAsync it's impossible to tell for certain what will happen.

Let's assume DoSomethingExpensiveAsync is something like this:

async Task DoSomethingExpensiveAsync()
{
     SynchronousMethod();
     await AsynchronousMethod();
}

In the first snippet, Task.Run will schedule the invocation of DoSomethingExpensiveAsync to the thread pool and returns as soon as SynchronousMethod returns.

In the second snippet, Task.Run will schedule the invocation of DoSomethingExpensiveAsync to the thread pool and returns when the Task return by DoSomethingExpensiveAsync is completed.

How does that answer the question? The question was about why async / await can be omitted in the cases shown. — Matt, Mar 31 '20 at 15:12

Are the await / async keywords needed under Task.Run?

4 Answers4