draft proposal for ref counting in D

[Sean Kelly]

On Thursday, 10 October 2013 at 02:28:13 UTC, Walter Bright wrote:
> Steven Schveighoffer wrote:
>
> On Jun 30, 2013, at 8:18 PM, Walter Bright wrote:
>
> >
> > I very much want to avoid requiring atomic counts - it's a
> major performance penalty. Note that if the GC is reaping a 
> cycle, nobody else is referencing the object, so this should 
> not be an issue.
>
> I think you didn't understand what Michel was saying.
>
> Take for example:
>
> 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.

I think this ties into the requirement that after the GC collects 
thread-local objects, they must be finalized by the thread that 
owns them (assuming it's still alive).  What's missing is some 
way to track what thread owns an object.  This isn't super 
difficult to add in the simple case, but if we allow thread-local 
objects to be transferred between threads, then the transferral 
of ownership has to be communicated to the GC.  Assuming for the 
moment that's not a problem though, I think RC updates could be 
non-atomic for thread-local data.