How to know that all the threads in pool are done with execution ?

[samir ware]

Hello Ranchers
I am using Executor.newFixedThreadPool to create a thread pool. I was able to create the desired numbe of threads. All these thread perform some task and on return will reside in the thread pool. Though is there any way by which I will get to know that now all the threads are done with the working and all of them came back in to the thread pool . I need to catch this event as I want to perform some operation when threads gets done with their processing .
Any white paper link will greatly be appricaited.
Thanks
Samir

[Marco Ehrentreich]

Hi samir,

if you have submitted all jobs to the thread pool you basically have to call shutdown() on the ExecutorService you get from the call to Executor.newFixedThreadPool(). This will tell the pool not to accept any more jobs. After this you can use the method awaitTermination(long timeout, TimeUnit unit) on the ExecutorService object which tells it to wait until all submitted jobs have completed their work but only for the given amount of time. This method simply blocks the calling thread (usually where you have created the pool) until all jobs are finished or the given timeout is reached. I hope this functionality is what you meant with "catch this event".

Marco

[samir ware]

Hey Macro
Thanks a lot for the reply. You got me right. Yes...I do want to know when exactly all the threads in the pool are done with their execution. API that you have suggested

awaitTermination(long timeout, TimeUnit unit)

is helpfull though I am quiet unsure about how much time will the thread take to finish their jobs. It may be 5 minutes, may be 1 hour...not sure as all my thrreads are performing as workers. Thats the reason I was looking for something which will fire an event indicating that all the threads are done with their processing and they returned back to the pool and simply waiting there.
Is there any way by which I can get to know @ this ?
Thanks in advance
Samir

[Jeff Verdegan]

samir ware wrote:Hey Macro
Thanks a lot for the reply. You got me right. Yes...I do want to know when exactly all the threads in the pool are done with their execution. API that you have suggested

awaitTermination(long timeout, TimeUnit unit)

is helpfull though I am quiet unsure about how much time will the thread take to finish their jobs. It may be 5 minutes, may be 1 hour

The point of the timeout isn't that you need to know how long the threads will take, it's so that you can pick some point that's too long, and if it gets to that point, then the method returns false or throws and exception or does something to let you know that it timed out before the threads finished.

If the threads finish before the timeout, then the await method returns at that point. So if you set the timeout for an hour, and the thread finishes in one minute, the method will return after that one minute. If you think your threads could take up to one hour, then set the timeout for 2 hours or 4 or 24. Or just set them to 1,000 years.

[Marco Ehrentreich]

Did this answer your question, Samir?

Perhaps I should note that it is in general a good idea to define reasonable timeouts in situations like this because otherwise your whole application could block ("hang") indefinetly if one of the worker threads doesn't return (for whatever reason) after finishing its work.

[Jeff Verdegan]

Marco Ehrentreich wrote:

Perhaps I should note that it is in general a good idea to define reasonable timeouts in situations like this

Indeed. And "reasonable" of course is more art than science and very dependent on your particular context. A good rule of thumb might be 2-4 times longer than the longest you would expect your work to take. Or maybe there's some hard deadline beyond which you cannot wait or beyond which the results become useless.

Additionally, if the work takes more than a few minutes--say, more than a person could just sit and watch and wait for the results--you'll probably want to add some sort of activity indicator. For instance, write to a log file indicating how much has been done every N steps, or N seconds. You don't want to wait for a 3-hour timeout to discover you've got an infinite loop or a deadlock.

[samir ware]

Yes Macro
I understood and that worked as well for me.
Thanks a lot for the kind help.
Samir

[Nomaan Butt]

samir ware wrote:Hello Ranchers
Though is there any way by which I will get to know that now all the threads are done with the working and all of them came back in to the thread pool . I need to catch this event as I want to perform some operation when threads gets done with their processing .

you can achive this using the isDone() method of Future interface, put all the tasks(Callable) in an ArrayList and pass them to the below method

List<Future<String>> invokeAll(ArrayList<callableObject> cb)

then call the isDone() method on the retuned list of Futures to find if they have finished.
isDone() will return true if the task has finished.

Future interface is used to find the states of the current threads in pool.

[Jeff Verdegan]

Nomaan Butt wrote:

samir ware wrote:Hello Ranchers
Though is there any way by which I will get to know that now all the threads are done with the working and all of them came back in to the thread pool . I need to catch this event as I want to perform some operation when threads gets done with their processing .

you can achive this using the isDone() method of Future interface, put all the tasks(Callable) in an ArrayList and pass them to the below method

List<Future<String>> invokeAll(ArrayList<callableObject> cb)

then call the isDone() method on the retuned list of Futures to find if they have finished.
isDone() will return true if the task has finished.

Future interface is used to find the states of the current threads in pool.

Actually, the Future is tied to your tasks, not to the threads that execute them. And I would argue that for this reason, it's probably a more appropriate approach than the other one suggested earlier.

@OP: If you're using a thread pool in the first place, it means you have deliberately chosen to separate your tasks from the threads that execute them, and it seems more likely that you would care about when those tasks are done, rather than caring about the threads. If you really do want to know when the threads are all done, it seems simpler to just manage the threads yourself, and call their join() methods.

[Nomaan Butt]

Jeff Verdegan wrote:
Actually, the Future is tied to your tasks, not to the threads that execute them. And I would argue that for this reason, it's probably a more appropriate approach than the other one suggested earlier.

@OP: If you're using a thread pool in the first place, it means you have deliberately chosen to separate your tasks from the threads that execute them, and it seems more likely that you would care about when those tasks are done, rather than caring about the threads. If you really do want to know when the threads are all done, it seems simpler to just manage the threads yourself, and call their join() methods.

quite right Jeff