Nvidia, TLS and __thread keyword -- an observation

[Marcel Moolenaar]

Guys,

I haven't followed the threads related to Nvidia and TLS, but after
browsing the archives it's clear that people don't understand the
issue and/or each other. Consequently, people get pissed off for
no good reason at all.

The __thread keyword does not originate from Linux and has no
relation to kernel and/or user threading. It has been introduced
to work around the limitations of pthread provided mechanisms
for thread local storage. It's a language extension that requires
support by the compiler, linker, runtime linker and threading
libraries.

Whether we want to support the __thread keyword or not is unrelated
to why OpenGL makes use of it. Any suggestion that OpenGL needs to
change their interfaces is utterly bollocks. Likewise, suggestions
made to reserve space for OpenGL is also not to the point. The whole
pivoting role of %gs is purely circumstantial. You can implement
TLS as implied by the __thread keyword in lots of different ways.

The simple truth of the matter is that OpenGL uses the __thread
keyword to create thread local variables and if we don't support
the __thread keyword (we do not now), we don't support OpenGL
(at least, proprietary implementations) in all cases.

There's a definite advantage to supporting the __thread keyword in
userland and we should add the support. It really isn't that hard,
but it requires some thought and testing. In most cases you simply
point your thread pointer between the control structure and the
thread local segments.

For dynamic TLS, Sun has come up with a mechanism that annihilates
all the performance advantages and consequently made it the default
model. This is where the __tls_get_addr() function call comes into
play (you don't need it for the static TLS model). It sucks, but
allows loading shared libraries that contain TLS.

Adding support for the __thread keyword in the kernel is probably
not worth it.

In short: Don't bash Nvidia. What they do is not uncommon. Well,
maybe in Open Source environments. So please end this thread,
unless people get constructive.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net