D array expansion and non-deterministic re-allocation
Steven Schveighoffer
schveiguy at yahoo.com
Tue Nov 24 10:06:57 PST 2009
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).
Note this also solves the problem of having to flush the MRU cache on a
collection -- the same allocated length property should remain attached to
that block.
:)
-Steve
More information about the Digitalmars-d
mailing list