Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29208

Re: thread pool

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On 2014-07-22 20:29:51 +0000, Eric Sosman said:

> 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.)

My solution seems to be similar, but if I run your startThreads again 
the  t.start();
throws the InterruptedException directly, so I do

main()
{
	Master x = new Master();

	x.startThreads(5);
	x.stopThreads();
	x.startThreads(5); <= this does not work because the exception is thrown
}

Phil

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-22 15:00 +0200
  Re: thread pool Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-22 09:11 -0400
    Re: thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-22 16:32 +0200
    Re: thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-22 21:38 +0200
      Re: thread pool Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-22 16:29 -0400
        Re: thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-22 23:01 +0200
          Re: thread pool Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-22 17:14 -0400
            Re: thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-23 08:11 +0200
              Re: thread pool Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 07:24 -0400
                Re: thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-23 15:57 +0200
                Re: thread pool Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-23 11:41 -0400
                Re: thread pool Philipp Kraus <philipp.kraus@flashpixx.de> - 2014-07-24 09:55 +0200
                Re: thread pool Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-07-24 08:39 -0400
  Re: thread pool Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-07-24 20:50 -0700

csiph-web