• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

ThreadPoolExecutor restart

 
Ranch Hand
Posts: 193
Mac OS X Fedora Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Suppose I added (submitted) some tasks (threads) into the ThreadPoolExecutor to be running. At some stage, I must ensure that the main thread to be blocked and all the threads in the ThreadPoolExecutor to be completed before releasing the lock on the main thread.

I spotted that I can use the combination of the following two methods on ThreadPoolExecutor:

shutdown();
awaitTermination();

That's great. Since after these two methods, the main thread can ensure all the threads in the pool have completed.

However, after the shutdown(), there is no way that you can add another task into the pool. (The pool is considered to be closed and shutdown). Where is the restart() method on the pool, I wonder.

The only workaround I found is to create a new instance of the ThreadPoolExecutor like the code below.

if (exec.isShutdown())
{
exec = (ThreadPoolExecutor)Executors.newCachedThreadPool();
}

Can anybody advise if this is a good practice to use ThreadPoolExecutor? It seems that everytime I perform a shutdown and awaitTermination, I need to create a new instance of ThreadPoolExecutor. I smells bad code.

Thanks
 
Ranch Hand
Posts: 56
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jiafan,

maybe the check



is a better choice.

Cheers,
Ramon
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For your use case, I think it would be better to use invokeAll(), which will block until all tasks in the Collection you pass in have been completed or cancelled. That way you don't have to keep creating a whole new ThreadPoolExecutor for each set of tasks you need to wait for.
 
Jiafan Zhou
Ranch Hand
Posts: 193
Mac OS X Fedora Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:For your use case, I think it would be better to use invokeAll(), which will block until all tasks in the Collection you pass in have been completed or cancelled. That way you don't have to keep creating a whole new ThreadPoolExecutor for each set of tasks you need to wait for.



Thanks for your reply. However, invokeAll() does not suit my case. As soon as a task is added (submitted) into the TPE, I hope to start it immediately. I do not wait for another tasks to be added before starting these threads.

Now I think I have another solution to wait for all the running threads in the TPE, *without* shutting down the TPE and re-instantiate another instance of TPE.

Every time I add a new task into the TPE, I maintain a hashmap like below:


And if I want to wait for all the running threads to complete, I simply need to invoke the get() method on all the Future object like below:


The nature of the get() method waits for the thread to complete and get the result if necessary. (In my case, I don't have any return values). This definitely look like a better solution.
 
reply
    Bookmark Topic Watch Topic
  • New Topic