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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-24 09:07:35

On Tue, Dec 24, 2013 at 5:43 PM, John Maddock <john_at_[hidden]> 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.