multithreading - QSerialPort - 是否可以在单独的线程上读取()和写入()？

Question

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

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

所以基本上，我们大部分的写作都是在 API 调用者的线程中完成的，而我们所有的阅读都是在一个监听线程中完成的。我已经尝试将我们的代码版本移植到使用 QSerialPort 而不是 Windows 和 OSX 的 native 串行文件 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 似乎在这里给出的唯一真正优势是在端口关闭时销毁通知程序。

Answer 1

影响最小的解决方案
您可以随意查看 QSerialPort和 QIODevice代码并查看需要更改哪些内容才能使 write方法线程安全，只能从一个线程访问。通知者不必是 QSerialPort 的子级。完全可以将它们添加到销毁时清理的指针列表中。
我的猜测是，可能不需要对主线代码进行其他更改，并且访问错误状态只需要互斥锁保护，但您需要确认这一点。这对您的代码的影响最小。
如果您关心发布完整性，那么无论如何您都应该自己编译 Qt，并且您也应该将它作为您自己的源代码存储库的一部分。所以这一切都不应该是任何问题。
关于性能
“这些命令直接转化为 API 调用者线程上的写入，因此无需等待上下文切换” 现代机器是多核的，多个线程当然可以并行运行而无需任何上下文切换。然而，根本的问题是:为什么要打扰？如果您需要硬实时保证，则需要一个硬实时系统。否则，您的系统中的任何内容都不应该关心这种微小的延迟。如果您这样做只是为了让 GUI 感觉响应，那么这种过度复杂化真的没有意义。
通讯线程方法
我所做的，取得了巨大的成功和出色的性能，是将通信协议(protocol)和通信端口放在同一个专用线程中，而用户则在 GUI 线程或其他线程中。通讯端口一般为QIODevice ，如 QTcpSocket , QSerialPort , QLocalSocket等。因为通信协议(protocol)对象“只是”一个 QObject ，它也可以与端口一起存在于 GUI 线程中以用于演示目的 - 无论如何它都是完全异步设计的，除了最微不足道的计算之外不会阻塞任何东西。
通信协议(protocol)正在排队执行多个请求。即使在单核机器上，一旦 GUI 线程完成提交所有请求，进一步的执行都在通信线程中。QSerialPort实现使用异步 OS API。在单独的线程上进一步处理这些异步回复几乎没有任何好处。这些操作的开销非常低，尝试这样做不会在延迟中获得任何可测量的结果。请记住:这不是您的代码，而只是在缓冲区之间推送字节的代码。是的，在重负载或单核系统上可能存在上下文切换开销，但除非您可以测量它的存在与否之间的差异，否则您正在与想象中的问题作斗争。
可以使用任何 QObject当然，来自多个线程，只要您通过事件队列互斥锁序列化对它的访问即可。每当您使用 QMetaObject::invokeMethod 时，都会为您完成这项工作。或信号槽连接。
因此，在 QSerialPort 周围添加一个简单的包装器暴露了 write作为线程安全的方法。在内部，它应该使用信号槽连接。你可以调用这个线程安全的 write从任何线程。这种调用的开销是互斥锁和2+n malloc/免费调用，其中n是参数的非零数量。
在您的包装器中，您还可以处理 readyRead信号，并用接收到的数据发出信号。该信号可以由 QObject 处理生活在另一个线程中。
总的来说，如果您正确地进行了测量，并且您的端口线程的实现是正确的，那么您应该会发现所有这些复杂性都没有任何好处。
如果您的通信协议(protocol)进行大量数据处理，则应将其排除在外。它可以进入一个单独的QObject然后可以在自己的线程上运行。或者，它可以简单地使用由 QtConcurrent::run 执行的专​​用仿函数来完成。 .