RE: [boost] [shared_ptr] InterlockedIncrement rocks!
Tomas Puverle <Tomas.Puverle@morganstanley.com> 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!
On Wed, Sep 22, 2004 at 02:34:58PM +0100, Ben Hutchings wrote:
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.
That macro would be a good idea anyway, since otherwise detecting libstdc++-v3 requires: #if defined(__GLIBCPP__) || defined (__GLIBCXX__) There are already places that don't detect GCC 3.4's libstdc++ because they haven't been updated to check for __GLIBCXX__ as well as __GLIBCPP__. Your suggested macro would make it easier to get right. jon -- "Yield to temptation, it may not pass your way again." - Robert Heinlein
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
participants (3)
-
Ben Hutchings -
Jonathan Wakely -
Tomas Puverle