从不同线程中的 QFile 读取

Posted 2023-02-16

【中文标题】从不同线程中的 QFile 读取

【英文标题】：Reading from a QFile in different thread

【发布时间】：2016-08-30 11:54:22

【问题描述】：

从与我想要读取的线程不同的线程中读取QFile 的最佳方式是什么？

考虑：

class AFile : public QObject

    Q_OBJECT
public:
    AFile(const QString &name, QObject *parent = Q_NULLPTR) : QObject(parent), m_File(name)  m_File.open(QIODevice::ReadWrite); 

public slots:
    void write(const QByteArray &data, qint64 pos)  m_File.seek(pos); m_File.write(data); 

private:
    mutable QFile m_File;
;

class AData : public QObject

    Q_OBJECT
public:
    using QObject::QObject;

    void save(const QByteArray &data)  emit saveData(data, 0); 

signals:
    void saveData(const QByteArray &data, qint64 pos) const;
;

AFile file("myfile");
AData data;
QThread *thread = new QThread;

connect(&data, &AData::saveData, &file, &AFile::write);

file.moveToThread(&thread);
thread.start();
data.save("Some data");

//how to concurrently read though?

AFile 是QFile 的包装器，用于处理对文件的所有写入。它被移动到不同的线程，以免因昂贵的磁盘写入操作而减慢主线程的速度。多线程读取情况由锁或互斥锁处理，但这会首先破坏将文件放在不同线程中的目的，因为主线程（想要从中读取）将不得不等待写入完成所以在这种情况下，我可以将它留在主线程中。

我不太喜欢的选项是信号和插槽，因为在我看来它有点重。我基本上会发送一个数据请求并等待它被读取（通过信号返回数据或发送变量以填充数据并等待它已经完成的信号）。

经过一番考虑，这似乎是最好的方法，但我不确定这是一个好的设计。

【问题讨论】：

写入文件真的会减慢您的应用程序的速度吗？我希望操作系统缓存它们，除非您强制使用某种同步模式。我是否也正确理解您想要在不同步的情况下独立读取和写入文件？我假设您正在阅读和写作的不同部分。然后你可以简单地打开文件两次，一次读取，一次写入。

@michalsrb 从 GUI 线程执行的所有同步 I/O 是可用性问题和 GUI 挂起的主要原因 - 从事件循环驱动的 UI API 的第一天开始就是如此。这就是通用 Windows 平台等现代 API 主要使用异步 API 的原因：如果 UI 阻塞等待任何 I/O，您会给用户带来糟糕的体验。

【参考方案1】：

并发读取是通过拆分请求和指示部分来完成的：您首先请求数据，读取器读取它，然后您对读取数据的指示做出反应。

由于文件对象是从工作线程访问的，因此我将其封装在AData 类中。您可以将类移动到工作线程，您从外部调用的信号是线程安全的。

也应该可以围绕 QFile 创建一个异步包装器，但正确执行此操作需要使用 Qt 的实现细节（core_private 模块）。

// https://github.com/KubaO/***n/tree/master/questions/async-file-io-39226814
#include <QtWidgets>

class AData : public QObject

    Q_OBJECT
    QFile m_file;
public:
    explicit AData(QObject * parent = nullptr) : QObjectparent 
        connect(this, &AData::save, this, [=](const QByteArray & data, qint64 pos)
            m_file.seek(pos);
            m_file.write(data);
        );
        connect(this, &AData::load, this, [=](qint64 pos, qint64 len)
           m_file.seek(pos);
           if (len == -1) len = m_file.size();
           auto data = m_file.read(len);
           emit loaded(data, pos);
        );
    
    bool open(const QString & name) 
        m_file.setFileName(name);
        return m_file.open(QIODevice::ReadWrite);
    
    Q_SIGNAL void save(const QByteArray &data, qint64 pos = 0) const;
    Q_SIGNAL void load(qint64 pos, qint64 len) const;
    Q_SIGNAL void loaded(const QByteArray &data, qint64 pos) const;
;

一个测试 UI 演示了如何使用它：

int main(int argc, char ** argv) 
    QApplication appargc, argv;
    struct Thread : QThread 
        ~Thread()  quit(); wait(); 
     ioThread;
    AData data;
    data.open("myfile");
    data.moveToThread(&ioThread);
    ioThread.start();

    QWidget ui;
    QGridLayout layout&ui;
    QTextEdit text;
    QPushButton load"Load";
    QPushButton save"Save";
    QPushButton clear"Clear";
    layout.addWidget(&text, 0, 0, 1, 2);
    layout.addWidget(&load, 1, 0);
    layout.addWidget(&save, 1, 1);
    layout.addWidget(&clear, 2, 0, 1, 2);
    ui.show();

    using Q = QObject;
    Q::connect(&load, &QPushButton::clicked, &data, [&]
        data.load(0, -1);
    );
    Q::connect(&data, &AData::loaded, &app, [&](const QByteArray & data, qint64)
       text.setPlainText(QString::fromUtf8(data));
    );
    Q::connect(&save, &QPushButton::clicked, &data, [&]
        data.save(text.document()->toPlainText().toUtf8());
    );
    Q::connect(&clear, &QPushButton::clicked, &text, &QTextEdit::clear);

    return app.exec();

#include "main.moc"

【讨论】：

这非常简洁！不过我有一个问题，这种使用 QtConcurrent 不会引入竞争条件吗？假设 write 正在执行并由 QtConcurrent 分派到某个线程。在它完成之前，读取已调度并发送到相同的位置。会发生什么？ QtConcurrent 是否以某种方式防范这种情况？据我了解，m_File 是这里的共享资源。

这是一个共享资源，我不确定QFile 是否能够抵御此类访问。可以确保一次只执行一个访问，我稍后会编辑它。

我已经尝试过了，它对它没有弹性。为了解决它，我首先尝试锁定，但最终返回不使用 QtConcurrent 并将包装器移动到单个其他线程，因为这样它不会减慢主（GUI）线程并且没有“锁定”开销，因为它保证所有访问都不会并行，因为它们都在单线程中执行。不过，我期待您的解决方案（可能比我的更好:-)）。

谢天谢地，从线程池切换到专用线程所需的修改很少。