Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk