ForkJoinTask: порядок объединения () - PullRequest
Новая
       41

ForkJoinTask: порядок объединения ()

0 голосов
/ 08 июня 2018

JavaDoc из ForkJoinTask говорит:

[R] Вращения (соединения) должны выполняться в первую очередь.Например, a.fork ();b.fork ();b.join ();a.join ();скорее всего, будет существенно более эффективным, чем присоединение до а.

Я не могу понять, почему (и при каких обстоятельствах) будет иметь значение порядок join() с, предполагая, что мне нужно присоединиться к a и b и получите их результаты, прежде чем продолжить мои вычисления.

В частности, у меня есть пара десятков fork() задач, и мне нужно подождать, пока все из них вернут своирезультат;очень похоже на invokeAll(), но я все еще могу выполнять некоторую работу после fork(), но до join() ing, поэтому я реализовал что-то вроде joinAll(), которое вызывается только тогда, когда я знаю, что не могу продолжить без результатовиз разветвленных заданий.

Вопрос в том, как это joinAll() должно быть реализовано?Имеет ли значение, в каком порядке этот код на самом деле вызывает join() для задач?

1 Ответ

0 голосов
/ 14 ноября 2018

При подготовке ForkJoin-Framework для лекции я также наткнулся на это утверждение в документации и хотел узнать, почему это так.

Во-первых, я хочу отметить, что у меня нет окончательного ответа на ваш вопрос, но я хочу поделиться тем, что я нашел:

В оригинальной статье, написанной Дагом Ли (http://gee.cs.oswego.edu/dl/papers/fj.pdf), его реализация алгоритма работы-кражи более подробно описана в разделе 2.1: подзадачи, сгенерированные рабочими потоками (с использованием fork), помещаются в собственную очередь . Рабочие потоки обрабатывают свои собственная deque LIFO (младшая первая), в то время как рабочие крадут у других deques FIFO (самая старая первая).

И затем я думаю, что важная часть: «Когда рабочий поток встречаетjoin операция, обрабатывает другие задачи , если доступно, до тех пор, пока не будет замечено, что целевая задача выполнена (через isDone). В противном случае все задачи выполняются до завершения без блокировки. "

Следовательно, более эффективно сначала join выполнять задачи, которые затем будет обрабатывать сам работник, а не join выполнять другие задачи, которые могут быть украдены у других пользователей.orkers.В противном случае, возможно, возникнут дополнительные накладные расходы на управление потоками из-за возможных переключений контекста и конфликта блокировок.

По крайней мере, для меня эти рассуждения имеют смысл в отношении описания в JavaDoc.

...