Re: [boost] [shared_ptr] InterlockedIncrement rocks!

From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2004-09-22 09:33:33

> It means that it's hard to write portable lock-free algorithms.

Not necessarily.
Presumably you are thinking of not allowing lock-free algorithms to 
compile if the primitives used are not available on the target platform?
Presumably we could use template traits to indicate whether or not a 
particular atomic operation is available on a given platform, and then 
use if<>s to decide whether or not to use a lock in shared_ptr.
Speaking of which, are there any plans to include lock-free algos in 
boost?  That would be something I would be very interested in...

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

Agreed, but the solution is the same as for other non-conforming platforms.
Not to mention that AFAIK MP ia32 systems were only introduced with the 
Pentium/PPro, so it would actually be possible to use non-atomic ops on 
those platforms.

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

I think it would be preferable to distinguish between HW/OS combinations 
as opposed to C++ lib implementations.

> Making shared_ptr lock-free wherever possible is indeed a great idea
> and will hopefully become a great reality!

Yes.  What release are we looking at here?

Tom