[boost] Re: Lock-free shared_ptr on g++/x86, test/review needed

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2005-04-04 03:18:21

Peter Dimov wrote:
[...]
> If you are interested, please take a look at the file 

Looks correct, but sill not quite optimal to my taste.

A) There's no need to hinder compiler's ability to cache/reorder 
across increments. So you need neither __volatile__ nor "memory" 
clobber in increments case (lock prefix is still needed to ensure 
MP safety of competing read-modify-write operations).

B) Something branchless is better for unconditional increments.

C) In the case of decrements on weak_count, there's no need to
make all clients pay the price of rather expensive interlocked
operation even if they don't use weak pointers. I'd use "may
not store zero" decrement. You'll need __volatile__ and "memory" 
as compiler fence, and as for hardware, that initial load does
have acquire semantics and lock cmpxchg does have "msync::hsb"
which we need here.

[...]
> thanks to Alexander Terekhov 

Thanks to you for helping me to identify the problem with lock()
(lack of inter-thread ordering with respect to that access and
destruction of control block when the object is expired) in my
original sketch.

regards,
alexander.

P.S. When are you going to kick start an incarnation for Itanic 
with value dependent cmpxchg.rel-vs-cmpxchg.acq? ;-)