Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on December 4, 2014 2:49 pm wrote:
> Konrad Schwarz (no.spam.delete@this.no.spam) on December 4, 2014 1:10 pm wrote:
> > The code base / programmer mindset that relies on atomic operations stems from
> > a time/from operating systems where such light weight were not available.
>
> Not for all use cases. Thread-safe reference counting - something very common in C++
> - would be a couple of order of magnitudes slower using locks rather than atomic operations
> across pretty much any architecture I know of.

I really ought to test this -- a "couple of order of magnitudes" seems excessive.

Also, consider: a reference counted object has a
finite lifetime, otherwise, no reference count is required.

Hence it is (in general) not const
(i.e. mutable, or whatever it is called in C++).

Since it is being accessed in a multi-threaded way, via multiple access paths,
generally it needs its own mutex -- otherwise, reference counting would not
be required to be atomic and a lock of a higher-level object would suffice.

Since, when accessing the object, you already need to take the mutex,
you can adjust the reference count non-atomically while owning the mutex.

So atomic reference counts are useful only for dynamically-created but
otherwise const objects, or where every other mutational operation is
implemented by a single atomic operation.

So, "atomic reference counts" still seems like a poor architectural pattern
to me.