[M3devel] Thread local storage?

Fri Apr 15 04:46:46 CEST 2011

__thread is only used in C code. The difference is in the gcc backend within the gcc C/C++ compiler. Not cm3cg.

 I put in using __thread for Linux. There is some potential for using it elsewhere, but that's all I did. e.g. Solaris sometimes, AIX.
 All other non-Windows targets use pthread_getspecific/setspecific. 
 It is hidden from any Modula-3 code. It is all in C. m3gdb might might might need to know about it. It could also be that m3gdb gets confused by any C code linked in. Or that m3gdb is old (it is) and is confused by __thread (but again, m3gdb might or might not have a builtin need to often look at these, or maybe just the human debugger wants to see them).

Currently no targets support stack walking. I couldn't get SOLgnu/SOLsun's stack walker to work with the gcc 4.5 backend. I really really tried. I tried not optimizing at all. And/or putting volatile everywhere.
Tru64 also didn't work despite a bit of an attempt. I probably also tried not optimizing there. I probably didn't try as much as for SOLgnu/SOLsun due to the machine being slower and the platform being in less use.

 - Jay

From: hosking at cs.purdue.edu
Date: Thu, 14 Apr 2011 20:28:12 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Thread local storage?

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 University305 N. University Street | West Lafayette | IN 47907 | USAOffice +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/20110415/3ee8cf48/attachment-0002.html>