Jeffrey Richter and his AsyncEnumerator

 

 

Regarding the difference between this and PFX, they are solving different problems. PFX is about providing simple means of parallel execution; Jeff's library is about maximizing thread efficiency by avoiding thread blocking altogether by following the APM model. APM is a requirement when writing programs that:
(1) have potentially hundreds or thousands of parallel execution paths
(2) spend most of their time blocking
Without (1), you won't gain enough through the APM to justify the extra programming effort. Without (2), you won't save anything with the APM. The quintessential application is a sockets server that accepts requests over the net. Because the Internet is slow, requests may take many seconds from end to end, and yet spend most of their time blocked waiting on a slow network. A well-written asynchronous TCP server can handle a thousand concurrent requests while consuming just a few threads.

APM relies on methods returning with a callback rather than blocking the underlying thread. There are actually fairly few truely asycnhronous methods in the .NET Framework - most are related to networking, where the most gains are to be had.

 

Jeff's idea is very clever - but it's dubious using it for retrieving web pages in the background in a Win Forms application. The only thing he's achieving is saving the overhead of tying up one or two threads for a few seconds. There was a time when tying up 1MB of memory for a few seconds was a big deal, but those days are long gone. Using PFX (or asynchronous delegates, which interestingly don't follow the APM) would be simpler and just as effective.

 

By far, the most common use for the async-callback-method model is writing a TCP or HTTP server capable of handling hundreds of concurrent requests. It's NOT required within ASP.NET apps because the ASP.NET infrastructure already does this for you. It's also not needed around making database calls within a web app because the DB server will nearly always be more of a bottleneck than the accompanying thread overhead. And who in real life would give up the productivity of the high-level synchronous DB libraries such as LINQ to SQL and revert to using low-level async-compliant SqlCommand objects and the like?

 

So if you were writing a large TCP or HTTP server from scratch yourself, Jeff's library may be very helpful. The only problem I can see (unless I'm mistaken) is that you can't refactor iterator methods into smaller chunks - as its complexity grows, the method will get bigger and bigger and there's nothing you can do about it. The problem is that any methods that you call from an iterator can't themselves yield on behalf of the caller. So if you wanted to do this:

foreach (var foo in far)
   AnotherMethod (foo);

then AnotherMethod couldn't do anything asynchronous within its implementation.

Joe

I certainly agree with your comments about server-side code. However, I disagree with your thoughts about client-side code. On my machine Outlook (just to pick some app as an example) has over 50 threads in it because the Outlook developers have the mindset that it isn't bad to just spawn off a few more threads and allocate a few more megabytes of memory. However, this wastes a lot of resources and if Outlook is running on a terminal server machine hosting 100 client sessions, then that means 5,000 threads on the system! In fact, because this problem is so bad, Windows 7 is doing a lot to reduce the number of threads used throughout system services and applications that ship with the OS so that Windows 7 will run well on small footprint machines with only 1GB of RAM in them. Clearly the Windows team feels that all the threads they have been creating has been hurting them and they are finally doing something about it.

And, since I'd like to make things better for Windows users,  I highly recommend asynchrounous programming for client-side applications. Also, delegates DO support the APM via their BeginInvoke/EndInvoke methods and because of this, asynchronous delegate invocations integrate quite nicely with my AsyncEnumerator. In addition, my AsyncEnumerator automatically marshals the result back to the GUI thread so there is no need to call Control's BeginInvoke method (for Windows Forms) or DispatcherObject's BeginIvoke method (for WPF). Furthermore, my AE offers cancelation/timeout support as well as discard support which are all useful features for client-side applications that you do not get with the APM alone or by just spawning up another thread.

ASP.NET does support the ability for developers to implement their web form or web service app asynchronously but few developers take advantage of this. However, ASP.NET offers it as an option because it does not simply give it to you by default. Also, it is very useful to perform async programming when accessing a DB because the DB IS a bottleneck (as you point out). If you make synchronous requests to a DB then your server will create a ton of threads which are all blocked; your server will handle just a few concurrent requests and memory consumption will be very high with thread stacks which your code is not using at all.

In the real world, there are many developers who will avoid high-level synchronous libraries in order to gain scalability. I know that MS does avoid synchronous DB access for Hotmail and many of its other highly-scalable services. However, it is true, that if your service has few concurrent users, then you do get a lot of benefit from various synchronous abstractions (like Linq to SQL). In an ideal world, these abstractions that offer such productivity will offer asynchronous ways of using them. Linq to SQL doesn't offer this today but it could in the future (or Linq to Entities could).

And, as for refactoring...Iterators do offer some challenges here, I agree. However, from an iterator, you can call compute-bound synchronous methods or methods that initiate an asynchronous compute-bound or I/O-bound operation that itself returns an IAsyncResult. And, also my AsyncEnumerator does support composition where an iterator can invoke another iterator. For example, you could create an iterator that asynchronously queries a web server to get some data and process it. And then, you can create another iterator that consumes the first in a loop to do asynchronous processing for several web sites. In fact, all of this processing can happen concurrently allowing for phenominal scaling. If your iterator methods get overwhelming, then you can resort to call back methods which is what all native applications have to do and what developers writing scalable managed application have to do today. Iterators give you a new ability; they don't take away any of the old abilities. This ability has very few drawbacks but if you come across one, then don't use it; go back to an older tried and true way.