[boost] Re: boost::shared_ptr<> locking strategies (was Re:Singleton)

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2005-01-12 14:04:07

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.