Concurrency – and why are we still standing?

For the last three years, developers have been warned about the end of the free lunch. CPU makers no longer support ever-laxing performance standards by introducing a new GHz value every year, instead focusing on several cores. That in turn forces developers to learn multi-threaded programming.

If you’re new to all this, read yourself up on Dr. Dobb’s Journal and then get back here.

Now, I agree things have changed. If you used to push the CPU to the 100% max with a sloppy algorithm, it’s not getting better anymore. If your UI lags because of that, you would be best off by fixing the algorithm and then spreading your job across threads – and good luck with that.

But given the fact that concurrency is innately and undeniably hard, why hasn’t the world come to an end yet? It should have, if all the programmers had started writing multithreaded programs in 2005. They didn’t, for a simple reason: Most things are done on the web.

And that resolves a bunch of problems: A single page runs usually on a single thread or process, a single database request is served by a thread and so on. Suddenly you realize the parallelism was implemented by somebody else – responding to the web requests often works well without threading complexities, and the rendering part is smoothly distributed on all those clients. Wow!

Oh, but you weren’t a web developer? My apologies, because sooner or later, you’re bound to encounter all this. Get yourself a copy of Concurrent Programming on Windows and start preparing. The happy part is that there are lots of tools coming your way. Here are some Microsoft-focused links for starters:

Task Parallel Library, tools for delivering multi-threaded execution in .NET 4.0. What’s up in three parts: 1 2 3.
PLINQ, the ability to spread out some LINQ queries onto multiple cores.
Visual Studio 2010’s improved support for multi-threaded debugging
If you’re not afraid of Research projects, Axum is a toolset for building safe multithreading on the .NET platform.
And finally, for concurrency testing, try Microsoft’s CHESS, a timing bug test driver (also a research project)

And finally, if you end up wading waist-deep in the threadpool, remember: This is not the time to take shortcuts. Finally, you have a good chance to take some CS studies or just refresh your memory.

October 5, 2009 · Jouni Heikniemi · One Comment
Tags: concurrency · Posted in: .NET