Examples of poor performance that could be fixed by multithreading

This is a rather broad question, but I'm a beginner-intermediate programmer that has just completed an applications class and one of the topics was multithreading. We did various homework assignments that involved making GUIs with buttons that would start some long drawn out process (reading from a database, etc).

In these cases, we would create both single and multithreaded versions where the task of performing the processing was on a separate thread from everything else so that when the button was pressed the application did not stall.

To my question:

At work today, I did a search in my MS O开发者_如何学Pythonutlook for one specific word hoping to find a specific e-mail; unfortunately the word was a common one and a hundred million e-mails appeared. There is a stop button, but pressing it did absolutely nothing...

From my class experience, is this not an example of where putting the search process on its own thread would not cause the problem above? Surely Microsoft wouldn't do something silly like that... is there a reason this would not be made its own thread? If it IS its own thread, then why would the application stall and not respond to hitting the stop button? (OS-related reasons?).

All of this was on a Windows XP 32-bit dual core system, if thats relevant.

Really, I just want to better understand where multithreading comes into play and how to learn where to apply it. Are there any examples of well-known applications that clearly benefit or suffer from multithreading? Is it really possible to clearly even distinguish?

Thanks!

R

It is quite possible that the searching was, indeed, in another thread, but that passing the results to the main thread and drawing them was actually bogging down the main thread enough that it didn't have time to respond to your requests.

The only fix i know of for an issue like this is to limit the number of results that the search process can return. If you don't want to limit the number of results, draw the messages pane in a different thread. However, this is very difficult, as most gui toolkits are single-threaded. Furthermore, even so, the thread could (in extreme cases) take up so much memory that it slowed down the main gui even so.

Whenever you see a splash screen for an app, that's a big indicator something is happening on a separate thread.

This is more for an aesthetic use, but it helps the user understand the machine is not stuck while processes load in the background.