DIP80: phobos additions

[Steven Schveighoffer via Digitalmars-d]

On 6/10/15 11:49 AM, Andrei Alexandrescu wrote:
> On 6/10/15 3:52 AM, Steven Schveighoffer wrote:
>> On 6/9/15 5:46 PM, Andrei Alexandrescu wrote:
>>> On 6/9/15 1:53 PM, Steven Schveighoffer wrote:
>>>> On 6/9/15 2:59 PM, Andrei Alexandrescu wrote:
>>>>> On 6/9/15 11:42 AM, Dennis Ritchie wrote:
>>>>>> "And finally `std.bigint` offers good (but not outstanding)
>>>>>> performance."
>>>>>
>>>>> BigInt should use reference counting. Its current approach to
>>>>> allocating
>>>>> new memory for everything is a liability. Could someone file a report
>>>>> for this please. -- Andrei
>>>>
>>>> Slightly OT, but this reminds me.
>>>>
>>>> RefCounted is not viable when using the GC, because any references on
>>>> the heap may race against stack-based references.
>>>
>>> How do you mean that?
>>
>> If you add an instance of RefCounted to a GC-destructed type (either in
>> an array, or as a member of a class), there is the potential that the GC
>> will run the dtor of the RefCounted item in a different thread, opening
>> up the possibility of races.
>
> That's a problem with the GC. Collected memory must be deallocated in
> the thread that allocated it. It's not really that complicated to
> implement, either - the collection process puts the memory to deallocate
> in a per-thread freelist; then when each thread wakes up and tries to
> allocate things, it first allocates from the freelist.

I agree it's a problem with the GC, but not that it's a simple fix. It's 
not just a freelist -- the dtor needs to be run in the thread also. But 
the amount of affected code (i.e. any code that uses GC) makes this a 
very high risk change, whereas changing RefCounted is a 2-line change 
that is easy to prove/review. I will make the RefCounted atomic PR if 
you can accept that.

>>>> Can we make RefCounted use atomicInc and atomicDec? It will hurt
>>>> performance a bit, but the current state is not good.
>>>>
>>>> I spoke with Erik about this, as he was planning on using RefCounted,
>>>> but didn't know about the hairy issues with the GC.
>>>>
>>>> If we get to a point where we can have a thread-local GC, we can remove
>>>> the implementation detail of using atomic operations when possible.
>>>
>>> The obvious solution that comes to mind is adding a Flag!"interlocked".
>>
>> Can you explain it further? It's not obvious to me.
>
> The RefCounted type could have a flag as a template parameter.

OK, thanks for the explanation. I'd do it the other way around: 
Flag!"threadlocal", since we should be safe by default.

-Steve