Qthread reading a variable (in a while loop) whose value is to be synchronized...

[Qtnovice]

Hi,

this is my first post. Please apologize for any mistake (in language or posting) I may have made...
I preferred to write in English in case someone else needs the same sort of help.

If a QThread, different from the main one, repeatedly accesses a global variable x whose value is to be changed when the user interacts (by some widgets events) I know a QMutex mymutex could solve the trouble.
With x and mymutex declared as global everything should be fine.

However if many variables are to be managed some difficulties arise: I'm not sure it's a good idea to declare and allocate a mutex for each variable to be synchronized.

I don't think an event loop for the QThread could solve the trouble since, in my case, a sort of forever macro call is inside the QThread run() method (that accesses and uses these global variables)...
So even if a signal was emitted the corresponding QThread slot would never be executed while my QThread is running...

I think it's possible to use still one mutex: inside the forever loop, my QThread should detect the change by comparing its local variables with the corresponding global ones (to update the right local one in case of need before going to use it in the following calls) but this could oblige me to have a local variable (inside the QThread) for each variable to be synchronized...

What do you suggest?

Thank You!
Armando

[p-himik]

I did not use it but maybe it will help you: "QAtomicPointer":http://developer.qt.nokia.com/doc/qt-4.7/qatomicpointer.html and "QAtomicInt":http://developer.qt.nokia.com/doc/qt-4.7/qatomicint.html

[Qtnovice]

The variables to be shared are neither int nor pointers.

According to "Qt Threading Basics":http://doc.qt.nokia.com/stable/thread-basics.html, when there is an object living in another thread that performs repeated tasks such as polling a port and communicates with the GUI thread, the solution is:
to derive a class from QObject and implement the necessary slots and signals, move the object to a thread with a running event loop and communicate with the object over queued signal/slot connections; to use also a timer in the worker thread to implement polling.

But I'm not sure to fully understand these indications.
I think that using a timer and implementing polling would mean to have sleep calls and a local variable (in the worker thread) for each global variable updated from GUI. So no benefits except for the ability (by the worker thread's event loop) to update local worker thread variables.
But I still see the need for local variables (I mean inside the worker thread). Am I right?

If so, I think the use of a single mutex inside the worker thread (that performs repeated tasks) and a local variable for each global one to keep worker thread local variables updated by lock/unlock calls and no timer should be fine. Am I right?

[p-himik]

You can hide actual data behind a pointer which you can protect with QAtomicPointer, can't you?

[giesbert]

I would use one global mutex if the access is fast. If access takes more time for some of the globals, perhaps having one for the heavier ones and one for the quick ones could also be a good idea.

[Qtnovice]

Hi p-himik,[quote author="p-himik" date="1323954376"]You can hide actual data behind a pointer which you can protect with QAtomicPointer, can't you?[/quote]I understand that QAtomicPointer class provides atomic operations on pointers.
I can obviously use a pointer but the worker thread should keep a copy of the generic variable to be updated: a change in a variable right value doesn't mean a change in its pointer.

Hi Gerolf,[quote author="Gerolf" date="1323954775"]I would use one global mutex if the access is fast. If access takes more time for some of the globals, perhaps having one for the heavier ones and one for the quick ones could also be a good idea.[/quote]I fully understand your suggestion. Frankly I found basic threads documentation a little too complex and I hoped my solution could still be appropriate. Thank you for your confirmation!