Messages in this thread | | | Date | Tue, 14 Dec 1999 02:39:29 -0700 (MST) | From | Jason Gunthorpe <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data |
| |
On Mon, 13 Dec 1999, Jon Leech wrote:
> - whether that mechanism is private mappings or tarot cards matters not, > so long as it's extremely fast.
I'm not sure if someone mentioned this before but..
It seems to me that in the OS/2 environment this problem was solved by sacrificing one of the i386 segment registers to a thread-specific value. Each thread stored a thread id of sorts that could be used to quickly perform a table lookup and find thread local stuff [it may even have been that it was a valid segment, don't remember]. There even existed extended compilers (CSet and HighC) that could generate this inlined code automatically though some weird pragma.
Obviosly rather Intel specific, but a different sort of solution :>
Jon, looking at the pthread code, I'm not sure it is that horrible - the pthread interface isn't so hot, but the general concept seems speedy. What if you were to change pthread so that it set aside the first 4k of the (aligned) stack pointer for thread-local stuff, then an access to it is just something like (CURRENT_STACK_FRAME & SOME_MASK)[0] which is probably a couple instructions on most archs..
Jason
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |