QThread vs std :: thread [英] QThread vs std::thread

问题描述

我在"pthread vs std :: thread"和"QThread vs pthread"上看到了不同的主题，但在"std :: thread vs QThread"上没有看到相同的主题.

I saw different topics on "pthread vs std::thread" and "QThread vs pthread" but none on "std::thread vs QThread".

我必须对驱动3D打印机的软件进行编程，并且需要使用线程.会有一个线程会不断检查安全性，另一个线程会执行打印过程，一些线程会分别驱动每个硬件组件(运动，喷射，...)，等等. 该程序是针对Windows使用C ++ 11/Qt开发的.

I have to program a software to drive a 3D Printer and need to use threads. There will be a thread that will check safety constantly, another to execute the printing process, some for driving each hardware component (movement, jet, ...) separately, etc... The program is developed for Windows with C++11/Qt.

首先，我想使用QThread，但是例如，在我阅读《 C ++并发操作》时，QThread不允许您执行与std :: thread 一样多的事情.通过Anthony Williams，我发现可以通过执行类似std::thread t1(&Class::function, this, ...);的事情来让std :: thread从另一个线程执行函数，这似乎在QThread中是不可能的.

First I wanted to use QThread, but it seems to me that QThread does not allow you to do as many things as std::thread, for instance, while reading "C++ Concurrency in Action" by Anthony Williams, I saw that it was possible to ask a std::thread to execute a function from another thread by doing something like std::thread t1(&Class::function, this, ...); which does not seem to be possible with QThread.

我最想拥有的机制是一种说出是否要在当前线程或另一个线程中执行函数的方式.

您会选择哪个，为什么?

Which one would you choose to do that and why ?

推荐答案

QThread不仅是线程，还是线程管理器.如果您想让您的线程播放Qt，那么QThread是您的理想选择.与大多数现代编程一样，Qt是事件驱动的.这比使一个线程运行一个函数"更加复杂和灵活.

QThread is not just a thread, it is also a thread manager. If you want your thread to play Qt, then QThread is the way to go. Qt is event driven, as is most of modern programming. That's a little more complex and flexible than "make a thread run a function".

在Qt中，通常会与QThread一起创建一个工作程序，将该工作程序移至该线程，然后事件系统为该工作程序对象调用的每个函数都将在该工作程序对象具有亲和力的线程中执行到.

In Qt, you'd typically create a worker together with a QThread, move the worker to that thread, then every function invoked by the event system for that worker object will be executed in the thread the worker object has affinity to.

因此，您可以将功能封装在不同的工作程序对象中，例如SafetyChecker，Printer，ServoDriver，JetDriver等，创建每个的实例，将其移至专用线程，然后进行设置.您仍然可以调用将阻塞"的函数，而不使用细粒度的事件，并使用原子或互斥锁进行线程间同步.只要您不阻塞main/gui线程，这没什么问题.

So you can encapsulate your functionality in different worker object, say SafetyChecker, Printer, ServoDriver, JetDriver and so on, create an instance of each, move it to a dedicated thread and you are set. You still can invoke functions that would "block" instead of using fine grained events, and use atomics or mutexes to do inter-thread synchronization. There is nothing wrong with that, as long as you don't block the main/gui thread.

您可能不希望您的打印机代码受事件驱动，因为在涉及排队连接的多线程方案中，这比直接连接甚至虚拟调度要慢一些.如此之多，以至于如果您使多线程的粒度过细，您实际上可能会遇到巨大的性能损失.

You would probably not want to do your printer code event driven, since in a multithreaded scenario that would involve queued connections, which are marginally slower than direct connections or even virtual dispatch. So much so that if you make your multithreading too fine grained, you are likely to actually experience a huge performance hit.

话虽这么说，使用Qt的non-gui东西有其自身的优点，它可以使您更简洁，更灵活的设计变得更加容易，并且如果正确实现事情，您仍将获得多线程的好处.您仍然可以使用事件驱动的方法来管理整个事情，这将比仅使用std::thread(这是一个低得多的结构)要容易得多.您可以使用事件驱动的方法来设置，配置，监视和管理设计，而关键部分则可以在辅助线程的阻塞功能中执行，从而以尽可能低的同步开销实现细粒度的控制.

That being said, using Qt's non-gui stuff has its own merits, it will allow you to make a cleaner and more flexible design much easier, and you will still get the benefits of multithreading if you implement things properly. You can still use an event driven approach to manage the whole thing, it will be significantly easier than using only std::thread, which is a much lower level construct. You can use event driven approach to setting up, configuring, monitoring and managing the design, while the critical parts can be executed in blocking functions in auxiliary threads to achieve fine grained control at the lowest possible synchronization overhead.

为了澄清-答案并不专注于异步任务的执行，因为其他两个答案已经存在，并且正如我在评论中所提到的，异步任务并不是真正针对控制应用程序的.它们适合执行小任务，这些小任务仍然比您要阻塞主线程花费更多的时间.作为推荐的准则，所有花费25毫秒以上的时间最好以异步方式执行.而打印可能要花几分钟甚至几小时，这意味着要并行，同步地连续运行控制功能.异步任务不会为您提供控制应用程序的性能，延迟和顺序保证.

To clarify - the answer does not focus on async task execution, because the other two answers already do, and because as I mentioned in the comments, async tasks are not really intended for control applications. They are suited to the execution of small tasks, which still take more time than you'd want to block the main thread for. As a recommended guideline, everything that takes more than 25 msec is preferable to be executed async. Whereas printing is something that may take minutes or even hours, and imply continuously running control functions, in parallel and using synchronization. Async tasks won't give you the performance, latency and order guarantees for control applications.

这篇关于QThread vs std :: thread的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！