Re: atomic operations for shared_ptr ?

[Bronek Kozicki <brok at spamcop dot net>]

On 25/08/2013 15:28, Federico Terraneo wrote:
> I may well be missing something, but isn't this the kind of problem
> that the "atomic increment and fetch" algorithm in the article solves?
>
> Simply quoting the aticle: "In RCP terms, it atomically copies the
> reference out of memory, then increments the counter of the referent.
> This has to be done atomically to avoid various race conditions. For
> example, one thread may read the reference, another overwrites it and
> deletes the old value (the one the first thread just read), and then
> the first thread increments the counter of the now-defunct object,
> which is bad."

Not really. The kind of problems addressed by the article are solved by 
regular read-modify-write operation, which many CPU architectures have 
implemented directly in hardware (not old generations of PowerPC, 
though). These are available on most moder architectures and do not 
solve the problem, unless two data words can be subjected to one atomic 
operation. Which, as Oleg noted, is the case when 64bit operations are 
available on 32bit platform. If such operation is not available, we have 
to find other means of performing a single atomic operation on two data 
words, and locks are one way of doing it.


B.