Concurrency and shared mutable state

[dabrahams]

I've been thinking a little about the problem solved in Swift by Sendable and in Rust by send and sync: IIUC the basic idea is to constrain what kinds of things can be copied or moved across thread boundaries to account for shared mutable state… which mostly, we don't care about, but it comes up from time to time, and sometimes in the guise of value semantics, i.e. when you have a cache shared by multiple instances of a thing. Being able to make a thing with a shared cache not-sendable across threads means you don't have to worry about the thread-safety of the cache: you can access it without a mutex. In Swift and Rust, marking a thing sendable is a way of certifying that it has no hidden shared state, so it can freely move across threads (sync in Rust means that the type is fully threadsafe—you can mutate an instance freely from multiple threads—but AFAICT its only real value is to say that a reference to the type is sendable).

I've been under the weather so not necessarily thinking clearly, and this is a little fuzzy, so make allowances please…
Maybe instead of preventing things from moving across thread boundaries, it would be simpler to allow almost anything to move across thread boundaries, but make it safe to do so by using an explicit operation. It would be a no-op for most types, but e.g. things with unsynchronized shared caches could release or copy their caches. That way we could avoid having an explicit marker protocol to prevent transfers.

In truth, I don't know what all the use cases are, so I don't really have a clue whether a scheme like this covers them, but I thought it might be worth discussing.