Announcement

Collapse
No announcement yet.

When to use threads

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • When to use threads

    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.
    Last edited by Gary Beene; 9 Apr 2009, 03:12 PM.

  • #2
    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.
    hellobasic

    Comment


    • #3
      Having a threaded print engine allows a user to use an application while a report is being printed.
      Bernard Ertl
      InterPlan Systems

      Comment


      • #4
        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.
        <b>George W. Bleck</b>
        <img src='http://www.blecktech.com/myemail.gif'>

        Comment


        • #5
          Originally posted by George Bleck View Post
          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).
          hellobasic

          Comment


          • #6
            Originally posted by Gary Beene View Post
            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!
            Last edited by Marco Pontello; 9 Apr 2009, 05:01 PM.
            -- The universe tends toward maximum irony. Don't push it.

            File Extension Seeker - Metasearch engine for file extensions / file types
            Online TrID file identifier | TrIDLib - Identify thousands of file formats

            Comment


            • #7
              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
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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.
                  Furcadia, an interesting online MMORPG in which you can create and program your own content.

                  Comment


                  • #10
                    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
                    Engineer's Motto: If it aint broke take it apart and fix it

                    "If at 1st you don't succeed... call it version 1.0"

                    "Half of Programming is coding"....."The other 90% is DEBUGGING"

                    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                    Comment


                    • #11
                      Originally posted by Michael Mattias View Post
                      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!
                      -- The universe tends toward maximum irony. Don't push it.

                      File Extension Seeker - Metasearch engine for file extensions / file types
                      Online TrID file identifier | TrIDLib - Identify thousands of file formats

                      Comment


                      • #12
                        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.
                        Warped by the rain, Driven by the snow...

                        jimatluv2rescue.com

                        Comment


                        • #13
                          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.
                          kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                          Comment


                          • #14
                            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?
                            "I haven't lost my mind... its backed up on tape... I think??" :D

                            Comment


                            • #15
                              Interesting reading re. Threads & Processes:

                              http://www.hanselman.com/blog/Micros...ewThreads.aspx

                              (Scott Hanselman is a Lead Program Manager at Microsoft)

                              Comment


                              • #16
                                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...
                                Jim Seekamp

                                Comment


                                • #17
                                  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).
                                  Michael Mattias
                                  Tal Systems Inc. (retired)
                                  Racine WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    Since about 1999 if you must know...
                                    Hey Michael you're in Racine??
                                    I'm in Beloit!
                                    Jim Seekamp

                                    Comment


                                    • #19
                                      Originally posted by Jim Seekamp View Post
                                      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.
                                      Jeff Blakeney

                                      Comment


                                      • #20
                                        >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
                                        Michael Mattias
                                        Tal Systems Inc. (retired)
                                        Racine WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X