Re: [boost] [proposal] Atomically Thread-Safe ReferenceCountingAlgorithm...

From: Chris Thomasson (cristom_at_[hidden])
Date: 2006-10-20 17:40:09

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:009a01c6f39f$c72f3ff0$6507a8c0_at_pdimov2...
> Hey Chris,

[...]

>> Here is a experimental prototype I created:
>>
>> http://appcore.home.comcast.net/vzoom/refcount/
>
> This doesn't contain any documentation, only source. You can't expect
> people
> to understand it without at least a brief reference that specifies what
> the
> various functions are supposed to do.

Yeah... Sorry. I plan on posting docs soon.

[...]

> Imagine that I add two member functions to shared_ptr:
>
> shared_ptr<T> shared_ptr<T>::copy() const; // return *this
> void shared_ptr<T>::replace( shared_ptr<T> const & p ); // *this = p
>
> that are synchronized with a mutex/spinlock/rwlock/rwspinlock and I
> declare
> that "strong" thread safety is offered only when everything goes through
> these two accessors and nothing else.

That should work...

> Is this inferior to your proposed scheme?

Maybe... Currently, all of my pointer-ops are 100% lock-free. My reference
count adjustments are 100% lock-free for everything except strong competing
accesses (e.g., it only *takes a spinlock for strong competing accesses,
**and when the count drops to zero). My counter objects can be swapped using
normal word-based atomic operations (e.g., XCHG and CAS, no DWCAS
required)...

Also, I can use parts of my algorithm in the context of a signal handler.
Can you use any part of shared_ptr<T> in a signal handler? I think the
answer is going to be NO; however, I would love to be corrected if I am
wrong...

;)

> In what scenarios?

I think my scheme could possibly be more efficient because all of the
pointer-ops are 100% lock-free, and most of the reference counts are 100%
lock-free... Humm... I would have to see a sketch of the algorithm you have
in mind Peter...

> Can you
> implement the copy/replace interface in a "more lock-free way" using your
> scheme (you are allowed to add to sp_counted_base whatever members you
> need)?

Let me define some of the previous asterisks:

*, **: The "hashed locking scheme can be completely replaced with one of my
PDR schemes" I posted here:

http://groups.google.com/group/comp.arch/browse_frm/thread/b2f751d5dad6c07b
(DWCAS: no)

or this one I posted here:

http://groups.google.com/group/comp.programming.threads/msg/f443b38cf7bbca8a
http://groups.google.com/group/comp.programming.threads/msg/a4a796e25a157ca1
(DWCAS: yes)

This stuff is not in my prototype yet... I guess I should augment it with
PDR. Once I do that, then I can implement copy/replace in a 100% lock-free
way...

Humm... Does any of this begin to address your questions Peter?