Date: Mon, 16 Jun 2003 16:46:36 -0700 From: Gareth Hughes <gareth@nvidia.com> To: 'Julian Elischer' <julian@elischer.org> Cc: Andy Ritger <ARitger@nvidia.com> Subject: RE: NVIDIA and TLS Message-ID: <2D32959E172B8F4D9B02F68266BE421401A6D7E2@mail-sc-3.nvidia.com>
next in thread | raw e-mail | index | archive | help
On Mon, 16 Jun 2003, Julian Elischer wrote: > > I think that the problem is that the access method for TLS is dependent > on which library is used. > > [snip] > > The trouble is that each of these would require a differnt mechanism to > reach TLS and the compiler cannot know ahead of time which one to use. > > [snip] > > I may be wrong but I don't think it is a standard yet.. > especailly for the reason that we see here.. > It requires that the compiler know what threading library is in use. > > We could certainly implement efficient TLS code generation for each > library, but which one would be compiled in when you compile a .o file > that may be used with any library? Please read Ulrich Drepper's document, if you haven't done so already. You'll see that the general case of __thread variable access involves a function call to look up the variables address. There are optimizations to this access model, that allows one of the other three models to be used (ranging from a function call the first time a __thread variable is accessed, down to a single instruction per access). FreeBSD could trivially implement __thread variables with the General Dynamic model (involving a function call per access). Our driver uses the Local Exec model (single instruction per access) because GNU libc has an optimization on x86 that allows shared libraries to use this model, which is normally reserved for applications. The key thing is that they're still __thread variables, the access model depends on the compile time options used and what's available at runtime. Please, I urge you to read Drepper's document carefully. -- Gareth Hughes (gareth@nvidia.com) OpenGL Developer, NVIDIA Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D32959E172B8F4D9B02F68266BE421401A6D7E2>