RE: [boost] [shared_ptr] InterlockedIncrement rocks!

From: Puverle, Tomas (IT) (Tomas.Puverle_at_[hidden])
Date: 2004-09-22 07:51:22

Ben,

> Atomic operations are highly platform-dependent, with 
> different platforms having different capabilities and many 
> requiring use of assembly language rather than providing an 
> API for atomic operations.

Would that be a problem?
I have implemented this for our internal managed pointer class, and our
code needs to run on a few different platforms (At the moment I am
discussing the posibility of contributing to boost with our legal dept -
note that it wasn't until recently that I was allowed to even post to an
external mail group.  Before that I used to follow boost quite closely)

> Second, shared_ptr has two counters and updating them safely 
> without using a lock requires some subtlety.  

On ia32, ia64 and amd64 you can always use DCAS.
On Ultrasparc you could restrict the counter to 32-bits and use CAS
(64-bit).
You can add other platforms as the implementation becomes available, but
use a lock by default.

> It's something 
> I meant to implement but hadn't quite got round to.  Perhaps 
> I could make it work on g++ (and hence most Linux 
> configurations) by using libstdc++'s atomic primitives?  I 

No.  This is not portable enough.
The problem is that libstdc++'s atomic ops come with libstdc++ which
precludes you from using other standard library implementations.
The ones that come with Linux in sys/atomic.h tend to be quite
inconsistent, not to mention that many are implemented in such a way
that they don't return the new/old value.
On Solaris, sys/atomic.h ops are not available in user space anyway, not
to mention that they are declared as extern - so they can't be inlined.

> don't think they are really public though, so this might be a 
> bad idea.

I think this would be a great idea, and it would make shared_ptr a lot
more acceptable at our company.

Tom 
--------------------------------------------------------
 
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited.