Советы по управлению потоками - Является ли TPL хорошей идеей?

Question

Я надеюсь получить несколько советов по использованию управления потоками и, надеюсь, параллельной библиотеки задач, потому что я не уверен, что шел по правильному маршруту. Наверное, лучше всего, чтобы я дал общее представление о том, что я пытаюсь сделать.

Учитывая Проблема Мне нужно сгенерировать Решение с использованием эвристического алгоритма. Я начну с вычисления базового решения, и я не думаю, что эту операцию можно распараллелить, поэтому нам не о чем беспокоиться.

После того, как исходное решение было сгенерировано, я хочу запустить n потоков, которые пытаются найти лучшее решение. Эти темы должны сделать пару вещей:

1. Их нужно инициализировать с помощью другой метрики оптимизации 1015 *. Другими словами, они пытаются оптимизировать разные вещи, с уровнем приоритета, установленным в коде. Это означает, что все они работают по-разному. Я не уверен, смогу ли я сделать это с TPL ..
2. Если один из потоков находит лучшее решение, чем наиболее известное в настоящее время решение (которое должно использоваться всеми потоками), ему необходимо обновить лучшее решение и принудительно перезапустить ряд других потоков (опять же, это зависит на приоритетные уровни показателей оптимизации).
3. Я также могу пожелать объединить определенные вычисления в потоках (например, сохранить объединение вероятностей для определенного подхода к проблеме). Это, вероятно, более необязательно.
4. Очевидно, что вся система должна быть поточно-безопасной, и я хочу, чтобы она работала максимально быстро.

Я попробовал довольно реализацию, которая включала управление моими собственными потоками, их отключение и т. Д., Но это стало довольно сложным, и теперь мне интересно, может ли TPL быть лучше. Мне интересно, может ли кто-нибудь предложить какое-либо общее руководство?

Спасибо ...

Answer 1

Я бы определенно посмотрел на TPL. Это позволяет вам абстрагироваться от вашей проблемы. Вы можете думать о задачах и о том, как они работают и обмениваться данными, вместо того, чтобы тратить как можно больше времени на базовую модель потоков, создавать потоки wn и управлять ими. TPL позволит вам создавать задачи, которые он назначает пулу потоков. Затем TPL управляет пулом и регулирует количество выполняемых задач, чтобы максимизировать производительность. Он будет делать это на различных аппаратных конфигурациях (ядрах), что облегчает разработку и приложение, которое не будет нуждаться в значительной переписке при перемещении между различными аппаратными средствами.

Есть еще много вещей, о которых вы должны подумать, особенно в отношении общего состояния. TPL обычно является лучшим подходом, чем собственный, если вы не обладаете большим опытом работы с потоками и / или у вас есть специальное приложение, которое TPL плохо подходит.

1.Они должны быть инициализированы с помощью другой «метрики оптимизации». В Другими словами, они пытаются оптимизировать разные вещи, с уровень приоритета, установленный в коде. это означает, что они все немного отличаются Расчет двигателей. Я не уверен, если я можно сделать это с помощью TPL ..

Это можно сделать, создав задачи и передав им разные начальные условия.

2.Если один из потоков находит лучшее решение, которое в настоящее время наиболее известно решение (которое должно быть разделено во всех темах) тогда нужно обновить лучшее решение и заставить количество других тем для перезапуска (опять же это зависит от приоритета уровни оптимизации показателей).

Можно отменить задания и запустить новые.

3.Можно также пожелать объединить некоторые вычисления в потоках (например, сохранить союз вероятностей для определенного подход к проблеме). Это возможно, более необязательный.

Не уверен, что понимаю это требование.

4. Очевидно, что вся система должна быть поточно-безопасной, и я хочу, чтобы она была работает как можно быстрее.

Даже если вы используете TPL, если вы делитесь данными между задачами (потоками), тогда вы по-прежнему несете ответственность за обеспечение безопасности потоков. Тем не менее, TPL поставляется с несколькими поточно-безопасными классами для очереди, коллекции, сумки и т. Д.

Судя по звукам этого варианта паттерна мастер / работник с добавлением некоторого умозрительного исполнения и кражи работы. Вы можете найти более подробную информацию об этом и других паттернах в http://parallelpatterns.codeplex.com/, внизу есть ссылка страницы к белой книге Стивена Туба, в которой также содержатся дополнительные сведения.

Answer 2

Это будет сложно, независимо от того, как вы это делаете. Написание правильного кода синхронизации очень сложно. И я думаю, что TPL будет излишним для этого.

Я бы порекомендовал откинуться на спинку кресла, посмотреть на проблему, выровнять ее и попытаться устранить как можно больше сложности.

Может быть, это поможет ... Создайте очередь метрик оптимизации и общий класс с лучшим ответом. Защитите свой общий класс с помощью блокировки чтения-записи, а свою очередь - с помощью мьютекса или другой блокировки. Запустите 4-8 потоков (один поток на процессор или более, если вы много блокируете), и пусть они запускаются в цикле. Удалить элемент из очереди, обработать его, проверить общие данные, повторять до тех пор, пока элементов больше не будет.

Не поддавайтесь искушению запустить 3000 потоков и будьте осторожны с условиями гонки, как этот: потяните блокировку читателя на общем классе, проверьте ваш ответ - скажем, это лучший ответ, снимите блокировку читателя и потяните писатель блокирует и обновляет общий класс. Проблема здесь в том, что другой поток мог обновить класс, пока вы ожидали блокировки записи, и вы просто отбрасывали «лучший» ответ, не проверяя его, как только у вас была блокировка записи.

Веселись.