Atomic Ref Counting

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> On 11/22/10 7:27 AM, dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
> >> Thanks for taking the time to build a credibla baseline. A lot of this
> >> depends on the perspective. We're looking at a 2.9x slowdown after all.
> >
> > Right, but this isn't a 2.9x slowdown in real world code.  It's a 2.9x slowdown in
> > a synthetic benchmark that does nothing but increment and decrement reference
> > counts.  Real world code would likely have a loop body and stuff.  That's why I
> > consider it minor.
> I think the cost is close to the real cost of copying a refcounted
> object. Experience with refcounted languages has shown that copies do
> impact the bottom line considerably. I wouldn't haste to discount a 2.9x
> factor.
> Andrei

Ok, if the destructor issue needs to be solved for the general case anyhow, then
how about making it configurable with a default of non-atomic?  If you want to
share a ref counted object across threads and be responsible for your own higher
level synchronization issues, you use atomic ref counting.  If you want to create
a shared wrapper, you make it use atomic under the hood.  If you're not sharing
the structure across threads, you stick with the default.