Sharing huge object between threads

gav007

Hi,

I developed a GUi application managing a huge object (a control unit description). This is made of hundreds of sub-objects, themselves made of sub-objects, ... Finally the object is really really huge.

Every objects and sub-objects use Qt classes (mainly container classes).

A communication thread is added to the application, bringing the need to share the huge object. If the standard Qt mechanism of signals and slots is used, hundreds of signals and slots should be created.

Is there any other way to share Qt (meta) objects ?
Is it viable to move the object (and all its sub-objects) to the communication thread and then to move it back to the main thread at the end of the communication thread ? I'm not really confident in such a solution.

To be honest, if the answer is negative, I would rather replace all the Qt classes with equivalent in the C++ Standard Library. This would be too bad !

Many thanks in advance for any support.

Regards.

etla

[I've removed this since it wasn't one bit helpful.]

gav007

@etla

In Qt, (meta-)object lives in a thread. Attempting to access it from another thread will fail (crash). Here is a good introduction for the topic : https://doc.qt.io/qt-5/threads-qobject.html

Regards

etla

@gav007 I see. Now I've learned something new again.

Apologies for the clutter then.

J.Hilk

Hi @gav007

you can pass everything through Signal&Slots & across Threads, that has a copy constructor.

Qt Container usually are not derived of Object and therefor have a copy constructor.

You could, If that's not already the case - make an underlying struct, or class, that contains all your data. define a copy constructor for that class and register it as a metaobject. And you can simply pass such an struct as argument for your cross thread signal.

KroMignon

@gav007
Removing QObject will not solve your problem. Why do you use QObject base classes if signals/slots are not relevant for you?

The advantage of QObject, is to enable you to use signals/slots to share "information" between threads without having to implement yourself mutex/semaphore to protect the datas.

This made it easy to move objects between threads, of course you need to implement copy constructor and register the classes.

But that's not that difficult.

gav007

Thanks for those answers.

@J.Hilk

Actually I did not wish copy the huge class. It hurts me a bit since the object is a singleton. And it needs to implement the copy constructor of decades of classes.

However this could be the solution ... :-)

In Qt containers, I include QString or QByteArray. You're right when you said they do not derive from QObject, but they are "meta-object". At least, they are not accessible from other threads than their own. This is more accurate when expressed like this ;-).

@KroMignon

I used Qt classes for convenience. It was easy since I'm developing with Qt Creator.

This could be the lesson to learn from this : not using Qt classes in such a description object. If afterwards I need to transfer some info through signals and slots, it shall still be time to convert the standard types to Qt classes.

The solution of the copy contsructor for registered class is not that difficult indeed. But, as I said above, it breaks the singleton design and makes me a bit upset ;-)

Thanks again.
Regards

SGaist

Hi,

Why are you sharing such an object ? You wrote that it's a singleton so why not properly protect the access to whatever is inside it and then pass a pointer to it to the the threads that needs to use it ?

gav007

@SGaist

That's what I did at first sight, but I experienced much crashes because of inaccessible content (for QString, QByteArray, ...).
For such a solution, I should change every getter to provide pointer ?

SGaist

You should provide proper synchronisation using QMutex, QSemaphor etc. If you have read-write access to these properties.