java - ¿Espera a que terminen todos los hilos en un ejecutor?

parallel-processing quicksort

Question

Estoy implementando una solución rápida parellel como práctica de programación, y cuando terminé, leí la página del tutorial de Java sobre ejecutores, que parece que podría hacer que mi código sea aún más rápido. Desafortunadamente, estaba confiando en join () para asegurarme de que el programa no continúe hasta que todo esté ordenado. En este momento estoy usando:

public static void quicksort(double[] a, int left, int right) {
if (right <= left) return;
int i = partition(a, left, right);
// threads is an AtomicInteger I''m using to make sure I don''t
// spawn a billion threads.
if(threads.get() < 5){
// ThreadSort''s run method just calls quicksort()
Future leftThread = e.submit(new ThreadSort(a, left, i-1));
Future rightThread = e.submit(new ThreadSort(a, i+1, right));
threads.getAndAdd(2);
try {
leftThread.get();
rightThread.get();
}
catch (InterruptedException ex) {}
catch (ExecutionException ex) {}
}
else{
quicksort(a, left, i-1);
quicksort(a, i+1, right);
}
}

Esto parece funcionar bien, pero si ejecuto e.shutdown () justo después de llamar a mi método no recursivo quicksort (), tiene un montón de Excepción de excepciones rechazadas, así que supongo que esto no está funcionando tan bien como yo quería.

Entonces, de todos modos, básicamente estoy tratando de obtener la misma funcionalidad que leftThread.join () pero con un Executor, y mis preguntas son:

¿Es esta la mejor manera de esperar hasta que todos los hilos hayan terminado?

EDITAR: Ok, entonces descubrí por qué tuve un montón de errores después de apagar mi Ejecutor, fue porque estaba llamando a esta función en un bucle (para igualar los tiempos de ejecución) y no crear un nuevo Ejecutor.

Answer 1

Podría usar CountDownLatch

Answer 2

¿Qué tipo de ejecutor estás usando?

ThreadPoolExecutor .awaitTermination() hará lo que está preguntando (en realidad es una operación de unión masiva).

Como un total aparte, ThreadPoolExecutor te permitirá establecer límites en el número de hilos, etc ... (podría ser mejor que ir recursivo como lo que estás haciendo si el conteo de subprocesos es alto, no estoy seguro).

PD: dudo que los ejecutores hagan que su código se ejecute más rápido, pero pueden hacer que su código sea más fácil de leer y mantener. El uso de un grupo de subprocesos hará las cosas más rápidas para este tipo de algoritmo, y el ejecutor facilita el trabajo con grupos de subprocesos.

Answer 3

Eche un vistazo a Executors.newFixedThreadPool que le permite crear un grupo de como mucho n hilos (se deshace de su "si") y el método ExecutorService.shutdown y el método ExecutorsService.awaitTermination .

Answer 4

PD: dudo que los ejecutores hagan que su código se ejecute más rápido, pero pueden hacer que su código sea más fácil de leer y mantener. El uso de un grupo de subprocesos hará las cosas más rápidas para este tipo de algoritmo, y el ejecutor facilita el trabajo con grupos de subprocesos.

Esto no es correcto.

El ejecutor puede ser ''respaldado'' por cualquier cantidad de sistemas de ejecución diferentes, incluidos los hilos agrupados.

Debe llamar a la clase de fábrica correctamente.

Además, también debe decidir sobre una política para tratar situaciones en las que los trabajos se envían a la cola más rápido de lo que pueden consumirse, porque puede que no se quede sin memoria inicialmente debido a los límites en la ejecución de la secuencia, pero si pone en cola millones trabajos, entonces tienen que ser almacenados en algún lugar mientras esperan su ejecución.