Is Task.Result the same as .GetAwaiter.GetResult()?

Question

I was recently reading some code that uses a lot of async methods, but then sometimes needs to execute them synchronously. The code does:

Foo foo = GetFooAsync(...).GetAwaiter().GetResult();

Is this the same as

Foo foo = GetFooAsync(...).Result;

Newsprint

From the docs of GetResult: "This type and its members are intended for use by the compiler." Other person shouldn't be using it. – Zaxis

This is called "sync over async", and unless you know how the task is implemented can be a really bad idea. It can instantly deadlock in many cases (an async/await method in MVC, for example) – Salisbarry

Don't Block on Async Code – Carinacarinate

In the real world, we have constructors, we have "no await" interfaces we need to implement, and we are given async methods everywhere. I would be pleased to use something that just works without I have to wonder why it is "dangerous", "not to be used" or "avoid at all costs". Every single time I have to mess with async turn out to a headache. – Skinflint

Totally agree Larry. I'm calling a new async microservice from my monolith and using async/await everywhere means I have to update 100+ files. Quite a headache. – Laundry

Answer 1

Task.GetAwaiter().GetResult() is preferred over Task.Wait and Task.Result because it propagates exceptions rather than wrapping them in an AggregateException. However, all three methods cause the potential for deadlock and thread pool starvation issues. They should all be avoided in favor of async/await.

The quote below explains why Task.Wait and Task.Result don't simply contain the exception propagation behavior of Task.GetAwaiter().GetResult() (due to a "very high compatibility bar").

As I mentioned previously, we have a very high compatibility bar, and thus we’ve avoided breaking changes. As such, Task.Wait retains its original behavior of always wrapping. However, you may find yourself in some advanced situations where you want behavior similar to the synchronous blocking employed by Task.Wait, but where you want the original exception propagated unwrapped rather than it being encased in an AggregateException. To achieve that, you can target the Task’s awaiter directly. When you write “await task;”, the compiler translates that into usage of the Task.GetAwaiter() method, which returns an instance that has a GetResult() method. When used on a faulted Task, GetResult() will propagate the original exception (this is how “await task;” gets its behavior). You can thus use “task.GetAwaiter().GetResult()” if you want to directly invoke this propagation logic.

https://devblogs.microsoft.com/pfxteam/task-exception-handling-in-net-4-5/

“GetResult” actually means “check the task for errors”

In general, I try my best to avoid synchronously blocking on an asynchronous task. However, there are a handful of situations where I do violate that guideline. In those rare conditions, my preferred method is GetAwaiter().GetResult() because it preserves the task exceptions instead of wrapping them in an AggregateException.

https://blog.stephencleary.com/2014/12/a-tour-of-task-part-6-results.html

Ormolu

So basically Task.GetAwaiter().GetResult() is equivalent to await task. I assume the first option is used when the method cannot be marked with async(constructor for instance). Is that correct? If yes, then it collides with the top answer @It'sNotALie – Nahshon

@OlegI: Task.GetAwaiter().GetResult() is more equivalent to Task.Wait and Task.Result (in that all three will block synchronously and have the potential for deadlocks), but Task.GetAwaiter().GetResult() has the exception propagation behavior of await task. – Ormolu

Can't you avoid deadlocks in this scenario with (Task).ConfigureAwait(false).GetAwaiter().GetResult(); ? – Therm

@DanielLorenz: See the following quote: "Using ConfigureAwait(false) to avoid deadlocks is a dangerous practice. You would have to use ConfigureAwait(false) for every await in the transitive closure of all methods called by the blocking code, including all third- and second-party code. Using ConfigureAwait(false) to avoid deadlock is at best just a hack). ... the better solution is “Don’t block on async code”." - blog.stephencleary.com/2012/07/dont-block-on-async-code.html – Ormolu

@NitinAgarwal Ah, I see the dilemma. If the top of the code is synchronous through all the layers and then you end up having to call an async method, the best answer is that you should make it async. However, if you have dozens of methods that happen to call this one method that then needs to call an async method, it isn't so easy of a change there. If you can guarantee ConfigureAwait(false) there, you can technically do it but it is dangerous/frowned upon. – Therm

I don't get it. Task.Wait and Task.Result are broken by design? Why aren't they made obsolete? – Daugavpils

