== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > Steven Schveighoffer wrote: > > On Tue, 24 Nov 2009 11:41:17 -0500, Steven Schveighoffer > > <schvei...@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
But if the full semantics of shared are not implemented for D2 (will they be), how do we even detect shared arrays?