Is some connection between using x86 segmentation and a possible implementation a thread package? I've been told that usually x86 segmentation is implemented in operating systems these days with an identity function (0 offset, unlimited limit), but can segmentation somehow be useful when dealing with multithreading?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
AFAIK, Windows is using one segment register to point to the thread specific variable area for the thread.
Note that what is useful here isn't the segmentation -- I think limit and protection are not really used, and IIRC that's the only thing which is now supported in 64 bits mode --, but the fact that segment registers had fell into disuse and so were available to be used simply as base register without impacting existing code.
So I found out that one interesting use of segmentation in thread packages (not saying this is actually done anywhere, but it's at least a potential use) is to manipulate the stack segment so that threads within a single process can share an address space, but not collide on the same stack. Each thread has its own stack, but the code running in the thread doesn't have to know where its stack is--if it doesn't try to manipulate its own stack segment register, the register will be set when it starts to point to an entry in the LDT, which leads it to some stack designated specifically for it in the process's address space.
This is similar to how I imagine kernels work when they run on a system with multiple cores. When an interrupt or exception occurs on one core, stuff gets pushed the kernel stack by the hardware--but this could mess up the stack if the kernel is also running on other cores at the moment that the exception/interrupt occurs. Instead, each core's kernel could have a separate stack, designated by entries in the IDT and GDT.