Boost thread - ограниченное количество потоков?, непонятное ограничение, не связанное с ресурсами системы Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Iron Bug]

добрый день всем.
вот, может, кто сталкивался с подобной проблемой:
использую библиотеку thread boost'а для кроссплатформенного программирования. до недавего времени всё было замечательно, но тут возникло одно неприятное открытие:
оказалось, что буст почему-то ограничивает возможное количество потоков. а именно: после создания какого-то числа работающих потоков создание очередного потока проваливается с исключением boost::thread_resource_error и до уменьшения количества работающих потоков создание нового потока невозможно (каждый раз выпадает это исключение). причём это максимальное число потоков не зависит от реальных ресурсов системы, либо зависимость мне непонятна.
для проверки была написана маленькая программа - генератор потоков. потоки просто создаются, спят какое-то время, потом завершаются. потоки пустые, мелкие - то есть, памяти теоретически должно хватать. при этом задавалось разное время жизни потоков и разное количество потоков. результаты по подсчёту количества потоков всегда одинаковы, независимо от времени жизни каждого потока. это число каким-то загадочным образом зависит от машины, но, по видимому, не зависит от количества свободной памяти процесса и системы.
из опытов получилась такая странная картина: дома стоит машина под линюксом, 4 гектара памяти, своп вообще не используется - опытным путём получен предел в 382 потока, на работе машина под вендой, 1 гектар памяти, предел - 2024 потока. увеличение-уменьшение количества других процессов в системе никак не влияет.
откуда берутся такие странные цифры? может, есть возможность определить каким-то образом, как распределять ресурсы, чтобы потоков было больше? по работе необходима возможность одновоеменного выполнения очень большого и заранее неопределённого количества потоков в риал-тайме (пул потоков как бы не подходит по замыслу задачи). непонятно, откуда исходит это ограничение и как с ним бороться (если это вообще возможно).

[ViGOur]

хотя возможно какие-то системные твики могут это изменить.

Я тоже слышал, что *nix'ах где-то это настраивается, а вот где пока не знаю.

[Andrew Selivanov]

#include <stdio.h>
#include <windows.h>

DWORD CALLBACK ThreadProc(void*)
{
 Sleep(INFINITE);
 return 0;
}

int __cdecl main(int argc, const char* argv[])
{
int i;
 for (i = 0; i < 100000; i++) {
  DWORD id;
  //HANDLE h = CreateThread(NULL, 0, ThreadProc, NULL, 0, &id);
    HANDLE h = CreateThread(NULL, 4096, ThreadProc, NULL,
               STACK_SIZE_PARAM_IS_A_RESERVATION, &id);
  if (!h) break;
  CloseHandle(h);
 }
 printf("Created %d threads\n", i);
 return 0;
}

У меня 8643 потока...
Взято отсюда: http://blogs.msdn.com/oldnewthing/archive/.../29/444912.aspx

А нахрена столько...?

[Iron Bug]

А нахрена столько...?

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

[Andrew Selivanov]

Ааа.. стало яснее, но картину в целом всё равно представить сложно
Я обычно всё что связано с тестированием или срочно проверить итп ваяю на Perl-e. Очень удобно.

<тупые советы>
Кстати лучше ночью спать. Еще банальность - совершенство недостижимо Еще банальность - чем проще тем лучше.
</тупые советы>

На самом деле для внутренностей винды наиболее авторитетное и объемное издание это Сломон/Руссинович "Internals..." Хотя искать там что-то сложновато да и есть не всё. Но тем не менее.
Там довольно хорошо раскрыта тема потоков.

