views:

432

answers:

7

If I allocate memory in one thread in C++ (either new or malloc) can I de-allocate it in another, or must both occur in the same thread? Ideally, I'd like to avoid this in the first place, but I'm curious to know is it legal, illegal or implementation dependent.

Edit: The compilers I'm currently using include VS2003, VS2008 and Embedded C++ 4.0, targetting XP, Vista, Windows 7 and various flavours of Windows CE / PocketPC & Mobile. So basically all Microsoft but across an array of esoteric platforms.

+1  A: 

Sorry for this unhelpful answer, but standard C++ does not have threads, so all bets are off!

However some C++ compilers and run time systems supports threading, on these you often have to tell the linker to use the thread safe version of the standard liberties.

Ian Ringrose
+11  A: 

Generally, malloc/new/free/delete on multi threaded systems are thread safe, so this should be no problem - and allocating in one thread , deallocating in another is a quite common thing to do.

As threads are an implementation feature, it certainly is implementation dependant though - e.g. some systems require you to link with a multi threaded runtime library.

nos
+2  A: 

To be able to allocate in one thread and free in another, you need the runtime library to be thread safe. The Microsoft runtimes have all been thread safe since Visual Studio 2005, Visuals Studio 2003 provides both single threaded and thread safe runtimes - obviously you should choose to link with the multithreaded ones if you're using threading.

As to whether it's legal, illegal or implementation dependent, I'd say none of the above. It's entirely outside the scope of the standard as it doesn't the mention threading at all.

Joe Gauterin
Thanks Joe, well worth knowing since we still have some development sitting on VS2003.
Shane MacLaughlin
VS2003 provides both multithreaded and single threaded runtimes - you just have to make sure you're linking against the right ones.
Joe Gauterin
+1  A: 

I believe it is implementation defined since C++ Standard doesn't say anything about how threads will share address space.

Kirill V. Lyadvinsky
A: 

it works because threads belong to the same process and share the same address space ..

luca
+5  A: 

There's nothing about new/delete themselves that prevent you from allocating and deallocating in separate threads. As many have said, the Standard is silent on multi-threading -- there is neither support for multi-threading, nor is there anything preventing you from doing it using any of the standard facilities. This is both good and bad in that you can do anything you want, but the language provides no direct mechanism to help you do it safely.

There are many potential technical issues you may need to contend with however. Many compilers have multi-threaded- and single-threaded flavors of the runtime libraries that implement new & delete, so you must be sure you use the right one. (VS 2008 has done away with the single-threaded CRT, so this is not an issue there.) More importantly, your software must be designed from the ground up to be multi-thread aware, and this is the biggest challenge for us. Resources need to be protected, ownership must be clear, and you need to avoid deadlocks & race conditions. But while this is probably the most important and difficult challenge you face when allocating and deallocating in separate threads, it is not directly related to your question, so I'll leave that for another discussion.

John Dibling
Thanks for the response John. I kept the question intentionally narrow as I'm aware that discussing the various potential pitfalls of writing multi-threaded code would take a large book. I say this having fallen into many of said pits myself on more than one occasion ;)
Shane MacLaughlin
It's like playing an old Activision game, isn't it?
John Dibling
A: 

Do you mean that you allocate some memory on one thread and free the same memory on another thread? In order to do this you must somehow share the pointer to the allocated memory between these threads. In this case you have no way of knowing when the memory gets to be deallocated. You must care not to use pointer to the deallocated memory on the thread which had allocated it.

Irakl

irakl