moveToThread(this)

Because a QThread is a QObject, and we create QThread when an additional thread for processing is needed, it is understandable that we might think of one as representing the other. However, the additional thread is not actually created until QThread::exec() is called, which confuses the issue.

Recall that each QThread, by virtue of being a QObject, has an affinity to its creating thread, rather than the one that it started.

It is for this reason that some people say a QThread is not the thread itself, but rather, a manager of that thread. It might help you to think of it that way also. In effect, the QThread is a wrapper for an underlying thread API and also serves to manage a single thread via an API that is based on java.lang.thread.

This implies that when signals are connected to slots of this QThread, the processing of the slot is done in the creating thread, not in the managed thread.

Some programs have changed the definition of QThread, so that it represents the thread that it manages, and executes its slots in its managed thread. Such programs use a workaround: moveToThread(this) from the QThread's constructor.

This article discusses the issue in more detail and says that even though the documentation and some of older examples from Qt itself use this, it is no longer recommended. For one thing, it is undefined what happens to events and signals when the managed thread terminates. For another, it mixes the purpose of QThread with QRunnable and puts too much responsibility on a single class.

"volatile correctness"

volatile, like const, can be used by the compiler to enforce a certain degree of "thread safety" in your program. When an object is volatile, only methods marked volatile can be called on it. volatile is used in Qt to implement some atomic operations, which in turn are used to implement higher-level locking structures such as QMutex, QSharedPointer, and QReadWriteLock. More info about volatile can be found in the following two articles.