Tracking issue for reentrant mutexes

[alexcrichton]

This is a tracking issue for the unstable reentrant_mutex feature in the standard library. Currently this flavor of mutex is not exposed at all in the standard library (it's private in the sysmodule), but it's an often-useful form of a mutex.

We should decide whether or not the standard library will expose this flavor of mutex and then ensure that the API is audited for conventions, naming, and performance.

cc @nagisa

[nagisa]

I’m still a bit uncomfortable by the fact that we do not allow inner mutability in this particular Mutex. You’d usually won’t want to Mutex-guard immutable data because it is, well, immutable and in most cases is already MT-safe, and mutable ReentrantMutex ready to share and use looks a little bit odd/redundant: Arc<ReentrantMutex<RefCell<T>>>.

[arielb1]

@nagisa

The idea of ReentrantMutex is to allow accessing a big multi-Cell (and/or RefCell) context-structure from multiple threads. This would be kind-of broken by making it return &mut

[Diggsey]

@nagisa RwLock already does pretty much what you're suggesting anyway? ReentrantMutex fills a gap in the standard library: taking something !Sync, and making it Sync, with as little overhead as possible.

[alexcrichton]

This type isn't actually exposed from the standard library, I believe I just mistakenly read the unstable tag, so closing.

[nox]

Can we reopen this? We are going to need this in Servo for exactly the reason @Diggsey mentioned.

Cc @asajeffrey.

[asajeffrey]

I ended up reimplementing the interface on top of regular mutexes https://github.com/servo/servo/blob/master/components/util/remutex.rs. The main use case is data structures that are reentrant but not thread-safe, and use interior mutability. In our case that was IPC channels, but you can do similar examples with cells.

[alexcrichton]

Note that this was never an exported interface of the standard library, so we'd probably require an RFC to add this feature to the standard library

[asajeffrey]

Given that reentrant mutexes can be implemented on top of stdlib's mutexes, should they be in std or a crate? One argument for putting them in std would be if there's an efficiency gain from using native reentrant mutexes.

[nox]

Given the stdlib's reentrant mutexes AFAIK aren't implemented on top of Mutex and they already live in there, I would rather write an RFC and just expose them.

[ckaran]

Well, it's been about 4.5 years, can we look at this again?

[SimonSapin]

This thread can be informative for historical context but it is marked as closed, let’s discuss in #58612.