<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
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: darko@darko.org<BR>> Date: Tue, 14 Sep 2010 05:34:59 -0700<BR>> To: hosking@cs.purdue.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Per thread data<BR>> <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>> <BR>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote:<BR>> <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>> > <BR>> > On 14 Sep 2010, at 01:08, Darko wrote:<BR>> > <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>> >> <BR>> >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote:<BR>> >> <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>> >>>> <BR>> >>>> Cheers,<BR>> >>>> Darko.<BR>> >>> <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>> >>> <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>> >>> <BR>> >>> I think what you want is also not a list but a Table.<BR>> >>> <BR>> >>> Mika<BR>> >> <BR>> > <BR>> <BR> </body>
</html>