CODEWITHSUNDEEP
c++multithreadingpthreadsmutex
iedoc
iedoc

Reputation: 2324

pthread mutex lock and unlock per variable

I'm wondering what the best practice for locking and unlocking mutexes for variables withing an object that is shared between threads.

This is what I have been doing and seems to work just fine so far, just wondering if this is excessive or not though:

class sharedobject
{
private:
    bool m_Var1;

    pthread_mutex_t var1mutex;

public:
    sharedobject()
    {
        var1mutex = PTHREAD_MUTEX_INITIALIZER;
    }

    bool GetVar1()
    {
        pthread_mutex_lock(&var1mutex);
        bool temp = m_Var1;
        pthread_mutex_unlock(&var1mutex);
        return temp;
    }

    void SetVar1(bool status)
    {
        pthread_mutex_lock(&var1mutex);
        m_Var1 = status;
        pthread_mutex_unlock(&var1mutex);
    }
};

this isn't my actual code, but it shows how i am using mutexes for every variable that is shared in an object between threads. The reason i don't have a mutex for the entire object is because one thread might take seconds to complete an operation on part of the object, while another thread checks the status of the object, and again another thread gets data from the object

my question is, is it a good practice to create a mutex for every variable within an object that is accessed between threads, then lock and unlock that variable when it is read or written to?

I use trylock for variables i'm checking the status to (so i don't create extra threads while the variable is being processed, and don't make the program wait to get a lock)

I haven't had a lot of experience working with threading. I would like the make the program thread safe, but it also needs to perform as best as possible.

Upvotes: 1

Views: 2374

Answers (1)

Richard Hodges
Richard Hodges

Reputation: 69864

if the members you're protecting are read-write, and may be accessed at any time by more than one thread, then what you're doing is not excessive - it's necessary.

If you can prove that a member will not change (is immutable) then there is no need to protect it with a mutex.

Many people prefer multi-threaded solutions where each thread has an immutable copy of data rather than those in which many threads access the same copy. This eliminates the need for memory barriers and very often improves execution times and code safety.

Your mileage may vary.

Upvotes: 1

Related Questions