[M3devel] Thread local storage?

[Tony Hosking]

There is a difference between an API call for thread locals (pthread_getspecific/pthread_setspecific) and use of __thread in the gcc backend.
I think the API call should work fine.  But, as I understand it we are now using __thread for thread exception stacks on targets that don't support stack unwinding (only SOLgnu/SOLsun AFAIK).

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On Apr 14, 2011, at 5:32 PM, Jay K wrote:

>  > We've always had thread locals
> 
> ps: user threads do this differently and it could be that m3gdb was never updated for pthreads?
> 
>  - Jay
> 
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; rodney_bates at lcwb.coop
> Date: Thu, 14 Apr 2011 21:27:10 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Thread local storage?
> 
> [I wrote a long answer here but it seemed to have gotten lost.]
> 
> We've always had thread locals via TlsAlloc/TlsSetValue/TlsGetValue / pthread_key_create, pthread_setspecific, pthread_getspecific.
> On Linux we now use __thread instead. It might be a little more efficient. But a much better more difficult change will be to eliminate them in favor of underlying stack walkers.
> There is nothing in cm3cg about this.
> 
> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c
> Revision 1.155: download - view: text, markup, annotated - select for diffs
> Wed Jan 5 18:32:00 2011 MET (3 months, 1 week ago) by jkrell
> Branches: MAIN
> Diff to: previous 1.154: preferred, unified
> Changes since revision 1.154: +2 -1 lines
> Don't use __thread on Solaris.
> It failed to link.
> See:
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/166/console
> Revision 1.151: download - view: text, markup, annotated - select for diffs
> Tue Dec 28 12:53:16 2010 MET (3 months, 2 weeks ago) by jkrell
> Branches: MAIN
> Diff to: previous 1.150: preferred, unified
> Changes since revision 1.150: +30 -0 lines
> Use __thread on Linux and Solaris.
> Doesn't compile on Apple.
> Segfaults on OpenBSD and NetBSD.
> Not tested on FreeBSD, AIX, Irix, HP-UX, etc., stick with pthread_get/setspecific.
> In future hope to eliminate this code anyway, in favor of gcc/libgcc stack walker
>   or C++ exceptions (C++ backend).
> 
>  - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Thu, 14 Apr 2011 17:05:27 -0400
> > To: rodney_bates at lcwb.coop
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Thread local storage?
> > 
> > I think that these were introduced into the C libraries by Jay.
> > 
> > On Apr 14, 2011, at 11:45 AM, Rodney M. Bates wrote:
> > 
> > > I have never understood what "thread local storage" is all about, in particular,
> > > what need it addresses.
> > > 
> > > All local variables and parameters are already private to a thread, as consequence
> > > of semantics going back as far as Algol-60. They are allocated space when and
> > > only when a call is executed. That can't happen until there is a thread to
> > > execute the call and it has to have its own private stack where the space is
> > > allocated, or it wouldn't work as a thread, (OK leaving out languages like
> > > very old Fortrans that don't support recursion either.)
> > > 
> > > That leaves global variables. At least some of these have to be shared by all
> > > the threads of a process, or the threads could have no shared memory interaction,
> > > and thus no function that would not be served by just separate processes running
> > > separate main programs.
> > > 
> > > If you need variables that are private to a thread but in some sense global,
> > > just put them in the Thread.Closure. They would hardly make sense as declared
> > > lexically global variables anyway, since, except for the initial thread provided
> > > by the OS/RTS, their lifetime does not cover the entire execution of the main
> > > program.
> > > 
> > > So what are they really, and what are they for? And do we even have or use them in
> > > Modula-3?
> > > 
> > > It is looking to me like some sort of accommodation for them in cm3cg may be what has
> > > undermined m3gdb in the CVS head.
> > > 
> > > Rodney Bates
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110414/eaadfa9c/attachment-0002.html>