Should operations on atomics which mutate via raw pointers accept a mutable reference to self?

[vext01]

Hi,

I was looking at the AtomicU32 documentation. The signature for compare_and_swap is:

pub fn compare_and_swap(&self, current: u32, new: u32, order: Ordering) -> u32

I found this curious, as clearly this operation may mutate the u32 inside. So why is it not accepting an &mut self?

Looking at the implementation, I see why this works. It boils down to a call to atomic_compare_exchange, which is unsafe thus (I think) allowing the immutable reference to coerce to a *mut.

But should the outward facing interface accept an &mut self to:

• Aid the mental model of the programmer?
• Prevent the ability to hold multiple mutable references.

Thoughts?

[sfackler]

You can only obtain a &mut self if you have unique access to the value. The entire point of the atomic types is to be used in contexts where multiple threads have concurrent access to the value.

[vext01]

You can only obtain a &mut self if you have unique access to the value.

Yeah, you're right. But you can see why I find the interface counter-intuitive?

Perhaps in parallel universe (no pun intended) there would be a way of sharing mutable references to atomics between threads...

[sfackler]

At one point the language behaved like that: 4c62486, and there was discussion of renaming &mut to &only: rust-lang/rfcs#58.

[vext01]

OK, I suppose this issue is a dud then. Sorry for the noise.