Messages in this thread | | | From | cd_smith@ou ... | Date | Tue, 27 Jul 1999 10:59:27 -0500 (CDT) | Subject | Q: Thread local storage, thread IDs |
| |
joerg.pleumann@trantor.de wrote: > (1) Thread local storage. It would be perfectly okay if this were a > single pointer that could be read/written for the current thread. If > more values are needed, it's no problem to attach a larger memory block > to this pointer.
What's wrong with user space solutions here? The normal approach is to put that pointer on the stack rather than requiring a system call to access it. It's faster, and it keeps stuff out of the kernel where it belongs (since by far the vast majority of programs don't use TLS). So just use pthread_*specific and be done with it. No problem there.
> (2) 1-based IDs for the threads belonging to a process (in addition to > the system-wide unique process IDs).
What do you mean by 1-based? Do you mean that you want to require that the first thread in a process always has TID 1? That's pretty kuldgy, and very non-portable if you actually use it. If you need 1-based ID's, use TLS and a mutex-protected global variable and have threads allocate their process-local ID at startup and then increment the counter.
If, OTOH, you just want thread IDs (unspecified opaque handles) in addition to process IDs, I am actually working on a patch that revamps a lot of stuff in terms of thread vs. process right now, although "working on" is used loosely since I've been busy and haven't touched it in a week now. :( (BTW, this is not an invitation to re-open the somewhat stale discussion of whether this is a good idea. I'll resume that dialog when I have benchmark numbers and concrete results to draw from.)
> For the other platforms, as well as for Delphi itself, there's a simpe > solution: The FS selector points to a thread information block whose > first longword points to the head of the handler chain. The OS ensures > that FS has the correct value for each thread.
I doubt that the kernel really does any screwing around with the values of registers for the context. If so, I've lost a lot of what respect I previously had for any of these operating systems. More likely, the use of FS for that purpose is a convention used by the program, and the kernel properly context switches, without caring what you're using your registers for.
Actually, though, I think using a data block at the top of the stack for this purpose is a better idea. The stack segment already exists, and is already set up to be different for each thread.
> (on the other hand FS and GS are quite unused in i386-Linux)
You don't know that. You mean that the *kernel* doesn't use them.
Chris Smith <cd_smith@ou.edu>
- 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/
| |