Необходимость нового потока для очередно

[brucemax]

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

[Пантер]

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

[brucemax]

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

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

[Bepec]

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

[brucemax]

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

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

[Bepec]

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

[brucemax]

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

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

[Igors]

Насколько важно создавать отдельный поток для каждого подключения (сокета)? 

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

[Bepec]

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

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

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

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

[brucemax]

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

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

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

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

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

[Igors]

Я те по секрету скажу - у меня примерно 8 линий по 120 устройств

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

[Fregloin]

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

[brucemax]

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

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

[Igors]

Вообщем стоит ли дальше развивать такую архитектуру или это совсем бредовые мысли?))  Может пример на эту тему есть!?  Направьте на путь истинный пожалуйста.. 

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

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

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

[Bepec]

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


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

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