RE: [boost] [shared_ptr] InterlockedIncrement rocks!

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-22 08:34:58

Tomas Puverle <Tomas.Puverle_at_[hidden]> wrote:
> 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?

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.

<snip> 
> > 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+
vs 486+.)

> 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.

Right.

> > 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.

<snip> 
> > 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!