Atomics need to take &self rather than &mut sef

[bill-myers]

In Rust, safe code cannot create a situation where an &mut aliases anything else that is accessible.

Unsafe code can do so, but it makes sense to ban it and make that undefined behavior at least if the &muts are then used, since in addition to preserving the desirable safe semantics, it means that the information can be used in optimizations like alias analysis without fear of introducing bugs due to unsafe code creating and using aliased &muts.

However, current Atomic* and mutex implementations require an &mut self.

This is wrong, because the whole point of such classes is to support multiple concurrent users, so having them take an &mut self means that they are either pointless or that clients are breaking the rules about &mut detailed above.

So, I think atomics need to take &self, and AtomicT should simply be viewed as a variant of Cell that uses atomic operations instead of non-atomic ones.

This also applies to operations on mutexes and other lockless data structures.

Note that this means that safe code will be able use atomics (for example, by putting them in an Arc-like structure without a Freeze bound), which does introduce potential data races but not memory corruption; however, data races that can happen due to multiple atomics can be equivalently produced using multiple RwArcs, so I think this is not an issue.

There has already been quite some discussion of this in pull request #11520, and also a partial implementation (it doesn't change the compiler intrinsics themselves, only the high-level Atomic* APIs).

[brson]

@nikomatsakis curious what you think of this argument.

[brson]

Nominating.

[nikomatsakis]

I think this argument makes sense -- basically atomics should declare themselves as "inherently mutable" types, as Cell does. Or non-freezable, whatever we call that.

[nikomatsakis]

That said, I think we should revisit these categorizations before 1.0, with an eye towards possible future data parallelism. Atomic is quite different from Cell in that, while it permits mutation and hence is not freezable, it's also threadsafe.

[brson]

Perhaps they should also be #[non_freeze] then as well. There are probably a lot of synchronization types that need to be reexamined in this light.

[brson]

Yeah, it seems pretty clear that we will eventually need some notion of a type that is threadsafe.

[pnkfelix]

Accepted for 1.0, P-backcompat-libs.

[brson]

I've started looking into changing atomics to use immutable references. There's one snag though in that drop creates aliased &mut pointers, as in

#[unsafe_destructor]
impl<T> Drop for AtomicOption<T> {
    fn drop(&mut self) {
        let _ = self.take(SeqCst);
    }
}

[alexcrichton]

One use-case I realized the other day is that

static COUNT: AtomicUint = INIT_ATOMIC_UINT;

is placed into read-only data, so any usage of the atomic will result in a segfault :(

[nikomatsakis]

@alexcrichton good point. It seems like we may want a rule saying that static values must be freezable.

cc @flaper87 and issue #10577

[flaper87]

@nikomatsakis @alexcrichton just noticed this (I've to improve my email filters a bit).

Makes sense to me, I'll update the pull-request.