Boost logo

Boost :

Subject: Re: [boost] [Lockfree review] Meta-comments
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-07-26 13:52:11


On 7/26/2011 11:54 AM, Phil Endecott wrote:
> Matthew Chambers wrote:
>> That's too bad. It seems reasonably stable now for my platforms (x86[_64] Windows/Linux)
>
> Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to
> lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the
> correct operation but non-atomically, or without the required memory barriers, would often appear to
> work perfectly.)
We use fifo/queue in our command-line multithreaded analysis software. My measure of stability is
that we don't get any mysterious crashes or aberrant results compared to when we used lock-based
synchronization. :) Like any thread-safety issue, it's practically impossible to prove something is
correct through testing. But you make a good point that Boost.Atmoic should have some tests that at
least try to stress its correctness.

> But: my suspicion is that it is now too late for Boost.Atomic to be useful. g++ already seems to
> have its own std::atomic implementation (since 4.4 apparently). With the impending ratification of
> C++0x we can surely expect Microsoft and LLVM to have their implementations ready soon (apparently
> LLVM says "The only major missing piece of C++'0x support [in libc++] is <atomic>". So by the time a
> group of replacement maintainers got their acts together, they/we might only be maintaining
> Boost.Atomic for the benefit of a few people who are unable to use newest compilers. That wouldn't
> motivate me much.
I too disagree with this. It will be many years before many (important) projects even consider
moving to C++1x. And as with many features (regex, filesystem, thread, etc.), having C++1x features
in boost that work with old compilers is a great way to play with them and wet feet without making a
big leap.

-Matt


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