We Keep Coding

await Task.Run vs await

I've searched the web and seen a lot of questions regarding Task.Run vs await async, but there is this specific usage scenario where I don't not really understand the difference. Scenario is quite simple i believe.
await Task.Run(() => LongProcess());
vs
await LongProcess());
where LongProcess is a async method with a few asynchronous calls in it like calling db with await ExecuteReaderAsync() for instance.
Question:
Is there any difference between the two in this scenario? Any help or input appreciated, thanks!

Task.Run may post the operation to be processed at a different thread. That's the only difference.
This may be of use - for example, if LongProcess isn't truly asynchronous, it will make the caller return faster. But for a truly asynchronous method, there's no point in using Task.Run, and it may result in unnecessary waste.
Be careful, though, because the behaviour of Task.Run will change based on overload resolution. In your example, the Func<Task> overload will be chosen, which will (correctly) wait for LongProcess to finish. However, if a non-task-returning delegate was used, Task.Run will only wait for execution up to the first await (note that this is how TaskFactory.StartNew will always behave, so don't use that).

Quite often people think that async-await is done by several threads. In fact it is all done by one thread.
See the addition below about this one thread statement
The thing that helped me a lot to understand async-await is this interview with Eric Lippert about async-await. Somewhere in the middle he compares async await with a cook who has to wait for some water to boil. Instead of doing nothing, he looks around to see if there is still something else to do like slicing the onions. If that is finished, and the water still doesn't boil he checks if there is something else to do, and so forth until he has nothing to do but wait. In that case he returns to the first thing he waited for.
If your procedure calls an awaitable function, we are certain that somewhere in this awaitable function there is a call to an awaitable function, otherwise the function wouldn't be awaitable. In fact, your compiler will warn you if you forget to await somewhere in your awaitable function.
If your awaitable function calls the other awaitable function, then the thread enters this other function and starts doing the things in this function and goes deeper into other functions until he meets an await.
Instead of waiting for the results, the thread goes up in his call stack to see if there are other pieces of code he can process until he sees an await. Go up again in the call stack, process until await, etc. Once everyone is awaiting the thread looks for the bottom await and continues once that is finished.
This has the advantage, that if the caller of your awaitable function does not need the result of your function, but can do other things before the result is needed, these other things can be done by the thread instead of waiting inside your function.
A call without waiting immediately for the result would look like this:
private async Task MyFunction()
{
Task<ReturnType>taskA = SomeFunctionAsync(...)
// I don't need the result yet, I can do something else
DoSomethingElse();
// now I need the result of SomeFunctionAsync, await for it:
ReturnType result = await TaskA;
// now you can use object result
}
Note that in this scenario everything is done by one thread. As long as your thread has something to do he will be busy.
Addition. It is not true that only one thread is involved. Any thread who has nothing to do might continue processing your code after an await. If you check the thread id, you can see that this id can be changed after the await. The continuing thread has the same context as the original thread, so you can act as if it was the original thread. No need to check for InvokeRequired, no need to use mutexes or critical sections. For your code this is as if there is one thread involved.
The link to the article in the end of this answer explains a bit more about thread context
You'll see awaitable functions mainly where some other process has to do things, while your thread just has to wait idly until the other thing is finished. Examples are sending data over the internet, saving a file, communicating with a database etc.
However, sometimes some heavy calculations has to be done, and you want your thread to be free to do something else, like respond to user input. In that case you can start an awaitable action as if you called an async function.
Task<ResultType> LetSomeoneDoHeavyCalculations(...)
{
DoSomePreparations()
// start a different thread that does the heavy calculations:
var myTask = Task.Run( () => DoHeavyCalculations(...))
// now you are free to do other things
DoSomethingElse();
// once you need the result of the HeavyCalculations await for it
var myResult = await myTask;
// use myResult
...
}
Now a different thread is doing the heavy calculations while your thread is free to do other things. Once it starts awaiting your caller can do things until he starts awaiting. Effectively your thread will be fairly free to react on user input. However, this will only be the case if everyone is awaiting. While your thread is busy doing things your thread can't react on user input. Therefore always make sure that if you think your UI thread has to do some busy processing that takes some time use Task.Run and let another thread do it
Another article that helped me: Async-Await by the brilliant explainer Stephen Cleary

This answer deals with the specific case of awaiting an async method in the event handler of a GUI application. In this case the first approach has a significant advantage over the second. Before explaining why, lets rewrite the two approaches in a way that reflects clearly the context of this answer. What follows is only relevant for event handlers of GUI applications.
private async void Button1_Click(object sender, EventArgs args)
{
await Task.Run(async () => await LongProcessAsync());
}
vs
private async void Button1_Click(object sender, EventArgs args)
{
await LongProcessAsync();
}
I added the suffix Async in the method's name, to comply with the guidlines. I also made async the anonymous delegate, just for readability reasons. The overhead of creating a state machine is minuscule, and is dwarfed by the value of communicating clearly that this Task.Run returns a promise-style Task, not an old-school delegate Task intended for background processing of CPU-bound workloads.
The advantage of the first approach is that guarantees that the UI will remain responsive. The second approach offers no such guarantee. As long as you are using the build-in async APIs of the .NET platform, the probability of the UI being blocked by the second approach is pretty small. After all, these APIs are implemented by experts¹. By the moment you start awaiting your own async methods, all guarantees are off. Unless of course your first name is Stephen, and your surname is Toub or Cleary. If that's not the case, it is quite possible that sooner or later you'll write code like this:
public static async Task LongProcessAsync()
{
TeenyWeenyInitialization(); // Synchronous
await SomeBuildInAsyncMethod().ConfigureAwait(false); // Asynchronous
CalculateAndSave(); // Synchronous
}
The problem obviously is with the method TeenyWeenyInitialization(). This method is synchronous, and comes before the first await inside the body of the async method, so it won't be awaited. It will run synchronously every time you call the LongProcessAsync(). So if you follow the second approach (without Task.Run), the TeenyWeenyInitialization() will run on the UI thread.
How bad this can be? The initialization is teeny-weeny after all! Just a quick trip to the database to get a value, read the first line of a small text file, get a value from the registry. It's all over in a couple of milliseconds. At the time you wrote the program. In your PC. Before moving the data folder in a shared drive. Before the amount of data in the database became huge.
But you may get lucky and the TeenyWeenyInitialization() remains fast forever, what about the second synchronous method, the CalculateAndSave()? This one comes after an await that is configured to not capture the context, so it runs on a thread-pool thread. It should never run on the UI thread, right? Wrong. It depends to the Task returned by SomeBuildInAsyncMethod(). If the Task is completed, a thread switch will not occur, and the CalculateAndSave() will run on the same thread that called the method. If you follow the second approach, this will be the UI thread. You may never experience a case where the SomeBuildInAsyncMethod() returned a completed Task in your development environment, but the production environment may be different in ways difficult to predict.
Having an application that performs badly is unpleasant. Having an application that performs badly and freezes the UI is even worse. Do you really want to risk it? If you don't, please use always Task.Run(async inside your event handlers. Especially when awaiting methods you have coded yourself!
¹ Disclaimer, some built-in async APIs are not properly implemented.
Important: The Task.Run runs the supplied asynchronous delegate on a ThreadPool thread, so it's required that the LongProcessAsync has no affinity to the UI thread. If it involves interaction with UI controls, then the Task.Runis not an option. Thanks to #Zmaster for pointing out this important subtlety in the comments.

Task.Run vs. direct async call for starting long-running async methods

Several times, I have found myself writing long-running async methods for things like polling loops. These methods might look something like this:
private async Task PollLoop()
{
while (this.KeepPolling)
{
var response = await someHttpClient.GetAsync(...).ConfigureAwait(false);
var content = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
// do something with content
await Task.Delay(timeBetweenPolls).ConfigureAwait(false);
}
}
The goal of using async for this purpose is that we don't need a dedicated polling thread and yet the logic is (to me) easier to understand than using something like a timer directly (also, no need to worry about reentrance).
My question is, what is the preferred method for launching such a loop from a synchronous context? I can think of at least 2 approaches:
var pollingTask = Task.Run(async () => await this.PollLoop());
// or
var pollingTask = this.PollLoop();
In either case, I can respond to exceptions using ContinueWith(). My main understanding of the difference between these two methods is that the first will initially start looping on a thread-pool thread, whereas the second will run on the current thread until the first await. Is this true? Are there other things to consider or better approaches to try?

My main understanding of the difference between these two methods is
that the first will initially start looping on a thread-pool thread,
whereas the second will run on the current thread until the first
await. Is this true?
Yes. An async method returns its task to its caller on the first await of an awaitable that is not already completed.
By convention most async methods return very quickly. Yours does as well because await someHttpClient.GetAsync will be reached very quickly.
There is no point in moving the beginning of this async method onto the thread-pool. It adds overhead and saves almost no latency. It certainly does not help throughput or scaling behavior.
Using an async lambda here (Task.Run(async () => await this.PollLoop())) is especially useless. It just wraps the task returned by PollLoop with another layer of tasks. it would be better to say Task.Run(() => this.PollLoop()).

My main understanding of the difference between these two methods is that the first will initially start looping on a thread-pool thread, whereas the second will run on the current thread until the first await. Is this true?
Yes, that's true.
In your scenario, there seem to be no need for using Task.Run though, there's practically no code between the method call and the first await, and so PollLoop() will return almost immediately. Needlessly wrapping a task in another task only makes the code less readable and adds overhead. I would rather use the second approach.
Regarding other considerations (e.g. exception handling), I think the two approaches are equivalent.
The goal of using async for this purpose is that we don't need a dedicated polling thread and yet the logic is (to me) easier to understand than using something like a timer directly
As a side-note, this is more or less what a timer would do anyway. In fact Task.Delay is implemented using a timer!

nUnit Assert.That delegate concurrency issue

I am experiencing some temporary dead lock in my code and can't wrap my head around it.
Simple code (I cannot create a simple call chain to reproduce the code in InvokeChangeEvent)
[Test]
public async void Test()
{
sut.InvokeChangeEvent("./foo.file");
// Event is handled by an async handler chaining multiple await resulting in a file write
// await Task.Delay(3000);
Assert.That(() => Directory.GetFiles("some dir").Count(), Is.EqualTo(3).After(15000, 300));
}
I am aware that y'all (:D) want executable code but I wasn't able to slice it down therefore I hope for some insight by explanation.
What happens: sut.InvokeChangeEvent calls an event handler that later calls an async event handler which then calls some async. The end of the chain results in an Task.Run that boils down to write 3 files.
The Assert above is implemented as a delegate with After that returns a DelayedConstraint and has a very large max time (15 secs) and a small polling interval.
Now when I debug the code the InvokeChangeEvent call is entirely executed to the last Task.Run but when the Task.Run returns, the execution is yielded back to the main thread and the Assert is executed entering the "wait with polling".
However the assert never succeeds. When I debug the issue the return of the Task.Run is always handled after the Assert delegate has run (and failed).
I've figured out, that when I place an await Task.Delay(3000); before the Assert, then the code executes properly.
As mentioned the system under test has plenty await and Task.Runs chained and I was unable to reproduce the issue with some easy runnable code.
I've been googling around for a while and I cannot figure out why the Task.Run (which is executed on a different thread) yield in a (temporary) deadlock even though the DelayedConstraint has an explicit polling interval to allow the main thread to progress.
It looks like the DelayedConstraint locks the main thread by some sort of Thread.Sleep. await Task.Delay does not, I am aware of that. What confuses me is I have checked that I always do an await (and never Task.Result, etc) and therefore would expect that the file has been written before the Assert has executed.
(Note: Thread.Sleep instead of await Task.Delay does not work.)
Usually the DelayedConstraint is used to ensure that file system has properly written all files as I have experienced some delays of the file system dealing with files.
I have some feeling that async void event handler may create a situation which I do not understand.
If I manage to create a simple sample, I will update the thread.

By analogy with VS2012 unit testing, try async Task signature rather than async void for your test method. This way, NUnit should be able to keep track of the pending task status and inspect exceptions via Task.Exception.
The async void method is a fire-and-forget concept, by definition. The method returns instantly (precisely, upon the first asynchronous await inside it), and then there is no way to handle its completion or any errors possibly thrown inside it. As is, async void methods are only good for event handlers, provided exceptions are handled within the method with try/catch.

When should you use Task.Run() rather than await?

I am storing the state of my data model. I clone the data model and then want to have it written to "disk" asynchronously.
Should I be using Task.Run() which runs it on a background thread?
Or should I just make it an async function and not await on it? (this will make it run on the UI thread)
Similar stuff to this, but my question is a bit different:
async Task.Run with MVVM
And what is the criteria to decide which to choose?
Thanks!

You should use Task.Run for CPU-based work that you want to run on a thread pool thread.
In your situation, you want to do I/O based work without blocking the UI, so Task.Run won't get you anything (unless you don't have asynchronous I/O APIs available).
As a side note, you definitely do want to await this work. This makes error handling much cleaner.
So, something like this should suffice:
async void buttonSaveClick(..)
{
buttonSave.Enabled = false;
try
{
await myModel.Clone().SaveAsync();
}
catch (Exception ex)
{
// Display error.
}
buttonSave.Enabled = true;
}

