D array expansion and non-deterministic re-allocation

[Steven Schveighoffer]

On Tue, 24 Nov 2009 12:46:37 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>
>>>> The cache is a thread-local map from pointers to size_t. Using it  
>>>> does not require any locking I think.
>>>
>>> When reallocating, do you not also need to update the allocated length  
>>> in the heap, even if the allocation fits into the same block to  
>>> prevent other threads from stomping?  Doesn't that require a lock?   
>>> Somewhere you have to share the allocated length between threads  
>>> sharing the same array.  I assumed it was going to be in the MRU  
>>> cache...
>>  If all this is true, I had another thought for an MRU cache.  It could  
>> simply be a map of pointers to the right blocks in the GC that store  
>> the lengths (to avoid the block search with the global mutex locked).
>
> That's a great idea. I keep on dreaming someone will implement all this  
> stuff we talk about :o).
>
>> Lookup should be atomic without locking (I think, simply an integer  
>> load right?), but you'd have to lock to actually do an append.
>>  I don't think we solve the lock problem without having multiple  
>> heaps...
>
> I don't think we need to worry about optimizing growth of shared arrays.

What about immutable arrays?  Can't those be shared without being marked  
as shared?

-Steve