[M3devel] Thread local storage?

[Jay K]

[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/0b508e82/attachment-0002.html>