Subj : Re: A question about atomic_ptr
To   : comp.programming.threads
From : Peter Dimov
Date : Sat Apr 16 2005 04:52 pm

Chris Thomasson wrote:
>> A non-tricky copy constructor cannot be made
>> race-resistant, no matter how I fiddle with the assignment.
>
> Here is a "tricky" way to increment a reference count wrt strong
> thread safety:

[ hazard pointers algorithm ]

> http://appcore.home.comcast.net/appcore_4_1_2005.zip
> ( full source to AppCore. )

Totally incomprehensible. ;-) I'll probably need a day or two to navigate 
that.

ac_i686_lfgc_smr_activate_reload:
  mov eax, [ecx]
  mov [edx], eax
  mfence
  cmp eax, [ecx]
  jne ac_i686_lfgc_smr_activate_reload

Have you tried lock mov [edx], eax or lock cmp eax, [ecx]?

From what I can understand, it looks like a textbook hazard pointer 
implementation. (Except that you are using the high bit of the reference 
count for something that I haven't deciphered yet.)

For me, the most painful part of a hazard pointer implementation is the 
pointer-per-thread table (ac_thread.c). (There are some issues with 
destruction and deallocation but they probably can be solved.)

But there's one other thing: shared_ptr is two pointers, not one. Without 
DWCAS, or at least double-wide atomic loads and stores, even hazards aren't 
enough to make it atomic. :-(

.