D array expansion and non-deterministic re-allocation

[Andrei Alexandrescu]

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.


Andrei