Re: thread pool
On 7/22/2014 3:38 PM, Philipp Kraus wrote:
On 2014-07-22 13:11:14 +0000, Eric Sosman said:
On 7/22/2014 9:00 AM, Philipp Kraus wrote:
Hello,
I would like to create a thread pool with threads, which are should
stopped by the user.
So I create my pool with
m_pool = Executors.newCachedThreadPool();
for (int i = 0; i < m_barrier.getParties(); i++)
m_pool.submit(new Worker(m_barrier));
my Worker implements Runnable with the run-method
while (!Thread.currentThread().isInterrupted()) {
// do something
}
Within the while-loop I run my barrier and I catch the
InterruptedException
I would like to create a thread pool with a number of threads, which
runs until the user
sends a stop signal. At the moment I run m_pool.shutdown() and/or
shutdownNow(), but
which way is the correct Java structure. My target is, that a method
creates all threads
of the pool, each thread runs unlimited time until the user sends a stop
signal.
If "each thread runs unlimited time," why use a thread pool? The
purpose of this kind of pool is to run many short-lived (usually) tasks
on a set of threads, with each thread handling many tasks in succession.
You don't need that (it seems), so wouldn't it be simpler to launch
as many threads as you want and just let them run? When it's time to
stop you can interrupt them all (telling them to quit) and join them
all (so you'll know when all the quitting's finished).
If that doesn't seem to meet your need, please describe what you're
trying to do in more detail.
This works very fast :-) but I have got a problem with the thread
interrupt.
I create a thread pool with:
m_threadcounter = new CountDownLatch(m_barrier.getParties());
for (int i = 0; i < m_barrier.getParties(); i++)
new CWorker(m_runners, m_threadcounter, m_barrier, i == 0, m_world,
m_currentstep).start();
and stop the pool with:
try {
m_runners.interrupt();
m_threadcounter.await();
} catch (InterruptedException l_exception) {
m_Logger.error(l_exception.getMessage());
}
m_runners is a ThreadGroup;
The thread run shows:
while (!Thread.currentThread().isInterrupted()) {
// do something
try {
Thread.sleep(CConfiguration.getInstance().get().ThreadSleepTime);
} catch (InterruptedException l_exception) {
Thread.currentThread().interrupt();
}
}
m_counter.countDown();
This works fine on the first run. After I run the stop part once and run
the creation part again
all new threads a stopped, because the interrupt flag is set, so my new
thread dows not run the while
loop within the run.
So I would like to create a a thread group, run it, stop it and create a
group again. I cannot set the thread to
sleep, because the data which is used by the threads must be
reinitialize if the group is created
The normal pattern is for the interrupted Thread to terminate,
either by returning from its run() method (or its Runnable's run()
method) or by throwing an uncaught Exception (InterruptedException,
for example). The control thread can call join() on the terminating
workers to learn when they've all stopped. Then to start anew you'd
create a new batch of worker Threads, and all of them would go through
whatever initialization you like.
Here's one way to arrange things (there are many others), just
typed in without testing:
class Worker implements Runnable {
...
public void run() {
try {
for(;;) {
// do something
Thread.sleep(interval);
}
} catch (InterruptedException ex) {
// Stop running, but otherwise ignore
}
}
...
}
class Master {
...
private List<Thread> threads = new ArrayList<>();
...
void startThreads(int howMany) {
while (--howMany >= 0) {
Thread t = new Thread(new Worker());
t.start();
threads.add(t);
}
}
...
void stopThreads() {
// Tell all the workers to stop:
for (Thread t : threads) {
t.interrupt();
}
// Wait until they have all done so:
for (Thread t : threads) {
try {
t.join();
} catch (InterruptedException ex) {
// The *Master* has been interrupted -- this may
// be reason to panic, log a failure message,
// and shut down the whole application
}
}
threads.clear(); // All the old Threads are gone.
}
...
}
I've never used ThreadGroup, so I can't offer advice on it. (Java
may be using ThreadGroup behind the scenes when I operate on Threads and
Executors and so on, but I've never had a reason to use ThreadGroup
directly.)
--
esosman@comcast-dot-net.invalid