Russian Qt Forum

Здравствуйте! Программа создаёт набор подключений (сокетов..  около 10)  для обмена инфой с другими устройствами.  Насколько важно создавать отдельный поток для каждого подключения (сокета)?  Первая мысль, что это зависит от тяжести операция при обмене данными..  тогда как судить об этой тяжести..  хватит ли одного потока для всех подключений..?  или не мучиться с вопросом "хватит/не хватит"  и сразу делать многопоточную архитектуру!?!  ???

А что за обмен? На сколько интенсивен?

Tcp.. Инфа о состоянии тех устройств к которым подключаемся.. их мониторинг плюс небольшое управление (команды).  Точно пока не смогу сказать насколько часто посылки буду осуществляться..  возможно около раза в пол секунды для одного подключения.. хотя в будущем возможно и чаще.

Ыыы... раз  в 500 мс. пстц. Я тут за 20 мс борюсь на приём/ответ/обработку, а они... эхх... многопоточная архитектура...

Наверное это я погорячился..  будет чаще. Мне б просто эту грань научиться видеть..  многопоточная/немногопоточная..

Мну раз в 20 мс приходят уходят. Нужды в многопоточности не вижу. (1 поток гуи, 1 поток работа, чтоб гуи не застывало).

А вдруг потом заказчику что в голову стукнет  и он скажет "а давайка ещё сообщения об этом и об этом впихнём!!" и придётся переделывать всё архитектуру. 

Это также перетиралось здесь много раз, общий вывод: эта схема не годится для высоко нагруженных серверов, хотя и удобна/проста в реализации

Я те по секрету скажу - у меня примерно 8 линий по 120 устройств :D
И протокол собственный разработанный. И он позволяет обеспечивать работу их всех с приёмлимой задержкой.
А уж места под "развёртывание" у него дохренища. Ещё ровно 4 мс есть под новый функционал :D

Хотя у меня чуть иная ситуация, у меня RS-485 линии + коммутаторы. Быстродействие требуется максимальное.

PS а вот у тебя меньше 50 устройств планируется. Вот и не мучайся.

PPS вот только у меня организация. :D

Солидно =)  А можете с архитектурой подсказать.. так как опыта в этом у меня совсем мало..  вот думаю, что будет класс описывающий само утройство: допустим CDevice (до 10 экземпляров), который для создания подключения обращается к классу отвечающему за сетевые подключения CNetworkProvider(наверно целесообразно сделать его cинглтоном), который и будет хранить в себе  объекты подключения (сокеты, или объекты отвечающие за сокеты и содержащие их: CTcpConnection) которые будут привязаны сигналами каждый к своему экземпляру CDevice.  Теперь..  CNetworkProvider стартует в себе новый поток куда впоследствии и отправляются методом moveToThread()  созданные подключения (сокеты или объекты CTcpConnection).   
Вообщем стоит ли дальше развивать такую архитектуру или это совсем бредовые мысли?))  Может пример на эту тему есть!?  Направьте на путь истинный пожалуйста..  :)

Не стоит красоваться "голым числом"  :) Напр 100 линий по 1000 устройств могут быть относительно легкой задачей. И наоборот, всего 5 линий всего по 10 - очень трудной. Все зависит от того что считать "приемлЕмой задержкой"

Попробуй пул потоков, может это то что нужно для тебя?

Да я как-то изучал этот пул с его QRunnable.. да в чём-то облегчает жизнь, но всё-таки решил пользоваться QThread.

А с чего Вы взяли что такой путь есть вообще? :) Все зависит от конкретной задачи, только простые/типовые сводятся к переписанному и (кое-как) измененному примеру, остальные требуют мЫшления и самостоятельных решений. Это кому нравится, кому нет.

С точки зрения многопоточности "идеальная архитектура" давно известна. Число ниток = числу ядер + 1. Однако мало кто горит желанием делать "идеальную", т.к. обычно это сводится к выделению независимых подзадач которые могут быть скормлены любой их рабочих ниток. Это очень трудно и составляет 90% работы.

Поэтому часто идут на упрощения, напр/типа 1 коннект = 1 нитка. Да, это конечно "до определенного предела" - дальше все время ОС будет тратить на переключения между нитками. Но до того это будет работать вполне хорошо - и это сократит время разработки во много (может в десятки) раз. Отсюда и рекомендации типа "да не парься" - они имеют реальный, практический смысл.