I don't think it matters. As far as I know, both methods get dispatched to a thread in the thread pool.
Using async will make the async method run on a background thread and continue on the thread that started it when the async method is finished. You can imagine the compiler seeing the await keyword, put the awaited method in a background thread and wiring up events to notice when the asynch method is finished. Therefore this might be the better choice if you want to show a UI change because of the successful save, and because this is lesser code of course.
Task.Run() would be nicer when you for any reason don't want to put the code in an async method, for example because you want the calling method itself not be async. Also, there's lesser event marshaling involved, but I heavily doubt that there's any performance difference at all.

How to use .net async CTP with just one thread

SO I've been doing a ton of reading lately about the net Async CTP and one thing that keeps coming up are sentences like these: "Asynchrony is not about starting new threads, its about multiplexing work", and "Asynchrony without multithreading is the same idea [as cooperative multitasking]. You do a task for a while, and when it yields control, you do another task for a while on that thread".
I'm trying to understand whether remarks like this are purely (well, mostly) esoteric and academic or whether there is some language construct I'm overlooking that allows the tasks I start via "await" to magically run on the UI thread.
In his blog, Eric Lippert gives this example as a demonstration of how you can have Asyncrhony without multithreading:
async void FrobAll()
{
for(int i = 0; i < 100; ++i)
{
await FrobAsync(i); // somehow get a started task for doing a Frob(i) operation on this thread
}
}
Now, it's the comment that intrigues me here: "...get a started task for doing a Frob(i) operation on this thread".
Just how is this possible? Is this a mostly theoretical remark? The only cases I can see so far where a task appears to not need a separate thread (well, you can't know for sure unless you examine the code) would be something like Task.Delay(), which one can await on without starting another thread. But I consider this a special case, since I didn't write the code for that.
For the average user who wants to offload some of their own long running code from the GUI thread, aren't we talking primarily about doing something like Task.Run to get our work offloaded, and isn't that going to start it in another thread? If so, why all this arm waiving about not confusing asynchorny with multithreading?

Please see my intro to async/await.
In the case of CPU work, you do have to use something like Task.Run to execute it in another thread. However, there's a whole lot of work which is not CPU work (network requests, file system requests, timers, ...), and each of those can be wrapped in a Task without using a thread.
Remember, at the driver level, everything is asynchronous. The synchronous Win32 APIs are just convenience wrappers.

Not 100% sure, but from the article it sounds like what's going on is that it allows windows messages (resize events, mouse clicks, etc) to be interleaved between the calls to FrobAsync. Roughly analogous to:
void FrobAll()
{
for(int i = 0; i < 100; ++i)
{
FrobAsync(i); // somehow get a started task for doing a Frob(i) operation on this thread
System.Windows.Forms.Application.DoEvents();
}
}
or maybe more accurately:
void FrobAll()
{
SynchronizationContext.Current.Post(QueueFrob, 0);
}
void QueueFrob(Object state) {
var i = (int)state;
FrobAsync(i);
if (i == 99) return;
SynchronizationContext.Current.Post(QueueFrob, i+1);
}
Without the nasty call to DoEvents between each iteration. The reason that this occurs is because the call to await sends a Windows message that enqueues the FrobAsync call, allowing any windows messages that occurred between Frobbings to be executed before the next Frobbing begins.

async/await is simply about asynchronous. From the caller side, it doesn't matter if multiple threads are being used or not--simply that it does something asynchronous. IO completion ports, for example, are asychronous but doesn't do any multi-threading (completion of the operation occurs on a background thread; but the "work" wasn't done on that thread).
From the await keyword, "multi-threaded" is meaningless. What the async operation does is an implementation detail.
In the sense of Eric's example, that method could have been implemented as follows:
return Task.Factory.StartNew(SomeMethod,
TaskScheduler.FromCurrentSynchronizationContext());
Which really means queue a call to SomeMethod on the current thread when it's done all the currently queued work. That's asynchronous to the caller of FrobAsync in that FrobAsync returns likely before SomeMethod is executed.
Now, FrobAsync could have been implemented to use multithreading, in which case it could have been written like this:
return Task.Factory.StartNew(SomeMethod);
which would, if the default TaskScheduler was not changed, use the thread pool. But, from the caller's perspective, nothing has changed--you still await the method.
From the perspective of multi-threading, this is what you should be looking at. Using Task.Start, Task.Run, or Task.Factory.StartNew.