Работа с QSerialPort из разных потоков

@Alechin · Регистрация: 23.03.2017

Студворк — интернет-сервис помощи студентам

Задача такая. есть POS-принтер на COM порту. Необходимо иметь возможность передавать ему команды как из одного потока (основного) так и из дополнительного потока (фоновая печать).
QSerialPort создается и открывается в основном потоке. с вызовом функций write, waitForBytesWritten, wiatForReadyRead проблем нет - все работает (что логично).
Для фоновой печати записываю в очередь требуемые для передачи в принтер команды и вызываю метод фоновой печати через QtConcurrent::run. Соответственно тут все перестает работать - порт принадлежит другому потоку.
Как можно выкрутиться? или у меня что-то не так идеологически?
спасибо!

@Wyn · 23.03.2017, 14:30

Держите лучше QSerialPort в отдельном потоке. Тогда и проблема с фоновой печатью решится.
Общайтесь с ним или интерфейсом над ним с помощью сигналов и слотов между потоками.

@Alechin · 23.03.2017, 15:43 **[ТС]**

тогда появятся проблемы с нефоновым доступом

например: как сделать запрос и тут-же дождаться ответа (заблокироваться на операции)?

@Wyn · 23.03.2017, 16:23

Alechin, основной поток у вас - это поток GUI?

@Alechin · 23.03.2017, 19:07 **[ТС]**

ну сейчас в процессе отладки да, потом не факт.
в принципе я реализовал SerialPort в отдельном потоке - получился монстр. например: я не могу просто сделать port->write из другого потока - только через сигнал-слот QueueedConnection (зачем?! откуда берется связь записи в порт с потоком!?). Поэтому до начала передачи проходит 10-20 мсек (переключение потока?). Чтобы дождаться завершения передачи нужно сначала дождаться ее начала, потом дождаться завершения. на все приходится заводить WaitCondition....... в общем задача из 10 строчек вылилась в малопонятного монстра с кучей перекрестных связей (сигнал-слот) логически не относящихся к задаче, например передача сообщения - через сигнал-слот! вместо того чтобы напрямую.....).

@Wyn · 24.03.2017, 08:13

Сообщение от Alechin

Откуда берется связь записи в порт с потоком

Проблема тут в том, что SerialPort требователен к задержкам. А в gui потоке задержки бывают довольно длительными. Поэтому его лучше помещать в отдельный поток.

Read и write к внешнему доступу из потока с SerialPort вообще закрыты должны быть. Все операции с вводом и выводом на порт реализуйте исключительно в потоке с портом. Внешне же предоставьте только абстрагированные слоты и сигналы. Типа слот запросТемпературы и сигнал температура(вызываемый, когда температура с устройства получена). И т.д. в том же духе. Для чего-то более сложного придётся использовать специальные паттерны и придумывать логику, которая учитывала бы задержку на запрос данных.

@Alechin · 24.03.2017, 08:20 **[ТС]**

не очень понял откуда задержки? какие и откуда. Задержки как раз и появляются оттого, что вместо "прямого" port->write приходится вызывать через сигнал "отложеный" слот, в котором будет этот port->write и получить вместо 0.5 мсек прямого обращения 20-30 мсек такого "через сигнал".
И доступ к read и write как-бы "закрыт" методами класса, типа Send_Reset_Cmd или Send_Get_Status_Cmd, но внутри этих методов тот-же port->write, который нифига не работает в контексте другого потока (я не понимаю, если я открыл файл в одно потоке я не могу в него писать из другого?)

@Wyn · 24.03.2017, 10:43

Сообщение от Alechin

если я открыл файл в одно потоке я не могу в него писать из другого

А как вы это себе представляете? Представьте себе файл, с которым одновременно работают сразу два потока. И которые в него и пишут и читают. Это как два повара, которые пытаются приготовить два разных блюда в одной кастрюле. Что в итоге получится? Тут есть только один выход - какой-то из поваров заберёт себе кастрюлю и будет в ней готовить, а второй будет ждать. Так и с файлом.

@Alechin · 24.03.2017, 10:45 **[ТС]**

я не написал "писать из двух потоков одновременно" я написал "открыл в одном, пишу из другого".

@Wyn · 24.03.2017, 10:56

Также и ваш принтер. Как вы предполагаете с ним работать в двух разных потоках одновременно? Кто-то должен его обязательно забрать(заблокировав при этом доступ для других) в пользование, проделать работу и только потом освободить. В отдельный поток я его рекомендую вынести исключительно по причине того, чтобы обеспечить ему максимальную скорость запроса, ибо в большинстве случаев COM-port - это весьма узкое горлышко. Заодно это облегчает построение логики работы с лимитированным ресурсом, который в данный момент может быть не доступен. Это в общей теории. На практике каждое устройство обладает своими собственными способностями, которые описывает документация. Но опять таки логику работы с подобным устройством проще абстрагировать и реализовывать в классе, который и владеет портом, а не размазывать ровным слоем по всей программе.

@Alechin · 24.03.2017, 11:02 **[ТС]**

слова ОДНОВРЕМЕННО нигде не прозвучало. Конечно кто-то его заблокирует, попользует и отпустит. само собой.
а в отдельный поток он вынесен для возможности фоновой печати, когда кто-то накидал ему заданий и запустил фоновую печать. Так вот этот кто-то перед фоновой печатью хочет, например, проверить состояние принтера. Из другого потока. И это как раз делается через попу.
я уже разобрался. меня убедили фактами, что если порт создан одним потокам вызывать его методы можно только из этого потока. соответствкенно все другие обращения через сигнал-слот QueuedConnection.
Собственно у меня так и сделано, просто удивила монструозность и тормознутость данного решения. например у меня на железе трансляция сигнала QueuedConnection занимает 20 мсек, т.е. цикл обмена из передачи двух байт и приема в ответ одного, реально занимающий 400 мксек через слоты и сигналы занял 50 мсек.

@Wyn · 24.03.2017, 11:12

Сообщение от Alechin

Собственно у меня так и сделано, просто удивила монструозность и тормознутость данного решения. например у меня на железе трансляция сигнала QueuedConnection занимает 20 мсек, т.е. цикл обмена из передачи двух байт и приема в ответ одного, реально занимающий 400 мксек через слоты и сигналы занял 50 мсек.

Это минус многопоточного программирования.

Сообщение от Alechin

когда кто-то накидал ему заданий и запустил фоновую печать. Так вот этот кто-то перед фоновой печатью хочет, например, проверить состояние принтера. Из другого потока.

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

@Alechin · 24.03.2017, 11:14 **[ТС]**

Это не минус многопоточного, это минус реализации Qt. Который не позволяет сделать write из другого потока.
так как в аналогичном ПО в другой среде (Билдер) все замечательно и шустро работает.
ладно, думаю тему можно закрыть.

@Wyn · 24.03.2017, 11:22

Сообщение от Alechin

Это не минус многопоточного, это минус реализации Qt. Который не позволяет сделать write из другого потока.
так как в аналогичном ПО в другой среде (Билдер) все замечательно и шустро работает.
ладно, думаю тему можно закрыть.

С Qt тут всё в порядке. Почитайте про многопоточное программирование, тогда и сами поймёте, что в Qt всё реализовано правильно.
Про Билдер тут заливать не надо, магии в нём нет и на ровно том же самом сценарии он будет работать точно также.
Проблема тут только в том, что из-за недостатка опыта и знаний вы не можете придти к нужной структуре программы, которая наиболее оптимально решит проблему. Но это дело наживное.

@Alechin · 24.03.2017, 11:39 **[ТС]**

насчет недостатка опыта в Билдере вы погорячились - 15 лет.
и в Билдере как раз не так. с файлом (портом) я могу делать что угодно и откуда угодно по его хендлу. вот WaitForMultipleObjects я могу сделать на файле (порту) только в одном потоке, но это и логично.
более того все классы работы с портами построены на этом. Есть поток (_begin_thread), который крутится на WaitFor разных событий, и WaitableTimerы разные (тайма-ауты, общий цикл опроса, например), и события порта, например завершение передачи и прием терминального или просто символа и все что нужно.
Запустить передачу я могу откуда угодно. Запуск передачи собственно к потоку никакого отношения не имеет.
Если положу сообщение в очередь заданий и сгенерю Event - поток сам отработает передачу и все что нужно. если мне нужно однократное непродолжительно действия - я сам без ожидания попадания таск шедулера на этот поток отправлю данные в порт.

@Wyn · 24.03.2017, 12:13

Alechin, Про опыт и знания - я имел в виду Qt(в конце концов эта ветка про Qt). В остальном же скажу, что принципы многопоточного программирования ещё никто не отменял. Разнообразные хаки и другие подходы, помогающие более тонко настроить взаимодействие элементов есть и в Qt, но для этого надо знать Qt и знать как он работает. Никакой особой магии тут нет, всё тот же с++.

Новые блоги и статьи Все статьи Все блоги /
WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .	Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8

	Работа с QSerialPort из разных потоков 23.03.2017, 12:23. Показов 6069. Ответов 15 Метки нет (Все метки) Задача такая. есть POS-принтер на COM порту. Необходимо иметь возможность передавать ему команды как из одного потока (основного) так и из дополнительного потока (фоновая печать). QSerialPort создается и открывается в основном потоке. с вызовом функций write, waitForBytesWritten, wiatForReadyRead проблем нет - все работает (что логично). Для фоновой печати записываю в очередь требуемые для передачи в принтер команды и вызываю метод фоновой печати через QtConcurrent::run. Соответственно тут все перестает работать - порт принадлежит другому потоку. Как можно выкрутиться? или у меня что-то не так идеологически? спасибо! 0

@Wyn 1073 / 654 / 230 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	23.03.2017, 14:30
	Держите лучше QSerialPort в отдельном потоке. Тогда и проблема с фоновой печатью решится. Общайтесь с ним или интерфейсом над ним с помощью сигналов и слотов между потоками. 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	23.03.2017, 15:43 [ТС]
	тогда появятся проблемы с нефоновым доступом например: как сделать запрос и тут-же дождаться ответа (заблокироваться на операции)? 0

@Wyn 1073 / 654 / 230 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	23.03.2017, 16:23
	Alechin, основной поток у вас - это поток GUI? 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	23.03.2017, 19:07 [ТС]
	ну сейчас в процессе отладки да, потом не факт. в принципе я реализовал SerialPort в отдельном потоке - получился монстр. например: я не могу просто сделать port->write из другого потока - только через сигнал-слот QueueedConnection (зачем?! откуда берется связь записи в порт с потоком!?). Поэтому до начала передачи проходит 10-20 мсек (переключение потока?). Чтобы дождаться завершения передачи нужно сначала дождаться ее начала, потом дождаться завершения. на все приходится заводить WaitCondition....... в общем задача из 10 строчек вылилась в малопонятного монстра с кучей перекрестных связей (сигнал-слот) логически не относящихся к задаче, например передача сообщения - через сигнал-слот! вместо того чтобы напрямую.....). 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	24.03.2017, 08:20 [ТС]
	не очень понял откуда задержки? какие и откуда. Задержки как раз и появляются оттого, что вместо "прямого" port->write приходится вызывать через сигнал "отложеный" слот, в котором будет этот port->write и получить вместо 0.5 мсек прямого обращения 20-30 мсек такого "через сигнал". И доступ к read и write как-бы "закрыт" методами класса, типа Send_Reset_Cmd или Send_Get_Status_Cmd, но внутри этих методов тот-же port->write, который нифига не работает в контексте другого потока (я не понимаю, если я открыл файл в одно потоке я не могу в него писать из другого?) 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	24.03.2017, 10:45 [ТС]
	я не написал "писать из двух потоков одновременно" я написал "открыл в одном, пишу из другого". 0

@Wyn 1073 / 654 / 230 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	24.03.2017, 10:56
	Также и ваш принтер. Как вы предполагаете с ним работать в двух разных потоках одновременно? Кто-то должен его обязательно забрать(заблокировав при этом доступ для других) в пользование, проделать работу и только потом освободить. В отдельный поток я его рекомендую вынести исключительно по причине того, чтобы обеспечить ему максимальную скорость запроса, ибо в большинстве случаев COM-port - это весьма узкое горлышко. Заодно это облегчает построение логики работы с лимитированным ресурсом, который в данный момент может быть не доступен. Это в общей теории. На практике каждое устройство обладает своими собственными способностями, которые описывает документация. Но опять таки логику работы с подобным устройством проще абстрагировать и реализовывать в классе, который и владеет портом, а не размазывать ровным слоем по всей программе. 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	24.03.2017, 11:02 [ТС]
	слова ОДНОВРЕМЕННО нигде не прозвучало. Конечно кто-то его заблокирует, попользует и отпустит. само собой. а в отдельный поток он вынесен для возможности фоновой печати, когда кто-то накидал ему заданий и запустил фоновую печать. Так вот этот кто-то перед фоновой печатью хочет, например, проверить состояние принтера. Из другого потока. И это как раз делается через попу. я уже разобрался. меня убедили фактами, что если порт создан одним потокам вызывать его методы можно только из этого потока. соответствкенно все другие обращения через сигнал-слот QueuedConnection. Собственно у меня так и сделано, просто удивила монструозность и тормознутость данного решения. например у меня на железе трансляция сигнала QueuedConnection занимает 20 мсек, т.е. цикл обмена из передачи двух байт и приема в ответ одного, реально занимающий 400 мксек через слоты и сигналы занял 50 мсек. 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	24.03.2017, 11:14 [ТС]
	Это не минус многопоточного, это минус реализации Qt. Который не позволяет сделать write из другого потока. так как в аналогичном ПО в другой среде (Билдер) все замечательно и шустро работает. ладно, думаю тему можно закрыть. 0

@Alechin 0 / 0 / 0 Регистрация: 23.03.2017 Сообщений: 8
	24.03.2017, 11:39 [ТС]
	насчет недостатка опыта в Билдере вы погорячились - 15 лет. и в Билдере как раз не так. с файлом (портом) я могу делать что угодно и откуда угодно по его хендлу. вот WaitForMultipleObjects я могу сделать на файле (порту) только в одном потоке, но это и логично. более того все классы работы с портами построены на этом. Есть поток (_begin_thread), который крутится на WaitFor разных событий, и WaitableTimerы разные (тайма-ауты, общий цикл опроса, например), и события порта, например завершение передачи и прием терминального или просто символа и все что нужно. Запустить передачу я могу откуда угодно. Запуск передачи собственно к потоку никакого отношения не имеет. Если положу сообщение в очередь заданий и сгенерю Event - поток сам отработает передачу и все что нужно. если мне нужно однократное непродолжительно действия - я сам без ожидания попадания таск шедулера на этот поток отправлю данные в порт. 0

@Wyn 1073 / 654 / 230 Регистрация: 14.01.2016 Сообщений: 2,031 Записей в блоге: 9
	24.03.2017, 12:13
	Alechin, Про опыт и знания - я имел в виду Qt(в конце концов эта ветка про Qt). В остальном же скажу, что принципы многопоточного программирования ещё никто не отменял. Разнообразные хаки и другие подходы, помогающие более тонко настроить взаимодействие элементов есть и в Qt, но для этого надо знать Qt и знать как он работает. Никакой особой магии тут нет, всё тот же с++. 0