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

From: Chris Thomasson (cristom_at_[hidden])
Date: 2006-10-22 16:33:06

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:00e901c6f613$06ed8a00$6607a8c0_at_pdimov2...
> 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.

Yup.

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

Are you referring to the case in which a collection was not protected by a 
mutex? If so, I was basically referring to some sort of lock-free, or mostly 
lock-free collection. You can use ptr::global in a lock-free collection, it 
isn't very practical because of the spinlock, but it is compatible. Its was 
just a simple example to show some of the algorithms flexibility...

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

Interesting...

> Is a "mostly lock-free" atomic_cell possible?

Probably, but it might be more expensive that a more direct solution... 
Humm... Need to put my thinking cap back on...