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

[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 потоков они в основном будут бесполезно кушать ресурсы процесса, не успевая сделать ничего полезного.
Нет?