Re: thread-local storage, especially on x86
Re: thread-local storage, especially on x86
- Subject: Re: thread-local storage, especially on x86
- From: Gary Byers <email@hidden>
- Date: Sun, 11 Sep 2005 12:12:32 -0600 (MDT)
On Sun, 11 Sep 2005, Matt Watson wrote:
On Sep 11, 2005, at 10:35 AM, Gary Byers wrote:
The concerns that I have aren't based on the belief that the pthread
library functions are somehow grossly inefficient
If not performance, then what are your concerns, exactly?
As I thought I explained in my message, I'm concerned about perfomance.
Darwin/x86 already uses %gs internally as the selector for TLS, just like
Linux.
There's a difference between "having a dedicated register point to
TLS" and "having an API for fast access to TLS." An example of
the latter is described in:
<http://people.redhat.com/drepper/tls.pdf>
The 64-bit PowerPC ABI reserves r13 for TLS.
Yes, I know.
I can't access that thread-local storage directly (without the overhead
of a function call), because the contents of r13/%gs are opaque.
Since the 32-bit PowerPC Mac OS X ABI does not provide a register dedicated
to TLS, Darwin/ppc uses a user readable SPRG on platforms which support it
(i.e. G5), and an optimized kernel trap on platforms which don't.
It's certainly a step forward to not require a trap to access thread-local
storage.
It would be a further step forward to not require a function call.
Perhaps if you stated your complaint more succinctly, without trying to
design the solution first, it would be more evident how you would like the
implementation to behave.
I was trying to describe the issue. I honestly thought that I did so,
If you still don't understand the point that I'm trying to make, I'd
be willing to try again.
matt.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden