Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Tue Apr 12 2005 04:00 pm

Chris Thomasson wrote:
>> There seems to be some attraction in c.l.c++.m to smart pointers that
>> have almost no overhead, the deferred reference counting being
>> promoted by Andrei but there's no such thing a a free lunch. Deferred 
>> reference counting does Boehm style GC against the thread
>> stacks and that requires a "stop the world while we GC" which has huge
>> performance implications in multi-threading.
>
> Actually, you mentioned a scheme that would allow for "deferred
> reference counting" using per-thread lock-free
> single-producer/consumer queues. Pushing a node ( reference
> adjustment request ) into a "local" per-thread queue is certainly
> less overhead than performing an interlocked-operation on a "shared"
> variable. I don't think you would need to use DWCAS either. The logic
> could be isolated in the "collection phase"...

Thread-local count update queues only work if you are willing to postpone 
the destruction for an unspecified amount of time, IIUC.

p1 = 0; // thread 1

p2 = 0; // thread 2

Now if these were the only two references to *p1 and if thread 1 and thread 
2 don't do anything smart pointer related in the next few hours, *p1 will be 
kept alive.

And if you drop the deterministic destruction requirement, reference 
counting is usually less efficient than other garbage collection 
algorithms... not all of them need to stop the world (if my understanding is 
correct).

I tried to come up with a deferred counting scheme where only non-essential 
updates would be queued but the final transition from non-zero refs to zero 
was always done "on time", but I failed. It might be possible, I haven't 
studied the refcounting research much. But even if it is, it would probably 
be less efficient on today's hardware for the typical shared_ptr uses in 
C++, where most non-essential count updates are manually eliminated (or just 
not introduced) by the programmer.

(Now that I think about it, it may be possible to use such a scheme for 
local_ptr, which is supposed to never be shared between threads, but not for 
shared_ptr, which can be shared if accesses are properly synchronized.)

.