Asignación de memoria y desasignación a través de subprocesos

Question

Todavía estoy intentando depurar un problema de corrupción de memoria muy furtivo. Encontré una sección de mi código que asigna memoria en un hilo y lo elimina en otro.

Tengo la vaga sensación de que esto está mal, pero no estoy seguro de por qué. Los hilos comparten la memoria del proceso y el acceso a estas estructuras está protegido por un mutex, así que creo que todo funcionará. Sin embargo, ¿hay algún peligro que no esté viendo?

Answer 1

como se indica en otra respuesta por @monjardin, no hay nada inherentemente malo en lo que estamos tratando de hacer.

Como una idea adicional, no mencionó la plataforma, etc. se encuentra con este problema pero si multi-threading es nuevo para usted y/o esta aplicación en la que está trabajando, quiere asegurarse de que el las bibliotecas de soporte estándar que está utilizando son las versiones seguras para subprocesos de las bibliotecas. En muchos entornos/plataformas tienen las versiones de subproceso único y multiproceso de las bibliotecas de soporte disponibles para el desarrollador. Si está utilizando subprocesos pero está enlazando con la versión de subproceso único de las bibliotecas, pueden estar ocurriendo muchas cosas malas. Por ejemplo, en una única biblioteca de soporte con subprocesos para malloc() y libre() no tendría protección de exclusión mutua para el montón (como una optimización). La versión de múltiples hilos de la biblioteca agregaría protección mutex al heap manager para admitir más de un hilo manipulando el heap a la vez. (Esto es sólo un ejemplo).

Answer 2

El peligro es que el código de subprocesos múltiples es más difícil de escribir. Sin embargo, si el programa es correcto, entonces no debería haber ningún problema. Esto es probablemente una ocurrencia común en producer/consumer patrones donde el hilo productor asigna memoria que se coloca en un synchronized queue y liberado por un hilo consumidor.

Answer 3

Siempre que la asignación y la desasignación de la memoria estén protegidas adecuadamente y, también se asegura de que las estructuras solo se accedan mientras están bajo el mismo mutex, realmente no puedo ver que esto sea un problema. Tenga en cuenta que esto se aplica al acceso de lectura y escritura, no solo para el acceso de escritura, ya que necesita asegurarse de que la estructura permanezca donde está mientras alguien está leyendo datos de ella.

¿Hay alguna posibilidad de que algún código en alguna parte intente acceder a estas estructuras de datos fuera de la protección de exclusión mutua? O peor, ¿podría haber alguna posibilidad de que algunas de estas estructuras sean víctimas de las consideraciones de por vida del objeto C++ (por ejemplo, están siendo destruidas porque se referencian mediante boost :: shared_ptrs y el último shared_ptr acaba de salir del edificio?

¿Está 100% seguro de que es una corrupción de memoria? Otro error que se ve muy similar es cuando algún código se mantiene en una referencia que no debería y el objeto referenciado se mueve debido a la reasignación de memoria. Este no es un escenario tan extravagante como añadir otro elemento a un vector que puede desencadenar (sólo para dar un ejemplo).

Answer 4

No, esto está bien, y bastante común especialmente con la programación de Windows usando CreateThread, donde puede asignar los argumentos en el montón, y pasar el argumento como el argumento void * a CreateThread. Y lo más fácil es dejar que el hilo invocado elimine sus argumentos cuando haya terminado con ellos. Sin embargo, si tiene problemas de corrupción de memoria y le preocupa que un subproceso elimine la memoria creada por otro, quizás deba considerar si hay una eliminación doble, por ejemplo, si la transferencia de qué contexto es ahora responsable de limpiar el asignado. la memoria no está clara, tal vez tanto la llamada como la sección llamada lo están haciendo?

Answer 5

recuerde que el administrador de memoria también tiene que ser seguro para subprocesos, no solo para el uso de la memoria. revisa los documentos de tu plataforma.