Совет управления потоком - действительно ли TPL является хорошей идеей?
Я надеюсь получить некоторый совет относительно использования управления потоком и надо надеяться библиотеки параллели задачи, потому что я не уверен, что спускался по правильному маршруту. Вероятно, лучше всего то, что я даю схему того, что я пытаюсь сделать.
Учитывая проблему я должен генерировать Решение с помощью основанного на эвристике алгоритма. Я запускаю путем вычисления основного решения, эта операция, я не думаю, может быть параллелизирована так, мы не должны волноваться о.
После того как inital решение было сгенерировано, я хочу инициировать потоки n, которые пытаются найти лучшее решение. Эти потоки должны сделать несколько вещей:
- Они должны быть initalized с другой 'метрикой оптимизации'. Другими словами, они пытаются оптимизировать разные вещи с набором уровня приоритета в рамках кода. Это означает, что они все выполняют немного отличающиеся механизмы вычисления. Я не уверен, могу ли я сделать это с TPL..
- Если один из потоков находит лучшее решение, что в настоящее время самое известное решение (который должен быть совместно использован через все потоки) затем он должен обновить лучшее решение и вынудить много других потоков перезапустить (снова, это зависит на уровнях приоритета метрик оптимизации).
- Я могу также хотеть объединить определенные вычисления через потоки (например, сохранить объединение вероятностей для определенного подхода к проблеме). Это является, вероятно, более дополнительным все же.
- Целая система должна быть ориентирована на многопотоковое исполнение, очевидно, и я хочу, чтобы она работала максимально быстро.
Я попробовал настоящую реализацию, которая включила управление моими собственными потоками и завершение работы их и т.д., но это начало быть вполне сложным, и я теперь задаюсь вопросом, мог ли TPL быть лучше. Я задаюсь вопросом, может ли кто-либо предложить общее руководство?
Спасибо...
2 ответа
Я бы обязательно посмотрел ТОП. Это позволяет абстрагироваться от вашей проблемы. Вы можете думать о задачах и о том, как они работают, и обмениваться данными, вместо того, чтобы тратить столько же времени на базовую модель потоков, создавать свои потоки wn и управлять ими. TPL позволит вам создавать задачи, которые он назначает пулу потоков. Затем TPL управляет пулом и регулирует количество выполняемых задач для максимальной производительности. Он будет делать это на различных аппаратных конфигурациях (ядрах), что упрощает разработку и применение, которое не требует серьезной перезаписи при переходе с одного другого оборудования на другое.
Есть еще много над чем подумать, особенно о совместном использовании состояния. TPL обычно является лучшим подходом, чем сворачивание собственного, если у вас нет большого опыта работы с потоками и / или у вас есть какое-то специальное приложение, для которого TPL плохо подходит.
1. Их нужно инициализировать с другой «метрикой оптимизации». Другими словами, они пытаются оптимизировать различные вещи с уровнем приоритета, установленным в коде. Это означает, что все они используют несколько разные вычислительные машины. Я не уверен, что смогу сделать это с помощью TPL ..
Вы можете сделать это, создав задачи и передав им различные начальные условия.
2.Если один из потоков находит лучшее решение, чем наиболее известное на данный момент решение (которое необходимо использовать для всех потоков), ему необходимо обновить лучшее решение, и принудительно перезапустить количество других потоков (опять же, это зависит от уровней приоритета показателей оптимизации).
Есть возможность отменять задания и запускать новые.
3. Я также могу объединить определенные вычисления в потоках (например, сохранить объединение вероятностей для определенного подхода к проблеме). Хотя это , вероятно, более необязательно.
Не уверен, что понимаю это требование.
4. Очевидно, что вся система должна быть потокобезопасной, и я хочу, чтобы она работала как можно быстрее.
Даже с TPL, когда вы обмениваетесь данными между задачами (потоками), вы все равно обязаны делать это потокобезопасным способом. Однако TPL поставляется с несколькими потокобезопасными классами для очереди, сбора, сумки и т. Д.
Судя по звукам, это вариант шаблона главный / рабочий с некоторым спекулятивным выполнением и кражей работы. Вы можете найти более подробную информацию о этот и другие шаблоны на http://parallelpatterns.codeplex.com/ внизу страницы есть ссылка на технический документ Стивена Туба, в котором также описаны дополнительные детали.
Это будет сложно, как бы вы это ни делали. Написать правильный код синхронизации очень сложно. И я думаю, что TPL будет излишним для этого.
Я бы порекомендовал сесть и посмотреть на проблему, дорисовать ее на доске и попытаться устранить как можно больше сложностей.
Может быть, это поможет ... Создайте очередь показателей оптимизации и общий класс с лучшим ответом. Защитите свой общий класс блокировкой чтения и записи, а свою очередь - мьютексом или какой-либо другой блокировкой. Запустите 4-8 потоков (один поток на процессор или больше, если вы блокируете много), и пусть они запускаются в цикле. Удалите элемент из очереди, обработайте его, проверьте общие данные, повторяйте, пока элементы не исчезнут.
Не поддавайтесь искушению запустить 3000 потоков и будьте осторожны с условиями гонки, такими как это: снимите блокировку считывателя на разделяемом классе, проверьте свой ответ - скажем, это лучший ответ, сбросьте блокировку считывателя и вытяните блокировка писателя и обновление общего класса. Проблема здесь в том, что другой поток мог обновить класс, пока вы ждали блокировку писателя, и вы просто сдули «лучший» ответ, не проверяя его, когда у вас есть блокировка писателя.
Удачи.