Static creation of mutexes

[dhardy]

I haven't been following the constant-evaluation work, but wanted to check that this is on the agenda?

// for any T ...
static mut X: Mutex<Option<T>> = Mutex::new(None);

[RalfJung]

I think this would be nice to have, but there are some difficulties not related to the general const fn concerns: Mutex::new, at least on POSIX platforms, performs allocation and AFAIK even interacts with the kernel in order to properly initialize the lock.

We might be able to switch to using PTHREAD_MUTEX_INITIALIZER instead, that could help. I am not sure though, and I have no idea how/if this works on non-POSIX platforms.

[RalfJung]

Ah, the problem is that statically initialized mutexes are reentrant, which is unsound in Rust.

So, I do not see a good way to support Mutex::new in const fn, I am afraid. It would have to keep track, at run-time, of whether the Mutex has already been configured properly to not be reentrant, or we would have to implement our own reentrancy checker.

I suppose we could change the mutex implementation on POSIX to a lazy initialization scheme: Use some dummy value in an AtomicPtr first, and then on every operation test if we have to initialize. This is what windows locks do. So maybe it is not so bad?

Essentially, if you want this, I propose you try to get rid of sys_common::mutex::Mutex::init while keeping sys_common::mutex::Mutex::new a const fn. I think right now, from what I can see, sys::unix is the only implementation which actually needs init. The main concern here, of course, is a potential performance impact -- but this should be down to a single read once initialization happened, which sounds acceptable.

EDIT: Oh, the Windows thing is simpler. That's just lazy detection of which kind of lock to use. On POSIX, whoever gets second in the race to initialize would have to spin waiting until the first thread completed initialization.

[RalfJung]

This seems like an issue for the main project repo, and anyway has been implemented in the mean time, so I think we can close this. (Thanks to the person who noted this, even though for some reason they deleted their message again.)