Memory allocation and deallocation across threads

Question

I'm still trying to debug a very sneaky memory corruption problem. I came across a section of my code that allocates memory on one thread and deletes it on another.

I have a vague feeling that this is wrong, but I'm not sure why. The threads share the process memory and access to these structures is protected by a mutex, so I think everything would work. However, is it there any danger I'm not seeing?

Answer 1

As indicated in another answer by @monjardin, there is nothing inherently wrong with what you are trying to do.

As an additional thought, you didn't mention the platform, etc. you are running into this problem on but if multi-threading is new to you and/or this application you are working on, you want to be sure that the standard support libraries you are using are the thread safe versions of the libraries. In many environments/platforms they have both the single threaded and multi-threaded versions of the support libraries available to the developer. If you are using threads but linking against the single thread version of the libraries, lots of bad things could be happening. For example, in a single threaded support library for malloc() and free() it would not have mutex protection for the heap (as an optimization). The multi-thread version of the library would add mutex protection to the heap manager to support more than one thread manipulating the heap at a time. (This is just one example).

Answer 2

Nope, This is fine, and quite common especially with windows programming using CreateThread, where you might allocate the arguments on the heap, and pass the argument as the a void * argument to CreateThread. And the easiest thing to do is to let the called thread delete it's arguments when it's done with them. However if you are having memory corruption issues, and you are concerned about having one thread delete memory that another created, perhaps you should consider if there is a double delete happening, say if the transfer of what context is now responsible for cleaning up the allocated memory is not clear, perhaps both calling and called section are doing it?