Fw: [patch] Make std::tr1::shared_ptr thread-safe.

[Alexander Terekhov]

"Peter Dimov" <pdimov@mmltd.net> on 30.03.2005 20:58:31:
> 
> Jakub Jelinek wrote:
> > Even as an interim solution it sounds wrong.  The lock has been added
> > to this method only, so it would only protect from concurent
> > add_ref_lock calls.  But _M_use_count is changed in a bunch of other
> > methods as well, so either you use atomic instructions everywhere, or
> > you use (the same) lock everywhere, but mixing that just can't work.
> 
> It is correct, to the best of my knowledge. This is Tyson Whitehead's...

I second that.

<Forward Inline>

Alexander Terekhov
14.07.2004 16:55

To:    pdimov@mmltd.net
Subject:    Re: Fwd: Fw: lightweight mutex

Yup, it's correct. Uhmm, but "use_count_ = 0" is probably better
than "--use_count_" -- less work for the ALU (given that compilers
may not figure out that the value of use_count_ is guaranteed to
remain 1 when atomic_increment(use_count_) in add_ref_lock() sets
it to 1) and one less trip to memory, oder?

regards,
alexander.

To:    Alexander Terekhov/Germany/IBM@IBMDE
cc:
Subject:    Fwd: Fw: lightweight mutex

"Peter Dimov" <pdimov@mmltd.net> schrieb am 10.07.04 00:30:29:

What do you think? The code seems correct to me, but I could've easily
missed something.

Tyson Whitehead wrote:
> Russell Hind wrote:
>> If you're referring to the ref-counted shared_ptr, then it has two
>> counts it needs to keep track of, strong_count and weak_count, so
>> InterlockedXXXXXX can't be used.  Therefore the 'spin-lock' was
>> introduced IIUC.
>
> I like the looks of the 'shared_count_x86_exp2.hpp' code.  I can't
> see how you could implement the 'atomic_conditional_increment'
> function with the atomic primitives supplied by gcc (atomicity.h) or
> the Linux kernel (atomic.h).
>
> The problem the weak pointers introduce is syncronization between the
> two counters (as Russell observed).  I believe, however, that this is
> only an issue in 'add_ref_lock'.  This is because we really have two
> interfaces here.  A weak pointer interface and a strong pointer
> interface.
>
> A program that calls the strong interface from a weak pointer is in
> error (and would cause problems in the current implementation under
> the right conditons).  Likewise for one that uses the weak interface
> from a strong pointer.
>
> Thus we can assume:
> 1)  Code that calls a strong interface routine is telling us that both
> use_count_ and weak_count_ will not be concurrently decremented to
> zero by another thread (because our thread has at least one strong
> reference). 2)  Code that calls a weak interface routine is telling
> us that the weak_count_ will not be concurrently decrement to zero by
> another thread (because our thread has at least one weak reference).
>
> If I am correct then, we could still do the following (as Windows,
> Linux, and gcc all provided atomic increment/decrement functions):
>
>
> // Strong interface
>
> void add_ref_copy(){
>   atomic_increment(use_count_);
> }
>
> void release(){
>   if(atomic_decrement(use_count_)) return;
>
>   dispose();
>   weak_release();
> }
>
>
> // Weak interface
>
> void add_ref_lock(){
>   mutex_type::scoped_lock lock(mtx_);
>
>   if(atomic_increment(use_count_) == 1){
>     --use_count_;
>     boost::throw_exception(boost::bad_weak_ptr());
>   }
> }
>
> void weak_add_ref(){
>   atomic_increment(weak_count_);
> }
>
> void weak_release(){
>   if(atomic_decrement(weak_count_)) return;
>
>   destruct();
> }
>
> -T
>
> NOTE:  The gcc/Linux atomic operations return the prior value.  The
> Windows operations return the new value.  The above code uses the
> Windows style.

________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193