hilo de seguridad std :: shared_ptr explicó

Question

estoy leyendo http://gcc.gnu.org/onlinedocs/libstdc++/manual/shared_ptr.html y algunos problemas de seguridad de rosca todavía no están claras para mí:

1. garantías establecidas en que el recuento de referencias se manipula el hilo de seguridad y es independiente de la plataforma, ¿verdad?
2. Problema similar: el estándar garantiza que solo un hilo (manteniendo la última referencia) llamará a eliminar en el objeto compartido, ¿verdad?
3. shared_ptr no garantiza ningún hilo de seguridad para el objeto almacenado en él?

EDIT:

Pseudo código:

// Thread I 
shared_ptr<A> a (new A (1)); 

// Thread II 
shared_ptr<A> b (a); 

// Thread III 
shared_ptr<A> c (a); 

// Thread IV 
shared_ptr<A> d (a); 

d.reset (new A (10)); 

restablecimiento de llamada() en el hilo IV eliminará anterior instancia de una clase creada en primer hilo y sustituirla por nueva instancia? Además, después de llamar a reset() en el hilo IV, ¿otros hilos verán solo el objeto recién creado?

Answer 1

Como han señalado otros, lo ha descifrado correctamente con respecto a sus 3 preguntas originales.

Pero la parte final de su edición

Calling reset() en el hilo IV eliminará anterior instancia de una clase creada en primer hilo y sustituirla por nueva instancia? Además, después de llamar a reset() en el hilo IV, ¿otros hilos verán solo el objeto recién creado?

es incorrecto. Solo d apuntará al nuevo A(10), y a, b y c continuará apuntar al A(1) original. Esto se puede ver claramente en el siguiente breve ejemplo.

#include <memory> 
#include <iostream> 
using namespace std; 

struct A 
{ 
    int a; 
    A(int a) : a(a) {} 
}; 

int main(int argc, char **argv) 
{ 
    shared_ptr<A> a(new A(1)); 
    shared_ptr<A> b(a), c(a), d(a); 

    cout << "a: " << a->a << "\tb: " << b->a 
    << "\tc: " << c->a << "\td: " << d->a << endl; 

    d.reset(new A(10)); 

    cout << "a: " << a->a << "\tb: " << b->a 
    << "\tc: " << c->a << "\td: " << d->a << endl; 

    return 0;                           
} 

(Claramente, no me molesté con cualquier roscado: que no es un factor en el comportamiento shared_ptr::reset().)

La salida de este código es

a: 1 b: 1 c: 1 d: 1

a: 1 b: 1 c: 1 d: 10

Answer 2

1. correcta, shared_ptr s utilizan atómicas incrementos/decrementos de un valor de recuento de referencia.

2. El estándar garantiza que solo un hilo llamará al operador delete en un objeto compartido. No estoy seguro si especifica específicamente que el último hilo que borre su copia del puntero compartido será el que llama eliminar (probablemente en la práctica sería el caso).

3. No, no lo hacen, el objeto almacenado en él puede editarse simultáneamente por varios hilos.

EDIT: Leve seguimiento, si se quiere tener una idea de cómo funcionan los punteros compartida, en general, es posible que desee mirar a la fuente boost::shared_ptr: http://www.boost.org/doc/libs/1_37_0/boost/shared_ptr.hpp.

Answer 3

std :: shared_ptr no es seguro para subprocesos.

Un puntero compartido es un par de dos punteros, uno para el objeto y otro para un bloque de control (que contiene el contador de referencia, enlaces a punteros débiles ...).

Puede haber varios std :: shared_pointer y cada vez que acceden al bloque de control para cambiar el contador de referencia es threadsafe pero el "std :: shared_ptr" en sí no es threadsafe o atomic.

Si asigna un objeto nuevo a std :: shared_pointer mientras que otro hilo lo usa, podría terminar con el nuevo puntero de objeto pero aún utilizando un puntero al bloque de control del objeto antiguo => CRASH.