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.
