Трансляция переменных Intel TBB

Я хотел лучше понять алгоритм, поэтому сделал несколько Погуглил" параллельный Эратосфен "и нашел это, в котором используется язык, аналогичный вашему подходу, но не очень хорошо объясняющийся алгоритм. Судя по описанию алгоритма, он плохо подходит для API на основе задач, такого как TBB. В частности, задача не должна блокировать или ждать чего-либо; он должен быть порожден, когда у него есть работа, а затем выполняться до завершения. Если мы адаптируем концепцию вашего алгоритма к подходу, основанному на задачах, то он будет выглядеть так:

1. Создайте вектор, содержащий известные простые числа. Здесь нет необходимости в параллелизме, потому что он не будет записываться одновременно. Заполните его стартовым набором (все простые числа до 100?). Создайте int для хранения наибольшего проверенного числа (установлено значение 100).
2. Запустите parallel_reduce разделов чисел от наибольшего проверенного числа p +1 до некоторого числа не более p ^ 2. Каждая задача parallel_reduce будет поддерживать свой собственный вектор обнаруженных простых чисел. parallel_reduce автоматически разделит эти задачи на более мелкие.
3. В задачах parallel_reduce каждый запускает последовательное сито, используя вектор известных простых чисел, чтобы исключить составные числа в своем диапазоне, и заполняет свой собственный вектор обнаруженных простых чисел.
4. Когда parallel_reduce объединяет две задачи, скопируйте все простые числа из вектора одной задачи в вектор другой задачи.
5. Когда вы решаете одну задачу, у вас есть вектор простых чисел, который нужно добавить к известным простым числам. Опять же, параллелизм здесь не нужен.
6. Обновите int наибольшего проверенного числа до того, что вы проверили, и вернитесь к шагу 2, пока не получите все нужные простые числа.

Так что нет ни «трансляции» простых чисел, ни какой-либо специальной работы для первой задачи. Есть просто серия parallel_reduces, которая дает вам все больше и больше простых чисел.

ОБНОВЛЕНИЕ

Если вы должны передавать информацию между задачами, способ сделать это с помощью TBB - защитить доступ к этим данным с помощью tbb :: mutex.

Однако проблема дизайна заключается не в том, как безопасно передавать данные между задачами - проблема в том, что делает каждая задача, пока она ожидает данных? Если ответ «ничего», вам не следует использовать задания. Задачи предназначены для выполнения до завершения и не должны вызывать ожидание вращения или блокировку на примитиве синхронизации, таком как tbb :: mutex. Если вы можете спроектировать свои задачи таким образом, чтобы они повторялись через работу и периодически проверяли наличие новых данных из других задач, чтобы изменить их подход, это будет работать нормально. Тот же подход с повторением и проверкой новых данных легче смоделировать с помощью серии вызовов parallel_reduce, как описано выше.