[M3devel] Thread local storage?
jay.krell at cornell.edu
Thu Apr 14 23:32:22 CEST 2011
> We've always had thread locals
ps: user threads do this differently and it could be that m3gdb was never updated for pthreads?
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.
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
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.
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
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).
> 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...
More information about the M3devel