[M3devel] Per thread data

[Tony Hosking]

Ah, sorry. I misunderstood.  Sounds like we need a thread-local pragma <*LOCAL*>?

On 14 Sep 2010, at 08:59, Jay K wrote:

> 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/c1208444/attachment-0002.html>