Безопасный размер стека потока? - PullRequest
5 голосов
/ 11 ноября 2010

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

Я устанавливаю размер стека с помощью pthread_attr_setstacksize(), и я могу получить минимально допустимый размер стека из PTHREAD_STACK_MIN. Но мой вопрос: Безопасно ли использовать PTHREAD_STACK_MIN для размера стека потока? Как мне рассчитать, сколько стека мне нужно? Есть ли какие-то скрытые накладные расходы, которые мне нужно будет добавить в мои расчеты?

Кроме того, есть ли другие методы, которые я могу использовать, чтобы уменьшить нагрузку на потоки в системе?

Ответы [ 3 ]

7 голосов
/ 11 ноября 2010

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

Что касается размера стека, вы не можете реально рассчитать, сколько вам нужно для произвольного потока, так как это полностью зависит от выполнения кода. Однако в Visual Studio типичный размер стека составляет несколько мегабайт. Вы должны были бы опубликовать весь код и результирующую разборку, выполняемую потоком, чтобы узнать, какой размер стека использовать. Просто вставь пару мегабайт.

5 голосов
/ 11 ноября 2010

Требуемый размер стековых фреймов зависит от используемого компилятора, в основном вы можете попытаться угадать размер ваших автоматических переменных, параметров и некоторых накладных расходов для обратного адреса, сохранения регистров и т. Д.

Вам следует подумать, будет ли альтернативой использование Thread Pool . Поскольку создание темы не бесплатно.

4 голосов
/ 11 ноября 2010

Уменьшение размера стека потоков не уменьшит накладные расходы (не с точки зрения использования процессора, памяти или производительности). Ваш единственный предел в этом отношении - это общее доступное виртуальное адресное пространство, выделенное потокам на вашей платформе.

Я бы использовал размер стека по умолчанию, пока платформа не создаст проблемы в противном случае (если это вообще произойдет). Затем минимизируйте использование стека, если и когда возникнут проблемы. Однако это приведет к реальным проблемам с производительностью, так как вам потребуется увеличить кучу или разработать потоково-зависимое распределение в другом месте.

Скрытые накладные расходы могут включать:

  • Распределение больших массивов в стеке, таких как VLA , alloca() или просто автоматические статические массивы простого размера.
  • Код, который вы не контролируете или не знали о последствиях использования, таких как шаблоны, фабричные классы и т. Д. Однако, учитывая, что вы не указали C ++, это вряд ли станет проблемой.
  • Импортированный код из заголовков библиотек и т. Д. Они могут изменяться в зависимости от версии и значительно изменять их стек или даже использование потоков.
  • рекурсия. Это происходит также из-за вышеупомянутых моментов, учитывайте такие вещи, как boost::bind, шаблоны с переменными числами, сумасшедшие макросы, а затем просто общую рекурсию с использованием буферов или больших объектов в стеке.

В дополнение к настройке размера стека, вы можете управлять приоритетами потоков, а также приостанавливать и возобновлять их по мере необходимости, что значительно поможет планировщику и отзывчивости системы. Pthreads позволяет вам установить область конфликта; LWP и объем планирования значительно различаются по своим рабочим характеристикам.

Вот несколько полезных ссылок:

...