March 10
The Scourge of Multi-Threading and its mitigation
Multi-threading was promoted by IBM in the days of OS/2 2.0 as a way to differentiate it from the far more successful Windows 3.11. OS/2 had it; Windows only got it with Windows 95. Multi-threading was promoted as a way to never let the user looking at an hourglass cursor again.
Never mind that:
- The programming effort required to successfully develop a stable multi-threading program was far from trivial;
- In most cases there were much more stable and easy ways to code alternatives that relied on co-operative multitasking. One of them was to call Windows message loop (PeekMessage API) inside your own loops. Another would have been to introduce something called “coroutines” at the language level (check Wikipedia if you want to know more about it).
I do believe Mankind would have been better served had we took the coroutine path back then. But IBM marketing folks decided it was not to be. In fact the whole industry fell in love with this multi-threading thing.
Hopefully, very few programs *really* needed multi-threading. Things like web browsers, web servers, database servers and application servers did need (and used) it. Your average “Joe programmer” didn’t need to bother – and the few who did bother are to this day trying to figure out what hit them. So the damage was limited.
Forward to 2008. We now have CPUs with two, four and more cores and counting. If they are in a server, the cores are already being heavily used by the highly multi-threaded server software. However, if they sit in a workstation, chances are that the multiple cores are not really being used much. The reason is that most of the time workstations do nothing but wait for user input. When they do run some heavy load, like printing a large report, chances are this program was not developed with multiple cores in mind and run no faster that they would have run in a single core CPU. In order to take advantage of the multiple cores, some clever multi-threading programming is in order. Much clever than the average Joe programmer is capable of, unfortunately.
In order to address this problem, Microsoft is coming up with some new clever “parallel extensions” for .NET Framework 4.0. Those extensions include several ways to extract parallelism from the average program with minimum additional complexity. They also include better debugger support, parallel LINQ query and much more.
Note that we are not talking about “multi-threading”, but “running parallel”. Although similar, the two things are not quite the same.
Tools 
Help
Loading...