И ещё я тут подумал - есть ли вообще смысл в многопоточной модели в твоём случае? Ведь реальных ядер всего (два, четыре, восемь) а потоков - куча. Будет много переключений контекста. Не проще ли взять нечто вроде Reactor-а ( http://www.cs.wustl.edu/~schmidt/PDF/reactor-rules.pdf ) и контролировать взаимодействие самому..?

[Tonal]

Ежели железки тестируются независимо, то действительно почему бы не взять какой-нибудь нормальный скриптовый язык, Python, например.
И запускать по процессу на каждую железячку?
Думаю тот же linux 2000 python процессов выдержит без труда.

Ежели что-то более сложное - можно erlang посмотреть - вроде самое оно.

[Iron Bug]

To Andrew Selivanov:
Руссинович у меня есть, но действительно довольно мутная книжка, сложно там что-то найти. Рихтер тоже ничего, гораздо более читабельно. Собственно, у меня вопросов-то почти не возникает, я под венду очень давно пишу. Про потоки в венде я и так знаю всё. Я и дрова для железа под неё писала, и сервисы, и всякие приблуды для юзеров, и всё, что только можно... Ну, архитектура у неё... эээ... КХМ... короче говоря, венда и есть венда! У компании пока по некоторым причинам нет планов переходить на линюкс, хотя давно пора уже! Мешает куча наработок и боязнь перехода. Собственно, планы всегда горят и особо времени нет, а кадров вечно не хватает... И вот сейчас у меня есть идея перейти на кроссплатформу и окончательно избавиться от мелкософтовских библиотек, что я уже успешно сделала в первом приближении. Но, как всегда бывает, сначала система была простой и логичной, но потом по требованиям юзеров обрастала всё новыми и новыми фичами, которые надо было городить срочно и которые всё хуже и хуже увязывались с изначально поставленными задачами... И вот программа превратилась в монстра, обвешанного костылями и стала ненадёжно работать. Поэтому я сейчас вот измышляю универсальную и стройную систему, чтобы учесть те требования, которые на данный момент существуют и, по возможности, предусмотреть возможность для безболезненной модификации при необходимости внесения новых фич. Более того, я замышляю линюксовый переворот хотя бы в области тестирования. Хочу попробовать написать пару дров и полностью протестировать работу машин под линём. Естессно, с демонстрацией преимуществ линюкса начальству! Я знаю, что я фанат, но тут ничего не поделать.
To Tonal:
Насчёт скриптов... Железки не независимы! Они как раз представляют собой единый очень сложный механизм. И процессы и потоки активно взаимодействуют в риал-тайме... И ещё юзер вмешивается до кучи. И надо проверять что все ответы от девайсов приходят, и чтобы юзера куда-нибудь не зажевало случайно, и чтобы железяки не запороли друг друга и ещё команды подавать, чтобы всё это бодро шевелилось Скрипты - хорошая вещь для мелких задач. А у меня задачи объёмистые и надо ещё юзерский интерфейс городить. Тестирую, естественно, не я, а те люди, которые занимаются разработкой механики. Так что нужен простой и понятный полновесный графический интерфейс, а не просто запуск из командной строки. Пользователь задаёт кучу параметров, запускает различные тесты и может контролировать отдельные устройства и управлять или в ходе теста вручную. Кроме того, пользователь работает с механической частью, что тоже надо контролировать - во избежание. Всё это происходит без помощи программиста и рассчитано на людей, которые к программированию отношения не имеют. У меня интерфейс написан - из XML в wxWidgets генерит морды и подключается к межпроцессным очередям сообщений. Эта часть отработана. Я подозреваю, что скрипты привязать к межпроцессному обмену под вендой сложновато будет. К тому же, на Си я пишу с детства, со времён ДОСа и первого борландовского компилятора , питоном я вообще никогда не интересовалась, а в перл я дальше регекспов не лазила.
Так что пока буду стремиться к совершенству на Си. А по ночам я один фиг не сплю, даже если программировать ничего срочно не надо - я не контрабасе играю на радость соседям

[Tonal]

Erlang таки не скрипт а виртуальная машина. Заточенная специально под телеком и довольно производительная (soft real-time). Процессы у ей свои, легковесные, поэтому их можно запустить гораздо больше и быстрее чем потоках в винде или линухе.
К тому же есть стандартный биндинг с wxWidgets, так что мордочку можно и старую сохранить.
Ежели тяжелых вычислений нет, то вполне может покатить.

С другой стороны, Erlang - это функциональный язык с иммутабельными переменными.
По отзывам, инженер не отягощённый знанием программинга вьезжает в него за неделю, другую.
Но если есть привычка к императивщине, то может оказаться изрядно сложно...

Да, про python: привязать его куда угодно вполне просто - очень вменяемый апи для расширений.
Ну и своих библиотек море. И IPC, и wxWidgets, и XML

[Iron Bug]

ну, тут много деталей... если даже виртуальная машина и быстрая (что, мягко говоря, сомнительно) - то как её связать с реальным железом, у которого может не быть стандартных драйверов и стандартных интерфейсов? боюсь, что тут гемора будет выше крыши. хотя вычислений у меня не так много и они простые, зато надо постоянно и шустро парсить поток байтов с драйвера и вылавливать из него нужные данные. так что тут задача довольно специфическая. вообще, к телекому это отношения не имеет: это обработка данных от специально разработанного железа и управление точной механикой на очень большой скорости. то есть, автоматизация промышленных процессов. сетевого взаимодействия на уровне тестирования просто нет. все данные льются по спецшинам и ДМА в корзину, где и обрабатываются. довольно специфическая задача, со своими требованиями.
что касается Эрланга... я бегло просмотрела в сети отзывы народа про него... судя по отзывам, Эрланг вроде как не используется для таких задач, как у нас. что он быстрее С# - ну дык... гы! меня шарп вообще не интересует ни с какой стороны, ибо дикие тормоза и чисто прикладная реализация, в принципе не рассчитанная на низкоуровневую работу с железом. для стандартных интерфейсов это может быть и проканает, но очень маловероятно, что в него можно внедрить работу с межпроцессным адресным пространством, различными системными объектами и фреймами ДМА в памяти. отзывы в плюс Эрлангу - в основном по объёму кода. но мне совершенно фиолетово на объём - мне не лень писать код, лишь бы он работал быстро и надёжно. конечно, оптимизация может быть во всём, но объём кода тут на самом последнем месте. к тому же всякие автоматические сборки мусора напрягают сразу: это означает фактическую непредсказуемость работы системы. я думаю, если в промышленной автоматизации и системном программировании никто за столько лет не написал ничего на таких языках - то это неспроста. так что я всё же придерживаюсь программирования на Си: простой и надёжный язык, на нём можно написать всё, что только захочется. а про Эрланг - ну, если появится время, можно будет глянуть спецификацию более детально. однако пока что мне кажется, что он не подходит для моих задач.

[Andrew Selivanov]

To Andrew Selivanov:
Руссинович у меня есть, но действительно довольно мутная книжка, сложно там что-то найти. Рихтер тоже ничего, гораздо более читабельно. Собственно, у меня вопросов-то почти не возникает, я под венду очень давно пишу. Про потоки в венде я и так знаю всё. Я и дрова для железа под неё писала, и сервисы, и всякие приблуды для юзеров, и всё, что только можно... Ну, архитектура у неё... эээ... КХМ... короче говоря, венда и есть венда! У компании пока по некоторым причинам нет планов переходить на линюкс, хотя давно пора уже! Мешает куча наработок и боязнь перехода. Собственно, планы всегда горят и особо времени нет, а кадров вечно не хватает... И вот сейчас у меня есть идея перейти на кроссплатформу и окончательно избавиться от мелкософтовских библиотек, что я уже успешно сделала в первом приближении. Но, как всегда бывает, сначала система была простой и логичной, но потом по требованиям юзеров обрастала всё новыми и новыми фичами, которые надо было городить срочно и которые всё хуже и хуже увязывались с изначально поставленными задачами... И вот программа превратилась в монстра, обвешанного костылями и стала ненадёжно работать. Поэтому я сейчас вот измышляю универсальную и стройную систему, чтобы учесть те требования, которые на данный момент существуют и, по возможности, предусмотреть возможность для безболезненной модификации при необходимости внесения новых фич. Более того, я замышляю линюксовый переворот хотя бы в области тестирования. Хочу попробовать написать пару дров и полностью протестировать работу машин под линём. Естессно, с демонстрацией преимуществ линюкса начальству! Я знаю, что я фанат, но тут ничего не поделать.

Про винду
Виндовая архитектура это вообще сплошные holy wars... Там поколения программистов оставили свои следы.

Про юзеров
Где то когда-то прочитал, что если просят ругаются и приносят баги - значит пользуются. Это хорошо Плохо, когда месяц трахался и "А.. спасибо" и - тишина...

Про костыли, горящие планы
Как знакомо Очевидно это у всех - следовательно - нормально.

Про кроссплатформу
Я для себя пришёл к выводу, что поддерживать КП без очень, очень веских на то причин - жутко затратная штука. Оттестил там - здесь отвалилось. Оттестил здесь - там отвалилось. Скачиваешь какой нибудь Open Source, вроде как КПный, а одна из версий - эммм... датирована годом эдак прошлым. Мягко говоря

Про C
Очевидно C++

Про рефакторинг
Сам им страдаю периодически. Очень помогает изучение всякого качественного Open Source-a. Последнее время часто зависаю в коде DC++. Хорошая штука. А как там сделан протокол, автор мог бы статью отдельную написать. На радость разработчикам. Правда я не уверен, кто автор концепции.

Про Perl
Я его для себя воспринимаю как "Всё то, что бы хотели сделать в CMD, но не могли". СтОит потратить немного времени и понять про массивы, хэши, сокеты и прочее. IMHO.

Ударились во флейм и ушли от темы Думаю пора двинуть в специализированный раздел.

[Влад]

Iron Bug, вот я прочел и так и не понял: зачем все-таки плодить такое колоссальное количество потоков? Тем более, что 99.9% постоянно будут в состоянии ожидания, а когда же им дадут чуток поработать....
Мне кажется, здесь что-то не так в архитектуре приложения. Не лучше ли было бы использовать такие концепции, как "пул потоков" и "задание"? То есть, создается относительно небольшой пул рабочих потоков (размером, например, 2 * количество процессоров), и - баааальшая такая очередь заданий, которую они будут трудолюбиво разгребать. Как-то так.......
А при 2000 потоков они в основном будут бесполезно кушать ресурсы процесса, не успевая сделать ничего полезного.
Нет?