draft proposal for ref counting in D

[Walter Bright]

Michel Fortin wrote:
Le 30-juin-2013 à 20:25, Steven Schveighoffer a écrit :

 > A->B->C->A
 >
 > this is a cycle.  Imagine that nobody else is pointing at A, B or C.  Fine. 
The GC starts to collect this cycle.
 >
 > But let's say that D is not being collected *AND* B has a reference to D.
 >
 > B could be getting destroyed in one thread, and decrementing D's reference 
count, while someone else in another thread is incrementing/decrementing D's 
reference count.
 >
 > I agree that RC optimally is thread-local.  But if you involve the GC, then 
ref incs and decs have to be atomic.

Exactly what I was trying to explain. Thanks.

 > I don't think this is that bad.  iOS on ARM which has terrible atomic 
primitives uses atomic reference counts.

Moreover iOS uses a single spinlock to protect a global hash table containing 
all reference counts.

 > If you do NOT involve the GC and are careful about cycles, then you could 
potentially have a RC solution that does not require atomics.  But that would 
have to be a special case, with the danger of having cycles.

Not involving the GC is quite difficult: you need to be absolutely sure you have 
no pointer pointing to that thread-local ref-counted object anywhere in the 
GC-heap. Unfortunately, there's no way to guaranty statically what is part of 
the GC heap and what is not, so any non-atomic reference counter is not @safe.