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