Threading

A thread is an independent stream of instructions in a program. All your C# programs up to this point have one entry point — the Main() method. Execution starts with the first statement in the Main() method and continues until that method returns.

This program structure is all very well for programs in which there is one identifiable sequence of tasks, but often a program actually needs to be doing more than one thing at the same time; for example, when you start up Internet Explorer and get increasingly frustrated with the time it takes a page to load. Eventually, you get so fed up (if you're like me, after about 2 seconds!) that you click the Back button or type in some other URL. For this to work, Internet Explorer must be doing at least three things:

• Grabbing the data for the page as it is returned from the Internet, along with any accompanying files

• Rendering the page

• Watching for any user input that might indicate the user wants Internet Explorer to do something else instead (for example, watching for button clicks)

The same situation applies to any case where a program is performing some task while at the same time displaying a dialog box that gives you the chance to cancel the task at any time.

Let's look at the Internet Explorer example in more detail. We will simplify the problem by ignoring the task of storing the data as it arrives from the Internet and assume that Internet Explorer is simply faced with two tasks:

• Displaying the page

• Watching for user input

Assume that this is a Web page that takes a long time to display; it might have some processor-intensive JavaScript in it, or it might contain a marquee element in it that needs to be updated continually. One way that you can approach this situation is to write a method that does a little bit of work in rendering the page. After a short time, say, a twentieth of a second, the method checks to see if there has been any user input. If so, the input is processed (which may mean canceling the rendering task). Otherwise, the method carries on rendering the page for another twentieth of the second.

This approach works, but it is going to be a very complicated method to implement. Also, it totally ignores the event-based architecture of Windows. Recall from the coverage of events earlier in the book that if any user input arrives, the system will want to notify the application by raising an event. To modify your method to allow Windows to use events, you would do the following:

• Write an event handler that responds to user input. The response may include setting some flag to indicate that rendering should stop.

• Write a method that handles the rendering. This method is designed to be executed whenever you are not doing anything else.

This solution is better, because it works with the Windows event architecture. However, look at what it has to do. For starters, it will have to time itself carefully. While this method is running, the computer cannot respond to any user input. That means this method will have to make a note of the time that it gets called, continue monitoring the time as it works, and return as soon as a fairly suitable period of time has elapsed (the absolute maximum to retain user responsiveness would be a bit less than a tenth of a second). Furthermore, before this method returns, it will need to store the exact state it was at when it was interrupted, so that the next time it is called it can carry on. It is certainly possible to write a method that would do that, and in the days of Windows 3.1, that's exactly what you would have had to do to handle this sort of situation. Luckily, NT 3.1 and then Windows 95 brought multithreaded processes, which provide a far more convenient solution to this type of problem.