Re: thread specific information
- From: Dave Butenhof <david.butenhof@xxxxxx>
- Date: Mon, 14 Jan 2008 06:36:45 -0500
Rahul wrote:
Hi Everyone,
I was working with threads and wanted to know which segments are
specific to each thread?
like stack, program counter and other registers, heap, data segment
(bss)...
Thanks in advance!!!
Depends a lot on what you mean by "specific to each thread". There's ACTUALLY thread-specific and EFFECTIVELY thread-specific.
The only things ACTUALLY thread-specific are the hardware registers. Even those are kinda loose definitions of "actual", if you take "thread specific" to the level of "there's absolutely no physical means by which another thread can change them", because when a thread's not active those register values need to be saved somewhere in memory.
POSIX requires that all memory is globally addressable, by all threads. Windows threading follows the same model, as do most common proprietary threading models (e.g. the archaic UI threads, Mach cthreads, etc.)
Stacks, and the thread context switch data areas, are EFFECTIVELY thread specific. There's rarely any reason or need for another thread to touch them, but it's not physically impossible. In fact many real world programming techniques require threads to access stack data allocated by another thread. It's just a matter of passing addresses. (Many real world BUGS also require threads to access stack data allocated by another thread -- usually by accident. Some of these bugs are directly related to the aforementioned "programming techniques", so such things should always be viewed with caution. ;-) )
Heap is at best "casually" thread-specific. That is, one thread allocates heap and retains a pointer to it. If it keeps that pointer to itself there's no reason for another thread to access it, except by accident. But if you store the pointer in a globally accessible place, any other thread CAN access it -- and this is critical to thread programming. After all, threads are intended to be COOPERATIVE, and to cooperate they need to communicate. Communication through statically allocated data is rather limited, so sharing heap is important.
All static program data (text, data, bss, etc) are globally accessible by label. You can run the code in any thread, you can access extern/static data in any thread. That of course means that all such data must be protected by some synchronization scheme. (As simple or complex as required by the application.)
POSIX provides the "thread specific data" (TSD) mechanism by which any application can effectively declare a global "key" by which each thread can reference it's own private value -- generally a pointer to some (heap) allocation. But again, the allocated memory itself is globally visible; only the key value is really private, and at that usually only "effectively" private.
Less standard, but essentially universal now, is "thread local storage" (TLS), a compiler/loader/runtime mechanism that allows a special declaration for data with private instantiation for each thread. This may be implemented on top of TSD, or even the other way around, but it can be more convenient. There's just (as yet) no portable syntax for declaring it. Again, this effectively allocates GLOBALLY visible memory to which only one thread is (by default) granted a pointer; but there's nothing to prevent that thread from making a pointer visible to other threads, or to keep other threads from accidentally "scribbling" over the data via a random uninitialized pointer.
.
- References:
- thread specific information
- From: Rahul
- thread specific information
- Prev by Date: Re: Solving the memory issue of lock-free algorithms
- Next by Date: Re: Solving the memory issue of lock-free algorithms
- Previous by thread: Re: thread specific information
- Next by thread: thread context switching
- Index(es):
Relevant Pages
|
