One of the biggest challenges when using async/await is mixing sync with async, and in particular calling an async function within a sync function. It's tempting to use Task.Result or Task.Wait to resolve this. For example:

public bool SomeSyncFunc()
{
    ...
    HttpClient client = new HttpClient();  
    var callResponse = client.PostAsJsonAsync(url, request).Result;
    ...
}

Here we're calling an async function, and immediately blocking by accessing the Task.Result. This is referred to as "Sync over async", and is something to avoid. It may successfully block and wait for the async call to complete (thereby keeping SomeSyncFunc a sync function). However this leads to a performance issue. Here's what happens at a high level:

• The asynchronous operation is kicked off (PostAsJsonAsync).
• The calling thread is blocked waiting for that operation to complete.
• Once completed, a second thread is used to perform the unblock notification on the original thread.

As a result, two threads are used instead of one. Under some conditions, this could lead to thread-pool starvation.

Task.Run(...).Result

Another variation looks like the following:

public string DoOperationBlocking()
{
    return Task.Run(() => DoAsyncOperation()).Result;
}

This is another example of code that's tempting to use, and seems to work when testing it, but can lead to performance issues.

Conclusion

Using Task.Result is tempting because it's a simple way to call an async function. However it doesn't scale well. When at all possible, either make the outer function async, or find a sync API call to use within it.