Regarding threads

[nishant vats]

This is regarding threads.I am nt able to understand how threads can be helpful on single processor with respect to execution time.Because if we drill down to processor level(Single processor) then only one task can be executed at particular point.I am nt able to get how threads can reduce the execution time .i have searched a lot but unable to get satisfactory answer.

Can anyone explain with the help of web Server or download accelator.they are best examples of multithreading

[M Beck]

with regard to execution time, in theory, threads will not help you on a single processor. in fact, they will hurt you; they will introduce a mandatory task switching overhead - the thread scheduler will waste more of your cycles juggling your threads.

but very few programmers need to worry about CPU time that much any longer; processors have grown fast. that small overhead should be of no real consequence in the vast majority of cases. what threads might do for you is simplify your code. if each one of your threads does a single, simple, easy to understand thing, then you won't have to burden your logic with switching back and forth between your tasks to keep them all serviced - the thread scheduler will do that for you. as a result, your code should be more maintainable.

should be, in theory, that is. for myself, i am not yet convinced that this will necessarily be the case with threads, or that threads have that much advantage over standard, "heavyweight" processes. however, threads are the model the designers of Java chose to go with, and it's still one of the most powerful tools in the Java language. so long as we're using Java, not learning threads would be silly.

[Joe Ess]

Originally posted by nish vats:
I am nt able to get how threads can reduce the execution time

Threads do not reduce execution time. As a matter of fact, because of the extra housekeeping the CPU has to do to track multiple threads, they may INCREASE the load on a CPU. They do, however, make it possible to do several things simultaneously. Think of when when you are downloading a file. One thread may be moving the file data while another updates the GUI with a progress bar. In any Java program you always have the garbage collection thread running and in any GUI Java program, there's also the event thread.
If you have a single CPU, as most of us do, multiple threads will not run simultaneously. They share the CPU's processing time, each thread getting a tiny slice of time in turn with all the other threads. This is called multitasking, and the link explains that can of worms better than I.

[Ernest Friedman-Hill]

Threads can indeed simplify many kinds of code, as M. Beck has stated. Regarding whether Threads or Processes are better, I can't see how you can ask that question: threads can communicatye vastly more easily than processes, and of course the context-switching for processes is, by definition, vastly greater than for threads.

But besides these examples, it's actually quite possible for threads to speed up a program on a single processor. That's because most programs aren't actually CPU bound; in fact, most software leaves your CPU idle most of the time. What limits most programs is I/O bandwidth. Many programs spend most of their time waiting for I/O to complete.

A single-threaded program has to block while waiting. A multi-threaded program can do other work while the I/O thread is blocked. This makes a multithreaded GUI program, for example, able to respond to user actions even while disk I/O is going on.

Note, actually, that Java nowadays has asynchronous I/O in the java.nio package, which lets you do some of these things in other ways -- but they're more complicated ways, to be sure.

[M Beck]

threads can indeed communicate more easily than processes, but they can also step on each others' toes more easily. the synchronization and locking problems with threads are hairier than with processes, and the dangers of threads messing with each others' address spaces remind me of the bad old days before memory protection. moreover, while processes do indeed switch contexts more slowly than threads, i'm not so sure that the difference is all that vast on a modern operating system; there's been much progress by the *BSD and Linux kernel gurus in reducing context switch overhead.

what i'm unconvinced of, in short, is that the benefits of threads outweigh their backdraws, and that their benefits over processes are as large as they've been made out to be. but this is a subject on which people can reasonably disagree.

what i do not disagree with, at all, is that threads can help I/O-bound programs (which is most programs) harness CPU better while blocked on I/O. non-threaded programs can do this too, of course -- asynchronous I/O is a fascinating subject that i like to study -- but that usually comes at a cost (sometimes large, sometimes small) in complexity and readability. threads can make programs that accomplish the same thing be easier to understand, and that is an advantage for them which i won't deny.
[ April 21, 2005: Message edited by: M Beck ]

[Stan James]

I have a little program at home that downloads files. I can run four or five threads and each gets the same throughput as one by itself. So this program is definitely running 4-5 times as fast as it would on a single thread. Judging from the network throughput I'm saturating CPU before I saturate my network connection, so a faster CPU would run even more threads. This pays off because network speed is glacial compared to the CPU and even writing to disk.

Another benefit of threads is you can run a long task in background and keep the UI responsive to mouse and keyboard gestures. (I recall a trick in Turbo Pascal to do the same thing without threads ... any keyboard event interrupted a loop in the background process.)

Sometimes by presenting data progressively you can make a program seem much faster even if the total wall time is the same or a little longer. We have managed to satisfy users performance needs by presenting the first bit of data sooner.

There is an interesting pipeline alternative to threads. If you have 100 user requests, run the first step for all 100, queue up the next step. Run the next step 100 times and queue up the next step, and so on. Running a small chunk of code many times reduces paging and instruction fetching and increases the value of optimization by the CPU - optimize once, run many.