RE: [boost] [shared_ptr] InterlockedIncrement rocks!

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-09-22 11:25:16

Tomas Puverle <Tomas.Puverle_at_[hidden]> 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.