[M3devel] Per thread data

[Jay K]

Eh? Just one thread local for the entire process? I think not.

More like:

PROCEDURE AllocateThreadLocal(): INTEGER;
PROCEDURE GetThreadLocal(INTEGER):REFANY;

PROCEDURE SetThreadLocal(INTEGER;REFANY);


or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet.
The first set of names sounds better, the second "scales" better.
This seems like a constant dilemna.

btw, important point I just remembered: unless you do extra work,
thread locals are hidden from the garbage collector.

This is why the thread implementations seemingly store extra data.
The traced data is in globals, so the garbage collector can see them.

 - Jay

________________________________
> From: darko at darko.org
> Date: Tue, 14 Sep 2010 06:13:26 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Per thread data
>
> I think a minimalist approach where you get to store and retrieve one
> traced reference per thread would do the trick. If people want more
> they can design their own abstraction on top of that. Maybe just add
> the following to the Thread interface:
>
> PROCEDURE GetPrivate(): REFANY;
> PROCEDURE SetPrivate(ref: REFANY);
>
>
> On 14/09/2010, at 5:59 AM, 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
> > >>
> > >
> >
>