Question

I need some synchronous mechanism for thread. I am wondering the implementation below which one is a better way?

classA{

public:
   int sharedResourceA;
   pthread_mutex_t mutex1;
   functionA();
   int nonSharedResources;

}

classA::functionA(){
  pthread_mutex_lock( &mutex1 );
  use sharedResourceA;
  pthread_mutex_unlock( &mutex1 );
}

classA objA;
pthread_mutex_lock(&objA.mutex1) //use lock because another thread can call obj.functionA
  use objA.sharedResources;
pthread_mutex_unlock(&objA.mutex1)

use objA.nonSharedResources = blah //without lock because is non shared

OR I shouldn’t create a lock at classA, instead I create a lock at the application. Eg:

classA objA;
pthread_mutex_t mutex2;
pthread_mutex_lock(mutex2) //use lock because another thread can call obj.functionA
  use objA.sharedResources;
pthread_mutex_unlock(mutex2)

pthread_mutex_lock(mutex2) //use lock because another thread can call obj.functionA
  functionA();
pthread_mutex_unlock(mutex2)

use objA.nonSharedResources = blah //without lock because is non shared

Answer 1

First – the idiomatic way for doing locks in c++ is to create a lock class that uses RAII.

Then you can go

Lock l(mutex1);
// do stuff under mutex1 lock;
// Lock is freed at end of scope

(I bet boost has a lock, we made our own)

Second. (the scope question). If class A uses shared resources internally then it should lock them internally. Otherwise

1. how does a caller know to do it
2. how can you be sure they did it
3. what if you change the implementation

The application level lock should be used when the caller is the one using the shared resources and is composing something larger that uses classA, funcX and file W. Note that classA may still have its own internal lock in this case