Boost thread - ограниченное количество потоков?, непонятное ограничение, не связанное с ресурсами системы Опции

[Iron Bug]

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

[Iron Bug]

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

[Andrew Selivanov]

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

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

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

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

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

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

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

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

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

[Влад]

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

[Гость_Stranger_*]

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