Async IO- don’t do naive async!

This post comes from a response here: http://stackoverflow.com/questions/882686/asynchronous-file-copy-move-in-c .  The second-highest rated response includes absolutely terrible advice.  It says, just put the file IO on a background thread.  It shows a complete lack of understanding of how IO works.

When your do IO (reading/writing from/to HDD or network), the software thread goes to the hardware, and says, ‘hey, can you write this info somewhere’ or ‘hey, I need this info, can you get it for me.’  The hardware then takes that request and does something with it, and when it is done it tells the software thread (let’s assume there’s no caching or lazy behavior going on).  This entire time, the software thread is just waiting while the hardware does the work.

What you really want to do is have the software thread run to the hardware and say, ‘hey, can you do this for me, I’ll be back later,’ then run back to the software threadpool (where all the inactive software threads hang out).  And then it should be dispatched to do something else (like run another request down to the hardware, or some processing).  When the hardware is done, the software threads will pick it up and report it as finished- the software threads are never waiting around for hardware to do stuff.

Unfortunately async IO in .NET is cumbersome, so it is often not worth doing truly async IO.  So it still makes sense to do IO on background threads, but it is just inefficient and NOT best practice- hence this post.  Just keep in mind this is a vastly simplified version of what actually goes on, but it is important to understand it at least on some basic level so you can design efficient and fast systems.