Ways to share data between threads

[wysota]

If the class inherits QObject then that's not enough. But so far your class doesn't use its QObject legacy for anything so you can just remove the inheritance.

[unit]

Use QSharedMemory class

Don't make bicycle

[AndresBarbaRoja]

QQueue doesn't inherit QObject. But it's also not thread-safe.

Well, I block access to the queue before actually doing anythong to it, so i guess is the same as if it were an int
Thanks for the replies
(to both of you)

---

Added after 22 minutes:

Use QSharedMemory class

Don't make bicycle

I'm reading the QSharedMemory docs but it appears to me that I lock the whole memory and not just parts. If it does not allow me to lock only one variable at a time i'll have to create a shared memory for each (or at least for groups of variables).
I believe I currently need to define serval locks to provide protected access to different variables at the same time. Do you know if defining several shared memory instances would be worthy?
And what does "bicycle" means? I am not a programmer (yet) so i lack a lot of concepts :S

[AndresBarbaRoja]

More changes!
Since I need to protect each variable i've defined a template class to create a single protected variable:

#ifndef PROTECTEDVARIABLE_H
#define PROTECTEDVARIABLE_H
 
#include <QReadWriteLock>
 
template <class T> class ProtectedVariable
{
public:
    ProtectedVariable(T=0);
    void set(T);
    T get();
 
private:
    T value;
    QReadWriteLock lock;
};
 
template <class T> ProtectedVariable<T>::ProtectedVariable(T data)
{
    set(data);
}
 
template <class T> void ProtectedVariable<T>::set(T value)
{
    QWriteLocker wlocker(&lock);
    this->value=value;
}
 
template <class T> T ProtectedVariable<T>::get()
{
    QReadLocker rlocker(&lock);
    return value;
}
#endif // PROTECTEDVARIABLE_H

#ifndef PROTECTEDVARIABLE_H
#define PROTECTEDVARIABLE_H

#include <QReadWriteLock>

template <class T> class ProtectedVariable
{
public:
    ProtectedVariable(T=0);
    void set(T);
    T get();

private:
    T value;
    QReadWriteLock lock;
};

template <class T> ProtectedVariable<T>::ProtectedVariable(T data)
{
    set(data);
}

template <class T> void ProtectedVariable<T>::set(T value)
{
    QWriteLocker wlocker(&lock);
    this->value=value;
}

template <class T> T ProtectedVariable<T>::get()
{
    QReadLocker rlocker(&lock);
    return value;
}
#endif // PROTECTEDVARIABLE_H

To copy to clipboard, switch view to plain text mode 

Then in the data container I create the different variables.

#include <protectedvariable.h>
 
class DataTable
{
public:
    ProtectedVariable<int> data;
    ProtectedVariable<double> differentData;
}

#include <protectedvariable.h>

class DataTable
{
public:
    ProtectedVariable<int> data;
    ProtectedVariable<double> differentData;
}

To copy to clipboard, switch view to plain text mode 

Now the question, when I access the variables as

DataTable dt;
dt.data.set(5);

DataTable dt;
dt.data.set(5);

To copy to clipboard, switch view to plain text mode 

Is my variable still really protected?

[wysota]

Change your get methods to return a const reference instead of a copy if possible.

Honestly I'm not sure your approach is a good idea. It's usually better to have a single mutex that guards access to a group of variables used together instead of having several mutexes to protect each variable separately. It might happen that you'll end up with a situation where two threads are walking the same code path and accessing the same protected variables in sequence and the "second" thread stops at every possible mutex along the way. Locking mutexes is quite expensive in terms of cpu usage.

As for integers it's better to use QAtomicInt instead of protecting an integer variable with a mutex.

[AndresBarbaRoja]

Thanks for the insight, I have a lot to learn.
In fact I think some variables can be grouped. I have to think how it can be done though.
Maybe I can create several data storage objects... anyway, it's Friday afternoon! time to disconnect at least for a couple of hours

[AndresBarbaRoja]

Thanks. I do not see anything that forces me to inherit QObject so that will go away. So after fixing that, can I consider this class to be thread safe or at least safe enough for my purposes?
Just to learn more, why would this protection be insufficient? Right now I'm using in another part of the code a QQueue which is a member of a QThread. These two do inherit from QObject, so is my app in danger?

[wysota]

Thanks. I do not see anything that forces me to inherit QObject so that will go away. So after fixing that, can I consider this class to be thread safe or at least safe enough for my purposes?

Yes.

Just to learn more, why would this protection be insufficient?

Because QObject is not thread-safe and since you don't have access to internals of QObejct, you can't protect your class from concurrent access. As long as you don't any QObject API this doesn't matter but then it doesn't make sense to inherit QObject in the first place.

Right now I'm using in another part of the code a QQueue which is a member of a QThread. These two do inherit from QObject, so is my app in danger?

QQueue doesn't inherit QObject. But it's also not thread-safe.