On 2010-10-13 20:18, Walter Bright wrote:
Jacob Carlborg wrote:
I don't know how you have implemented TLS on Mac OS X but it does
support TLS via the Posix API pthreads. This is the only page from
Apple's documentation I could find for now (I'm certain I've seen a
better page)
http://developer.apple.com/macosx/multithreadedprogramming.html .

Yeah, I know about pthreads TLS, but that's wholly inadequate.

According to these:
http://lifecs.likai.org/2010/05/mac-os-x-thread-local-storage.html and
http://lists.apple.com/archives/darwin-dev/2005/Sep/msg00005.html the
implementation of TLS in the Posix API on Mac OS X should be as fast
as the EFL implementation. As the blog post mentions, there is an
inline version of pthread_getspecific. I also have to add that I have
no idea if the pthreads can be used to implement TLS in the compiler.

With gcc on OSX, try this:

__thread int x;

It will fail. Furthermore, OSX has no documented way to allocate TLS
static data in the object file. I spent considerable effort figuring out
a way to do this and get around the numerous bugs in the OSX linker that
tried to stop me.

I just read a bit about how TLS is implemented on linux, just of curiosity what was the problem, the linker, runtime, loader or all? On linux the static TLS data is put in the the object file like any other data. The only difference is it has a different name of the section/segment and an additional flag. Then of course the linker, runtime and loader know about these sections and make any necessary initializations when the application loads.

There's good reason for Windows, Linux, FreeBSD, etc. to support the
declaration of TLS in the C source code.

BTW, the dates on the second article postdate the D TLS implementation
by years. Perhaps Apple has improved things. The third article just
points out problems with the TLS.

Anyhow, the source is here:

http://www.dsource.org/projects/druntime/browser/trunk/src/core/thread.d

and the function you're interested in is ___tls_get_addr. You're welcome
to make improvements to it.

That doesn't seem to be a lot of code to optimize, is Thread.getThis() slow?

--
/Jacob Carlborg

Reply via email to