Add Share kind

[brson]

The Share kind is a type bound for types that can be safely shared across threads. This is necessary to support fork/join operations while capturing an environment safely. Nominating.

Migration Plan

1. Add Share kind and replace usages of Freeze with Share in bounds.
   • Keep the NonFreeze markers and rules.
2. Work on Introduce a Unsafe<T> type to be used as the basis for Cell, RefCell, Atomic, etc and remove Freeze #12577
   • Remove markers
   • Forbid values with unsafe interiors in static items
3. Remove Freeze

[flaper87]

What's the thought behind replacing Freeze with Share?

IIUC the idea, Share should imply Freeze but not the other way around.

[brson]

Yes, Share is a superset of Freeze. It's not clear that Freeze continues to have a useful role once we have Share. Is knowing that a type is immutable good for other purposes?

[nikomatsakis]

cc me. I am increasingly of the opinion that Freeze as distinct from
Share may not be necessary. I believe the main reason for it was to
allow Rc to be acyclic.

[thestinger]

@brson: It's not necessary for any semantic reason that I know of, but I was planning on using it as the basis for type-based alias analysis (&T is NoAlias with all other pointers when it is Freeze). The extra burden is the need to mark a thread-safe type with inner mutability. I think this would be a single location inside an unsafe Arc type used to build mutable concurrent data structures.

@flaper87: A MutexArc can be shared across threads but is not Freeze. This applies to any mutable concurrent data structures.

[sanxiyn]

See also the post Data Parallelism in Rust.

[flaper87]

I'm interested in working on this!

[brson]

@flaper87 OK. You've got it. This may be as easy as renaming Freeze and #[no_freeze] to Share and #[no_share] and removing the #[no_share] attributes from types like MutexArc that are now sharable.

@nikomatsakis I am worried that Rust allows some types to be unsafely shared by default. Would making unsafe pointers unsharable by default prevent this?

[pnkfelix]

Accepted for 1.0, assigning P-high.

[pnkfelix]

(assigning E-mentor in hopes that @nikomatsakis has spare cycles to act as a mentor here... or someone else could...)

[nikomatsakis]

I will mentor. @brson that's an interesting thought, maybe we can make unsafe sharing opt-in in this way

[brson]

Share probably interacts in subtle ways with Send. At the least, something not Send can't be put into something Share, though maybe the same rule already applies to Send and Freeze.

[nikomatsakis]

I think we want Freeze to stay. it's not clear to me that Send and Freeze have any inherent relationship. I think the breakdown is:

• Send (deeply owned)
• Freeze (deeply immutable if aliased)
• Share (mutable, but threadsafe even if aliased)

I don't know that any of those three traits have any particular relationship to one another:

• Freeze does not seem to imply Share: consider GC<T> -- it is Freeze, I think, but it is not threadsafe to access from another thread.
• Send does not seem to imply Freeze: consider Cell<T>, which owns its contents.
• Send does not seem to imply Share: consider again Cell<T>.

For many cases, then, multiple bound are probably required:

• Sending data requires Send
• ARC wants Send+Share
• ...

OK, gotta go, maybe more writeup / thought is needed here than I previously thought!

Note: In the past I've considered a fourth builtin bound Fork, which was supposed to be something like "mutable but threadsafe is not aliased". But I'm not sure that this bound is still needed. The primary motivation was to describe the set of closures that can safely be executed as data-parallel jobs. But I think it's better to address this via a combination of the above bounds and #8622 (closure, trait unification). That is, if we had two trait types like trait Fn { fn call(&self, ...) } and trait FnMut { fn call(&mut self, ...) }, then a "parallel fork" API would take &mut FnMut:Share and the "parallel map" API would take &Fn:Share, and I believe that all requirements are met.

[glaebhoerl]

@nikomatsakis Gc<T> would be non-Freeze if we have a moving GC (we might want it non-Freeze either way to keep options open).

While the relationship between them is an interesting question, I think the more significant question is: in what use cases do you want Freeze and not Share?