How to use .net async CTP with just one thread

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.