[M3devel] Per thread data

[Darko]

The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable.

I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that?


On 14/09/2010, at 7:05 AM, Jay K wrote:

> 
> 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
>>>>> 
>>>> 
>>> 
>> 
>