Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Chris Thomasson
Date : Mon Apr 11 2005 08:25 pm

> There's a bit of a learning curve here.  I don't think the general
> programming community has enough experience in multi-threaded
> programming,  compared to the experience we have here in c.p.t, to have
> a good feel for all the issues yet.

That's for sure.




> For example, when you're doing reference counting in a single threaded
> program, you don't need to distinguish between read access and write
> access.  But when you start using multi-threading, the performance
> implications of distinquishing between read and write access become
> more important, which is why I've been emphasizing smart pointers
> as a solution to the readers/writers problem rather than a generic
> resource management tool.

I guess the smart-pointer's themselves could be considered "generic resource 
management tools"  ;)




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

There is just one problem, if the collection cycles could not keep up with 
user allocs/frees the applications memory usage could climb out of control.




> We're well aware of the problem
> of checking or monitoring threads local references.  That's what makes
> RCU or SMR so tricky.

Indeed. The "collection phase" of basically all distributed garbage 
collection algorithms can be very tricky.




> If there was an easy way around it, we'd be
> using it.  There isn't.   What you have is a bunch of different techniques
> with different trade-offs.  What you do is use the one that gives
> you the most benefit depending on the situation.  There won't be one
> size fits all.

;)

.