On 9/24/13 2:02 PM, Rainer Schuetze wrote:
On 24.09.2013 21:36, Andrei Alexandrescu wrote:
On 9/24/13 11:28 AM, Rainer Schuetze wrote:
expand is nice, but I don't like minDelta and maxDelta as arguments. On
a shared allocator this can lead to undesired side-effects, i.e. when
this function is called concurrently on the same block by two threads,
the net result will be the sum of the deltas of the two threads, while
later synchronization on the memory block might only allow one thread to
actually use the extended memory area. This can happen with gc_extend in
the current GC when appending to a shared array.
I'd prefer the function to actually pass the desired sizes:
void[] expand(void[] b, size_t minSize, size_t maxSize);
I don't understand this argument. These parameters can be trivially
computed from the others, after which locking etc. proceeds just the
same.
Taking the current array implementation as an example, the deltas are
computed before the actual GC lock happens inside gc_extend which means
that the second of two concurrent requests leads to overallocation.
(I'm confused - which array implementation?) Does this qualify as an
implementation bug, or are you referring to the case where the void[]
being reallocated is being shared?
FWIW I chose the "delta"-based signature because with it the
precondition is:
assert(minDelta <= maxDelta);
In fact behavior can be easily defined at no cost even if this
precondition is not satisfied. With the "absolute"-based signature the
precondition is:
assert(minSize <= maxSize && b.length <= minSize);
which causes confusion - people will pass small sizes to expand()
expecting it to contract, something that expand() can't support as a
matter of principle (safety!!!).
Why would you expect a function "expand" to reduce the memory size?
Ask Dmitry :o). Far as I can tell he assumed so.
Andrei