I think Task.GetAwaiter().GetResult() can be protected by Mutex to avoid deadlocks should there is an absolute need in using Task.GetAwaiter().GetResult() – Premium

This statement “Don’t block on async code” is really frustrating to me. I am converting older, ahem, console apps from .NET 3.x and 4.5 into .NET 6.0 for LTS support. I am using async calls for the Repository and Service classes but some of the original code is just not setup for async operations so I HAVE TO block async calls. Since I am in a STA Thread to start with wouldn't this be acceptable if the async calls were using GetAwaiter().GetResult()? Remember, this is NOT theory but a practical example so I would expect a practical use case answer. – Ammoniac

@NitinAgarwal For the sake of completeness, when using (Task).ConfigureAwait(false).GetAwaiter().GetResult();, the ConfigureAwait(false) wouldn't do anything. It configures how the "continuation" works, not the Task. – Anglicize

@Ammoniac IMO you answered your own question. Sometimes you just can't follow the "best practices". Just be aware of the pitfalls. Consider using continuations with ContinueWith() instead of GetAwaiter().GetResult(). If you need to capture the context you can set TaskScheduler.FromCurrentSynchronizationContext() as a parameter. – Anglicize

Answer 2

EDIT: This was written when I was 13, and is out of date. I recommend Nitin Agarwal's answer instead.

Pretty much. One small difference though: if the Task fails, GetResult() will just throw the exception caused directly, while Task.Result will throw an AggregateException. However, what's the point of using either of those when it's async? The 100x better option is to use await.

Also, you're not meant to use GetResult(). It's meant to be for compiler use only, not for you. But if you don't want the annoying AggregateException, use it.

Prato

"The 100x better option is to use await". One example of where this is done is in unit test methods. You gotta sync up sometime, right? – Newsprint

@JayBazuzi Not if your unit testing framework supports async unit tests, which I think newest versions of most frameworks do. – Cisterna

@JayBazuzi At the top level you should ideally be creating a new sync context (i.e. a message loop) to handle the test. As was mentioned, some frameworks now do this for you. If they don't, it's probably appropriate for you to actually make your own, given that you're most likely testing code that assumes it will have a sync context and exist within a message loop. If the framework code itself isn't written to be async this simply means you need a message loop per test (which is fine, and probably a good thing) rather than for an entire suite. – Loire

@JayBazuzi: MSTest, xUnit, and NUnit all support async Task unit tests, and have for some time now. – Oblivious

pushing back on the 100x - it's 1000x worse to use await if you're adapting old code and using await requires a rewrite. – Pressroom

@StephenCleary anyway, sometimes you should call async method form constructor. In this case you have to block on Result. – Anchie

@AlexZhukovskiy: I disagree. – Oblivious

@StephenCleary well, sometimes it fits. But for example, when I run some initialization in constructor of WCF service (or any other framework), then I cannot say to framework `hey, use my cool static method instead of constructor). – Anchie

The 100x better option is to use await. I hate statements like this, if I could slap await in front of it I would. But, when I'm trying to get async code to work against non-async code like what frequently happens to me a lot in Xamarin, I end up having to use things like ContinueWith a lot in order to make it not deadlock the UI. Edit: I know this is old, but that doesn't alleviate my frustration finding answers that state this with no alternatives for situations where you can't just use await. – Pestalozzi

.GetAwaiter.Result is the recommended use instead of .Result. Your answer is misleading... Check Microsoft Blog – Perseid

@Perseid - my detail obsession just kicked in, actually the blog says .GetAwaiter().GetResult() – Candycecandystriped

One place I see usage of the synchronous waiting is when refactoring legacy / bad code. When the dependency already is returning a Task, but the caller is not yet ready or is using it for example in it's constructor. – Fabrianne

Hello? Constructors? We can't use async there. – Schreibman

Some .NetFramework handlers only offer sync methods so you will need to sync await the result. Like ModelBinders for ASP.Net. – Ioab

There is certainly a reason for needing to use Wait() or GetAwaiter().GetResult(). One of the simplest examples is running a timer that must run async code. The way that timers are setup with their elapsed callback, it only allows you to return void. You can't simply make that callback async, the framework doesn't allow you. I think that it's a decent answer, but don't neglect the fact that there are reasons that you can't simply await the async method – Alagoas

@MladenB. Stephen Cleary already provided a link about that: blog.stephencleary.com/2013/01/async-oop-2-constructors.html – Objection

@NewteqDeveloper yes you can. Situations like that and event handlers are why async void methods exist. – Nowhere

Also, we already have github.com/StephenCleary/AsyncEx/blob/master/doc/… thanks to StephenCleary. Sure, we sometimes have to wait, and have to block that current caller's thread, but sometimes the deadlocks are about SynchronizationContext, not thread. Stephen's AsyncContext can help with those deadlock cases. – Pinwheel

Answer 3

https://github.com/aspnet/Security/issues/59

"One last remark: you should avoid using Task.Result and Task.Wait as much as possible as they always encapsulate the inner exception in an AggregateException and replace the message by a generic one (One or more errors occurred), which makes debugging harder. Even if the synchronous version shouldn't be used that often, you should strongly consider using Task.GetAwaiter().GetResult() instead."

Odessa

The source referenced here is someone quoting someone else, without a reference. Consider context: I can see lots of people blindly using GetAwaiter().GetResult() everywhere after reading this. – Dubious

So we shouldn't use it? – Parsec

If two tasks end with an exception you will loose the second one in this scenario Task.WhenAll(task1, task2).GetAwaiter().GetResult();. – Beggar

Here's another example: github.com/aspnet/AspNetCore/issues/13611 – Those

Answer 4

Another difference is when async function returns just Task instead of Task<T> then you cannot use

GetFooAsync(...).Result;

Whereas

GetFooAsync(...).GetAwaiter().GetResult();

still works.

I know the example code in the question is for the case Task<T>, however the question is asked generally.

Calida

This is not true. Check out my fiddle which uses exactly this construct: dotnetfiddle.net/B4ewH8 – Everson

@Everson In your code, you are using Result with GetIntAsync() which returns Task<int> not just Task. I suggest you to read my answer again. – Calida

You're right, at first I understood you answer that you can't GetFooAsync(...).Result inside a function that returns Task. This now makes sense, since there are no void Properties in C# (Task.Result is a property), but you can of course call a void method. – Everson

The Task is not returning a value so we expect .Result to be an error. The fact that task.GetAwaiter().GetResult() still works is counter-intuitive and deserves a little emphasis. – Belldame

Answer 5

As already mentioned if you can use await. If you need to run the code synchronously like you mention .GetAwaiter().GetResult(), .Result or .Wait() is a risk for deadlocks as many have said in comments/answers. Since most of us like oneliners you can use these for .Net 4.5<

Acquiring a value via an async method:

var result = Task.Run(() => asyncGetValue()).Result;

Syncronously calling an async method

Task.Run(() => asyncMethod()).Wait();

No deadlock issues will occur due to the use of Task.Run.

Source:

https://mcmap.net/q/47495/-39-await-39-works-but-calling-task-result-hangs-deadlocks

Update:

Could cause a deadlock if the calling thread is from the threadpool. The following happens: A new task is queued to the end of the queue, and the threadpool thread which would eventually execute the Task is blocked until the Task is executed.

Source:

https://medium.com/rubrikkgroup/understanding-async-avoiding-deadlocks-e41f8f2c6f5d

Gouache

Why does it prevent a deadlock? I realize that Task.Run offloads the work to ThreadPool, but we're still waiting on this thread for that work to finish. – Immunize

@Immunize The problem with using only .Result or .Wait() is that if you block the threads which are supposed to work on the Tasks, then there won’t be a thread to complete a Task. You can read more about it here: medium.com/rubrikkgroup/… – Gouache

Weird, I would do Task.Run(async () => await blahblah()); – Alabama

Answer 6

I checked the source code of TaskOfResult.cs (Source code of TaskOfResult.cs):

If Task is not completed, Task.Result will call Task.Wait() method in getter.

public TResult Result
{
    get
    {
        // If the result has not been calculated yet, wait for it.
        if (!IsCompleted)
        {
            // We call NOCTD for two reasons: 
            //    1. If the task runs on another thread, then we definitely need to notify that thread-slipping is required.
            //    2. If the task runs inline but takes some time to complete, it will suffer ThreadAbort with possible state corruption.
            //         - it is best to prevent this unless the user explicitly asks to view the value with thread-slipping enabled.
            //#if !PFX_LEGACY_3_5
            //                    Debugger.NotifyOfCrossThreadDependency();  
            //#endif
            Wait();
        }

        // Throw an exception if appropriate.
        ThrowIfExceptional(!m_resultWasSet);

        // We shouldn't be here if the result has not been set.
        Contract.Assert(m_resultWasSet, "Task<T>.Result getter: Expected result to have been set.");

        return m_result;
    }
    internal set
    {
        Contract.Assert(m_valueSelector == null, "Task<T>.Result_set: m_valueSelector != null");

        if (!TrySetResult(value))
        {
            throw new InvalidOperationException(Strings.TaskT_TransitionToFinal_AlreadyCompleted);
        }
    }
}

If we call the GetAwaiter method of Task, Task will wrapped TaskAwaiter<TResult> (Source code of GetAwaiter()), (Source code of TaskAwaiter) :

public TaskAwaiter GetAwaiter()
{
    return new TaskAwaiter(this);
}

And if we call the GetResult() method of TaskAwaiter<TResult>, it will call Task.Result property, that Task.Result will call Wait() method of Task ( Source code of GetResult()):

public TResult GetResult()
{
    TaskAwaiter.ValidateEnd(m_task);
    return m_task.Result;
}

It is source code of ValidateEnd(Task task) ( Source code of ValidateEnd(Task task) ):

internal static void ValidateEnd(Task task)
{
    if (task.Status != TaskStatus.RanToCompletion)
         HandleNonSuccess(task);
}

private static void HandleNonSuccess(Task task)
{
    if (!task.IsCompleted)
    {
        try { task.Wait(); }
        catch { }
    }
    if (task.Status != TaskStatus.RanToCompletion)
    {
        ThrowForNonSuccess(task);
    }
}

This is my conclusion:

As can be seen GetResult() is calling TaskAwaiter.ValidateEnd(...), therefore Task.Result is not same GetAwaiter.GetResult().

I think GetAwaiter().GetResult() is a better choice instead of .Result because the former doesn't wrap exceptions.

I read this at page 582 in C# 7 in a Nutshell (Joseph Albahari & Ben Albahari).

If an antecedent task faults, the exception is re-thrown when the continuation code calls awaiter.GetResult() . Rather than calling GetResult , we could simply access the Result property of the antecedent. The benefit of calling GetResult is that if the antecedent faults, the exception is thrown directly without being wrapped in AggregateException , allowing for simpler and cleaner catch blocks.

Source: C# 7 in a Nutshell's page 582

Raver

Answer 7

If a task faults, the exception is re-thrown when the continuation code calls awaiter.GetResult(). Rather than calling GetResult, we could simply access the Result property of the task. The benefit of calling GetResult is that if the task faults, the exception is thrown directly without being wrapped in AggregateException, allowing for simpler and cleaner catch blocks.

For nongeneric tasks, GetResult() has a void return value. Its useful function is then solely to rethrow exceptions.

source : c# 7.0 in a Nutshell

Museum

Answer 8

Task.Result, .GetAwaiter().GetResult(), and Task.Wait are all mechanisms to wait synchronously for a Task to complete in C#, but they differ in their behavior and side effects:

Task.Result:

• Blocks the calling thread until the task completes.
• If the task has completed with an exception, Task.Result will rethrow the original exception wrapped in an AggregateException.
• This can make it harder to catch specific exceptions since you must catch the AggregateException and then check its InnerExceptions.

.GetAwaiter().GetResult():

• Also blocks the calling thread until the task completes.
• Unlike Task.Result, it rethrows the original exception directly,
  without wrapping it in an AggregateException.
• This makes exception handling more straightforward because you can
  catch specific exceptions directly.

Task.Wait:

• Blocks the calling thread until the task completes, similar to Task.Result.
• Does not return the result of the task; it's used when you only care about the completion of the task, not its result.
• Like Task.Result, it wraps any exceptions in an AggregateException.

In summary, Task.Result and Task.Wait are similar in that they both wrap exceptions in an AggregateException, but Task.Result is used when you need the result of the task. .GetAwaiter().GetResult() is preferred when you need both the result of the task and direct exception handling. All three should be used cautiously to avoid deadlocks, especially in UI applications or in asynchronous code paths.

Com