<html><head><base href="x-msg://170/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ah, sorry. I misunderstood.  Sounds like we need a thread-local pragma <*LOCAL*>?<div>
<br><div><div>On 14 Sep 2010, at 08:59, 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></div></body></html>