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