On Tue, Dec 24, 2013 at 5:43 PM, John Maddock <john@johnmaddock.co.uk> wrote:
I'm looking to use Boost.Atomic for the double-checked-locking-idiom, but I'm having trouble discovering
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.
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.
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.
I can't help thinking that questions like this could be allayed by better documentation - specifically what operations are used to ensure correctness on each supported platform, plus rationale and/or link to reference material.
Well, if you have knowledge of a particular architecture, you probably know what atomic ops it supports and both Boost.Atomic and std::atomic are most likely based on them. The particular instructions and their code representation (i.e. compiler intrinsics, inline assembly, kernel calls, etc.), I think, is more an implementation detail. It could be generally described for a curious reader though.
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.
Documentation is hardly a measure of code correctness, but I admit, in case of Boost.Atomic it could be improved.