std.allocator needs your help

[Rainer Schuetze]

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.


> 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?