QThread 使用探讨

QThread 使用探讨

2010-10-23 00:30

注意：本文停止更新，请优先考虑 Qt 线程基础(QThread、QtConcurrent等) dbzhang800 2011.06.18 QThread 似乎是很难的一个东西，特别是信号和槽，有非常多的人(尽管使用者本人往往不知道)在用不恰当(甚至错误)的方式在使用 QThread，随便用google一搜，就能搜出大量结果出来。无怪乎Qt的开发人员 Bradley T. Hughes 声嘶力竭地喊you are-doing-it-wrong 和众多用户一样，初次看到这个时，感到 Bradley T. Hughes有 些莫名奇妙，小题大作。尽管不舒服，当时还是整理过一篇博客QThread 的使用方法 时间过去3个月，尽管依然没怎么用thread；但今天csdn论坛中有人问到这个问题，想想还是尽我所能整理一下吧。提升自己，方便他人，何乐而不为呢? QThread东西还是比较多的，而且我对底层对象了解有限，仅就一点进行展开(或许是大家最关心的一点)：QThread中的slots在那个线程中执行？ QThread::run run 函数是做什么用的？Manual中说的清楚： run 对于线程的作用相当于main函数对于应用程序。它是线程的入口，run的开始和结束意味着线程的开始和结束。 原文如下(这段话我们称为定理一吧)： The run() implementation is for a thread what the main() entry point is for the application. All code executed in a call stack that starts in the run() function is executed by the new thread, and the thread finishes when the function returns. 这么短的文字一眼就看完了，可是，这是什么意思呢？又能说明什么问题呢？看段简单代码： class Thread:public QThread { Q_OBJECT public: Thread(QObject* parent=0):QThread(parent){} public slots: void slot() { ... } signals: void sig(); protected: void run() { ...} }; int main(int argc, char** argv) { ... Thread thread; ... } 对照前面的定理，run函数中的代码时确定无疑要在次线程中运行的，那么其他的呢？比如 slot 是在次线程还是主线程中运行？ 你想说主线程，但又心有不甘，对么？ QObject::connect 涉及信号槽，我们就躲不过 connect 函数，只是这个函数大家太熟悉。我不好意思再用一堆废话来描述它，但不说又不行，那么折中一下，只看它的最后一个参数吧(为了简单起见，只看它最常用的3个值) 下面的列表，我们暂称为定理二: 自动连接(Auto Connection) 这是默认设置 如果信号在接收者所依附的线程内发射，则等同于直接连接 如果发射信号的线程和接受者所依附的线程不同，则等同于队列连接 也就是这说，只存在下面两种情况 直接连接(Direct Connection) 当信号发射时，槽函数将直接被调用。 无论槽函数所属对象在哪个线程，槽函数都在发射信号的线程内执行。 队列连接(Queued Connection) 当控制权回到接受者所依附线程的事件循环时，槽函数被调用。 槽函数在接收者所依附线程执行。 同前面一样，这些文字大家都能看懂。但含义呢？ 不妨继续拿前面的例子来看，slot 函数是在主线程还是次线程中执行呢？ 定理二强调两个概念：发送信号的线程 和 接收者所依附的线程。而 slot 函数属于我们在main中创建的对象 thread，即thread依附于主线程 队列连接告诉我们：槽函数在接受者所依附线程执行。即 slot 将在主线程执行 直接连接告诉我们：槽函数在发送信号的线程执行。信号在那个线程发送呢？？不定！ 自动连接告诉我们：二者不同，等同于队列连接。即 slot 在主线程执行 太绕了？不是么（要彻底理解这几句话，你可能需要看Qt meta-object系统和Qt event系统） 怎么办呢？ 如果上两节看不懂，就记住下面的话吧（自己总结的，用词上估计会不太准确）。 QThread 是用来管理线程的，它所依附的线程和它管理的线程并不是同一个东西 QThread 所依附的线程，就是执行 QThread t(0) 或 QThread * t=new QThread(0) 的线程。也就是咱们这儿的主线程 QThread 管理的线程，就是 run 启动的线程。也就是次线程 因为QThread的对象依附在主线程中，所以他的slot函数会在主线程中执行，而不是次线程。除非： QThread 对象依附到次线程中(通过movetoThread) slot 和信号是直接连接，且信号在次线程中发射 但上两种解决方法都不好，因为QThread不是这么用的(Bradley T. Hughes) 好了，不再添加更多文字了，看代码，估计咱们都会轻松点 主线程(信号)QThread(槽) 这是 Qt Manual 和 例子中普遍采用的方法。 但由于manual没说槽函数是在主线程执行的，所以不少人都认为它应该是在次线程执行了。 定义一个 Dummy 类，用来发信号 定义一个 Thread 类，用来接收信号 重载 run 函数，目的是打印 threadid /*! * \file main.cpp * * Copyright (C) 2010, dbzhang800 * All rights reserved. * */ #include /QCoreApplication> #include /QObject> #include /QThread> #include /QDebug> class Dummy:public QObject { Q_OBJECT public: Dummy(){} public slots: void emitsig() { emit sig(); } signals: void sig(); }; class Thread:public QThread { Q_OBJECT public: Thread(QObject* parent=0):QThread(parent) { //moveToThread(this); } public slots: void slot_main() { qDebug()<<"from thread slot_main:" < protected: void run() { qDebug()<<"thread thread:"<#include "main.moc" int main(int argc, char *argv[]) {   QCoreApplication a(argc, argv); qDebug()<<"main thread:"<thread; Dummy dummy; QObject::connect(&dummy, SIGNAL(sig()), &thread, SLOT(slot_main())); thread.start(); dummy.emitsig(); return a.exec(); } 然后看到结果(具体值每次都变，但结论不变) main thread: 0x1a40 from thread slot_main: 0x1a40 thread thread: 0x1a48 看到了吧，槽函数的线程和主线程是一样的！ 如果你看过Qt自带的例子，你会发现 QThread 中 slot 和 run 函数共同操作的对象，都会用QMutex锁住。为什么？ 因为slot和run处于不同线程，需要线程间的同步！ 如果想让槽函数slot在次线程运行(比如它执行耗时的操作，会让主线程死掉)，怎么解决呢？ 注意：dummy信号是在主线程发射的， 接收者 thread 也在主线程中。 参考我们前面的结论，很容易想到: 将 thread 依附的线程改为次线程不就行了？ 这也是代码中注释掉的 moveToThread(this)所做的，去掉注释，你会发现slot在次线程中运行 main thread: 0x13c0 thread thread: 0x1de0 from thread slot_main: 0x1de0 这可以工作，但这是 Bradley T. Hughes 强烈批判的用法。推荐的方法后面会给出。 run中信号与QThread中槽 定义一个 Dummy 类，在run中发射它的信号 也可以在run中发射 Thread 类中的信号，而不是Dummy（效果完全一样） QThread 定义槽函数，重载run函数 /*! * \file main.cpp * * Copyright (C) 2010, dbzhang800 * All rights reserved. * */ #include /QCoreApplication> #include /QObject> #include /QThread> #include /QDebug> class Dummy:public QObject { Q_OBJECT public: Dummy(QObject* parent=0):QObject(parent){} public slots: void emitsig() { emit sig(); } signals: void sig(); }; class Thread:public QThread { Q_OBJECT public: Thread(QObject* parent=0):QThread(parent) { //moveToThread(this); } public slots: void slot_thread() { qDebug()<<"from thread slot_thread:" <void sig(); protected: void run() { qDebug()<<"thread thread:"<this, SLOT(slot_thread())); dummy.emitsig(); exec(); } }; #include "main.moc" int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); qDebug()<<"main thread:"<thread; thread.start(); return a.exec(); } 想看结果么？ main thread: 0x15c0 thread thread: 0x1750 from thread slot_thread: 0x15c0 其实没悬念，肯定是主线程 thread 对象本身在主线程。所以它的槽也在要在主线程执行 如何解决呢？ （方法一）前面提了 moveToThread,这儿可以用，而且可以解决问题。当同样，是被批判的对象。 （方法二）注意哦，这儿我们的信号时次线程发出的，对比connect连接方式，会发现： 采用直接连接，槽函数将在次线程(信号发出的线程)执行 这个方法不太好，因为你需要处理slot和它的对象所在线程的同步。需要 QMutex 一类的东西 推荐的方法 千呼万唤始出来。 其实，这个方法太简单，太好用了。定义一个普通的QObject派生类，然后将其对象move到QThread中。使用信号和槽时根本不用考虑多线程的存在。也不用使用QMutex来进行同步，Qt的事件循环会自己自动处理好这个。 /*! * \file main.cpp * * Copyright (C) 2010, dbzhang800 * All rights reserved. * */ #include /QCoreApplication> #include /QObject> #include /QThread> #include /QDebug> class Dummy:public QObject { Q_OBJECT public: Dummy(QObject* parent=0):QObject(parent) {} public slots: void emitsig() { emit sig(); } signals: void sig(); }; class Object:public QObject { Q_OBJECT public: Object(){} public slots: void slot() { qDebug()<<"from thread slot:" < #include "main.moc" int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); qDebug()<<"main thread:"<thread; Object obj; Dummy dummy; obj.moveToThread(&thread); QObject::connect(&dummy, SIGNAL(sig()), &obj, SLOT(slot())); thread.start(); dummy.emitsig(); return a.exec(); } 结果：恩，slot确实不在主线程中运行（这么简单不值得欢呼么？） main thread: 0x1a5c from thread slot: 0x186c 其他 本文只考虑了使用事件循环的情况，也有可能run中没有事件循环。这时信号与槽会与本文有点差别。比如run中使用connect时，队列连接就受限制了。其实只要理解了前面这些，没有事件循环的情况很容易就想通了。

