<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> We've always had thread locals<br><br>ps: user threads do this differently and it could be that m3gdb was never updated for pthreads?<br><br> - Jay<br><br><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: hosking@cs.purdue.edu; rodney_bates@lcwb.coop<br>Date: Thu, 14 Apr 2011 21:27:10 +0000<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] Thread local storage?<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
[I wrote a long answer here but it seemed to have gotten lost.]<br><br>We've always had thread locals via TlsAlloc/TlsSetValue/TlsGetValue / pthread_key_create, pthread_setspecific, pthread_getspecific.<br>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.<br>There is nothing in cm3cg about this.<br><br>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c<br>Revision <b>1.155</b>: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/%7Echeckout%7E/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.155;content-type=text/x-c%2B%2Bsrc" class="ecxdownload-link" target="_blank">download</a> - view: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.155;content-type=text/plain" class="ecxdisplay-link" target="_blank">text</a>, <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.155;content-type=text/x-cvsweb-markup" class="ecxdisplay-link" target="_blank">markup</a>, <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?annotate=1.155" target="_blank">annotated</a> - <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?r1=1.155#rev1.155" target="_blank">select for diffs</a><br>
<i>Wed Jan 5 18:32:00 2011 MET</i> (3 months, 1 week ago) by <i>jkrell</i><br>
Branches: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?only_with_tag=MAIN" target="_blank">MAIN</a><br>
Diff to: previous 1.154: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c.diff?r1=1.154;r2=1.155" target="_blank">preferred</a>, <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c.diff?r1=1.154;r2=1.155;f=u" target="_blank">unified</a><br>
Changes since revision 1.154: +2 -1 lines<br>
<pre class="ecxlog">Don't use __thread on Solaris.<br>It failed to link.<br>See:<br><a href="http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/166/console" target="_blank">http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/166/console</a><br></pre>
Revision <b>1.151</b>: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/%7Echeckout%7E/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.151;content-type=text/x-c%2B%2Bsrc" class="ecxdownload-link" target="_blank">download</a> - view: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.151;content-type=text/plain" class="ecxdisplay-link" target="_blank">text</a>, <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.151;content-type=text/x-cvsweb-markup" class="ecxdisplay-link" target="_blank">markup</a>, <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?annotate=1.151" target="_blank">annotated</a> - <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?r1=1.151#rev1.151" target="_blank">select for diffs</a><br>
<i>Tue Dec 28 12:53:16 2010 MET</i> (3 months, 2 weeks ago) by <i>jkrell</i><br>
Branches: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?only_with_tag=MAIN" target="_blank">MAIN</a><br>
Diff to: previous 1.150: <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c.diff?r1=1.150;r2=1.151" target="_blank">preferred</a>, <a href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c.diff?r1=1.150;r2=1.151;f=u" target="_blank">unified</a><br>
Changes since revision 1.150: +30 -0 lines<br>
<pre class="ecxlog">Use __thread on Linux and Solaris.<br>Doesn't compile on Apple.<br>Segfaults on OpenBSD and NetBSD.<br>Not tested on FreeBSD, AIX, Irix, HP-UX, etc., stick with pthread_get/setspecific.<br>In future hope to eliminate this code anyway, in favor of gcc/libgcc stack walker<br> or C++ exceptions (C++ backend).<br></pre><br> - Jay<br><br><br>> From: hosking@cs.purdue.edu<br>> Date: Thu, 14 Apr 2011 17:05:27 -0400<br>> To: rodney_bates@lcwb.coop<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Thread local storage?<br>> <br>> I think that these were introduced into the C libraries by Jay.<br>> <br>> On Apr 14, 2011, at 11:45 AM, Rodney M. Bates wrote:<br>> <br>> > I have never understood what "thread local storage" is all about, in particular,<br>> > what need it addresses.<br>> > <br>> > All local variables and parameters are already private to a thread, as consequence<br>> > of semantics going back as far as Algol-60. They are allocated space when and<br>> > only when a call is executed. That can't happen until there is a thread to<br>> > execute the call and it has to have its own private stack where the space is<br>> > allocated, or it wouldn't work as a thread, (OK leaving out languages like<br>> > very old Fortrans that don't support recursion either.)<br>> > <br>> > That leaves global variables. At least some of these have to be shared by all<br>> > the threads of a process, or the threads could have no shared memory interaction,<br>> > and thus no function that would not be served by just separate processes running<br>> > separate main programs.<br>> > <br>> > If you need variables that are private to a thread but in some sense global,<br>> > just put them in the Thread.Closure. They would hardly make sense as declared<br>> > lexically global variables anyway, since, except for the initial thread provided<br>> > by the OS/RTS, their lifetime does not cover the entire execution of the main<br>> > program.<br>> > <br>> > So what are they really, and what are they for? And do we even have or use them in<br>> > Modula-3?<br>> > <br>> > It is looking to me like some sort of accommodation for them in cm3cg may be what has<br>> > undermined m3gdb in the CVS head.<br>> > <br>> > Rodney Bates<br>> <br> </body>
</html>