This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Java in General and the fly likes If not listening to socket but might later, kill threads in pool, recreate? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "If not listening to socket but might later, kill threads in pool, recreate?" Watch "If not listening to socket but might later, kill threads in pool, recreate?" New topic
Author

If not listening to socket but might later, kill threads in pool, recreate?

Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
I have an app that has a pool of threads which wait to be passed a socket (from ServerSocket.accept()). The user can click a "do not disturb" button which will stop them from being notified of info coming in to the socket. Is it better performance-wise (or otherwise) when the don't disturb is selected to:

1. kill all threads in the pool (and now serversocket class won't even call sock.accept() )
2. When they turn it back on, recreate a pool of threads

or keep those threads running in the background but just don't send them anything?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'll assume a normal kind of thread pool thing where a number of threads are blocked waiting to get a task from a queue. I'd have to guess those blocked threads are using zero CPU cycles and whatever memory the Thread class plus your Runnable take up. I'd rather leave them waiting around than tear them down and build new ones later.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Guy Allard
Ranch Hand

Joined: Nov 24, 2000
Posts: 776
I think the answer depends on what the user is likely to do.

If "do not disturb" is usually reversed by the user in a short time (60 secs???) then keep the threads alive, otherwise kill.

Might try and keep some history, so you can possibly calculate an individual user's optimal wait-to-kill time.

Guy
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Not wanting to sound argumentative, but I'd want some proof that idle threads are a problem before I put any effort into making them go away and come back and track time and such. Thread pools come free with Java5, pick one, devote your time to the next feature the customer cares about. If the app has problems, profile it and find the real issues. If you're really worried about this one, hide it behind an API that will be stable even if you have to come back in and rewrite this bit.
[ October 05, 2006: Message edited by: Stan James ]
Dan Bizman
Ranch Hand

Joined: Feb 25, 2003
Posts: 387
Originally posted by Stan James:
I'll assume a normal kind of thread pool thing where a number of threads are blocked waiting to get a task from a queue. I'd have to guess those blocked threads are using zero CPU cycles and whatever memory the Thread class plus your Runnable take up. I'd rather leave them waiting around than tear them down and build new ones later.


That's sort of what I was thinking. I mean, there's something in me where I don't want to leave objects sitting around uncollected (feels like memory leaks perhaps ) but my understanding is that creating threads is VERY intensive and a thread can sit on wait() with very little in the way of resources.

I know that it's not guaranteed to do anything, but perhaps it'd be worth marking down the priority of each of those threads when "do not disturb" is chosen?

(And yes, they'll be waiting on a task)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'd guess the cost of a blocked thread is very near zero. Any time the thread manager in the JVM thinks it might be time to switch threads it looks through all the non-running ones to find one that is runnable. Your blocked threads aren't runnable, so the cost is just the check. Again, I wouldn't worry about those idle threads until I knew I had a problem.
 
Consider Paul's rocket mass heater.
 
subject: If not listening to socket but might later, kill threads in pool, recreate?