Re: [boost] [atomic] Probable documentation issue: how do we know atomic is safe and/or efficient?

Subject: Re: [boost] [atomic] Probable documentation issue: how do we know atomic is safe and/or efficient?
From: tim (tim_at_[hidden])
Date: 2013-12-24 10:08:53

>> a) Whether the library is correctly implemented.
> 
> I hope so. :) The tests are there, but they were mostly run on x86 in
> the test farm.

atomic<>s are hard to test, so it is best to verify the correctness by
analyzing the code.

>> b) How efficient (or otherwise) the library is on various platforms.
> 
> In general, if the library reports the particular type as lock-free,
> you should expect performance comparable to std::atomic. In some cases
> (notably, older gcc) it's even better.

for arm/ppc platforms i suppose that std::atomics will perform better,
because (a) some operations are emulated with cas (no idea if this has a
real-world impact) and (b) boost.atomic does not support all hardware
instructions (iirc armv7 provides atomic double-width instructions which
boost.simd does not make use of).

>> I'm sure the answer to (a) is that it is correct, but I was surprised that
>> atomic<int> relied on the volatile modifier for thread safe load/stores on
>> MSVC, I had assumed that something more than that would have been required,
>> but I know I'm out of date on this stuff!
> 
> This is enough in case of x86, which has been the primary, if not the
> only target for MSVC for a long time. I'm not so experienced with ARM,
> so Boost.Atomic may need some adjustments for MSVC for this target
> architecture.

compare http://en.cppreference.com/w/cpp/atomic/memory_order, section
"Relationship with volatile"

>> My apologies if this has been covered already in the review, and I realize
>> that documentation is a lot of work, but I can see no way to ensure
>> correctness other than through code inspection, so proper documentation is
>> essential in that case.

fyi: the original author did the review and disappeared. i (as in review
manager) was actually surprised that he committed the stuff to trunk ...
it only ended up in the release, because andrey and me adopted the
library, though personally i have limited time to work on stuff other
than bug fixes (and no interest in improving the documentation) ...

my personal recommendation:

* if your compiler supports std::atomic, use it instead
* if you need a good API documentation, check the std::atomic documentation
* if you want to verify the correctness, use the source ;)

cheers,
tim