Is Qt QBuffer thread safe?

Question

I am using QBuffer in ReadWrite mode. One working QThread pushes data into the buffer, and another QThread reads from it.

Does QBuffer provide thread safety or do I need to get from QBuffer and add mutex stuff?

Answer 1

To quote the Mark Summerfield program C ++ GUI Programming with Qt 4:

Qt thread safe classes include QMutex, QMutexLocker, QReadWriteLock, QReadLocker, QWriteLocker, QSemaphore, QThreadStorage, and QWaitCondition. In addition, parts of the QThread API and several other functions are thread safe, especially QObject :: connect (), QObject :: disconnect (), QCoreApplication :: postEvent (), and QCoreApplication :: removePostedEvents ().

Qt expects you to use locking mechanisms in most of its classes. The docs will say, "All functions are thread safe," if any, and individual functions will also indicate "thread safe."

Qt Class Notes

Many Qt classes are reentrant, but they are not made thread-safe, because to ensure their thread safety there is additional overhead for repeatedly locking and unlocking QMutex. For example, QString is reentrant, but not thread safe. You can safely access different QString instances from several threads at the same time, but you cannot safely access the same QString instance from several streams at the same time (if you do not protect it gets access to QMutex).

Some classes and functions of Qt are thread safe. These are mainly thread-related classes (e.g. QMutex) and core functions (e.g. QCoreApplication :: postEvent ()).

Since QBuffer is a direct subclass of QIODevice , I would especially expect it to not be thread safe, but there are container classes that are thread safe for read access, but a write lock requires a lock:

Container classes

Container classes are implicitly separated, they are reentrant, and they are optimized for speed, low memory consumption, and minimal extension of embedded code, resulting in smaller executable files. In addition, they are thread safe in situations where they are used as readable containers by all the threads used to access them.

Answer 2

QBuffer is not the best way to communicate between threads, since writing to it increases the buffer, but reading from it does not delete the data at the beginning.

Instead, you can use a signal / slot with the QByteArray parameter, use a QLocalSocket or write a ring buffer buffer class derived from QIODevice yourself.

Answer 3

This extends QIODevice, and the documentation says that all QIODevice methods are reentrant, but do not indicate thread safety. Given that QBuffer does not mention anything, I expect QBuffer to not be thread safe.

http://qt-project.org/doc/qt-4.8/qiodevice.html

Answer 4

The easiest way to communicate between threads in Qt is to place events in another thread's event queue. This suggests that another thread rotates the event loop. It only needs to be rotated periodically when you usually check for new data, etc.

Answer 5

As several other authors have noted, QBuffer is an inappropriate tool to work with, regardless of thread safety issues.

Is there an in-process local channel inside Qt? describes a QIODevice-based FIFO queue that would be more suitable for the intended purpose (although it does not include any thread safety mechanism)