As far as I know each thread gets a distinct stack when the thread is created by the OS. I wonder if each thread has a heap distinct to itself also?
+8
A:
No. All threads share a common heap.
Each thread has a private stack, which it can quickly add and remove items from. This makes stack based memory fast, but if you use too much stack memory, as occurs in infinite recursion, you will get a stack overflow.
Since all threads share the same heap, access to the allocator/deallocator must be synchronized. There are various methods and libraries for avoiding allocator contention.
Some languages allow you to create private pools of memory, or individual heaps, which you can assign to a single thread.
brianegge
2009-11-03 05:33:17
That depends on the runtime.
swillden
2009-11-03 05:34:46
Typically threads share resources, such as memory, so any non-braindead thread implementation would share the heap.
Martinho Fernandes
2009-11-03 05:36:06
The *main* reason each thread has its own stack is so that the thread can actually do something (like call a functions) ...
Edmund
2009-11-03 06:08:26
+1
A:
Typically, threads share the heap and other resources, however there are thread-like constructions that don't. Among these thread-like constructions are Erlang's lightweight processes, and UNIX's full-on processes (created with a call to fork()). You might also be working on multi-machine concurrency, in which case your inter-thread communication options are considerably more limited.
Ken Bloom
2009-11-03 05:40:44
I thought fork was more like creating a new process that just copied the data to a new memory location.
Jason Tholstrup
2009-11-03 06:18:42
fork() can serve in many use-cases where threads may be used also. Due to copy-on-write, there is no significant cost difference on Unix systems. Typical use-case is where the worker is autonomous (like web server) from the rest of the service. Another possibility is to communicate through stdin/out with the main thread/program. fork() is strong on Unix, whereas other platforms like Windows prefer threading. The main reason probably is that using fork() is much simpler and safer and Unix has this simplicity philosophy. See for example apache webserver, with its slow transition to threads.
ypnos
2009-11-03 13:41:13
+2
A:
By default, C has only a single heap.
That said, some allocators that are thread aware will partition the heap so that each thread has it's own area to allocate from. The idea is that this should make the heap scale better.
One example of such a heap is Hoard.
R Samuel Klatchko
2009-11-03 06:33:22
By default C, and C++, don't have multiple threads. The 2003 c++ specification at least makes no allowances for threads in its virtual machine design, so threads, in c++, are implementation defined.
Chris Becke
2009-11-03 09:32:50
Even if different threads have different areas to allocate from on the heap, they can still see data allocated by another thread, so the threads do still share the same heap.
Ken Bloom
2009-11-03 14:25:22
A:
Each thread has its own stack and call stack.
Each thread shares the same heap.
tsalter
2009-11-03 18:01:11
+1
A:
Generally speaking, all threads use the same address space and therefore usually have just one heap.
However, it can be a bit more complicated. You might be looking for Thread Local Storage (TLS), but it stores single values only.
Windows-Specific: TLS-space can be allocated using TlsAlloc and freed using TlsFree (Overview here). Again, it's not a heap, just DWORDs.
Strangely, Windows support multiple Heaps per process. One can store the Heap's handle in TLS. Then you would have something like a "Thread-Local Heap". However, just the handle is not known to the other threads, they still can access its memory using pointers as it's still the same address space.
EDIT: Some memory allocators (specifically jemalloc on FreeBSD) use TLS to assign "arenas" to threads. This is done to optimize allocation for multiple cores by reducing synchronization overhead.
Meinersbur
2009-11-03 18:28:25
A:
Depends on the OS. The standard c runtime on windows and unices uses a shared heap across threads. This means locking every malloc/free.
On Symbian, for example, each thread comes with its own heap, although threads can share pointers to data allocated in any heap. Symbian's design is better in my opinion since it not only eliminates the need for locking during alloc/free, but also encourages clean specification of data ownership among threads. Also in that case when a thread dies, it takes all the objects it allocated along with it - i.e. it cannot leak objects that it has allocated, which is an important property to have in mobile devices with constrained memory.
Erlang also follows a similar design where a "process" acts as a unit of garbage collection. All data is communicated between processes by copying, except for binary blobs which are reference counted (I think).
Srikumar
2009-11-05 18:17:07