Ok, I think im beginning to understand how threads work but could someone tell me if this is actualy using a thread? this is my class that holds the run() method: class ThreadApp implements Runnable { public void run() { for (int i=1;i<=100;i++) { count += i; System.out.println(count); } } } and this is my class that calls it: class UseThreadApp { int count = 10; public static void main(String args[]) { ThreadApp obj = new ThreadApp(); Thread thread = new Thread(obj); thread.start(); } } i guess ill go read more on what exactly a thread is meant to be used for because this dosnt seem anymore help than a simple for loop. GIMPS

That doesn't seem to be anything more special than a simple for loop, but what if you put some code inside Run() that did some real work, like copy a file from one PC to another, or read a record from a database and calculate someones pay for the week. Next, what if you have 1million pieces of work to do, for example you need to copy one million files from one pc to another. And it takes your program 1 second to copy the file. Since you can copy only one file at a time it will take 1million seconds. But if you use threads and start up 100 threads, where each thread can copy files, then it'll take roughly 10,000 (1million / 100) seconds (assuming the computer is powerful enough). Also, threads don't help much if your thread never does any kind of i/o or something that causes it to give up control of the cpu.

so what i did was using a thread, but it wasnt showing how they can be helpful. All i want to make was an example for me to go by from now on when i make a program that uses threads :) GIMPS

I wrote this program a while ago to see how many threads XP could handle. It seems to top out at 2032 for a single instance of a program. http://www.tommycoolman.com/misc/thread.html

When you are writing something useful/practical *always* paramaterize the maximum number of threads to use (e.g read max from a .properties or .xml file at system start). The *best* actual maximum needs to be discovered by experimentation: try 1 thread, try 10 threads, try 100 threads, ..... and observe what gives you best results. You will find that after the best maximum, adding more threads does *not* produce more efficient results, and indeed, can often cause a loss in throughput. What I usually do is graph the number of threads (x-axis) against "throuput" (I did N things per second) (y-axis). This will quickly pinpoint what your maximum should be. And yes, as Don indicated, threads are not usually very good for work that is processor bound. They are usually very good candidates for work that is I/O bound (local disk or network, makes no difference). Note the word 'usually' - there are always exceptions to the rule. Guy

Not to be negative, but there are two main performance penalties threading can hit you with. Both of these apply to programs that have moderate load. If you have no load, then up to around several thousand threads you probably will not notice too much (depends on the details though). Too many threads of course will always bite you. First, creating new threads (and destroying them) entails some overhead. When all you're doing is making threads (or when you're not making very many) there is no issue. But often times your program has real work to do. Thread with care. Second, switching between threads (context or task switching) is also not a free ride. The details depend on your setup. You have to know the thread model of your OS and your library to get a better grip on this. The problem usually has to do with hitting a memory cache to complete a switch. Within 18 months there should be multicore processors in reasonably priced desktop configurations. At that point, threading of processor bound routines will be much more useful (for just about any type of program).