Await and parallelism

If you want to achieve parallelism and you have 3 methods that return say Task<T1>, Task<T2>, Task<T3>, it's pretty simple: start all the tasks first, but don't await any, and only then await, either all of them together with await Task.WhenAll() (ideally; otherwise less preferably with the blocking Task.WaitAll()), or individually with await for each. So something like this:

Task<T1> getFooTask = GetFoo(); Task<T2> getBarTask = GetBar(); Task<T3> getQuuxTask = GetQuux(); // All tasks started (or at least queued) now, potentially (probably) running in parallel await Task.WhenAll(getFooTask, getBarTask, getQuuxTask); // All tasks complete now 

You can then inspect the results individually:

T1 fooResults = await getFooTask; T2 barResults = await getBarTask; T3 quuxResults = await getQuuxTask; 

or perhaps:

Getstuff(await getFooTask, await getBarTask, await getQuuxTask); 

You can also use .Result without blocking at this point, but using await again refactors better.

To await them individually (and still achieve parallelism), just drop the await Task.WhenAll() line.

As a side note, dropping the await Task.WhenAll() is a simple example showing the benefit of using await on a completed task instead of .Result. If you had used .Result instead, the behaviour would have changed from non-blocking to blocking.

Your scenario is pretty vague. I am assuming here that all three of these awaitable tasks are already running concurrently, such that your original code is synchronously awaiting the individual results.

First, it's important to point out that your proposed change to the code does materially and detrimentally change the basic behavior of the code. Where the code used to potentially allow for asynchronous waiting of completion, your proposed change forces the thread to synchronously wait for completion. This should be avoided.

I'd thought that was reasonably obvious, but judging from the comments, there are folks who are confused about my intent here, hence this explicit caveat. With that in mind…

Your second example, ignoring your syntax errors, can (and should) be simplified to:

Task.WaitAll(getFoo, getBar, getQuux); var fooLookup = getFoo.Result.Entries.ToLookup(x => x.Something); var barDictionary = getBar.Result?.Entries.ToDictionary(x => x.Something); var quuxDictionary = getQuux.Result?.Entries.ToDictionary(x => x.Something); 

But in reality, if your method is not itself inherently an asynchronous operation, you should not force that onto it. It is simple enough for the caller to do that as needed:

Task.WaitAll(getFoo, getBar, getQuux); GetStuff(await getFoo, await getBar, await getQuux); 

The WaitAll() enforces the synchronous behavior your example has. Again, it's not that this is desirable. It's just that this is required, in order to be consistent with your example.

In this way, all three tasks are assured of having completed before you try to pass their results to GetStuff() and GetStuff() can remain its nice, simple synchronous self.

Using await just helps unpack exceptions, making them easier to handle, log, etc. You could of course use e.g. getFoo.Result instead of await getFoo.

But you don't even need that! Assuming these three tasks are all already running, then awaiting all three in sequence doesn't in any way prevent them from running concurrently. Even if the first is the last to finish, by the time that one finishes, the other two will have also and those awaits will complete immediately.

And importantly, doing it in this way prevents the thread from being blocked while you wait for the results to be available. This is much better than the synchronous waiting you'd proposed as an alternative.

In other words, your original code is fine, and better than what you'd proposed as an alternative. Don't change it.