[M3devel] Per thread data

[Jay K]

Tony -- then why does pthread_get/setspecific and Win32 TLS exist?
What language doesn't support heap allocation were they designed to support?
It is because code often fails to pass all the parameters through all functions.
 
Again the best current answer is:
  #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD.
 
As well, you'd get very very far with merely:
#ifdef _WIN32
__declspec(thread)
#else
__thread
#endif
 
Those work adequately for many many purposes, are more efficient, much more convenient, and very portable.
I believe there is even an "official" C++ proposal along these lines.
 
We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well.
Can anyone propose something?
It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use.
 
 - Jay

 
> From: darko at darko.org
> Date: Tue, 14 Sep 2010 05:34:59 -0700
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Per thread data
> 
> 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.
> 
> On 14/09/2010, at 5:08 AM, Tony Hosking wrote:
> 
> > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not?
> > 
> > On 14 Sep 2010, at 01:08, Darko wrote:
> > 
> >> 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.
> >> 
> >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote:
> >> 
> >>> Darko writes:
> >>>> I need to have certain data structures allocated on a per thread basis. =
> >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to =
> >>>> index a list. Is there a better, more portable way of allocating on a =
> >>>> per-thread basis?
> >>>> 
> >>>> Cheers,
> >>>> Darko.
> >>> 
> >>> In my experience what you suggest works just fine (remember to lock the
> >>> doors, though!) But you can get disappointing performance on some thread
> >>> implementations (ones that involve switching into supervisor mode more
> >>> than necessary when accessing pthread structures).
> >>> 
> >>> Generally speaking I avoid needing per-thread structures as much as possible
> >>> and instead put what you need in the Closure and then pass pointers around.
> >>> Of course you can mix the methods for a compromise between speed and
> >>> cluttered code...
> >>> 
> >>> I think what you want is also not a list but a Table.
> >>> 
> >>> Mika
> >> 
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100914/2b4edfcc/attachment-0002.html>