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

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

Re: thread pool

Show all headers | View raw

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

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