This question already has an answer here:
According to MSDN, async
and await
do not create new threads:
The
async
andawait
keywords don't cause additional threads to be created.
With this in mind, I'm having difficulty understanding control flow of some simple programs. My complete example is below. Note that it requires the Dataflow library, which you can install from NuGet.
using System;
using System.Threading.Tasks.Dataflow;
namespace TaskSandbox
{
class Program
{
static void Main(string[] args)
{
BufferBlock<int> bufferBlock = new BufferBlock<int>();
Consume(bufferBlock);
Produce(bufferBlock);
Console.ReadLine();
}
static bool touched;
static void Produce(ITargetBlock<int> target)
{
for (int i = 0; i < 5; i++)
{
Console.Error.WriteLine("Producing " + i);
target.Post(i);
Console.Error.WriteLine("Performing intensive computation");
touched = false;
for (int j = 0; j < 100000000; j++)
;
Console.Error.WriteLine("Finished intensive computation. Touched: " + touched);
}
target.Complete();
}
static async void Consume(ISourceBlock<int> source)
{
while (await source.OutputAvailableAsync())
{
touched = true;
int received = source.Receive();
Console.Error.WriteLine("Received " + received);
}
}
}
}
Output:
Producing 0
Performing intensive computation
Received 0
Finished intensive computation. Touched: True
Producing 1
Performing intensive computation
Received 1
Finished intensive computation. Touched: True
Producing 2
Performing intensive computation
Received 2
Finished intensive computation. Touched: False
Producing 3
Performing intensive computation
Received 3
Finished intensive computation. Touched: False
Producing 4
Performing intensive computation
Received 4
Finished intensive computation. Touched: True
This seems to indicate that Consume
is given control while the for
loop is running, as the OutputAvailableAsync
task completes:
for (int j = 0; j < 100000000; j++)
;
This would be unsurprising in a threaded model. But if no additional threads are involved, how can Produce
yield control in the middle of the for
loop?
if no additional threads are involved, how can Produce yield control in the middle of the for loop?
Who said no additional threads are involved? The fact that you stated was:
The async and await keywords don't cause additional threads to be created.
Which is absolutely true. Your program includes the fragments
target.Post(i);
await source.OutputAvailableAsync())
My guess would be that the call to target.Post(i)
or source.OutputAvailableAsync()
created a thread. The await
doesn't produce a thread; all the await
does is assigns the remainder of the method as the continuation of the task returned by the call and then returns control to the caller. If that task spawned a thread to do its work, that's it's business.
await
is just another control flow; a very complicated control flow, to be sure, but a control flow nevertheless. It's not a syntactic sugar for creating threads; it's a syntactic sugar for assigning a continuation to a task.
await
operator (more specifically, the task awaiter used by the code generated by the await
operator) is using the default SynchronizationContext
to schedule method continuations on thread pool threads. - Stephen Cleary
The control handling is done within the same thread, so that when the loop is running, the Consume
method is not, and vice versa. If you were using threads it might not necessarily be so, and in fact you'd expect both to run concurrently.
The fact that they are in the same thread does not mean in any way that control can't pass from a part of the code to another. .NET (and every other framework, AFAIK) handles that smoothly, and each part runs with its own context with no problems.
However, running both things in one thread means that while Consume
is running, the loop will "hang". If Consume
takes too long, that's exactly what a user might perceive. That's why many programmers who are new to windows forms get surprised that filling their GUI controls with too much information at once causes their forms to hang and sometimes blank out - the thread that refreshes the screen is the same one where control logic runs, if you're not using background worker threads.
Consume
without Produce
explicitly yielding control? Does .NET notice that Produce
has been running for a long time, and give control to Consume
(similar to the role of the OS in a threaded model)? - Matthew
Produce
toConsume
withoutProduce
explicitly yielding control. That is the part that I am confused about. - MatthewSynchronizationContext
, which means that all of the callbacks fromawait
calls go toSynchronizationContext.Default
, which is the thread pool, so technically there are actually two threads running at times during the execution of this program. To prevent the creation of additional threads you'd need to create your own custom sync context and set that. If you did, you'd see that theRecieved
calls wouldn't be called until all of the producing was done specifically because you're not yielding control while producing. - Servyawait
doesn't necessarily involve the creation of thread. You can use it in ways that don't ever create threads. You simply haven't done so. Also note that it's using the thread pool thread just to run the callback. That thread pool thread isn't blocking when it has nothing to do, it's actually doing nothing and is released back to the pool; it's capable of handling another request. This is important because it means you don't have 100 thread pool thread sitting there blocking, waiting for IO to be completed. - Servyasync
/await
intro helpful. I tried to cover the basics (with all relevant details) in a single post. - Stephen Cleary