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

From: Chris Thomasson (cristom_at_[hidden])
Date: 2006-10-21 23:37:46

"Chris Thomasson" <cristom_at_[hidden]> wrote in message 
news:ehenuk$if2$1_at_sea.gmane.org...
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message 
> news:000601c6f582$10c92890$6507a8c0_at_pdimov2...
>> Chris Thomasson wrote:
>>> The basic technique for 'copying' is as follows:

[...]

I need to clarify one thing here

> A refcount object drop to zero condition means that there are no shared 
> locations that contain any pointers to it. Any increment threads that have 
> loaded pointers, will fail when they reload-and-compare.

[...]

> If one gets through, and their compare succeeds, it doesn't matter because 
> it has already locked the associated spinlock, so it has exclusive access 
> to the refcount. Since its reload and compare succeeded, that means it 
> happened before any decrement thread got to execute; swaps happen before 
> decrements (e.g., swap shared loc with 0, dec the old ptr). A decrement 
> thread will always lock the spinlock before it calls the destructor, so it 
> will wait for the one that got through the compare logic...
^^^^^^^^^^^^^^^^^

I forgot to mention that the thread that got through the gap between the 
decrement to 0, and the lock, it will be subject to the compare logic and/or 
the logic the prevents a copy when a refcount value get increments and its 
previous value was less than 1. I know this is a bit tricky logic, however I 
believe that if you examine some more you will find it to be correct...

;^)