Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

public async Task<string> GetName(int id)
    Task<string> nameTask = Task.Factory.StartNew(() => string.Format("Name matching id {0} = Developer", id));
    return nameTask.Result;
In above method return statement I am using the Task<T>.Result property.
public async Task<string> GetName(int id)
     Task<string> nameTask = Task.Factory.StartNew(() => string.Format("Name matching id {0} = Developer", id));
     return await nameTask;
Here I am using await Task<T>. I wont be wrong if I think that await will release the calling thread but Task<T>.Result will block it, would it be right?
                Since the second code has no continuation - you gain nothing. in the first code you just mark the method async but you don't await.
– Royi Namir
                Dec 13, 2014 at 22:29
                @RoyiNamir, isn't your statement incorrect? The first method gains nothing by using async as the method blocks the calling thread. However, the second method should yield the current thread and not block until the task is set into a completion state.
– Matt
                Jan 3, 2018 at 9:48
                @MattWolf - I agree that the second method will have a benefit to whatever calls it, by letting it yield control back to the caller while the Task finishes.
– Don Cheadle
                Jul 1, 2018 at 17:15
  
I wont be wrong if I think that await will release the calling thread but Task.Result will block it, would it be right?
Generally, yes. await task; will "yield" the current thread. task.Result will block the current thread. await is an asynchronous wait; Result is a blocking wait.
There's another more minor difference: if the task completes in a faulted state (i.e., with an exception), then await will (re-)raise that exception as-is, but Result will wrap the exception in an AggregateException.
As a side note, avoid Task.Factory.StartNew. It's almost never the correct method to use. If you need to execute work on a background thread, prefer Task.Run.
Both Result and StartNew are appropriate if you are doing dynamic task parallelism; otherwise, they should be avoided. Neither is appropriate if you are doing asynchronous programming.
                and is there any difference of getting a result after await Task.WhenAll(task1, task2)? await task1 vs task1.Result? awaiting WhenAll should have done all work with threads already, right?
– demo
                Apr 18, 2019 at 13:13
                @demo: I prefer await for two reasons: 1) it avoids AggregateException wrappers, and 2) it's more forgiving of code changes - i.e., if someone changes the method earlier and now the task is no longer complete.
– Stephen Cleary
                Apr 18, 2019 at 15:24
I wont be wrong if I think that await will release the calling thread but Task.Result will block it, would it be right?
You're correct, as long as the task hasn't completed synchronously. If it did, using either Task.Result or await task will execute synchronously, as await will first check if the task has completed. Otherwise, if the task hasn't completed, it will block the calling thread for Task.Result, while using await will asynchronously wait for the tasks completion. Another thing that differs is exception handling. While the former will propagate an AggregationException (which may contain one or more exceptions), the latter will unwrap it and return the underlying exception.
As a side note, using asynchronous wrappers over sync methods is bad practice and should be avoided. Also, using Task.Result inside an async method is a cause for deadlocks and should also be avoided.
                how can a deadlock happen in this "using Task.Result inside an async method is a cause for deadlocks", can you elaborate?
– Deepak
                May 7, 2021 at 13:22
                Yuval, the link to your side note is dead. Do you have another resource? Or could you elaborate a bit about what the link was discussing?
– Metro Smurf
                Feb 10 at 14:45
                @Deepak Due to the way SynchronizationContext works, it captures the current context before marshaling control back to the caller when it hits an await. Blocking with Task.Result means that when the callback tries to execute on that context once ready, it'll be forever locked waiting since .Result blocks. There many questions on SO explaining this phenomenon.
– Yuval Itzchakov
                Feb 11 at 10:04
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.