Я бы посоветовал, да незнаю задачи и устройств :) У меня к примеру охранка.Там скорость обработки важна + наивысший приоритет тревог. А у тебя я незнаю что :)


to Igors:
Ну дай, ну дай мне похвастаться :D Я может быть ради этого момента на форуме регистрировался :D

PS и вообще мы на OPC переходим. Хоть и дороговат, но от головной боли по проектированию избавляет.

Та на здоровье, это нормально  :)

Не слышал ни о каком OPC, но не разделяю Вашего оптимизма, то палка о двух концах.Сегодня без проектирования - завтра без программистов вообще. А чего - девочки дешевле (+ имеют массу др. достоинств)

Не в том смысле. OPC избавляет от головной боли распределённого доступа к объектам :)
Ну и унификацию позволяет произвести малой кровью. А программисты всё равно нужны (те, которые OPC изучат, ибо он в России почти не применяется) :)

Мониторинг и частичное управление промышленными станциями (не могу сказать какими).  На каждой где-то по 4-5 датчиков. Но их опрашивает устройство на той стороне и уже оно формирует пакет и присылает его мне. Критичность по времени не сильно важна да и отправка как я сказал не часто. Теперь посоветуешь?  :D 

Время не важно. Значит что? Значит спокойно используем 1 поток на приём пакетов, 1 поток на обработку/сохранение результатов. Плюс основной поток на отображение информации.

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

Другой поток стоит на семафоре. Как только появляются данные, обрабатывает (хзкак, опять таки твоё дело) и отдаёт их на откуп модели и снова стоит ждёт.

Модель уже отображает данные и/или записывает в БД.

PS у тебя получается система сбора информации. Так же ты упоминал "частичное управление". Но это уже на твой откуп, подробностей не даёшь :)

Спасибо!
В программном эквиваленте это например пустить сигнал,соединённый с объектом из потока обработки с указанием Qt::QueuedConnection?

Как вариант да. Будет обычная очередь.

Хотя мне больше нравится обычное добавление в конец контейнера. Что по сути будет та же очередь :)

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

 

А корректно ли делать moveToThread после того как поток уже стартовал?  Просто в примерах  от Qt видел, что они сначала пихают объект в поток, а уже потом этот поток стартуют..

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

В доке противопоказаний нет

Что-то типа SQLDatabase или SQLquery, не помню точно, будет требовать новое подключение к базе при переносе в другой поток. Т.е. фактически умирать :D

Пока не знаю, как определить имеет ли класс ограничения, но у меня подключения возникают во время работы и чтобы кинуть сокет в обслуживающий поток  без данного действия не обойтись...  ммм..   Хотя обойтись..  сделав в том потоке объект, один из слотов которого будет клепать сокеты..  и эмитить ему сигнал из главного потока.   Или имея дело с сокетами (которые, надеюсь не имеют ограничений) не стоит париться и так сойдёт?

ХЗ на всё. Сокеты бывают разные, черные, белые, красные, тисипишные и эскуэльные, удепешные и кутешные.

 ;D

А зачем вам сокеты в разных потоках?

А где я написал, что они у меня в разных потоках?

Как бы вот.

Ну, обслуживающий поток один..  сокеты туда кидаются по мере появления новых подключений.  Всё по вашей схеме  :), или я неправильно вас понял? ???

По моей схеме у вас один поток создаёт сокет (входящее соединение), забирает оттуда данные (проверяя на корректность) и суёт данные (и только их) в поток обработки :)
Какие тут разные потоки с сокетами?

Вообще я планирую только исходящие соединения..  (логика такая, мол с кем захотел с тем и соединился).  И сначала думал создавать сокеты в главном потоке, а потом их кидать все в один поток (который хранит все соединения),   но теперь сделаю какой-нибудь объект в том потоке, который будет порождать новые соединения.  Вообщем может сумбурно написал, но мне кажется я вас понял)

У вас главный (ГУИ) поток должен только картинки в идеале показывать :D

Вы наверно меня правильно поняли :D

Это бесспорно! :D   Не так всё запущено :)