tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: TLS support, MI part



On Fri, Mar 18, 2011 at 03:57:44PM +0000, Andrew Doran wrote:
> On Wed, Mar 09, 2011 at 12:35:04AM +0100, Joerg Sonnenberger wrote:
> 
> > @@ -305,10 +314,16 @@
> >  
> >  static void
> >  pthread__scrubthread(pthread_t t, char *name, int flags)
> >  {
> >  
> > +#if defined(__HAVE_TLS_VARIANT_I) || defined(__HAVE_TLS_VARIANT_II)
> > +   if (t->pt_tls) {
> > +           _rtld_tls_free(t->pt_tls);
> > +           t->pt_tls = NULL;
> > +   }
> > +#endif
> 
> Is there any way it can be recycled efficiently?  Since it will have an
> impact on threading benchmarks.

Not yet. I'm not sure how much can be gained from that since they have
to be initialised anyway.

> >  struct     __pthread_st {
> >     pthread_t       pt_self;        /* Must be first. */
> > +#if defined(__HAVE_TLS_VARIANT_I) || defined(__HAVE_TLS_VARIANT_II)
> > +   struct tls_tcb  *pt_tls;        /* Thread Local Storage area */
> > +#endif
> 
> Hmm I don't see the value to many of the #ifdefs.

It allows platforms to move to TLS support step by step.

> > +(7) Implement _lwp_getprivate_fast() in machine/mcontext.h and set
> > +__HAVE___LWP_GETPRIVATE_FAST.
> 
> Perhas wrap these with #ifndef _KERNEL.  The x86 kernels are free of inline
> assmebly allowing them to be compiled with compilers other than gcc; this
> block may cause problems.

Which compiler are we talking about? I am using this with a compiler
other than GCC.

Joerg


Home | Main Index | Thread Index | Old Index