Tomas Puverle <Tomas.Puverle@morganstanley.com> wrote:

...

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?

Yes. If a lock-free algorithm depends on an atomic operation which the processor does not support natively, that operation can presumably only be implemented using a hidden global (possibly per-type) mutex - or, even worse, an "unimplemented instruction" processor exception and fix-up in the kernel. This could make the lock-free algorithm far slower than a locking algorithm that uses a very specific mutex and locks and unlocks it only once.

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

There are plans afoot to include atomic operations in the standard. I dare say Boost may be the testing ground for them, but I don't know. <snip>

...

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.

I'm talking about using atomic operations that are included in libstdc++. I only mentioned Linux because most C++ programs built for Linux will use libstdc++ and so could take advantage of a lock- free shared_ptr implementation that depends on libstdc++. It would be less significant for other operating systems on which most people are using other libraries.

...

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?

I believe only bug fixes can now be committed to 1.32 so improvements to shared_ptr will have to wait for 1.33.