To multithread, or not to multithread

Bear and Electron - To multithread, or not to multithread

	Friend Bear, I am not a believer in the benefits of multithreading for the larger body of developers. I understand that you can do great things with multithreading, but for many it offers much opportunity to get into trouble with little benefit in return.
	Friend Electron, your fears can cost you greatly. I appreciate that you do not wish to expose your developers to the arcane knowledge at the core of multithreading, however there are a wide variety of areas where multithreading is an important feature that provides benefits your users now take for granted. Multithreading is no longer part of a specialists bag of tricks, its a mainstream design pattern now.
	Bear, many of the applications I am concerned with are fairly simple. The user does something, we go get some information from a web service and show it to the user, and so on....
	Uh huh. And when it takes a while for the web service to return ? Is the program sitting there locked up ? No feedback, no information, just an inert lump of pixels on the screen ?
	So what! Of course we'd do something with worker threads if this was a big UI, but for a lot of apps, it just isn't that important. Especially when you consider the problems multithreading can introduce.
	Hmmm. So you do agree that the larger body of developers is exposed to multithreading when you need to ensure the user has a responsive UI ?
	Sure, but we get a lot of that for free. If we're creating a web based application, the browser doesn't die just because the server is busy!
	Except when the page request takes a very long time.....
	Oh come on! That's just bad design.
	Possibly. However, you must admit we're talking about fairly common issues that your app might have to address.
	Certainly, but these cases are well known - and the documentation is filled with information on creating worker threads to work with UI processes. Furthermore, all of the big risks in multithreading, the need to syncronize threads, are not so common here.
	Electron, I'd have to differ with that. In .Net 1.1, the risks were there but you got away with ignoring them. Of course your app sometimes locked up for no apparent reason, but you could ignore the issue and risk the consequences. Now 2.0 is stricter, you have to specifically configure your app to indicate you are willing to risk the consequences, the normal behavior is now to terminate your app for bad behavior.
	Really ?
	Really. Ever have an app with a worker thread that updated a progress bar ? One that sometimes, maybe a rare sometimes, but sometimes nonetheless, behaved badly ?
	Uhh, maybe
	If so, it was an issue concerning cross thread access to UI controls, and is now dealt with more strictly in .Net 2.0. Perhaps we can take a break while you read the article How to: Make Thread-Safe Calls to Windows Forms Controls and see what I'm talking about.
	..... some time passes
	Bear, I have finished the article. I must admit that was all news to me, and I've got everyone else in my group reading it now. Even so, this only applies to a couple of major Winforms applications of ours, not to most of the day to day small applications and web forms we do.
	True enough, friend Electron. On the other hand, you're now saying that some of your developers actually deal with deep multithreading issues.
	Some. The better ones. Look Bear, I'm still unconvinced, I don't see why I need to consider multithreading as a central strategy to be used in a wide number of applications.
	Electron, this is certainly an area that requires careful analysis, and we're not going to come to an understanding in a single session. On the other hand, you've agreed that in certain cases where responsiveness is important, multithreading provides some benefit.
	Yes, I have - but that's only about 20% of the problems I confront.
	You're saying 80% of your stakeholders don't care about performance and responsiveness ?
	Of course they do, you honey eating fool! But multithreading is an implementation detail. I address performance where it should be addressed, in the design and architecture of the system. Multithreading can't fix a bad design, and a good design often doesn't need it.
	And when your app is successful, and becomes more and more widely used ?
	Which app ? Be specific Bear!
	Any application. Say you have three products, a web site, a web service, and a winforms application. Say you've done your usual bang up job, the users love them. In fact so many users love them, they're loving them to death.
	I go buy more hardware.
	What was that ?
	More hardware
	Excuse me ?
	MORE! HARDWARE! BEAR!!!!
	And what about the Winforms app ? How does more hardware help it ?
	A new CPU, or more disk, or memory, or whatever it needs.
	And if it just needs the CPU to do more stuff in less time ?
	OK, so a new CPU. I already said that.
	Noticed anything about CPUs over the past few years ?
	Well, there's all the dual core stuff they're talking about.....
	Not going to do you a lot of good if you're not multithreaded.....
	Sure, but the OS can use it, and at least I've got the app running on a new processor.
	Which as time passes is likely to be running at exactly the same speed as the old processor.
	??????????????????????????????????????????????? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! What about Moore's famous law ?????
	It only addresses increase in transistor count, not in operating speed of the transistors. There are 'issues' involved in the creation and use of modern processors that mean they're just not going to be steadily getting faster. That's why the chip companies are now putting multiple cores in the processor, they can't make them more powerful by making them run faster anymore.
	Wow! Now that you mention it, I had noticed they didn't seem to be getting any faster. But Bear, I never believed those stupid megahertz and gigahertz numbers anyway.
	Friend Electron, as I recall, you were deleriously happy when you traded in that 800Mhz Pentium II for the 2 point something Ghz machine. That difference seemed pretty clear to us all.
	OK, Bear. So what you're saying is that these days, four point something GHz is going to be around for a while, and there aren't going to be some snazzy new 8GHz machines coming ?
	Thats right. So I ask you, your stakeholders just went out and spent big dollars on new computers. And your app didn't receive any direct benefit from it. The users might notice a slight speed increase, but nothing major.
	And I suppose you're going to tell me multithreading is the answer to this.
	Yes I am. I do understand your concerns, Electron, and I agree with them. I run many projects myself, and I certainly don't need to find them wildly off schedule because of some arcane threading problem. On the other hand, circumstances are forcing me to rely more and more on multithreading to address a wide range of performance concerns.
	OK, Bear, it's certainly food for thought. I'm not totally convinced, but I can see how I'm getting squeezed on both sides. Under the covers, yes, there are obvious cases where multithreading can help me. And if my stakeholders are buying shiny new machines and not seeing any benefit from them, this could become a problem. We should discuss this further
	Yes, we should. And in the interim, here's a couple of very interesting things to read. The first, from Herb Sutter is entitled 'The Free Lunch is Over' and provides a good overview. And then there's this, which defines the heart of the evolving multicore processor strategy.
	OK,Bear, let me read these. Then we can discuss this further.
	Sounds good to me Electron. For now, I'm off to find a honey tree.
	Try not to get stung quite so badly this time.
	The risk is worth the reward, friend Electron
	fin