CODEWITHSUNDEEP
c++multithreading
zar
zar

Reputation: 12227

Should a critical section or mutex be really member variable or when should it be?

I have seen code where mutex or critical section is declared as member variable of the class to make it thread safe something like the following.

class ThreadSafeClass
{
public:
    ThreadSafeClass() { x = new int; }
    ~ThreadSafeClass() {};

    void reallocate()
    {
        std::lock_guard<std::mutex> lock(m);

        delete x;
        x = new int;
    }

    int * x;
    std::mutex m;
};

But doesn't that make it thread safe only if the same object was being shared by multiple threads? In other words, if each thread was creating its own instance of this class, they will be very much independent and its member variables will never conflict with each other and synchronization will not even be needed in that case!?

It appears to me that defining the mutex as member variable really reduces synchronization to the events when the same object is being shared by multiple threads. It doesn't really make the class any thread safer if each thread has its own copy of the class (for example if the class were to access other global objects). Is this a correct assessment?

Upvotes: 0

Views: 759

Answers (1)

imreal
imreal

Reputation: 10358

If you can guarantee that any given object will only be accessed by one thread then a mutex is an unnecessary expense. It however must be well documented on the class's contract to prevent misuse.

PS: new and delete have their own synchronization mechanisms, so even without a lock they will create contention.

EDIT: The more you keep threads independent from each other the better (because it eliminates the need for locks). However, if your class will work heavily with a shared resource (e.g. database, file, socket, memory, etc ...) then having a per-thread instance is of little advantage so you might as well share an object between threads. Real independence is achieved by having different threads work with separate memory locations or resources.

If you will have potentially long waits on your locks, then it might be a good idea to have a single instance running in its own thread and take "jobs" from a synchronized queue.

Upvotes: 2

Related Questions