<quote>It's usually better to keep the threads alive, if you just want to re-start them later. And in your case you have mentioned that it is for a game. And I guess that the game has a life cycle that is repeated. starting -> playing game. -> game over - > staring -> ...

That indicates that you should keep your threads alive.</quote>

In trying to create a Runnable class whose thread could be easily stopped and restarted without dying I ran into some trouble. I'm not sure if the concept is flawed or if my implemenation is bad. In any case, I'd appreciate any comments on:

1. The test code below.2. The idea of starting and stopping (but never killing) Threads in general. In particular, the object's state (ie, the values of its members which can be changed by the thread) seems to present a problem. When you create a new Thread on a new object, you get default values for all the members, which is what I want in my case. If you were manually starting and stopping the thread, you would have to create a special reset() method that your object's custom start() method could call. This seems messy. The run method in the test code below also seems messy. Are these design warts really compensated for by the overhead you save by never creating unnecessary threads?

I get about 2000 threads starts & stops per second ona Windows laptop. Test program below.

So unless you are starting hundreds of threads persecond, don't bother messing with thread pooling.You'd be optimizing something that already is fastenough.

Sjasja,It's a fact that threads are expensive. They all need to have a stack of their own, so they consume a lot of memory, and they need to be scheduled etc. If you tell a game developer that you are thinking about having a thread for each bullet in a game he will laugh his head off. It's just bad design. How many threads do you think doom 3 has? thousands? I bet not.

HotQuietDay give a short but complete example of what you want to do, and I will show you how to do it.

It's a fact that threads are expensive. They all needto have a stack of their own, so they consume a lot ofmemory, and they need to be scheduled etc. If you tella game developer that you are thinking about having athread for each bullet in a game he will laugh hishead off. It's just bad design.

I agree: a large number of threads can be problematic. On workstation/server -class systems a few dozen is ok, a few hundred starts getting problematic.

However, the OP wasn't discussing number of threads; the subject was whether threads should be kept alive (stopped & restarted).

Before trying to optimize thread starting & stopping: measure, measure, measure. Make back-of-the-envelope calculations: how many threads per second do you intend to start & stop. Then make a decision whether you need to optimize it.

I measure about half a millisecond here for start + run + stop + join (depends very much on OS, of course).

To wit:

It's usually better to keep the threads alive,if you just want to re-start them later

Not necessarily. It takes, say, 0.0005 seconds to start a thread (measure your environment if you are targeting e.g. a cell phone!) If you stop a thread, then re-start it a minute later, you are probably being quite silly to write the "suspend" code to save 0.0005 seconds once per minute. Spend your code optimizing effort elsewhere.

If you are stopping a thread for 0.001 seconds, then you could save a measurable percentage if you don't really stop it.

How many threads doyou think doom 3 has? thousands? I bet not.

How much do you think 1+1 is, 3? It's not, you are sooooo wrong. See, two people can play this game: make a silly claim about what the other person thinks, then prove he is wrong. Let's not do that, shall we?

I haven't said that it is slow to start a thread. Just that a thread allocates lots of resources, and that is something that the gc later on has to deal with. I still do think that the OP has some thing wrong in his design (read the original thread, named some thing like stack overflow)

I haven't said that it is slow to start a thread. Justthat a thread allocates lots of resources, and that issomething that the gc later on has to deal with.

Just like with the speed issue, "lots of resources" is a relative term. The same rule applies: make some rough calculations and some measurements before rushing off to optimize something. Allocation and GC isn't necessarily the terrible performance killer it used to be.

http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html

Nobody's saying that creating hundreds or thousands of threads will never be problematic, but your response to "first measure, then optimize" seems to be, "having lots of threads is always bad."

No, it's not always bad, but it's seldom needed. Many developers are using threads too much, and to things which you don't need them for. And I'm not a fan of; first write your program, and the optimize. The fastest executing code is the one which isn't there at all. Optimization when you are done won't help if you have a bad design. As a consultant I often profile systems written by others, and that has the drawback that you will find hotspots within the running code, but you will not find out that the system might have a design flaw. So I have to say if you want to build a robust, fast an reliable system you have to think during ALL phases of development. Speed isn't a thing you try to archieve when you are done building the system. It's too late.

By the way, it's a good article, and I don't say that you should avoid object allocations, but rather that you should think twice before you create threads. Do I need it? Can I keep the old thread running instead? In my opinion you shouldn't think the same way when it comes to objects and threads. A new thread isn't just a new object.

In my particular case, I will never have more than about 20-30 threads going at one time. My question was about wheather I should start and stop those 20-30 threads, or let them die and recreate them as needed. If the thread creation is under a millisecond, it seems to me the simplicity of design I'd gain by recreating threads is worth the extra half millisecond of effort. That is, I won't have to put those ugly if ... wait() statements in my run() methods, and I won't have to create reset() methods for the Runnable objects to get them back to a default state.

The case might be different if it were a matter of creating hundreds of threads.

Don't be to sure about that :)Why do you need 20-30 threads to run a game? It's very easy to create threads in java, but it's also very easy to create race conditions, deadlocks, etc. Even the people at sun agree to that, and that is why the concurrency package is added in Java 5.

When I have created small games (like pacman etc) I have only needed a couple of threads. One for updating the ui, one for playing sounds, and then you might need another one for reading the keyboard. That's about it.

And I'm not a fan of; first write your program, andthe optimize. The fastest executing code is the onewhich isn't there at all. Optimization when you aredone won't help if you have a bad design.

Optimizing before you know how much it will help has a very hight probability of not helping noticably at all.

I suspect we simply have a different view of what "optimizaion" means. To me, optimization means making a given section of code as fast as possible, even at the cost of clarity or clean design. It's quite true that optimization won't help if you have poor data structures and algorithms. Selecting quicksort over bubblesort is something I'd do as I write the code, but it's not what I'd call optimization.

In my particular case, I will never have more thanabout 20-30 threads going at one time. My questionwas about wheather I should start and stop those 20-30threads, or let them die and recreate them as needed.If the thread creation is under a millisecond, itseems to me the simplicity of design I'd gain byrecreating threads is worth the extra halfmillisecond of effort.

That's how I'd advise doing it. If your design calls for 20-30 live threads (and let's assume for now that that's a sound design), and if it's cleaner, easier, and "more natural" for run() to do it's thing and then complete than to implement some kind of queue or thread pool, then go with that.

However, I'd recommend two things: 1) make your design modular enough so that if you have to swap out that model for a thread pool type of model that you can do so without touching other code and 2) test the performance of that piece as early as possible. Quick & dirty proof of concepts and prototypes early on can sometimes save lots of rework later.

That is, I won't have to put

those ugly if ... wait() statements in my run()methods, and I won't have to create reset() methodsfor the Runnable objects to get them back to a default state.

The case might be different if it were a matter ofcreating hundreds of threads.

However, I'd recommend two things: 1) make your designmodular enough so that if you have to swap out thatmodel for a thread pool type of model that you can doso without touching other code and 2) test theperformance of that piece as early as possible. Quick& dirty proof of concepts and prototypes early on cansometimes save lots of rework later.

No, I wouldn't write it like that. That's why I asked what you wanted to do, so I could show you some code. I don't think I ever would stop the threads (will, I would when the game terminates).What you have tried to implement above looks more like a thread that serves runnables in a thread pool. And if that is what you want to do, then I would recommend to use the concurrency package by Doug Lea:http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html