D array expansion and non-deterministic re-allocation

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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

But if the full semantics of shared are not implemented for D2 (will they be), how
do we even detect shared arrays?