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..slowand 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 🙂
Samples
(114KB)
Blog Post by: Mick Badran