Tengo una pregunta acerca de boost::shared_ptr<T>.

Hay un montón de hilo.

using namespace boost;

class CResource
{
  //xxxxxx
}

class CResourceBase
{
public:
   void SetResource(shared_ptr<CResource> res)
   {
     m_Res = res;
   }

   shared_ptr<CResource> GetResource()
   {
      return m_Res;
   }
private:
   shared_ptr<CResource> m_Res;
}

CResourceBase base;

//----------------------------------------------
//Thread_A:
    while (true)
    {
       //...
       shared_ptr<CResource> nowResource = base.GetResource();
       nowResource.doSomeThing();
       //...
    }

//Thread_B:
    shared_ptr<CResource> nowResource;
    base.SetResource(nowResource);
    //...

Q1

Si Thread_A no se preocupan de la nowResource es la más reciente, esta parte de código de problema?

Me refiero a cuando Thread_B no SetResource() completamente, Thread_A obtener un mal smart punto por GetResource()?

Q2

¿Qué thread-safe significa?

Si no me importa acerca de si el recurso es el más reciente, el shared_ptr<CResource> nowResource accidente del programa cuando el nowResource se libera o se el problema destruir la shared_ptr<CResource>?

InformationsquelleAutor user25749 | 2009-03-28

5 Comentarios

  1. 31

    Desde el impulso documentación:

    shared_ptr objetos ofrecen el mismo
    nivel de seguridad de los subprocesos como built-in
    tipos. Un shared_ptr instancia puede ser
    «leer» (la que se accede utilizando sólo const
    operaciones) simultáneamente por varios
    los hilos. Diferentes shared_ptr
    las instancias pueden ser «escrita»
    (consultado el uso de operaciones mutables
    como operator= o reset)
    de forma simultánea por varios subprocesos
    (incluso cuando estos casos son copias,
    y comparten el mismo número de referencia
    de abajo).

    Cualquier otro simultáneo de accesos resultar en un comportamiento indefinido.

    Por lo que su uso no es seguro, ya que utiliza simultánea de lectura y escritura de m_res. Ejemplo 3 en el impulso de la documentación también ilustra esto.

    Usted debe usar un objeto mutex que protege el acceso a m_res en SetResource/GetResource.

    • -1 Su uso no se contradice con lo que citó el impulso doc. De hecho, es exactamente lo que el impulso doc dice.
    • He ampliado mi respuesta un poco. Su uso no es seguro, ya que él no simultánea de lectura y escritura de la misma `shared_ptr<> instancia.
    • Tienes razón: m_res es de lectura y escrita de diferentes hilos. Tuve este caso y sin bloqueos se bloquea. Es el ejemplo 3 del Hilo de la sección de seguridad de la potenciación de la documentación.
  2. 40

    boost::shared_ptr<> ofrece un cierto nivel de seguridad para los subprocesos. El recuento de referencia es manipulado en un hilo de un modo seguro (a menos que configure impulso para deshabilitar el roscado de apoyo).

    Así que usted puede copiar un shared_ptr alrededor y la ref_count se mantiene correctamente. Lo que no se puede hacer de manera segura en varios hilos se modifica el real shared_ptr instancia del objeto en sí de múltiples hilos (tales como llamar a reset() de múltiples hilos de ejecución). Por lo que su uso no es seguro – se modifica el real shared_ptr instancia en varios hilos – usted tendrá que tener su propia protección.

    En mi código, shared_ptr‘s son generalmente locales o los parámetros se pasan por valor, así que no hay problema. Consiguiendo de un hilo a otro, yo por lo general uso un hilo de seguridad de la cola.

    Por supuesto, nada de esto se refiere a la seguridad de los subprocesos de acceso al objeto señalado por el shared_ptr – que también depende de usted.

    • será este Thread-safe problema de memoria de la causa fugas?
    • No, él no la modificación de la shared_ptr instancia en diferentes hilos! Sólo el Subproceso B modifica.
  3. 3

    Bien, tr1::shared_ptr (que se basa en aumentar) la documentación que cuenta una historia diferente, lo que implica que la gestión de los recursos es seguro para subprocesos, considerando que el acceso a los recursos no es.

    «…

    Hilo De Seguridad

    C++0x-sólo características son: r-value-ref/mover apoyo, asignador de apoyo, alias constructor, make_shared & allocate_shared. Además, los constructores de tomar auto_ptr parámetros están en desuso en C++0x modo.

    El Hilo a la sección de Seguridad de la Boost shared_ptr documentación dice «shared_ptr objetos ofrecen el mismo nivel de seguridad de los subprocesos como tipos integrados.» La aplicación debe asegurar que las actualizaciones simultáneas para separar shared_ptr instancias son correctos, incluso cuando esas instancias compartir un recuento de referencia por ejemplo,

    shared_ptr un(nuevo);
    shared_ptr b(a);

    //Rosca 1 //Subproceso 2

    una.reset(); b.reset();

    La dinámicamente asignada el objeto debe ser destruido, exactamente uno de los subprocesos. Referencias débiles hacer las cosas aún más interesantes. El estado compartido utilizan para implementar shared_ptr debe ser transparente para el usuario y invariantes debe ser preservado en todo momento. Las piezas clave de un estado compartido son el fuerte y el débil recuentos de referencia. Las actualizaciones de estos deben ser atómicos y visible para todos los hilos para asegurar la correcta limpieza de los recursos administrados (que es, después de todo, shared_ptr del trabajo!) En sistemas multiprocesador de memoria de sincronización puede ser necesario para que el número de referencias de las actualizaciones y la destrucción de los recursos administrados son de carrera de libre.

    …»

    ver
    http://gcc.gnu.org/onlinedocs/libstdc++/manual/memoria.html#std.util.memoria.shared_ptr

    • «Bien, tr1::shared_ptr (que se basa en aumentar) la documentación que cuenta una historia diferente, lo que implica que la gestión de los recursos es seguro para subprocesos, considerando que el acceso a los recursos no es.» Bien tiendo a estar de acuerdo con esto, porque la mayoría de los que se puede garantizar un shared_ptr es que el recuento de referencia para el recurso se mantiene constantemente en la presencia de los hilos. El recurso del que se está señalando debe ser seguro para subprocesos en su propia en el caso de que mutar el valor de los recursos.
  4. 1

    m_Res no es seguro para subprocesos ,porque simultáneas de lectura/escritura,
    usted necesita boost::atomic_store/en función de la carga a lo protege.

    //--- Example 3 ---
    //thread A
    p = p3; //reads p3, writes p
    //thread B
    p3.reset(); //writes p3; undefined, simultaneous read/write
  5. -1

    Agregar, la clase tiene un Cíclica-referencias condición; el shared_ptr<CResource> m_Res no puede ser miembro de CResourceBase. Usted puede utilizar weak_ptr lugar.

    • «shared_ptr<CResource> m_Res no puede ser miembro de CResourceBase» ¿por qué no?

Dejar respuesta

Please enter your comment!
Please enter your name here