QT thread学习2

Choosing between using `QThreadPool` and `QThread`

Qt框架提供了许多用于多线程的工具。一开始选择正确的工具可能很有挑战性，但实际上，决策树只包含两个选项:您希望Qt为您管理线程，或者您希望自己管理线程。然而，还有其他重要的标准:

1、不需要事件循环的任务。具体来说，就是在任务执行过程中不使用信号/槽机制的任务。

使用:QtConcurrent和QThreadPool + QRunnable。

2、使用信号/槽的任务，因此需要事件循环。

使用:Worker对象移动到 + QThread。

Qt框架的巨大灵活性允许你解决“缺少事件循环”的问题，并添加一个到QRunnable:

class MyTask : public QObject, public QRunnable
{
    Q_OBJECT
    
public:
    void MyTask::run() {
        _loop.exec();  
    }
    
public slots:
    // you need a signal connected to this slot to exit the loop,
    // otherwise the thread running the loop would remain blocked...
    void finishTask() {
        _loop.exit();
    }
    
private:
    QEventLoop _loop;
}

但是，要尽量避免这种“变通方法”，因为这很危险，而且效率不高:如果线程池中的一个线程(运行MyTask)由于等待信号而被阻塞，那么它就不能执行池中的其他任务。

你也可以通过重写QThread::run()方法在不发生任何事件循环的情况下运行QThread，只要你知道你在做什么，这是完全可以的。例如，不要期望方法quit()在这种情况下工作。

Running one task instance at a time

假设您需要确保一次只能执行一个任务实例，并且运行同一任务的所有挂起请求都在某个队列上等待。当任务正在访问独占资源时，例如写入相同的文件或使用TCP套接字发送数据包时，通常需要这样做。

让我们暂时忘记计算机科学和生产者-消费者模式，考虑一些琐碎的事情; 在真正的项目中很容易找到的东西。

这个问题的一个原语解决方案可以使用QMutex。在任务函数中，您可以简单地获取互斥量，有效地序列化所有试图运行任务的线程。这将保证一次只有一个线程可以运行该函数。但是，这个解决方案会引入高争用问题，从而影响性能，因为所有这些线程在可以继续进行之前都会被阻塞(在互斥对象上)。如果有许多线程在积极地使用这样的任务，并在其间做一些有用的工作，那么所有这些线程在大部分时间都将处于睡眠状态。

void logEvent(const QString & event) {  
    static QMutex lock;  
    QMutexLocker locker(& lock);   // high contention!  
    logStream << event;            // exclusive resource  
}

为了避免争用，我们需要一个队列和一个在自己的线程中处理该队列的worker。这是典型的生产者-消费者模式。 worker (consumer)将从队列中一个接一个地挑选请求，而每个producer可以简单地将其请求添加到队列中。一开始听起来很简单，你可能会想到使用QQueue和QWaitCondition，但是等一下，让我们看看我们是否可以在没有这些原语的情况下实现目标:

我们可以使用QThreadPool，因为它有一个挂起的任务队列

或

我们可以使用默认的QThread::run()，因为它有QEventLoop

第一个选项是使用QThreadPool。我们可以创建一个QThreadPool实例，并使用QThreadPool::setMaxThreadCount(1)。然后我们可以使用QtConcurrent::run()来调度请求:

class Logger: public QObject
{
public:
    explicit Logger(QObject *parent = nullptr) : QObject(parent) {
        threadPool.setMaxThreadCount(1);
    }

    void logEvent(const QString &event) {
        QtConcurrent::run(&threadPool, [this, event]{
            logEventCore(event);
        });
    }

private:
    void logEventCore(const QString &event) {
        logStream << event;
    }

    QThreadPool threadPool;
};

这个解决方案有一个好处:QThreadPool::clear()允许您立即取消所有挂起的请求，例如当您的应用程序需要快速关闭时。然而，连接到线程私有的logEventCore函数也有一个显著的缺点:从调用到调用，logEventCore函数可能会在不同的线程中执行。我们知道Qt有一些类需要线程关联:QTimer, QTcpSocket和其他一些类。

Qt规范中关于线程相关性的说明:定时器在一个线程中启动，不能在另一个线程中停止。只有拥有套接字实例的线程才能使用这个套接字。这意味着任何正在运行的线程中你必须停止启动它们的计时器，并且你必须在拥有该套接字的线程中调用QTcpSocket::close()。这两个例子通常都在析构函数中执行。

更好的解决方案依赖于使用QThread提供的QEventLoop。这个想法很简单:我们使用信号/槽机制来发出请求，并且线程内部运行的事件循环将作为一个队列，每次只允许执行一个槽。

// the worker that will be moved to a thread
class LogWorker: public QObject
{
    Q_OBJECT

public:
    explicit LogWorker(QObject *parent = nullptr);

public slots:
    // this slot will be executed by event loop (one call at a time)
    void logEvent(const QString &event);
};

