Russian Qt Forum
Март 29, 2024, 11:03 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 2 3 [4] 5 6 7   Вниз
  Печать  
Автор Тема: Работа из QSerialPort из разных потоков  (Прочитано 42532 раз)
Alechin
Гость
« Ответ #45 : Март 24, 2017, 09:47 »

> У меня только прохождение Ququed сигнала начала передачи заняло 20 мсек!
Что за прохождение? Чем замерял? Вызов слота при выдаче сигнала в однопоточном окружении не несет практически никаких накладных расходов (если используется Qt::AutoConnection)
использовать Qt::AutoConnection не получается - потоки разные. Только Queued.
а замерял просто qDebug()<<Time().currentTime()
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #46 : Март 24, 2017, 09:49 »

У меня сейчас сервис на Qt работает по сокетам с автомобильными трекерами, одновременно бывает подключено около 10К трекеров. Вся работа проводится в констексте одного потока и никакой просадки по производительности нет.
Этот сервис использует DeviceCommunicator?
Идея этого класса хорошая, спасибо за науку  Улыбающийся
Нет, там более сложная архитектура. А это просто наколенный пример. Улыбающийся
Записан

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #47 : Март 24, 2017, 09:50 »

передача в порт 2-ух байтов "напрямую" с ожиданием их выдачи и получением ответа занимает 300 мксек. У меня
только прохождение Ququed сигнала начала передачи заняло 20 мсек! т.е. в 66 раз больше!
20 миллисекунд? Т.е. я смогу в секунду послать не более 50 сигналов queued? Такой рез-т - явный абсурд. Когда-то сам мерял - все там норм, не выдумывайте  

да, получается такое вот упрощение и повышения наглядности ПО.
Ну "преждевременной оптимизации" никто не отменял. Если хотите печатать из разных потоков - придется пойти на какие-то накладные расходы, и использование слот/сигналов - вариант очень приличный

почему вы все считаете что кто-то одновременно полезет? есть класс работы с принтеров. класс одни. все обращения к принтеру только через него. он сам разруливает кого пустить к принтеру а кого нет.
Ну и сосредоточьте всю работу с принтером в одном потоке, типа "всегда фоновый". Главный или какой-то другой поток захотел печатать - общается с "печатающим" через QueuedConnection
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #48 : Март 24, 2017, 09:50 »

> У меня только прохождение Ququed сигнала начала передачи заняло 20 мсек!
Что за прохождение? Чем замерял? Вызов слота при выдаче сигнала в однопоточном окружении не несет практически никаких накладных расходов (если используется Qt::AutoConnection)
использовать Qt::AutoConnection не получается - потоки разные. Только Queued.
а замерял просто qDebug()<<Time().currentTime()
Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.
Записан

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Alechin
Гость
« Ответ #49 : Март 24, 2017, 09:51 »

> У меня только прохождение Ququed сигнала начала передачи заняло 20 мсек!
Что за прохождение? Чем замерял? Вызов слота при выдаче сигнала в однопоточном окружении не несет практически никаких накладных расходов (если используется Qt::AutoConnection)
использовать Qt::AutoConnection не получается - потоки разные. Только Queued.
а замерял просто qDebug()<<Time().currentTime()
Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.
уточню: делать"не один поток" а делать все основном GUI потоке?
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #50 : Март 24, 2017, 09:53 »

Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.
Та хоть и разные - до 20 миллисекунд там "дистанция огромного размера"
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #51 : Март 24, 2017, 09:55 »

Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.
Та хоть и разные - до 20 миллисекунд там "дистанция огромного размера"
Если были какие-то действия и ивентлуп не прокручивался, то хоть час может пройти.
Записан

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #52 : Март 24, 2017, 09:56 »

> уточню: делать"не один поток" а делать все основном GUI потоке?

Делать все в контексте основного потока до тех пор, пока не столкнешься с проблемой в производительности и не докажешь, что эта проблема именно из-за однопоточности.
Записан

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Alechin
Гость
« Ответ #53 : Март 24, 2017, 09:56 »

20 миллисекунд? Т.е. я смогу в секунду послать не более 50 сигналов queued? Такой рез-т - явный абсурд. Когда-то сам мерял - все там норм, не выдумывайте  
да, qDebug()<<QTime показыват именно такие цифры. Я так понимаю это очень похоже квант времени потока.
Ну и сосредоточьте всю работу с принтером в одном потоке, типа "всегда фоновый". Главный или какой-то другой поток захотел печатать - общается с "печатающим" через QueuedConnection
да уже так и сделано. Все работает. Удивила монструозность и тормознутость решения. Плюс непрозрачность (при взгляде со стороны), например дерганье своего собственного сигнала что бы вызвать свой собственный слот только потому что обычный port->write (по сути обычная запись файла!) не работает из чужого потока.
потому и возник вопрос "все ли я делаю так".
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #54 : Март 24, 2017, 09:58 »

