Bloqueo de recursos compartidos en constructor y destructor

Question

Creo que tengo un buen manejo de al menos los conceptos básicos de multi-threading en C++, pero nunca he podido obtener una respuesta clara al bloquear un mutex alrededor de los recursos compartidos en el constructor o el destructor. Tenía la impresión de que deberías bloquear ambos lugares, pero recientemente los compañeros de trabajo no estuvieron de acuerdo. Fingir la siguiente clase se accede por varios subprocesos:

class TestClass 
{ 
public: 

    TestClass(const float input) : 
     mMutex(), 
     mValueOne(1), 
     mValueTwo("Text") 
    { 
     //**Does the mutex need to be locked here? 
     mValueTwo.Set(input); 
     mValueOne = mValueTwo.Get(); 
    } 

    ~TestClass() 
    { 
    //Lock Here? 
    } 

    int GetValueOne() const 
    { 
     Lock(mMutex); 
     return mValueOne; 
    } 

    void SetValueOne(const int value) 
    { 
     Lock(mMutex); 
     mValueOne = value; 
    } 

    CustomType GetValueTwo() const 
    { 
     Lock(mMutex); 
     return mValueOne; 
    } 

    void SetValueTwo(const CustomType type) 
    { 
     Lock(mMutex); 
     mValueTwo = type; 
    } 

private: 

    Mutex mMutex; 
    int mValueOne; 
    CustomType mValueTwo; 
}; 

Por supuesto que todo debe ser seguro a través de la lista de inicialización, pero qué pasa con las cuentas al interior del constructor? En el destructor, ¿sería beneficioso hacer un bloqueo sin alcance y nunca desbloquear (básicamente, solo llamar a pthread_mutex_destroy)?

Answer 1

Los subprocesos múltiples no pueden construir el mismo objeto, ni se debe permitir que ningún subproceso use el objeto antes de que esté completamente construido. Por lo tanto, en un código razonable, la construcción sin bloqueo es segura.

La destrucción es una carcasa un poco más dura. Pero, una vez más, una gestión adecuada de la vida de su objeto puede garantizar que un objeto nunca se destruya cuando existe la posibilidad de que algunos hilos todavía lo usen.

Un puntero compartido puede ayudar a lograr esto, por ejemplo. :

• construir el objeto en un cierto hilo
• pasar punteros compartidos a cada hilo que necesita el acceso al objeto (incluyendo el hilo que lo construyó si es necesario)
• el objeto se destruye cuando todas las discusiones ha lanzado el puntero compartido

Pero, obviamente, existen otros enfoques válidos. La clave es mantener los límites adecuados entre las tres etapas principales de la vida de un objeto: construcción, uso y destrucción. Nunca permita una superposición entre cualquiera de estas etapas.

Answer 2

No tienen que estar bloqueados en el constructor, ya que la única forma en que cualquier persona externa puede acceder a esos datos en ese punto es si los pasa por el propio constructor (o realiza un comportamiento indefinido, como llamar un método virtual).

[Editar: pieza extraída sobre destructor, ya que como un comentario afirma con razón, tiene problemas más grandes si usted está tratando de acceder a los recursos de un objeto que podría estar muerto]