[cpp-threads] Weak vs Strong Atomics

[Lawrence Crowl]

On 5/4/07, Roger Orr <rogero at howzatt.demon.co.uk> wrote:
> cpp-threads-bounces at decadentplace.org.uk wrote:
> >> - some explicit conversion between the C++ class and the C type
> >
> > N2145 has an inheritance relationship.  There is no conversion
> > though, because atomics are variables, not values.  To move
> > information from one atomic to another, you load and store contained
> > values.
> >
>
> I've a couple of comments about this.
>
> (1) conversion can occur silently if you call a function taking an
> atomic by reference.

I'm not sure that we are talking about the same thing.  In N2145, the
only conversion is a pointer-to-base conversion enabling generic use of
what must be named types in C.  That is the inheritance relationship
in N2145 is present to enable templates.  I want to keep that capability.

> (2) It is harder to grep uses of '&' rather than a named conversion
> function.

Oh, it's easy.  You just get more than you need.  :-)

> My goal is simply to make passing a strong atomic to a function
> expecting a weak one a bit more explicit, both for the writer and
> for the maintainer.

See my earlier mail on week versus strong views.  If you can relate
your concern to that discussion, it will help me understand.

>
> >> // C++
> >> {
> >>   std::atomic_int a;
> >>   std::atomic_int b;
> >>   a = b; // Error, as op= declared with "= delete" in C++ definition
> >> (using N2210) }
> >
> > The assignment operator is "wrong" here, and I would eliminate it in C
> > if I could, but there is simply no mechanism to do so in C99.  I
> > suspect that if C were to formally adopt the approach, they would
> > outlaw the assignment.  So, the intended semantics are the same.
>
> Ok, then I'm happier.
>
> Could the copy ctor be explicit rather than =delete, so 'fresh'
> atomic objects can be created (eg, when creating the implicit copy ctor
> for a class with an atomic as member data)?

I would have to look through several papers to say be sure, but I
think the answer is that it is possible.  The concern is whether defining
it will render some of the other attributes, like compatibility with C,
invalid.  In any event, N2215 enables one to write

    atomic_member { (int)other_atomic_variable }

to achieve the desired effect.

>
> >
> >> So could we:
> >> - declare struct atomic_int as a pretty nearly raw struct in both C
> >> and C++ (in std:: here)
> >> - move all the C++ 'clever stuff' into std::atomic<int> and have
> >> that as the strong atomic class
> >
> > We could do that, but then there would be no operator access to types
> > that are common to both C and C++.  For example:
> >
> > a.h:   ....  atomic_int x; ....
> > b.c:   ....  atomic_fetch_add_ordered( &x, 1 ); ....
> > c.cc:   ....  x += 1; ....
> >
> > Under N2145, the c.cc code works and is equivalent to the b.c code.
> > Under what you suggest, C++ programmers would be forced into
> > writing what is under b.c.  My vague recollection is that people
> > didn't want that approach.
>
> Not sure.  Perhaps we'd want to encourage people who wish to use
> '+=' in C++ to be using atomic<int> anyway?

The issue is what can C++ programmers write to access types that,
for C compatibility reasons, must be in the base type.  I was running
under the assumption that C++programmers would want to use the
operators where feasible.

-- 
Lawrence Crowl