Wednesday, May 4

Single-threaded developers in a parallel world

I screened a candidate yesterday with a background in web dev. ASP.NET, MVC, basic webservicess experience. When I asked him if he had ever used .NET's new Parallel object, or any of the more conventional multithreading facilities, his reply was, "No, I've never done multithreading, I've only done web development."

Once upon a time, I thought multithreading was pointless in webdev myself ... but that had to be 6-7+ years ago now at the least. I came up in the software world through "basic web design" back in '95-'96, n-tier web & database work starting in '98, then started adding getting into service-heavy stuff some five years ago now. This gentleman got his start some 16 years ago writing assembly, and at some point working in the embedded world. If anything, I'd think his perspective on efficient utilization of CPU resources would be even sharper than mine.

Any kind of iterative/enumerative operation can benefit from multithreading. Any kind of process that does not require synchronicity from the client/viewer/browser side of things can be done in an asynchronous fashion on a throwaway thread, giving the end user a perception of greater performance/responsiveness.

I found it a bit shocking that in 2011, someone with over a decade and a half of experience in the software world could, or would, be so dismissive of multithreading, even if doing "only" web development type work.

In .NET, it's so easy! The Asynchronous Programming Model has been around since .NET 1.1 and the async delegate and BeginInvoke/EndInvoke methods. The BackgroundWorker dispatch model has been available since .NET 2.0. Now in .NET 4.0 we have the Task Parallel Library (TPL) which allows simple-to-write inline asynchronous task execution and similarly easy parallel for/foreach operations against enumerables, as well as PLINQ which gives us parallel execution of LINQ queries.