¿El retorno es atómico y debería usarlo temporalmente en getter para que sea seguro para subprocesos?

Question

¿Es necesario usar un temporal aquí para que sea seguro para subprocesos?

int getVal() { 
     this->_mutex.lock(); 
     int result = this->_val; 
     this->_mutex.unlock(); 
     return result; 
} 

te daré el desmontaje de la función simple prueba RAII

int test() 
{ 
    RAIITest raii; //let's say it's a scoped lock 
    return 3; 
} 


{ 
    0x004013ce <_Z4testv>: push %ebp 
    0x004013cf <_Z4testv+1>: mov %esp,%ebp 
    0x004013d1 <_Z4testv+3>: sub $0x28,%esp 
    return 3; 
    0x004013d4 <_Z4testv+6>: lea -0x18(%ebp),%eax 
    0x004013d7 <_Z4testv+9>: mov %eax,(%esp) 
    0x004013da <_Z4testv+12>: call 0x4167a0 <_ZN8RAIITestD1Ev> //here destructor is called 
    0x004013df <_Z4testv+17>: mov $0x3,%eax //here result is pushed onto the stack 
} 
0x004013e4 <_Z4testv+22>: leave 
0x004013e5 <_Z4testv+23>: ret 

el compilador gcc es/g ++ 3.4.5

Answer 1

Si el acceso a this->_val está sincronizado por this->_mutex, entonces usted don No puedo elegir la forma en que se escribe el código actualmente. Debe leer this->_val antes de desbloquear el mutex y debe desbloquear el mutex antes de regresar. La variable result es necesaria para obtener este orden de acciones.

Si usa un lock_guard (o scoped_lock en Boost), entonces no necesita usar el temporal porque el bloqueo en el mutex se liberará cuando la función regrese. Por ejemplo, utilizando la biblioteca de hilos C++ 0x:

int getVal() { 
    std::lock_guard<std::mutex> lock(_mutex); 
    return this->_val; 
} // lock is released by lock_guard destructor 

Answer 2

Sí si usa el bloqueo explícito()/unlock(). No, si construyes un objeto de bloqueo en la pila y haces que su destructor lo desbloquee.

Answer 3

No: el compilador crea un valor temporal para el valor de retorno automáticamente. Normalmente, tampoco es necesario que proteja una lectura con mutex, por lo tanto, aunque sea multihilo, solo return _val; debería ser suficiente.

Sin embargo, me desharía del guión bajo principal: las reglas sobre qué nombres de variables puedes y no puedes usar cuando comienzan con un guión bajo son suficientemente complejas como para evitarlas por completo.

Answer 4

Puede hacerlo limpiamente es su exclusión mutua se encapsula en un scoped_lock que abre en la destrucción:

int getVal() { 
     scoped_lock lockit(_mutex); 
     return _val; 
} 

Y sí, sí es necesario para mantener el bloqueo hasta que sea devuelto.