LogWorker构造函数和logEvent的实现很简单，因此这里没有提供。现在我们需要一个服务来管理线程和worker实例:

// interface
class LogService : public QObject
{
    Q_OBJECT
    
public:
    explicit LogService(QObject *parent = nullptr);
    ~LogService();

signals:
    // to use the service, just call this signal to send a request:
    // logService->logEvent("event");
    void logEvent(const QString &event);

private:
    QThread *thread;
    LogWorker *worker;
};

// implementation
LogService::LogService(QObject *parent) : QObject(parent) {
    thread = new QThread(this);
    worker = new LogWorker;
    worker->moveToThread(thread);
    connect(this, &LogService::logEvent, worker, &LogWorker::logEvent);
    connect(thread, &QThread::finished, worker, &QObject::deleteLater);
    thread->start();
}

LogService::~LogService() {
    thread->quit();
    thread->wait();
}

让我们来讨论一下这段代码是如何工作的:

在构造函数中，我们创建了一个thread和worker实例。注意，worker没有接收父线程，因为它将被移动到新线程。因此，Qt不能自动释放worker的内存，因此，我们需要通过连接QThread::finished信号来实现这一点。我们还将代理方法LogService::logEvent()连接到LogWorker::logEvent()，因为不同的线程，LogWorker::logEvent()将使用Qt::QueuedConnection模式。
在析构函数中，我们将退出事件放入事件循环的队列中。此事件将在所有其他事件处理之后进行处理。例如，如果我们在调用析构函数之前调用了数百个logEvent()，日志记录器将在获取退出事件之前处理所有这些调用。当然，这需要时间，所以我们必须wait()直到事件循环退出。值得注意的是，退出事件之后发布的所有日志请求将永远不会被处理。
日志记录本身(LogWorker::logEvent)总是在同一个线程中完成，因此这种方法对于需要线程相关性的类来说工作得很好。同时，LogWorker构造函数和析构函数是在主线程中执行的(特别是运行LogService的线程)，因此，您需要非常小心在主线程中运行的是什么代码。特别地，不要在worker的析构函数中停止计时器或使用套接字，除非你可以在同一个线程中运行析构函数!

Executing worker’s destructor in the same thread

如果你的worker处理的是定时器或套接字，你需要确保析构函数在同一个线程中执行(你为worker创建的线程和你移动worker的线程)。最明显的支持方法是继承QThread并在QThread::run()方法中删除worker。考虑以下模板:

template <typename TWorker>
class Thread : QThread
{
public:
    explicit Thread(TWorker *worker, QObject *parent = nullptr)
        : QThread(parent), _worker(worker) {
        _worker->moveToThread(this);
        start();
    }

    ~Thread() {
        quit();
        wait();
    }

    TWorker worker() const {
        return _worker;
    }

protected:
    void run() override {
        QThread::run();
        delete _worker;
    }

private:
    TWorker *_worker;
};

使用这个模板，我们从前面的例子中重新定义LogService:

// interface
class LogService : public Thread<LogWorker>
{
    Q_OBJECT

public:
    explicit LogService(QObject *parent = nullptr);

signals:
    void **logEvent**(const QString &event);
};

// implementation
LogService::**LogService**(QObject *parent)
    : Thread<LogWorker>(new LogWorker, parent) {
    connect(this, &LogService::logEvent, worker(), &LogWorker::logEvent);
}

让我们来讨论一下这是如何工作的:

我们将LogService作为QThread对象，因为我们需要实现定制的run()函数。我们使用私有子类来防止访问QThread的函数，因为我们想要在内部控制线程的生命周期。
在Thread::run()函数中，我们通过调用默认的QThread::run()实现来运行事件循环，并在事件循环退出后立即销毁工作实例。注意worker的析构函数是在同一个线程中执行的。
LogService::logEvent()是一个代理函数(信号)，它将日志记录事件发布到线程的事件队列中。

Pausing and resuming the threads

另一个有趣的机会是能够暂停和恢复我们的定制线程。假设您的应用程序正在进行一些处理，当应用程序最小化、锁定或失去网络连接时，这些处理需要暂停。这可以通过构建一个自定义的异步队列来实现，该队列将保存所有挂起的请求，直到worker被恢复。然而，由于我们正在寻找最简单的解决方案，我们将(再次)使用事件循环的队列来实现同样的目的。

为了挂起一个线程，我们显然需要它在一个特定的等待条件下等待。如果线程以这种方式被阻塞，它的事件循环不会处理任何事件，Qt必须将keep放入队列中。一旦恢复，事件循环将处理所有累积的请求。对于等待条件，我们只需使用同样需要QMutex的QWaitCondition对象。为了设计一个可以被任何工作人员重用的通用解决方案，我们需要将所有挂起/恢复逻辑放到一个可重用的基类中。我们叫它SuspendableWorker。这样的类应该支持两个方法:

