[M3devel] Per thread data

[Darko]

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