From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-22 08:34:58
Tomas Puverle <Tomas.Puverle_at_[hidden]> wrote:
> > 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?
It means that it's hard to write portable lock-free algorithms.
However I don't think this is a problem for shared_ptr because it
already has a portable mutex-based implementation of the counter
operations which can be used as a fallback where a lock-free
implementation is impracticable.
> > 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.
That isn't available on all IA32; it was introduced with the Pentium.
Worse, on a 386SX even 32-bit atomic operations are unavailable.
(This is why Windows 95 requires a 386DX and why there have been some
binary compatibility problems with glibc and libstdc++ built for 386+
> 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.
Perhaps I could put #define BOOST_STDLIB_LIBSTDCPP3 in
<boost/config/stdlib/libstdcpp3.hpp> and then guard any use of
<bits/atomicity.h> with #ifdef BOOST_STDLIB_LIBSTDCPP3.
> > 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.
I meant that using libstdc++'s atomic operations might be a bad idea.
Making shared_ptr lock-free wherever possible is indeed a great idea
and will hopefully become a great reality!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk