QSerialPort - 是否可以在单独的线程上读取（）和写入（）？答案

【问题标题】：QSerialPort - Is it possible to read() and write() on separate threads?QSerialPort - 是否可以在单独的线程上读取（）和写入（）？
【发布时间】：2014-04-01 00:22:36
【问题描述】：

我们有一个 DLL，它为我们制造的 USB 设备提供 API，该设备可以显示为 USB CDC com 端口。实际上，我们在 Windows 上使用自定义驱动程序以获得最佳性能以及异步 i/o，但我们过去也使用串行端口异步文件 i/o 并取得了相当大的成功。

当 API 与我们的设备通信时，延迟在此 API 中非常重要，因此我们构建了我们的库，以便当应用程序调用 API 以在设备上执行命令时，这些命令会直接转化为 API 调用者线程上的写入，因此没有等待上下文切换。该库还维护一个侦听线程，该线程始终在异步读取时使用等待对象等待新响应。这些响应被解析并插入到线程安全队列中，供 API 用户在方便时读取。

所以基本上，我们大部分的写作都是在 API 调用者的线程中完成的，而我们所有的阅读都是在一个监听线程中完成的。我已经尝试将我们的代码版本移植到使用 QSerialPort 而不是 Windows 和 OSX 的本机串行文件 i/o，但是每当我尝试从调用者的线程中写入（）时，我都会遇到错误（QSerialPort 是在监听线程）：

QObject: Cannot create children for a parent that is in a different thread.

这似乎是由于为 QSerialPortPrivate::startAsyncWrite() 使用的通知器池创建了另一个基于 QObject 的 WriteOverlappedCompletionNotifier。

当前 5.2 版本的 QSerialPort 是否仅限于在同一个线程上进行读取和写入？这似乎很不幸，因为底层操作系统对串行端口文件 i/o 没有任何此类线程限制。据我所知，这个问题主要与 QSerialPort 的所有通知程序类都是基于 QObject 的事实有关。

有没有人可以解决这个问题？我可能会尝试构建自己的 QSerialPort，它使用不基于 QObject 的通知器来看看这让我走多远。 QObject 唯一真正的优势似乎是在端口关闭时销毁通知器。

【问题讨论】：

你应该带一些代码。你确定你在监听线程中创建了 QSerialPort 吗？你的线程实现如何？
-1，因为该问题预设了问题的存在，而没有提供任何测量来支持它。
Latency is very important -> 你正在使用 QtSerialPort... 你是认真的吗？！正如我们的一位用户所说，我们的库基本上是双击频率！
@FinalContest：我们不使用 QtSerialPort - 我们在 Windows 中使用我们自己的驱动程序和异步 i/o。当我遇到这些线程问题时，我正在为其他操作系统评估 QtSerialPort。在我们放弃之前，我们甚至都没有达到可以比较性能的地步。

标签： multithreading qt serial-port

【解决方案1】：

影响最小的解决方案

您可以随意检查QSerialPort 和QIODevice 代码，看看需要进行哪些更改才能使write 方法线程安全，只能从一个线程访问。通知器根本不需要是 QSerialPort 的子级，它们可以添加到在销毁时清理的指针列表中。

我的猜测是，可能不需要对主线代码进行其他更改，访问错误状态只需要互斥锁保护，但您需要确认这一点。这对您的代码的影响最小。

如果您关心发布的完整性，那么无论如何您都应该自己编译 Qt，并且您也应该将它作为您自己的源代码存储库的一部分。所以这些都不应该是任何问题。

关于性能

“这些命令直接在 API 调用者的线程上写入，因此无需等待上下文切换”现代机器是多核的，多个线程当然可以并行运行而无需任何上下文切换。然而，根本的问题是：为什么要打扰？如果您需要硬实时保证，则需要一个硬实时系统。否则，您的系统中的任何内容都不应该关心这种微小的延迟。如果您这样做只是为了让 GUI 感觉响应灵敏，那么这种过度复杂化真的没有意义。

通讯线程方法

我所做的，取得了巨大的成功和出色的性能，是将通信协议和通信端口放在同一个专用线程中，而用户则在 GUI 线程或其他线程中。通信端口一般为QIODevice，如QTcpSocket、QSerialPort、QLocalSocket等。由于通信协议对象“只是”一个QObject，它也可以与端口一起生活在用于演示目的的 GUI 线程 - 无论如何它都是完全异步设计的，除了最琐碎的计算之外不会阻塞任何事情。

