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.
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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk