Re: [boost] [proposal]AtomicallyThread-SafeReferenceCountingAlgorithm...

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-10-22 15:48:14

Chris Thomasson wrote:

>> You have two pointers, global and local; what levels of thread
>> safety do these offer?
>
> ptr::global = strong
>
>> Is global the atomic pointer and local the "as safe as an int"
>> equivalent? Or is local to be kept local to a thread?
>
> ptr::local should only have one 1 thread loading or storing into it
> at any one time; local does not have atomic pointer swaps. It makes
> use of impl_base::swap_naked(...). No reason to have atomic pointer
> swaps for a ptr::local. However, the count updates are still atomic.

So ptr::local = basic.

> - You can contain ptr::local<foo> in a shared collection that is protected 
> by a mutex. If the collection was not protected by a mutex then it would 
> have to contain ptr::global<foo> instead.

I don't see how this can work; the collection itself needs to be atomic, not 
its elements (it could demand element atomicity, I guess, but it still needs 
to be atomic on top of that)...

Having two separate pointer types is a legitimate option but (as you 
might've deduced by now) I've been exploring having only one and exposing 
the 'strong thread safety' as separate member functions. The reason I 
haven't added copy/replace to shared_ptr is that I'm not sure whether it 
won't be better to generalize the idea even further and implement something 
along the lines of

atomic_cell< shared_ptr<X> > px;

which would be useful for adding atomicity on top of any (thread-safe as 
int) type, not just shared_ptr.

What do you think of that? Is a "mostly lock-free" atomic_cell possible?