Larry Evans wrote: [...]
why are increments "naked"
Because additional constrains imposed on compiler and/or hardware with respect to reordering across increments would serve no purpose for the intended use of that smart pointer.
and what does "naked" mean?
Naked means "no barrier". BTW, for mutable objects with trivial destructors, use_count_ decrements do need classic msync::rel (release) but don't need classic msync::acq (when the count drops to min/zero), only cchsb (control condition hoist store barrier) and only if you can write something to the storage of the dead object (reuse it). A sorta pseudo C++ illustration of cchsb can be found here: http://www.google.de/groups?threadm=418AAF67.99C5F579%40web.de See also http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf I mean section 4.1. In mutex_and_condvar_free_single_producer_single_consumer case, "speculative" (hoisted above control condition) store doesn't need any correction (let's treat usleep() as no-throw ;-) ). regards, alexander.