<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I think a minimalist approach where you get to store and retrieve one traced reference per thread would do the trick. If people want more they can design their own abstraction on top of that. Maybe just add the following to the Thread interface:</div><div><br></div><div>PROCEDURE GetPrivate(): REFANY;</div><div>PROCEDURE SetPrivate(ref: REFANY);</div><div><br></div><br><div><div>On 14/09/2010, at 5:59 AM, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">Tony -- then why does pthread_get/setspecific and Win32 TLS exist?<br>What language doesn't support heap allocation were they designed to support?<br>It is because code often fails to pass all the parameters through all functions.<br> <br>Again the best current answer is:<br> #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD.<br> <br>As well, you'd get very very far with merely:<br>#ifdef _WIN32<br>__declspec(thread)<br>#else<br>__thread<br>#endif<br> <br>Those work adequately for many many purposes, are more efficient, much more convenient, and very portable.<br>I believe there is even an "official" C++ proposal along these lines.<br> <br>We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well.<br>Can anyone propose something?<br>It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use.<br> <br> - Jay<br><br> <br>> From:<span class="Apple-converted-space"> </span><a href="mailto:darko@darko.org">darko@darko.org</a><br>> Date: Tue, 14 Sep 2010 05:34:59 -0700<br>> To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] Per thread data<br>><span class="Apple-converted-space"> </span><br>> That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object.<br>><span class="Apple-converted-space"> </span><br>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote:<br>><span class="Apple-converted-space"> </span><br>> > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not?<br>> ><span class="Apple-converted-space"> </span><br>> > On 14 Sep 2010, at 01:08, Darko wrote:<br>> ><span class="Apple-converted-space"> </span><br>> >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table.<br>> >><span class="Apple-converted-space"> </span><br>> >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote:<br>> >><span class="Apple-converted-space"> </span><br>> >>> Darko writes:<br>> >>>> I need to have certain data structures allocated on a per thread basis. =<br>> >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to =<br>> >>>> index a list. Is there a better, more portable way of allocating on a =<br>> >>>> per-thread basis?<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> Cheers,<br>> >>>> Darko.<br>> >>><span class="Apple-converted-space"> </span><br>> >>> In my experience what you suggest works just fine (remember to lock the<br>> >>> doors, though!) But you can get disappointing performance on some thread<br>> >>> implementations (ones that involve switching into supervisor mode more<br>> >>> than necessary when accessing pthread structures).<br>> >>><span class="Apple-converted-space"> </span><br>> >>> Generally speaking I avoid needing per-thread structures as much as possible<br>> >>> and instead put what you need in the Closure and then pass pointers around.<br>> >>> Of course you can mix the methods for a compromise between speed and<br>> >>> cluttered code...<br>> >>><span class="Apple-converted-space"> </span><br>> >>> I think what you want is also not a list but a Table.<br>> >>><span class="Apple-converted-space"> </span><br>> >>> Mika<br>> >><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br></div></span></blockquote></div><br></body></html>