Question

I know that we can’t use GUI-interaction in non-GUI threads (QThread).
But I don’t know if we can or can’t interact with model (QAbstractItemModel) in threads and if True then how to do it in the right way?

I honestly searched something about this in Google and on SO and it seems like there are no relevant answers to my question.

Answer 1

What do you mean by “interact with model”? If you mean that you want to access the model from multiple threads by directly manipulating it, then you have to serialize the access to the model. Since there are so many methods within the model, I’d suggest you do not add a mutex within the model — it’d be very tedious and error prone as it’d be too easy to forget a mutex locker. Instead, use the fact that your model inherits QObject, and thus can accept events.

1. Your gui thread accesses the model directly.
2. Other threads interact with the model by posting events to it (and perhaps receiving reply events).
3. The gui thread will process those events serially with any other access, thus protecting your model from concurrent access.

Other threads can of course receive replies from the model — also via events. You’d have two event base classes: a Request class that is used to request things from the model, and then there’d be a Response event base class that the model would use to reply. The Request class should have a QObject* sender member, so that the model would know what QObject to post the reply event to. You’d probably want both the request and reply to carry identical identifier (say a serially increment int), so that requests and responses could be matched up.

You must implement all the threaded code that interacts with the model via events not by reimplementing QThread::run(), but within a QObject. After you instantiate the QObject, simply move it to a separate thread. QThread’s default implementation of run() will spin an event loop to keep your QObject executing if there are any events, signals or timers ready for it. A zero-duration timer is a way of keeping a thread permanently busy, but make sure you don’t do too much processing in one go, otherwise you’ll delay processing of incoming events.

You can also use signals and slots, but you cannot call them directly, you can only:

1. connect() to them,
2. invoke them via QMetaObject::invokeMethod with Qt::QueuedConnection.
3. invoke them through a functor (say, a lambda) executed in the main thread context; see this answer for how to do that.

Behind the scenes, when you connect signals to slots of QObjects that reside in separate threads, Qt creates a connection that marshals each signal into a QMetaCallEvent, and then unmarshals it in the thread where the QObject with target slot lives.