[M3devel] Per thread data

[Tony Hosking]

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
>