Thread local and memory allocation

[Andrew Wiley]

On Tue, Oct 4, 2011 at 3:52 AM, Walter Bright
<newshound2 at digitalmars.com> wrote:
> On 10/4/2011 1:22 AM, deadalnix wrote:
>>
>> Do you mean manage the memory that way :
>> Shared heap -> TL pool within the shared heap -> allocation in thread from
>> TL pool.
>>
>> And complete GC collect.
>
> Yes.
>
>
>> This is a good solution do reduce contention on allocation. But a very
>> different
>> thing than I was initially talking about.
>
> Yes.
>
>
>> Back to the point,
>>
>> Considering you have pointer to immutable from any dataset, but not the
>> other
>> way around, this is also valid to get a flag for it in the allocation
>> interface.
>>
>> What is the issue with the compiler here ?
>
> Allocate an object, then cast it to immutable, and pass it to another
> thread.
>

Assuming we have to make a call to the GC when an object toggles its
immutable/shared state, it seems like this whole approach would
basically murder anyone doing message passing with ownership changes,
because the workflow tends to be create an object -> cast to shared ->
send to another thread -> cast away shared -> do work -> cast to
shared...
On the other hand, I guess the counterargument is that locking an
uncontended lock is on the order of two instructions (or so I'm told),
so casting away shared probably isn't ever necessary. It just seems
somewhat counterintuitive that casting to and from shared would be
slower than unnecessarily locking the object.