Хорошая практика: постоянно создавайте темы или используйте их повторно

Question

Хорошая практика: постоянно создавайте темы или используйте их повторно

0

Я разрабатываю кросс-платформенное приложение (Windows, Linux и Android) C++, которое должно отправлять нагрузку. Эта рабочая нагрузка должна быть отправлена по отдельному потоку, и существует возможность для асинхронного представления нескольких рабочих нагрузок. Приложение работает по потоку, а не по основному потоку, который выполняет скрипт. Этот скрипт, в свою очередь, будет выполнять представления рабочей нагрузки для дополнительных потоков. Время не критично в этом приложении, так как рабочая нагрузка работает на аппаратном эмуляторе.

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

Я пытаюсь определить, считается ли это хорошей практикой? Я также пытаюсь определить последствия для каждой ОС: EG Это может быть хорошо в Windows, но может возникнуть проблема с Android версии 4.2, о которой я не знаю.

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

Chris 02 март 2014, в 02:39

Источник

2

Итак, в основном вы спрашиваете, можно ли быть немного ленивым в pgm, где ваша лень не имеет большого значения для ускорения вашего графика? Это не очень хорошая практика, но держу пари, что она широко принята и практикуется. Основная причина для пулов потоков - эффективность. Если вы не заботитесь об этом, или он недостаточно рентабелен, чтобы заботиться об этом, тогда это то, что есть. Здесь стоит позаботиться о том, чтобы (без пула) ограничить количество потоков, которые вы запускаете, что в какой-то момент становится контрпродуктивным.
Duck 02 март 2014, в 01:21
0

Приветствия за ответ. Вы отчасти правы в том, что ускорение графика, а не лень - плохая практика. Это не лень, хотя (иначе я бы просто сделал это и не размещен на SO). Я считаю, что это реальное соображение: нужна ли нам дополнительная работа / время для реализации очередей потоков, если они абсолютно никогда не используются полностью. + за указание на то, что лень не является хорошей практикой.
Chris 02 март 2014, в 01:27
0

По крайней мере, в достаточно хорошо спроектированном API использование пула потоков не больше (и часто меньше) работы, чем непосредственное создание потоков. Как таковой, мне трудно думать об обстоятельствах, при которых кажется, что это имело бы много (если таковые имеются) смысла.
Jerry Coffin 02 март 2014, в 01:42
0

Понял. Я, вероятно, реализую пул потоков только из-за почти негодования (но не совсем) идеи не использовать один получает. Просто чтобы прояснить это, приложение не является сервисом / демоном, который выполняет постоянно распределяющую рабочую нагрузку, скорее это инструмент, который запускает тестовые сценарии одним выстрелом, который запускает кучу потоков и завершает работу впоследствии. Я предполагаю, что это потому, что приложение "один выстрел и выход", что поднимает этот вопрос для меня. Я бы даже не просил об услуге. Приветствия.
Chris 02 март 2014, в 02:14
1

Существует немного известный паттерн, называемый паттерном Back-Off . Здесь вы выполняете некоторую обработку потока, затем Sleep() течение 1 секунды, если есть больше работы, обработайте ее и Sleep() еще 1 секунду. Однако, если нет работы, то вы в 2 раза больше предыдущего времени Sleep() , так что теперь вы Sleep() течение 2 секунд. Если работы больше нет, вы Sleep() течение 4 секунд. Я использую этот шаблон в очереди сообщений веб-сервера, поскольку не всегда сообщения должны обрабатываться. Обычно у вас есть ограничение, на моем веб-сервере ограничение составляет 1 минуту, так что пользователю никогда не придется ждать сообщения более 1 минуты.
user152949 02 март 2014, в 02:52
0

@IngeHenriksen - почему бы использовать контур отсрочки вместо condvar или семафора, чтобы сигнализировать о доступности новой работы?
Martin James 02 март 2014, в 08:26
0

@MartinJames Я думаю, что вариант с наименьшим количеством проблем параллелизма - это std::atomic<unsigned int> numJobs , а затем просто numJobs++ его numJobs++ чтобы сигнализировать о новом задании, и numJobs-- после numJobs-- задания. Проверьте с помощью if (numJobs.load() > 0) DoWork() и обновите без итераций, используя numJobs.store(newVal) . Еще быстрее работает std::atomic_flag который гарантированно не блокируется, используйте его, если вы просто хотите сообщить, что есть работа, которую нужно выполнить, и вам не нужно общее количество заданий.
user152949 02 март 2014, в 12:25

Показать ещё 5 комментариев

Теги:

c++

android

multithreading

linux

windows

1 ответ

Ещё вопросы

