Hello,
I have constructed several threads in my application (it is such that
some threads start other threads, etc.). Now I would like to have a
possibility to execute some actions just when all the threads finished
(i.e. go out from the run function). Is there any nice way to do it?
Regards, mark
Deniz Dogan - 12 Nov 2006 14:00 GMT
> Hello,
>
[quoted text clipped - 4 lines]
>
> Regards, mark
You should look into the arts of concurrent programming, and
specifically barrier synchronization.
-Deniz Dogan
Daniel Dyer - 12 Nov 2006 14:24 GMT
> Hello,
>
[quoted text clipped - 4 lines]
>
> Regards, mark
Depending on how your threads are arranged, you can use a CountdownLatch
or a CyclicBarrier from the java.util.concurrent package.
Dan.

Signature
Daniel Dyer
http://www.uncommons.org
mark - 12 Nov 2006 15:06 GMT
Hello,
> Depending on how your threads are arranged, you can use a CountdownLatch
> or a CyclicBarrier from the java.util.concurrent package.
Thank you for your quick answer. I have looked at both of the classes
and it seems that both are inappropriate for my case. CountdownLeach is
not good, because at the beginning I do not know the number of the
created threads (that number can changes depending on the execution of
the threads). Cyclic barrier is also not good, because I just want to
check the situation when the thread finish (I am not going to resume it
again) so using it I think will make java to keep every thread running
and what I want is just to allow the garbage collector to remove them
just to create a space for a new threads. If I am wrong please tell me.
Regards, mark
Patricia Shanahan - 12 Nov 2006 15:04 GMT
> Hello,
>
[quoted text clipped - 4 lines]
>
> Regards, mark
While you could use general barrier techniques, there may be a simple
alternative for your specific situation. Once the threads in question
have been created, pass a list of references to them to a additional
"join" thread.
The "join" thread just calls each Thread object's join method. When the
last join call completes, all the threads have finished their run
methods, and the "join" thread executes the "some actions".
The "join" thread can be the thread that created them if it has no other
work it needs to do afterwards.
You need the general barrier approach if you need the "some actions" to
run in the individual threads after each has completed the substance of
its work but before the actual return.
Patricia