Follow @PDSAInc To Thread or not to Thread, Is That the Question? - Paul Sheriff's Blog for the Real World

Paul Sheriff's Blog for the Real World

This blog is to share my tips and tricks garnered over 25+ years in the IT industry

Paul's Favorites

To Thread or not to Thread, Is That the Question?

A lot of developers want to use threads to offload some processing. There are many different ways to use threads. More often than not it is not a question of how to do threading, but whether or not you should. If you are trying to solve performance problems with your application, you might not want to employ the use of threading, at least not until you have exhausted all other methods of enhancing performance.

Adding more threads to your application can sometimes slow the application down more. You need to be very careful on how you utilize threading. You also need to be careful on what you do on those other threads of execution. If you are performing some method that sucks up a lot of processing on your CPU, then you could be robbing performance from your main thread of execution. This will not help your performance problems, but make them worse.

An Example: Database Operations

I have performed many performance reviews on code where programmers loop over 1000's of records. When this took too long, they tried putting this loop on a second thread. Of course, the better approach should have been to move this into a stored procedure, and use set-oriented operations instead of looping. Then if this process still took too long, use asynchronous processing that is built into ADO.NET instead of writing your own threading. I am always of the mind that Microsoft has much smarter people than myself and that they will do the background threading much more efficiently than I could write it.

Use the BackgroundWorker Class

If you really must have another thread do some work, you might want to check into the BackgroundWorker class. This class allows you to perform a long-running operation on a separate, dedicated thread. Again, since I am using a class that the smart folks at Microsoft have created, I figure they have put more thought into it and more testing than I have time to do. So, I will frequently use this class as opposed to creating my own thread. It also has a reporting mechanism built in, so I can report on the progress of my operation without having to create and raise my own events.

Example of the BackgroundWorker Class

I have created a sample WPF application that shows the updating of a progress bar in WPF. The BackgroundWorker class can raise a Progress event so you can do some UI work. Be careful to not do any UI updates from within the DoWork procedure.

To try out this sample, you can download it from our website at www.pdsa.com/downloads. Click on Tips and Tricks and download the "BackgroundWorker Class Sample".

So, the next time you are tempted to use a thread, really think about the problem you are trying to solve. You might want to have someone else look over your code prior to doing some complicated threading. Sometimes, someone else will see a better way to do something that just might give you the performance you want without resorting to multiple threads.

Thank you,
PDSA, Inc.
http://www.pdsa.com/

** SPECIAL OFFER FOR My Blog READERS **
Visit http://www.pdsa.com/Event/Blog for a free eBook on "Fundamentals of N-Tier" by Paul D. Sheriff

Posted: Aug 17 2009, 10:27 AM by psheriff | with 1 comment(s)
Filed under: ,

Comments

No Comments