通信协议正在排队执行多个请求。即使在单核机器上，一旦 GUI 线程完成提交所有请求，进一步的执行都在通信线程中。

QSerialPort 实现使用异步 OS API。在单独的线程上进一步处理这些异步回复几乎没有任何好处。这些操作的开销非常低，尝试这样做不会在延迟中获得任何可测量的结果。请记住：这不是您的代码，而只是在缓冲区之间推送字节的代码。是的，在重负载或单核系统上可能存在上下文切换开销，但除非您能够测量其存在与不存在之间的差异，否则您正在与想象中的问题作斗争。

可以在多个线程中使用any QObject，当然，只要您通过事件队列互斥锁序列化对它的访问即可。每当您使用 QMetaObject::invokeMethod 或信号槽连接时，都会为您完成此操作。

因此，在QSerialPort 周围添加一个简单的包装器，将write 公开为线程安全方法。在内部，它应该使用信号槽连接。你可以从 any 线程调用这个线程安全的write。这种调用的开销是互斥锁和2+n malloc/free 调用，其中n 是非零参数数。

在您的包装器中，您还可以处理readyRead 信号，并发出带有接收数据的信号。该信号可以由位于另一个线程中的QObject 处理。

总的来说，如果您正确地进行了测量，并且您的端口线程的实现是正确的，那么您应该会发现所有这些复杂性都没有任何好处。

如果您的通信协议执行繁重的数据处理，则应将其排除在外。它可以进入一个单独的QObject，然后可以在自己的线程上运行。或者，它可以简单地使用由QtConcurrent::run 执行的专用函子来完成。

【讨论】：

尝试了这个解决方案但没有成功。我从blockingMaster示例开始。 QSerialPort 在线程的“运行”方法中实例化。我建立了一个像这样的 QDSerialPort class QDSerialPort : public QObject { Q_OBJECT public: QDSerialPort(QObject* parent = nullptr); Q_INVOKABLE qint64 write(const QByteArray& byteArray){ serial->write(byteArray); } void setSerial(QSerialPort* serial) { this->serial = serial; } private: QSerialPort* serial; };
我从主线程调用 QMetaObject::invokeMethod(&s, "write", Qt::DirectConnection, Q_RETURN_ARG(qint64, result), Q_ARG(const QByteArray&, a)); 仍然有“无法为不同线程中的父级创建子级”。
直接连接与函数调用完全一样。 Qt 知道该怎么做 - 只需删除 Qt::DirectConnection 参数。
我做到了，但仍然有“无法为不同线程中的父级创建子级”。我的包装正确吗？
首先，您询问的是无处可见的代码，因此此评论不属于此处，而是针对一个新问题。其次，您收到的错误消息与该方法调用有关。您没有正确地将 I/O 中涉及的所有对象移动到工作线程，因此当工作在工作线程中完成时，它会失败。如果您还想了解更多，请提出问题并附上一个最小的、可编译的示例。看看我的repo 以获得灵感。

【解决方案2】：

如果您使用QSerialPort 打开和配置串行端口，并使用QSocketNotifier 监控读取活动（如果需要，还使用其他QSocketNotifier 实例进行写入完成和错误处理）？

QSerialPort::handle 应该给你你需要的文件描述符。在 Windows 上，如果该函数返回 Windows HANDLE，您可以使用 _open_osfhandle 获取文件描述符。

【讨论】：

【解决方案3】：

作为后续行动，在本次讨论之后不久，我确实使用 select() 等为 POSIX 系统实现了自己的线程安全串行端口代码，并且它在与 Qt 和非 Qt 应用程序结合的多线程上运行良好一样。基本上，我完全放弃了使用 QtSerialPort。

【讨论】：

这真是一个奇怪的想法。您可以尝试基于 (e)poll 的 Qt 事件循环。
有一些理由将 Qt 从这个库中取出，因为我使用它的次数最少。我用 boost 替换了线程、容器、互斥锁等，我的二进制文件变得更小了。关于您的 poll() / epoll() 评论，我对这些评论的理解是，当您等待大量文件时，它们的真正优势就来了。既然我们这里只处理一个设备，那真的比 select() 有优势吗？
据我所知，libev 明显更快。 Qt 事件循环有一些基准测试。无论哪种方式，提升的举动都非常好。串口可以考虑asio。