Dominic Sweetman wrote: > > > In any case, that's not the real problem. Linux user threads do not > > have true separate stacks. They share their _entire_ address space; > > the stacks are all bounded (default is 2MB) and grouped together at > > the top of the available memory region. > > Quite. > > A comment by Kevin reminded me of the real constraint (which the > experts probably take for granted): this system is supposed to work on > shared-memory multiprocessors and multithreaded CPUs. > > In both cases two or more threads within an address space can be > active simultaneously. On a multithreaded CPU (in particular) there's > only one TLB, so memory (including any memory specially handled by the > kernel) is all held in common. The *only* thing available to a user > privilege program which distinguishes the threads is the CPU register > set. > > (Well, and the stack, which is a difference inherited from the value > in the stack pointer register. But the stack pointer is not really > going to help much to return a thread-characteristic pointer or ID.) Well, why not use the stack? I am not quite familiar with the requirements on this "thread register", but couldn't something like this be made to work: #define TID *((sp & ~(STACK_SIZE-1)) + STACK_SIZE - TID_OFFSET) It assumes a fixed maximum stack size (and alignment), which it should be possible to meet (virtual memory is cheap). The STACK_SIZE could probably even be a (process global!) variable if it is not desirable to limit this at compile time. -Tommy
