Hi folks, I thought I’d share something that captivated me on this rainy Easter day and that was
Visual Studio Asynchronous Programming - http://msdn.microsoft.com/en-au/vstudio/async
(you’ll need VS2010 + SP1 before you grab the CTP)
There’s a new improved compiler + an extended library for us.
Hands up who’s done async programming in either VB.NET or C#??? It’s a pain! Thread management, Main UI threads can only update certain objects, passing values between main + background threads, determining whether a thread has completed its tasks… and so on…
Basically all these ‘issues’ keep us from delving further into the world of asynchronous programming cause it very rapidly becomes complex just managing the two worlds – sync + async.
Today I was pleasantly surprised!!!
About a year ago I saw a great presentation on F# and I was amazed at how if they wanted to run a bit of code async it was simple an extra character as in:
set results = ….. <-sync
set results! = …. <- run this async
(don’t quote me on the above, but it’s something like that – let’s call it pseudo code)
Why are we interested in this? – that’s always the first question to ask when investigating. Too many times we here ‘this is really cool’ and ‘check this cool software out’ etc… but the real reason of WHY do we want to go down this road is never answered.
On a ‘developers machine’ looking at 5 items, running a single test client – you’d have to say “works on my machine” and you’d have no need to async anything. True. Let’s move beyond our beloved developer box and think about UAT/PROD environments and what your code is doing.
What happens if 4 concurrent requests come along – how is your code going to perform? (As developers we’d be thinking …’it’s in the hands of IIS, not my issue’ :) )
(I recently was presented with a solution that ran across 20 odd servers, the answer to everything was get more hardware to make the app more performant, scalable etc – couldnt be the code.)
So as the requests start to build (don’t know an exact number but let’s say 100/sec), what is happening to your code? how often do we sit down with profiling tools on our code in this space? must be the disks..slow…and as always we have definitive proof works on my machine says the developer!
It’s not until we see our code running under load that we get an appreciation for where things could be improved and are causing grief for not only IIS but other systems as well.
Scalability, performance and scalability – single threaded app/service vs multi-threaded. Multi-threaded tend to win all the time.
Let me give you a couple of suggestions where this stuff is great:
- As part of a WF/WCF/Class where you want to ‘push’ some processing into the background – critical things can be done upfront, and you can push some of the ‘other stuff’ into the background.
- Take advantage of some of the great multi-core/multi-cpu Servers out there – single threaded tend to run on the same core on the same CPU (known as thread affinity)
Anyway enough jabbering from me and let’s see some of the hidden gems…
Async Programming Framework
Let me show you a couple of examples (from my set):
1. Fetching a webpage
Here I go off to twitter and search for all the BizTalk items.
Couple of things to notice
- …Async is added to the end of routines for convention, indicating that these are Async callable routines.
- not a single IAsyncResult to be seen, no StateObject and no Callback routines!
– line 104 the async keyword indicating that this routine itself can be called async if desired (more for the compiler)
- line 108 the await keyword is used in the Async framework to ‘wait for the async task to complete’ then move onto the next line.
- line 108 WebRequest.Create(…).GetResponseAsync – it’s the GetResponseAsync that is the async method, no …Begin or ..OnEnd calls! Just write it as you read it.
- line 109 We get a reference to the response stream (I should check for the existence of data etc – demo code, demo code :))
- line 112 …await stm.ReadAsync(…) – reads the response stream into a buffer on a background thread and we wait there until this completes (await keyword). By all means there’s many other ways to program this, as in we don’t need to wait, we could run this guy in the background quite happy and then check on him periodically.
That’s it! Not too tough at all, multi-threaded goodness right there. You can have blocking and non-blocking calls etc.
2. What about a Chunk of CPU based code
NO Async Example – as per normal, doing some cpu things.
Written in Async….
Points to notice:
- line 63 async Task<int[]> … to the Async framework the async methods are wrapped within a Task class. We must ‘wrap’ anything we return from our routines within a Task<..> – here I’m returning an int[]
-line 66 … = TaskEx.Run(…something to run in a background thread…). As we’re dealing with a block of code, there’s a Task Extension class that allows us to run that bit of code Async.
-line 79 await matrix – this line ensures that our async routine has indeed completed (or errored) before we move onto the next line.
Too easy if you’ve lived in the other world.
As always remember this is CTP so I wouldn’t go rolling out into Prod just yet. The perf numbers I get are pretty much identical to rolling all of this by hand with ThreadPool.QueueWorkItem(…) and IAsyncResult etc.
Well done MS!
Enjoy and here’s my VS.NET Sample Solutions – I had great fun! Oh – this is also applicable to Silverlight + WP7 apps :)