Qt 线程基础(QThread、QtConcurrent等)

使用线程

基本上有种使用线程的场合：

• 通过利用处理器的多个核使处理速度更快。
• 为保持GUI线程或其他高实时性线程的响应，将耗时的操作或阻塞的调用移到其他线程。

何时使用其他技术替代线程

开发人员使用线程时需要非常小心。启动线程是很容易的，但确保所有共享数据保持一致很难。遇到问题往往很难解决，这是由于在一段时间内它可能只出现一次或只在特定的硬件配置下出现。在创建线程来解决某些问题之前，应该考虑一些替代的技术 ：

替代技术	注解
QEventLoop::processEvents()	在一个耗时的计算操作中反复调用QEventLoop::processEvents() 可以防止界面的假死。尽管如此，这个方案可伸缩性并不太好，因为该函数可能会被调用地过于频繁或者不够频繁。
QTimer	后台处理操作有时可以方便地使用Timer安排在一个在未来的某一时刻执行的槽中来完成。在没有其他事件需要处理时，时间隔为0的定时器超时事件被相应
QSocketNotifier  QNetworkAccessManager  QIODevice::readyRead()	这是一个替代技术，替代有一个或多个线程在慢速网络执行阻塞读的情况。只要响应部分的计算可以快速执行，这种设计比在线程中实现的同步等待更好。与线程相比这种设计更不容易出错且更节能(energy efficient)。在许多情况下也有性能优势。

