DIP80: phobos additions

[Andrei Alexandrescu via Digitalmars-d]

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.

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


Andrei