When to use threads

[Gary Beene]

In my 20+ years of programming, I've yet to write an app where I felt I "had" to use multiple threads. All of my work has been as a solo programmer, writing standalone apps - all GUI, minimal database interface, minimal network considerations, a lot of graphics with animation, and only a few places where calculation time was a big factor.

So, my question for forum folks is can you give an example (in general terms) of an app you wrote where using threads gave a clear advantage - or perhaps allowed an app to work where a non-threaded approach did not?

I've read enough that I can intellectually understand some of the benefits of threads, but what I've read hasn't compelled me to use them. It may be that my particular programming needs don't require threads, but I've read so many forum comments on threads that it seems like many? programmers use them - except me.

I've starting looking again at using threads and I'm having a hard time getting excited about it. So I thought I'd take a look at the practical reasons folks turn to threads.

[Edwin Knoppert]

Threads are often used to give the GUI a way to update and/or cancel the process.
Imo a poor choice since it is not needed.

Basically to determine if you need a thread, is when it is a possibility for the app to invoke more than one.
So in fact independing of GUI stuff but really ment to improve speed or decrease time.

[Bern Ertl]

Having a threaded print engine allows a user to use an application while a report is being printed.

[George Bleck]

A very good reason for threads is for splitting the GUI from the function.

In this way a CPU intensive function does not create the dreaded "Application is not responding". The GUI will always be responsive.

[Edwin Knoppert]

A very good reason for threads is for splitting the GUI from the function.

In this way a CPU intensive function does not create the dreaded "Application is not responding". The GUI will always be responsive.

Here we go, that is exactly what i meant (and not to do).

[Marco Pontello]

So, my question for forum folks is can you give an example (in general terms) of an app you wrote where using threads gave a clear advantage - or perhaps allowed an app to work where a non-threaded approach did not?

Since today many systems (and about 100% of power users / developers ones) around are in fact multi processors, any workload that's mostly CPU bound can probably get much better performance with an MT approach, and will scale even better "tomorrow". Some of the usual suspects: ray tracing, various kind of audio / video encoding, encryption, password crack... guessing , etc.

Bye!

[Michael Mattias]

The "one-tenth second rule" in a GUI program says you should use a separate thread of exection when an action you wisk to take in response to some notification will take more than one-tenth second.

[Michael Mattias]

around are in fact multi processors, any workload that's mostly CPU bound can probably get much better performance with an MT approach,

That's because multiple processors work on the basis of servicing individual threads of execution.

Applications which are I-O bound can benefit from multi-threading regardless of the number of processors: a CPU can do "other stuff" whilst waiting for I-O to complete.

MCM

[colin glenn]

Another application which is a candidate for threading is a chat program which handles both an inbound and an outbound connection to either a single server or multiple servers, you can run an inbound message thread separate from the outbound message thread, and if you are really slick, the display for those messages can be handled by yet another thread so the user doesn't notice the sporadic pauses while typing messages.

[Cliff Nichols]

MCM is partially right (as how often does anyone notice 1/10th of a second?)

And I/O is a perfect example (Colin brought up the best one I could think of with a chatroom sort of thing.)

In my train of thought Chatrooms and external devices are the same thing.
aka anything external to a computer (Network, attached device, Leave a message wait for a return message) should be in a thread.

That way your routine can continue and not get held up asking a question and wait for a reply (when the reply could be a week later), or the entity that would give a reply instead asks you a question. (if you are using all your time looking for questions, it slows things down....if you are not looking for a question, you do not see the question until you check if there was one asked)

In the terms of Serial port (or anything port) You are the computer, what is attached is the device. If you ask it responds...(You should answer the response, or handle otherwise)....but what if IT asks??? (Do you wait some time to check if it asked???)

Polling vs threading

[Marco Pontello]

Applications which are I-O bound can benefit from multi-threading regardless of the number of processors: a CPU can do "other stuff" whilst waiting for I-O to complete.