一般情况下，建议只使用安全和经过测试的方案而避免引入特设线程的概念。QtConcurrent 提供了一个将任务分发到处理器所有的核的易用接口。线程代码完全被隐藏在 QtConcurrent 框架下，所以你不必考虑细节。尽管如此，QtConcurrent 不能用于线程运行时需要通信的情况，而且它也不应该被用来处理阻塞操作。

应该使用 Qt 线程的哪种技术？

有时候，你需要的不仅仅是在另一线程的上下文中运行一个函数。您可能需要有一个生存在另一个线程中的对象来为GUI线程提供服务。也许你想在另一个始终运行的线程中来轮询硬件端口并在有关注的事情发生时发送信号到GUI线程。Qt为开发多线程应用程序提供了多种不同的解决方案。解决方案的选择依赖于新线程的目的以及线程的生命周期。

生命周期	开发任务	解决方案
一次调用	在另一个线程中运行一个函数，函数完成时退出线程	编写函数，使用QtConcurrent::run 运行它
		派生QRunnable，使用QThreadPool::globalInstance()->start() 运行它
		派生QThread，重新实现QThread::run() ，使用QThread::start() 运行它
一次调用	需要操作一个容器中所有的项。使用处理器所有可用的核心。一个常见的例子是从图像列表生成缩略图。	QtConcurrent 提供了map()函你数来将操作应用到容器中的每一个元素，提供了fitler()函数来选择容器元素，以及指定reduce函数作为选项来组合剩余元素。
一次调用	一个耗时运行的操作需要放入另一个线程。在处理过程中，状态信息需要发送会GUI线程。	使用QThread，重新实现run函数并根据需要发送信号。使用信号槽的queued连接方式将信号连接到GUI线程的槽函数。
持久运行	生存在另一个线程中的对象，根据要求需要执行不同的任务。这意味着工作线程需要双向的通讯。	派生一个QObject对象并实现需要的信号和槽，将对象移动到一个运行有事件循环的线程中并通过queued方式连接的信号槽进行通讯。
持久运行	生存在另一个线程中的对象，执行诸如轮询端口等重复的任务并与GUI线程通讯。	同上，但是在工作线程中使用一个定时器来轮询。尽管如此，处理轮询的最好的解决方案是彻底避免它。有时QSocketNotifer是一个替代。

Qt线程基础

QThread是一个非常便利的跨平台的对平台原生线程的抽象。启动一个线程是很简单的。让我们看一个简短的代码：生成一个在线程内输出"hello"并退出的线程。

 // hellothread/hellothread.h
 class HelloThread : public QThread
 {
     Q_OBJECT
 private:
     void run();
 };

