Re: std::msync

< Forward Inline >

-------- Original Message --------
Message-ID: <42527847.92E3B24D@[EMAIL PROTECTED]
>
Subject: Re: Lock-free shared_ptr on g++/x86, test/review needed
References: ... <021601c539cc$c8a5ae20$6501a8c0@[EMAIL PROTECTED]
>

Peter Dimov wrote:
[...]
> Yes, but in this case threads are not a problem (we're in release,
> destroying the last remaining shared_ptr; if we read weak_count_ == 1,
no
> other thread can be creating/destroying weak pointers because of basic
> guarantee). Msync is not a problem because we've just acquired in the
> decrement.

Yeah. Hello Peter, remember original

void release() throw() {
  if (!use_count_.decrement()) { // "full" release-acquire protocol
    dispose();
    if (!self_count_.decrement(msync::rel, count::may_not_store_min))
      destruct();
  }
}

?

(msync::rel on self_count_.decrement() was meant for "result is not 
min" case only; with ****d op for "old value == min + 1" case.) 

Sure, it can be safely transformed to 

void release() throw() {
  if (!use_count_.decrement()) { // "full" release-acquire protocol
    dispose();
    if (self_count_.load(msync::****d_competing) == 1 || // min == 0
        !self_count_.decrement(msync::rel))
      destruct();
  }
}

but ...

> 
> Now that I think of it, compiler value propagation isn't a problem
either
> because of the "memory" clobber on the decrement. So the cast to
volatile
> can be removed.
> 
>     void release() // nothrow
>     {
>         if( atomic_exchange_and_add( &use_count_, -1 ) == 1 )
>         {
>             dispose();
> 
>             if( weak_count_ == 1 ) // no weak ptrs

(this doesn't convey the notion of (potentially) competing accesses; who 
says that implementation can't read it bit-after-bit-and-sum-it, bytes 
aside for a moment... just for the sake of breaking your logic?)

>             {
>                 destroy();
>             }
>             else
>             {
>                 weak_release();
>             }
>         }
>     }

.... you also have and manage client-provided "deleter" objects and 
I see no reason why weak_ptr clients may NOT have access to them 
(resulting in similar problem with respect to access and 
destruction as with Whitehead's mutex). 

So to be safe, you need

void release() throw() {
  if (!use_count_.decrement()) { // "full" release-acquire protocol
    dispose();
    if (self_count_.load(msync::ccacq) == 1 || // min == 0
        !self_count_.decrement()) // "full" release-acquire protocol
      destruct();
  }
  // "full" means either "value dependent" or fully-fenced operation
}

So again, 

http://gcc.gnu.org/ml/libstdc++/2005-04/msg00000.html

I suggest that you hide that access in asm (and consider using the 
same operation in weak_release() too... for the sake of KISS-on-IA32 
and "easy" ****ting to RISC archs, where "count::may_not_store_min" 
is surely better in both release() and weak_release()).

regards,
alexander.