Do I say anything that exclude / contradict this? I/O latency is a classic reason for a MT solution.
What I pointed out is that today there are even more reasons to do so, given how common multi-CPU machine are. With a highly parallel(izable) problem like raytracing, the performance can scale linearly with the available CPU: span 4 threads and -BANG- you cut 75% of the time on a quad-CPU machine. Seems a pretty compelling reason!
Even a compressor like 7-Zip cut the packing time near in half with two thread on any cheap dual core CPU. Same for MP3 encoding, as another common example.

Bye!

[Jim Padgett]

Threaded Program

I wrote an app that queried 10 to 20 servers, collecting CPU utilization and disk space usage.
Since I was collecting Utilization data for 1 minute I used threads to collect this data.. that way I only had to wait 1 minute for all the server data to be collected instead of doing each server one at a time.

[Kev Peel]

Generally, I'd say use threads for anything that involves long calculations, disk access or other I/O. With a long process you can start 3-4 threads to cover each part of the process, on a multi-cpu system this can cut processing time considerably. Also if you have a large app which has background 'tasks' (example: scanning the customer database for a mailout), each task would be run in a separate thread.

[William Burns]

I have several programs that would not be feasible without multi-threads. My rule is when you have an application that needs to do the same task over and over, it makes for a good multi-thread app. Especially if part of the delay in the function is from external sources.

For example I have several network type scanners I use at my company that must ping each workstation before connecting to ensure they are turned on. Of course if the PC is not turned on or connected, the ping has to wait for the timeout period to expire. For small networks this might not be a problem doing them one at a time, but my company has a massive network with almost a million IP addresses. So my scanners launch up to 50 threads at the same time. Each thread pings a single IP address and if it responds, it gets in line to be processed (which I also throttle so that only so many process at the same time to not overload the network) This works great because as it processes 10 or so PCs, the other 30-40 threads can be finding the other active PCs to line up for processing. So this mutes the ping delay so that it does not slow anything down.

Make sense?

[Knuth Konrad]

Interesting reading re. Threads & Processes:

http://www.hanselman.com/blog/MicrosoftIE8AndGoogleChromeProcessesAreTheNewThreads.aspx

(Scott Hanselman is a Lead Program Manager at Microsoft)

[Jim Seekamp]

Just thought I'd chime in on this topic...
I've been using separate threads for progress bar windows for years now, and they work great!
It allows you to create a progress dialog in a separate thread and update it from the current thread. When the work is complete, you just close the progress window and the thread!
Also works for the "One Moment Please" type of messages...

[Michael Mattias]

I've been using separate threads for progress bar windows for years now, and they work great

How many years?

Progress Bar Dialog for PB/CC programs October 24, 2002
(Ignore the "PB/CC" in the thread title. This will work in a GUI program exactly the same way).

[Jim Seekamp]

Since about 1999 if you must know...
Hey Michael you're in Racine??
I'm in Beloit!

[Jeff Blakeney]

Just thought I'd chime in on this topic...
I've been using separate threads for progress bar windows for years now, and they work great!
It allows you to create a progress dialog in a separate thread and update it from the current thread. When the work is complete, you just close the progress window and the thread!
Also works for the "One Moment Please" type of messages...

I also started using threads for progress bars. I wrote an include file for a progress dialog box about seven years ago while working with for my brother. It allowed you to set the progress dialog caption, and choose from 1 to 9 (I think) pairs of labels and progress bars and you used functions to send updates to the label or progress bar. The label was above the progress bar and subsequent pairs stacked below the first pair.

I think there were a couple things that didn't work quite right but it has been handy to use. Now that I finally bought my own copy of PB, I'll have to update it.

[Michael Mattias]

>I'm in Beloit!

No, you're not. At least not according to your profile. (HINT HINT!!!)

There's someone else here from Kenosha, so I guess Wisconsin's First Congressional District is adequately represented here.


MCM