Konrad Schwarz (no.spam.delete@this.no.spam) on December 4, 2014 11:08 pm wrote:
> I really ought to test this -- a "couple of order of magnitudes" seems excessive.

This contains a couple of data-points: Lockless Programming Considerations for Xbox 360 and Microsoft Windows

For the XBox 360 POWER processor:

lwsync was measured as taking 33-48 cycles.
InterlockedIncrement was measured as taking 225-260 cycles.
Acquiring or releasing a critical section was measured as taking about 345 cycles.
Acquiring or releasing a mutex was measured as taking about 2350 cycles.

For an unspecified x86 processor:

MemoryBarrier was measured as taking 20-90 cycles.
InterlockedIncrement was measured as taking 36-90 cycles.
Acquiring or releasing a critical section was measured as taking 40-100 cycles.
Acquiring or releasing a mutex was measured as taking about 750-2500 cycles.

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

Objects are rarely reference-counted per se, smart pointers are i.e. std::shared_ptr or its many predecessors widely deployed in large C++ codebases, RefPtr in WebKit/Blink and nsRefPtr in Gecko are two examples. The smart pointer must assume it *may* be accessed by multiple-threads hence the thread-safe reference counting.

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

I happen to agree with your assessment, I don't have any particular love for them, but they're actually very, very common in modern codebases thanks to the wide use of smart pointers classes.