我们从QThread派生出一个类，并重新实现run方法。

 // hellothread/hellothread.cpp
 void HelloThread::run()
 {
      qDebug() << "hello from worker thread " << thread()->currentThreadId();
 }

run方法中包含将在另一个线程中运行的代码。在本例中，一个包含线程ID的消息被打印出来。  QThread::start()将在另一个线程中被调用。

 int main(int argc, char *argv[])
 {
     QCoreApplication app(argc, argv);
     HelloThread thread;
     thread.start();
     qDebug() << "hello from GUI thread " << app.thread()->currentThreadId();
     thread.wait();  // do not exit before the thread is completed!
     return 0;
 }

QObject与线程

QObject有线程关联(thread affinity)[如何翻译？关联？依附性？dbzhang800 20110618]，换句话说，它生存于一个特定的线程。这意味着，在创建时QObject保存了到当前线程的指针。当事件使用postEvent()被派发时，这个信息变得很有用。事件被放置到相应线程的事件循环中。如果QObject所依附的线程没有事件循环，该事件将永远不会被传递。

要启动事件循环，必须在run()内调用exec()。线程关联可以通过moveToThread()来更改。

如上所述，当从其他线程调用对象的方法时开发人员必须始终保持谨慎。线程关联不会改变这种状况。 Qt文档中将一些方法标记为线程安全。postEvent()就是一个值得注意的例子。一个线程安全的方法可以同时在不同的线程被调用。

通常情况下并不会并发访问的一些方法，在其他线程调用对象的非线程安全的方法在出现造成意想不到行为的并发访问前数千次的访问可能都是工作正常的。编写测试代码不能完全确保线程的正确性，但它仍然是重要的。在Linux上，Valgrind和Helgrind有助于检测线程错误。

QThread的内部结构非常有趣：

• QThread并不生存于执行run()的新线程内。它生存于旧线程中。
• QThread的大多数成员方法是线程的控制接口，并设计成从旧线程中被调用。不要使用moveToThread()将该接口移动到新创建的线程中；调用moveToThread(this)被视为不好的实践。
• exec()和静态方法usleep()、msleep()、sleep()要在新创建的线程中调用。
• QThread子类中定义的其他成员可在两个线程中访问。开发人员负责访问的控制。一个典型的策略是在start()被调用前设置成员变量。一旦工作线程开始运行，主线程不应该操作其他成员。当工作线程终止后，主线程可以再次访问其他成员。这是一个在线程开始前传递参数并在结束后收集结果的便捷的策略。

QObject必须始终和parent在同一个线程。对于在run()中生成的对象这儿有一个惊人的后果：

 void HelloThread::run()
 {
      QObject *object1 = new QObject(this);  //error, parent must be in the same thread
      QObject object2;  // OK
      QSharedPointer  object3(new QObject); // OK
 }

使用互斥量保护数据的完整

互斥量是一个拥有lock()和unlock()方法并记住它是否已被锁定的对象。互斥量被设计为从多个线程调用。如果信号量未被锁定lock()将立即返回。下一次从另一个线程调用会发现该信号量处于锁定状态，然后lock()会阻塞线程直到其他线程调用unlock()。此功能可以确保代码段将在同一时间只能由一个线程执行。

使用事件循环防止数据破坏

Qt的事件循环对线程间的通信是一个非常有价值的工具。每个线程都可以有它自己的事件循环。在另一个线程中调用一个槽的一个安全的方法是将调用放置到另一个线程的事件循环中。这可以确保目标对象调用另一个的成员函数之前可以完成当前正在运行的成员函数。

那么，如何才能把一个成员调用放于一个事件循环中？ Qt的有两种方法来做这个。一种方法是通过queued信号槽连接；另一种是使用QCoreApplication::postEvent()派发一个事件。queued的信号槽连接是异步执行的信号槽连接。内部实现是基于posted的事件。信号的参数放入事件循环后信号函数的调用将立即返回。

连接的槽函数何时被执行依赖于事件循环其他的其他操作。

通过事件循环通信消除了我们使用互斥量时所面临的死锁问题。这就是我们为什么推荐使用事件循环，而不是使用互斥量锁定对象的原因。

处理异步执行

一种获得一个工作线程的结果的方法是等待线程终止。在许多情况下，一个阻塞等待是不可接受的。阻塞等待的替代方法是异步的结果通过posted事件或者queued信号槽进行传递。由于操作的结果不会出现在源代码的下一行而是在位于源文件其他部分的一个槽中，这会产生一定的开销，因为，但在位于源文件中其他地方的槽。 Qt开发人员习惯于使用这种异步行为工作，因为它非常相似于GUI程序中使用的的事件驱动编程。