Eventual Concern: Send/Sync insufficient in the presence of multiple execution contexts.

Following up from https://github.com/rust-lang/rust/issues/53639#issuecomment-790696798

This came up as a side tangent in the “deprecate static mut(?)” issue, and I didn’t want it to get buried and forgotten. It’s something we will have to face up against eventually, and it feels like the Lang team would want to have input here.

Essentially: Send/Sync are only “true” when all values (including all pointers/references) live in a single global execution context (a single global address space).

Once you’ve got more than one execution context all of Rust’s support in the type system flies right out the window.

Examples:

• multi-core bare metal (peripherals and/or memory can be exclusive to a core)
• multi-process (memory is shared between processes but each process might have it living in a different location)
• gpu/cpu interaction.

For now you can just “use raw pointers everywhere and be very careful”, but that shouldn’t be our answer forever.

(Note: This issue is not about a specific design proposal or change proposal, more like a “keep this on your radar” reminder.)

[RalfJung]

My comment on this is that “fundamental language assumptions” and “the operational range that Rust promises to work in” is exactly the sort of thing I am trying to capture, when I talk about the “environment”. This environment includes everything that happens/exists after code leaves rustc, including linking, the placement on hardware, the operational state of hardware, etc.

That makes a lot of sense, thanks for clarifying. 😃 Indeed, precisely documenting these assumptions will be an important part of a proper specification of the Rust Abstract Machine – or rather, it will be part of how rustc implements that Abstract Machine.

[jamesmunns]

@RalfJung this is getting off-topic for Send and Sync, but still relevant to my blog post. I’d be happy to follow up in https://github.com/jamesmunns/lab-notebook/issues/3, if you’re interested.

My comment on this is that “fundamental language assumptions” and “the operational range that Rust promises to work in” is exactly the sort of thing I am trying to capture, when I talk about the “environment”. This environment includes everything that happens/exists after code leaves rustc, including linking, the placement on hardware, the operational state of hardware, etc.

I don’t expect Rust as a language to help with this (similarly to how I don’t expect Rust to help with managing multiple processes), because it’s not a language/compiler concern, but rather an environmental/systems concern.

Whenever you leave the scope of “a single program running in a single process”, you cross out of “rust” land, and into “environment” land, and Rust has preconditions it expects of it’s environment to function correctly. You CAN use Rust to send IPC messages, but it’s on a library/programmer to impedance-match the environment to Rust’s expectations. You CAN use Rust to do FFI, but it’s on a library/programmer to impedance-match the environment to Rust’s expectations.

The thrust here is that Send and Sync are Rust preconditions, and they can’t help you (by themselves) with problems that cross the Rust-to-environment barrier (but you can build libraries that use Send and Sync to help enforce part of this impedance-matching requirement).

Sorry for the off topic rant, I’d be happy to discuss the broader/semi-overlapping scope in my blog post issue.