[cpp-threads] Weak vs Strong Atomics

[Lawrence Crowl]

On 5/8/07, Raul Silvera <rauls at ca.ibm.com> wrote:
> Lawrence Crowl wrote on 05/06/2007 11:18:12 PM:
> > Do you really think writing atomic_fetch_add_relaxed(x,3) versus
> > x.fetch_add_relaxed(3) will make a significant difference to
> > programmers at this level?
>
> Well, my point was that there should be access to weak operators
> from C++, without going down to the C-compatible level.

There may be a misunderstanding of N2145 here.  There isn't a
C-compatible level in the sense that I think you're talking about.
The confusion make come from atomic_int and atomic<int>,
and there is no difference here in operations or capability.  The
only difference is a generic name versus a specific name.  All
operations derive from a single type with a specific name, and that
type has a C view and a C++ view.  The only difference between
these two views is that the C++ view also includes member
operators.

Since the member operators cannot have different names and
cannot have additional parameters, the necessarily must pick only
one ordering constraint.  I think everyone agrees that this should
be fully ordered.  Am I wrong?

> The question of which syntax is more suitable than the other applies
> equally to weak atomics and strong atomics. From my point of view,
> if a syntax is not good enough for strong atomics, it isn't good enough
> for weak atomics either.

Is this statement in reference to N2145 or in reference to a future paper?

> > Can you explain what you mean by "conceal their existence"?
> > Anything in the standard is by definition not concealed, so you
> > must have something more specific in mind.
>
> The concern is about easy access to them. For example, it would be nice if
> programmers could declare a weak atomic variable and then get a list of all
> functions available from their GUI. Again, it is the same argument that
> applied to strong atomics.

I expect that GUIs will pop up member functions, but what about
free functions?

> grep would work fine as long as the names of the members are easily
> identifiable. Something like a namespace internal to the class to identify
> those member functions would have probably fit the bill (but I don't think
> that something like that exists in C++).

No.  Further, grep doesn't work well with namespaces in the presence
of using directives or using declarations.

> > > The new proposal using a derived type allows reasonable C++
> > > access to weak atomics while still satisfying Herb's requirements,
> > > so I think it is a reasonable compromise.
>  >
>  > Are you willing to live with being unable to get back to a weak atomic
>  > once an interface makes it strong?
>
> No. I don't think that's on the table, but it wasn't discussed to great
> lengths in Oxford.

The design suggested to me is exactly that.  With

   struct strong_atomic { .... }; struct weak_atomic : strong_atomic { .... };

you can do

   extern void f( strong_atomic & r );
   strong_atomic x;
   .... f( strong_atomic ); ....

but you cannot do

   void g( strong_atomic & r ) {
        apply weak operations to r;
   }

> I suspect some more discussion is needed to reach consensus on
> this issue. Such a guarantee isn't provided on your original
> proposal,

My original proposal doesn't have weak versus strong types.

> and it isn't provided on this proposal either: in general, weak
> atomics passed to routines expecting strongs can be downcasted
> back to weak, right?

Now without making them polymorphic and using dynamic_cast.
The cost of that just does not bear thinking upon.

> Also, both weak and strong operations would be available by going
> down to the C-compatible layer.

Again, the layer term is confusing me, because N2145 doesn't have
layers in that sense.

-- 
Lawrence Crowl