[M3devel] Per thread data

[Jay K]

Sure. <* ThreadLocal *> or such, be sure it mentions "thread".

 - Jay



________________________________
> Subject: Re: [M3devel] Per thread data
> From: hosking at cs.purdue.edu
> Date: Tue, 14 Sep 2010 12:48:22 -0400
> CC: darko at darko.org; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> 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
> > >>
> > >
> >
>