32

I'm trying to decide how to wait on all async tasks to complete.

Here is the code I currently have

[HttpGet]
public async Task<JsonResult> doAsyncStuff()
{
  var t1 = this.service1.task1();
  var t2 = this.service2.task2();
  var t3 = this.service3.task3();
  var t4 = this.service4.task4();

  await Task.WhenAll(t1,t2,t3,t4);
  return this.Json(new {redirect = true, href = Url.Action("Blah")}, JsonRequestBehavior.AllowGet);
}

I'm pretty certain the synchronization context isn't relevant so I tried this.

[HttpGet]
public async Task<JsonResult> doAsyncStuff()
{
  var t1 = this.service1.task1().ConfigureAwait(false);
  var t2 = this.service2.task2().ConfigureAwait(false);
  var t3 = this.service3.task3().ConfigureAwait(false);
  var t4 = this.service4.task4().ConfigureAwait(false);

  await Task.WhenAll(t1,t2,t3,t4);
  return this.Json(new {redirect = true, href = Url.Action("Blah")}, JsonRequestBehavior.AllowGet);
}

The problem is now Task.WhenAll has invalid arguments because it will not accept Configured Task Awaiatables.

So Task.WhenAll needs to be replaced with this

await t1; await t2; await t3; await t4;

This doesn't seem correct to me, yet virtually everywhere anyone has anything to say about ConfigureAwait it is "use it, if it doesn't error". And to my knowledge (I didn't write the tasks), they do not use the Synchronous Context, nor do they rely on it.

Important to note I'd like task1 through task4 to run at the same time since they don't rely on the previous one finishing. As a result I don't want await in front of each task. But I don't want to return the Json response until after all 4 complete which is why I currently have the await Task.WhenAll() in the current code.

Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
vipero07
  • 1,022
  • 1
  • 10
  • 16
  • 1
    I updated your title to be a little more representative of the actual problem and question you are having, if you want to you can change it back but "which is better" questions are frowned upon and will likely cause kneejerk reactions where people do not read your actual question. – Scott Chamberlain Jun 05 '15 at 16:16
  • It's "Configure*Await*", not "Configure*Task*". – Stephen Cleary Jun 05 '15 at 16:59
  • @StephenCleary when you use .ConfigureWait(false) on a task it makes the task into a Configured Task Awaitable object. https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.configuredtaskawaitable%28v=vs.110%29.aspx What I was saying is that Task.WhenAll doesn't work on said objects. – vipero07 Jun 05 '15 at 17:33
  • @vipero07: Right. I was saying that the naming is an indication of correct usage. `Task.WhenAll` works on tasks; it doesn't use `await` at all. – Stephen Cleary Jun 05 '15 at 17:46
  • @StephenCleary Ah, I follow now. Yes, good point. Honestly ConfigureAwait is a kind of odd name considering it reads Configure Await false (like... don't configure the await). Yes I am aware the false is for continue on captured context, but it doesn't read that way. – vipero07 Jun 05 '15 at 17:56

1 Answers1

65

You only need ConfigureAwait when you actually perform the await, the correct form would be

[HttpGet]
public async Task<JsonResult> doAsyncStuff()
{
  var t1 = this.service1.task1();
  var t2 = this.service2.task2();
  var t3 = this.service3.task3();
  var t4 = this.service4.task4();

  await Task.WhenAll(t1,t2,t3,t4).ConfigureAwait(false);
  return this.Json(new {redirect = true, href = Url.Action("Blah")}, JsonRequestBehavior.AllowGet);
}
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
  • 4
    @YuvalItzchakov Neither will doing it on each task. `ConfigureAwait` modifies the behavior of the `await` not the behavior of the task you are awaiting on. You don't get a opportunity to change SyncContexts until you hit a `await`, all 4 tasks will still start on the sync context the thread came in with even if he did put `ConfigureAwait` on each line then did `await t1; await t2; await t3; await t4;` at the end. – Scott Chamberlain Jun 05 '15 at 16:07
  • @ScottChamberlain You're right. I somehow got it mixed up. – Yuval Itzchakov Jun 05 '15 at 16:11
  • @ScottChamberlain Thanks, that makes a lot more sense and looks a lot cleaner. For some reason the internet is littered with solutions that immediately await, and it seemed odd to me no one thought of actually running multiple tasks asynchronously. – vipero07 Jun 05 '15 at 17:30
  • 1
    @vipero07 Some things that support async/await don't support multiple concurrent calls to them, even if the calls are all created on the same thread. See [this answer](http://stackoverflow.com/questions/30446100/async-controller-not-returning-anything-to-the-view-when-querying-multiple-datat/30446735#30446735) I posted a few days ago and the question that goes with it to see a example of how it can go wrong. – Scott Chamberlain Jun 05 '15 at 17:37