Re: thread static

Stefan Monnier <stefan.monnier@epfl.ch> writes:
>Registers are not *that* scarce !


On the x86 hardware they are! Especially if one is already dedicated
to the "this" pointer, one dedicated to the stack frame, etc.. They
don't go far. Nevertheless, I might choose to dedicate one to thread
local storage because of the utility.


Calling the operating system to get a pointer to an array of thread
local pointers can be expensive -- of course some operating systems
still don't support thread local storage and so you have to get a
thread id and look up the pointer in a table -- but still the cost of
getting a thread id and indexing/hashing vs. getting an array of
thread local pointers is about the same -- virtually all of the cost
is in the operating system call. It is ALSO fairly likely (although
I haven't bothered to time it) that the cost of that operating system
call is measured in the area of a microsecond. After all, the call
only has to switch to operating system context, grab something in a
table and return. I might argue that if access to thread local
storage is relatively rare, that might still be the best technique.


But you DEFINITELY don't want to screw with the page tables on
page switching. There are many of us that believe that we need
preemptive switching (sometimes) as frequently as 1ms, so the
cost of light weight thread switching has to be REALLY minimized.


Also consider the problem of dynamically linked libraries which are
separately linked. Then they must have their OWN thead local
storage (just like they have their own process local data). So you
definitely have, not just a single pointer, but an array of pointer.


Also, in many cases, VERY lightweight threads are used and will
not reference any thread local storage (I spin threads off at the
drop of a hat). So the imposing the cost of having thread local
storage for ALL threads is perhaps unreasonable. You may need
to specify when dispatching a new thread if it is to get its own
thread local storage.


I would also see no problem with passing pointers around. Surely
those doing so know how to handle concurrency, don't they? :-)
So, of course, they won't make silly mistakes like not properly
protecting their data, will they?


Michael Lee Finney
--

Return to the comp.compilers page.
Search the comp.compilers archives again.