Should we support convenience operators for methods on atomics

[bradcray]

Some methods on atomic variables have direct analogs in Chapel's operators. For example myAtomic.add(i) feels essentially the same as myAtomic += i. This issue asks whether we could/should support such convenience operators for atomic methods for which it makes sense (ones for which it doesn't would be things like the CAS-style operators, I expect.

[gbtitus]

With my user shoes on, I'd say what we should do is to embrace symmetry and support all of the existing op= assignments on atomics. Of course this will mean using CAS under the covers for the ones that don't have architectural support like <<=, but that's okay. We're already doing op= without architectural support for some other things already, such as **= on any type.

I view CAS as just an operation that's peculiar to the type but for which there's no corresponding op= operator, so I don't think it has to be dealt with here.

[ronawho]

C++ supports this, but rust does not "due to the general opinion being that atomics should force you to think about memory ordering and related semantics." -- rust-lang/rust#7423.

I think rust always requires users to specify memory orders and doesn't default to SeqCst, but we do so I don't think that argument aligns with Chapel. Wanting users to be able to more easily see atomic operations are happening resonates with me, but I think there's also productivity benefits to providing them. Plus the rest of our atomics interface is modeled after C/C++.

I'm on board with adding operator overloads personally, but I understand the argument against them. I don't think we'd want want to add arbitrary operators for atomics and implement them with CAS. I think we just want to support operators for the methods we implement (add/+=, sub/-=, and/&=, or/|=, xor/^=)

[ronawho]

Huh, not sure how I didn't find this when we were talking about it before, but #8847 was an existing issue for this.

[gbtitus]

I think we just want to support operators for the methods we implement (add/+=, sub/-=, and/&=, or/|=, xor/^=)

The atomic updates we support are simply the intersection of the op= operations we support, which we inherited largely from C, and the network atomics available on Cray's Gemini NIC. For language semantics, it seems better to me to define in terms of what's desirable for programmers (including how hard it is to remember what is supported and what is not), rather than in terms of what the underlying capabilities are. A case in point: defining in terms of what is available on the underlying system is what led to C's right shift on negative signed values being implementation-defined, which programmers (in my experience) find irksome. And indeed in Chapel, right shift on a negative signed integer fills with sign bits.

The lack of direct architectural support for **= hasn't stopped us from supporting that for regular variables, and similarly the lack of underlying support for atomic *= shouldn't stop us from supporting that for atomics. One never knows, maybe it will appear in an architecture some day!