Suspend()是一个阻塞调用，它设置线程等待一个等待条件。这可以通过将一个挂起请求提交到队列中并等待它得到处理来实现。非常类似于QThread::quit() + wait()。
Resume()将向等待条件发出信号，以唤醒处于睡眠状态的线程继续执行。

让我们回顾一下接口和实现:

// interface
class SuspendableWorker : public QObject
{
    Q_OBJECT

public:
    explicit SuspendableWorker(QObject *parent = nullptr);
    ~SuspendableWorker();

    // resume() must be called from the outer thread.
    void resume();

    // suspend() must be called from the outer thread.
    // the function would block the caller's thread until
    // the worker thread is suspended.
    void suspend();

private slots:
    void suspendImpl();

private:
    QMutex _waitMutex;
    QWaitCondition _waitCondition;
};
// implementation
SuspendableWorker::SuspendableWorker(QObject *parent) : QObject(parent) {
    _waitMutex.lock();
}

SuspendableWorker::~SuspendableWorker() {
    _waitCondition.wakeAll();
    _waitMutex.unlock();
}

void SuspendableWorker::resume() {
    _waitCondition.wakeAll();
}

void SuspendableWorker::suspend() {
    QMetaObject::invokeMethod(this, &SuspendableWorker::suspendImpl);
    // acquiring mutex to block the calling thread
    _waitMutex.lock();
    _waitMutex.unlock();
}

void SuspendableWorker::suspendImpl() {
    _waitCondition.wait(&_waitMutex);
}

记住，挂起的线程永远不会收到退出事件。由于这个原因，我们不能在普通的QThread中安全地使用它，除非我们在发布退出之前恢复线程。让我们将其集成到自定义的Thread<T>模板中。

template <typename TWorker>
class Thread : QThread
{
public:
    explicit Thread(TWorker *worker, QObject *parent = nullptr)
        : QThread(parent), _worker(worker) {
        _worker->moveToThread(this);
        start();
    }

    ~Thread() {
        resume();
        quit();
        wait();
    }

    void suspend() {
        auto worker = qobject_cast<SuspendableWorker*>(_worker);
        if (worker != nullptr) {
            worker->suspend();
        }
    }

    void resume() {
        auto worker = qobject_cast<SuspendableWorker*>(_worker);
        if (worker != nullptr) {
            worker->resume();
        }
    }

    TWorker worker() const {
        return _worker;
    }

protected:
    void run() override {
        QThread::*run*();
        delete _worker;
    }

private:
    TWorker *_worker;
};

有了这些改变，我们将在发布退出事件之前恢复线程。另外，线程<TWorker>仍然允许传入任何类型的worker，无论它是否是一个SuspendableWorker。

用法如下:

LogService logService;
logService.logEvent("processed event");
logService.suspend();
logService.logEvent("queued event");
logService.resume();
// "queued event" is now processed.

volatile vs atomic

这是一个经常被误解的话题。大多数人认为，volatile变量可以用于为多个线程访问的某些标志提供服务，这样可以避免数据竞争条件。这是假的，QAtomic*类(或std::atomic)必须用于此目的。

让我们考虑一个现实的例子:一个TcpConnection连接类，它工作在一个专用的线程中，我们希望这个类导出一个线程安全的方法:bool isConnected()。在内部，类将监听套接字事件:connected和disconnected，以维护一个内部布尔值标志:

// pseudo-code, won't compile
class TcpConnection : QObject
{
    Q_OBJECT 

public:
    // this is not thread-safe!
    bool isConnected() const {
        return _connected;
    }
    
private slots:
    void handleSocketConnected() {
        _connected = true;
    }
    
    void handleSocketDisconnected() {
        _connected = false;
    }
    
private:
    bool _connected;
}

让_connected成员volatile不会解决这个问题，也不会让isConnected()成为线程安全的。这个方法在99%的情况下都有效，但是剩下的1%会让你的生活变成一场噩梦。要解决这个问题，我们需要保护变量访问不受多线程的影响。我们使用QReadWriteLocker来实现这个目的:

// pseudo-code, won't compile
class TcpConnection : QObject
{
    Q_OBJECT 

public:
    bool isConnected() const {
        QReadLocker locker(&_lock);
        return _connected;
    }
    
private slots:
    void handleSocketConnected() {
        QWriteLocker locker(&_lock);
        _connected = true;
    }
    
    void handleSocketDisconnected() {
        QWriteLocker locker(&_lock);
        _connected = false;
    }
    
private:
    QReadWriteLocker _lock;
    bool _connected;
}

这可以可靠地工作，但不如使用“无锁”原子操作快。第三种解决方案既快又线程安全(例子是使用std::atomic而不是QAtomicInt，但它们在语义上是相同的):

// pseudo-code, won't compile
class TcpConnection : QObject
{
    Q_OBJECT 

public:
    bool isConnected() const {
        return _connected;
    }
    
private slots:
    void handleSocketConnected() {
        _connected = true;
    }
    
    void handleSocketDisconnected() {
        _connected = false;
    }
    
private:
    std::atomic<bool> _connected;
}