Итак, в основном вы спрашиваете, можно ли быть немного ленивым в pgm, где ваша лень не имеет большого значения для ускорения вашего графика? Это не очень хорошая практика, но держу пари, что она широко принята и практикуется. Основная причина для пулов потоков - эффективность. Если вы не заботитесь об этом, или он недостаточно рентабелен, чтобы заботиться об этом, тогда это то, что есть. Здесь стоит позаботиться о том, чтобы (без пула) ограничить количество потоков, которые вы запускаете, что в какой-то момент становится контрпродуктивным.
Приветствия за ответ. Вы отчасти правы в том, что ускорение графика, а не лень - плохая практика. Это не лень, хотя (иначе я бы просто сделал это и не размещен на SO). Я считаю, что это реальное соображение: нужна ли нам дополнительная работа / время для реализации очередей потоков, если они абсолютно никогда не используются полностью. + за указание на то, что лень не является хорошей практикой.
По крайней мере, в достаточно хорошо спроектированном API использование пула потоков не больше (и часто меньше) работы, чем непосредственное создание потоков. Как таковой, мне трудно думать об обстоятельствах, при которых кажется, что это имело бы много (если таковые имеются) смысла.
Понял. Я, вероятно, реализую пул потоков только из-за почти негодования (но не совсем) идеи не использовать один получает. Просто чтобы прояснить это, приложение не является сервисом / демоном, который выполняет постоянно распределяющую рабочую нагрузку, скорее это инструмент, который запускает тестовые сценарии одним выстрелом, который запускает кучу потоков и завершает работу впоследствии. Я предполагаю, что это потому, что приложение "один выстрел и выход", что поднимает этот вопрос для меня. Я бы даже не просил об услуге. Приветствия.
Существует немного известный паттерн, называемый паттерном Back-Off . Здесь вы выполняете некоторую обработку потока, затем Sleep() течение 1 секунды, если есть больше работы, обработайте ее и Sleep() еще 1 секунду. Однако, если нет работы, то вы в 2 раза больше предыдущего времени Sleep() , так что теперь вы Sleep() течение 2 секунд. Если работы больше нет, вы Sleep() течение 4 секунд. Я использую этот шаблон в очереди сообщений веб-сервера, поскольку не всегда сообщения должны обрабатываться. Обычно у вас есть ограничение, на моем веб-сервере ограничение составляет 1 минуту, так что пользователю никогда не придется ждать сообщения более 1 минуты.
@IngeHenriksen - почему бы использовать контур отсрочки вместо condvar или семафора, чтобы сигнализировать о доступности новой работы?
@MartinJames Я думаю, что вариант с наименьшим количеством проблем параллелизма - это std::atomic<unsigned int> numJobs , а затем просто numJobs++ его numJobs++ чтобы сигнализировать о новом задании, и numJobs-- после numJobs-- задания. Проверьте с помощью if (numJobs.load() > 0) DoWork() и обновите без итераций, используя numJobs.store(newVal) . Еще быстрее работает std::atomic_flag который гарантированно не блокируется, используйте его, если вы просто хотите сообщить, что есть работа, которую нужно выполнить, и вам не нужно общее количество заданий.

Martin James · Accepted Answer · 2014-03-02T08-27-00.000Z

Создание потоков по требованию и их истечение при представлении может показаться простым, и, как и другие комментаторы, это часто делается. Я почти никогда не делаю такого по следующим причинам:

Вы должны фактически создавать потоки и правильно их завершать. Это может быть нетривиальным и подвержено ошибкам - поиск SO для "прекратить поток" сообщений - есть тысячи. Проблемы с завершающими потоками можно избежать, не завершая их.
Не только создание/завершение потоков гораздо более дорогостоящим с точки зрения фактического создания/завершения потоков, но любые классы, используемые потоком /s, должны постоянно создаваться и уничтожаться. Это может быть дорогостоящим для некоторых классов, и ошибки в dtors могут привести к все возрастающей утечке памяти (классы в непрозрачных библиотеках, которые вы не можете исправить, как известно, течет :). Этого можно избежать, не прерывая нити и избегая разрушения таких объектов.
Для создания потока требуется, чтобы его стек был выделен. Многие ОС выделяют слишком большие стеки по умолчанию, которые потребляют пространство виртуальной памяти. Это может быть проблемой с "взрывными" рабочими нагрузками, когда внезапное прибытие большой партии работы может привести к смехотворному большому количеству потоков и исчезновению памяти.
Если вы находитесь в неудачной позиции, чтобы поделиться некоторыми ресурсами по потокам, чем больше потоков, тем больше у вас будет конфликтов на этих ресурсах, поэтому увеличивается время ожидания блокировок.
Неизвестное количество потоков делает отладку, которая уже сложна при многопоточности, еще сложнее. Это для меня основное внимание, и я сделаю почти все, чтобы избежать множественных шаблонов create/terminate/join.
Создание/завершение/присоединение печально известно, что оно предотвращает быстрое завершение работы приложений. Если у вас на вашем компьютере были плохо настроенные графические приложения, которые не сразу закрываются по запросу (и я уверен, что у вас есть), join(), вероятно, станет причиной.

Отправка задач в пулы потоков намного безопаснее и будет предпочтительнее.

Время жизни приложения-приложения, т.е. созданные при запуске приложения, посвящены какой-то задаче и никогда не завершаются, также прекрасны, и для некоторых функций, таких как ведение журнала, больше подходят, чем задачи threadpool.

Многократное создание/завершение/соединение? Просто попробуйте очень, очень трудно избежать этого. Поместите этот шаблон в категорию "отчаяние" :)

Хотя мне вряд ли придется иметь дело с пакетными проблемами в моей среде, вы определенно хорошо относитесь к отладке. Работа с пулом потоков продолжается. Спасибо за ответ на вопрос с деталями почему / почему-нет, а не просто раздражение.