>If as a thread, I ask for a new thread to be created and hence a new
>stack, I would guess (but I don't know) that the base for all stack
>pointers are stored in some global, locked, table, along perhaps with
>the limits of the stack which are either stored in that table, or
>local to the stack itself.
Suppose it is. Now you've got to locate the table - which, unless you're
willing to limit the number of simultaneous threads, must be able to
grow and therefore cannot be at a fixed address. Once you've located
the table, you've got to search it using the current SP as the search
key. Maybe you do it by binary search; maybe you do it by hashing the
high bits of SP. Whichever way you choose, I think it's going to require
several instructions.
Well the base of the table has to be at a fixed address, but it could be
a linked pointer. Or since growing it is presumably rare, it could be a
table that grows and when it does grow threads are momentarily blocked
from using it. No telling what the performance impacts are....
At any rate, I had thought we were talking about, for the most part,
rare occasions when new threads are created. If so, then taking a few
instructions or a loop to determine where the new stack can go seems
like it could be reasonable.
> Note that each time you create a stack from (or otherwise dynamically
> extend the stack), you need to compare the SP to a thread-specific
> limit, which means using TLS.
So using TLS storage appears to be an optimization (and in the case of
creating new stacks, and figuring out where they can go, a not terribly
profitable optimization) but not a requirement.
Thanks for your explanation. The truth is in the details. I can
clearly see architectures that permit all sorts of stuff but again, who
knows which will have sucky behavior or not.
Oh for Multics and being able to just ask for a new 2g segment at will.
Alas.
Jerry
