Russian Qt Forum

продумываю архитектуру приложения (обмен с сетевыми устройствами, типа опрос)
удобным видится использование множества потоков (т.е. 1 поток на работу по устройству)
но если устройств много, то и количество потоков растет (обычно до 100 устройств, но ограничу в 500)
тест QThread показал что можно создать 490 потоков, а если сделать setStackSize(PTHREAD_STACK_MIN), то чуть более 1000 (но там уже на общее количество открытых файлов ограничение, наверно можно увеличить)

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

А я ещё больше вас разочарую - примерное количество потоков в одном процессе не более 100. Более точная цифра зависит от ОС/железа. К примеру i7 на Win 7 в полной комплектации позволяет только 63 потока.

не страдайте. Обмен с сетевыми устройствами-опрос можно делать в одном потоке, одним менеджером. Тот же опрос по очереди будет не менее эффективен.

PS а как вы QThread проверяли? Пустых насоздавали?

Что за глупости? :)

Небольшая неточность - это для x86 процесса.
А так вот статейка для ознакомления - http://blogs.technet.com/b/mark_russinovich/archive/2009/11/02/3290815.aspx

А что именно вы этим уточнили? :)

Это глупости и для x86:

QThread и класс к нему который в нем живет
но проблема именно в создании - в коде QThread где вызов pthread_create, уменьшил стек - стало получше

очередь мутно городить, повторы всякие, вот потому и не хочу ее делать (не говорю что нельзя)

Все равно, делать столько потоков не нужно.
Работы для них никакой нет, а ресурсы на переключение будут тратится много.
Сделайте несколько ниток, например, по одной нитке на 50 - 100 устройств.

Верес, правильно, что вы убрали сообщение. :)
Лучше сначала сами прочтите эту статью, а еще лучше попробуйте сами. ;)
А qate уже дважды вам открыто написал, как можно (и под вендой в том числе) запустить больше потоков.

а смысл так делать ? на процессоры потоки раскидать ?
если и решу одну очередь, то один поток ее и обработает

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

Приведённая мною цифра была выдана как раз тестлимитом года полтора назад на приведённой мной конфигурации.
Сейчас перепроверил - теперь выдаёт около 2к. Что произошло - хз :)

Оформите этот линейный процесс опроса как функцию и запускайте ее в потоке. Нет никакой разницы.
Какие очереди вас пугают?

Вы забыли цифры из статьи и все наладилось. :)

линейный процесс на каждое устройство в функцию и в поток ? так это и будет 100 потоков )

пугает внесение логики в очередь
собственно для тестов я уже написал эту очередь ранее, но там много чего не хватает (повторов, событий, промежуточных состояний опроса)
поэтому я и подумал о потоках как иной вариант для рассмотрения

Может Верес имел ввиду ограничение в 63 (MAXIMUM_WAIT_OBJECTS) хендлов для функций типа WaitForMultipleObjects? :)

Я имел в виду что при запуске testLimit -t на i7 он выдал число 63.

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

Думаю можно еще посмотреть в сторону libev: https://github.com/sjinks/qt_eventdispatcher_libev

Почему? :)
Вы запустили 10 рабочих потоков, которые по очереди берут выполняют нужные функции, которые описывают линейный процесс. :)
Рабочий поток освободился - пошел проверять очередное устройство.
Посмотрите на QRunnable + QThreadPool

не знаком, что это и зачем ?

нужно запускать например 30 устройств сразу, не дожидаясь пока 10 первых отработают

QRunnable не имеет eventloop - нужны события ("наверх" о процессе запуска в gui) и внутрь (прерывание, сброс принудительно)

Ну сделайте 30 рабочих потоков. :)
Вы же понимаете, что реально 100 потоков не выполняются одновременно. Пока свой квант времени отрабатывает один поток (на одном ядре), все остальные ждут.

А вы не думали, быть может ваша задача вообще на одном потоке решается? Попробовать сделать замер....
Мне, вообще, видится, что нужно иметь по потоку на ядро и очередь запросов.

так и делаю 500 обычных (в том смысле что пул потоков мне тут не поможет)

Хозяин-барин. :)
Чем больше рабочих потоков - тем больше процессорного времени улетает впустую на переключения контекста. Не говоря уже о бесполезном расходовании адресного пространства на стеки этих потоков.
А выгоды никакой они не приносят. :)

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

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

мне как разработчику - приносят )

Я работу 10 потоков разных могу понять только с ручкой и бумажкой, и то приблизительно.
А вы на 100 замахнулись.

PS ну пусть человек порадуется :) Главное чтоб потом выложил результаты своих трудов - хотя б описание ощущений от отладки этой системы :)

что 2 что 100 - нет разницы, ведь они одинаковы в поведении
отладка также одинакова - лог действий

А вы попробуйте, а потом уже скажите :)

Один рабочий поток (на все ядра) и обмен асинхронный.

Как альтернатива:
1. Объявляете сигнал
2. Соединяете с ним слоты объектов-опросчиков (при этом объекты могут быть самых разных классов, даже не родственных)
3. Емитируете сигнал.
4. Опросчики запускаются в том порядке в котором было произведено соединение с сигналом.

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

А что тут "выдумывать" - очередь давно известна, это примерно 2 десятка строк кода. И на любое число ниток. Или еще проще: слот-сигнал с QueuedConnection. А вот заводить нитку "на каждый чих" - единодушно (и справедливо) осуждается