20 миллисекунд? Т.е. я смогу в секунду послать не более 50 сигналов queued? Такой рез-т - явный абсурд. Когда-то сам мерял - все там норм, не выдумывайте   
да, qDebug()<<QTime показыват именно такие цифры. Я так понимаю это очень похоже квант времени потока.
Ну и сосредоточьте всю работу с принтером в одном потоке, типа "всегда фоновый". Главный или какой-то другой поток захотел печатать - общается с "печатающим" через QueuedConnection
да уже так и сделано. Все работает. Удивила монструозность и тормознутость решения. Плюс непрозрачность (при взгляде со стороны), например дерганье своего собственного сигнала что бы вызвать свой собственный слот только потому что обычный port->write (по сути обычная запись файла!) не работает из чужого потока.
потому и возник вопрос "все ли я делаю так".
Нет, ты делаешь не так.
Записан

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #55 : Март 24, 2017, 10:02 »

да уже так и сделано. Все работает. Удивила монструозность и тормознутость решения. Плюс непрозрачность (при взгляде со стороны), например дерганье своего собственного сигнала что бы вызвать свой собственный слот только потому что обычный port->write (по сути обычная запись файла!) не работает из чужого потока.
потому и возник вопрос "все ли я делаю так".
Ну похоже что не так  Улыбающийся Иначе не пришлось бы дергать свой же слот через queued
Записан
Alechin
Гость
« Ответ #56 : Март 24, 2017, 10:02 »

я уже понял что нет так Улыбающийся в смысле выноса в отдельный поток.
в таком случает (насчет предыдущего ответа с непрокручивание event_loop) - возникает боязнь что работоспособность системы будет зависеть от event-Loopа основного потока, что не есть хорошо. Работа в отдельном потоке не зависит от event_loopa других модулей программы. Виндовому WaitForMultipleEvent было все равно, даже если остальные потоки повисли - текущий всегда отрабатывал "мгновенно" свой функционал.
более того - для каждого потока (считай устройства, потому как работы с каждым устройством обычно шла в своем потоке) всегда отображалась статистика занятой памяти и времени работы потока, что позволяло легко отследить "взбесившиеся" устройства. Плюс для каждого потока отслеживалось что поток крутится, события приходят. если этого не происходило - поток автоматически перезапускался, в системный журнал делалась запись об этом..
В общем в выделении отдельного потока на каждое устройство были свои плюсы....
в принципе я все понял.......
« Последнее редактирование: Март 24, 2017, 10:07 от Alechin » Записан
Alechin
Гость
« Ответ #57 : Март 24, 2017, 10:03 »

Ну похоже что не так  Улыбающийся Иначе не пришлось бы дергать свой же слот через queued
в подходе с отдельным поток все так.
запись в порт из соседнего потока НЕ РАБОТАЕТ для QSerialPort.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #58 : Март 24, 2017, 10:09 »

в подходе с отдельным поток все так.
запись в порт из соседнего потока НЕ РАБОТАЕТ для QSerialPort.
"И это правильно". Запускаете "принтерный" поток (он и только он юзает QSerialPort), и пуляете в него сигналами - это все. Не нужно никаких доп EveтtLoop и.т.п.  Если у потока нет работы - он сам повиснет в своем событийном цикле. Ну и там флажков парочку накиньте - и все дела
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #59 : Март 24, 2017, 10:11 »

я уже понял что нет так Улыбающийся в смысле выноса в отдельный поток.
в таком случает (насчет предыдущего ответа с непрокручивание event_loop) - возникает боязнь что работоспособность системы будет зависеть от event-Loopа основного потока, что не есть хорошо. Работа в отдельном потоке не зависит от event_loopa других модулей программы. Виндовому WaitForMultipleEvent было все равно, даже если остальные потолки повисли - текущий всегда отрабатывал "мгновенно" свой функционал.
в принципе я все понял.......
В большинстве случаев, все будет хорошо. Мне в сервисе пришлось выносить в отдельный поток сохранение данных на диск, когда я столкнулся с просадкой по производительности, ибо дисковый IO тормозил основной поток. Я создал класс, у которого есть метод на прием данных файла и поместил его в отдельный поток. Получилось так: класс принимает данне для файла и помещает их в очередь (собственно, вызов метода не имеет просадки), а дальше по ивентлупу потока происходит реальная запись данных в файл. В итоге, основной поток разгрузился и все опять заработало как часы.
Записан

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Страниц: 1 2 3 [4] 5 6 7   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.057 секунд. Запросов: 23.