On Tue, 24 Nov 2009 12:46:37 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
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.
What about immutable arrays? Can't those be shared without being marked
as shared?
-Steve
