From: Puverle, Tomas (IT) (Tomas.Puverle_at_[hidden])
Date: 2004-09-22 07:51:22
> 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
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.
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk