Our macOS os_unfair_lock do not complain when they are moved while being locked

[RalfJung]

In #3745, the question came up what to do when a os_unfair_lock is moved. Apparently the real implementation uses the address of the lock to identify the wait queue, so a moved lock will be a "fork" of the old lock: it will start in whatever state the lock had at the time of the move, but reset the wait queue.

In Miri, we use a mutex ID tracked in the os_unfair_lock value to identify the lock, so the wait queue moves with the lock.

I don't think it makes sense to exactly replicate the macOS behavior here, but it would make sense to detect when a lock is moved, and throw an "unsupported" error. This could work similar to what #3784 does for pthread mutexes.

[RalfJung]

Behavior changed a bit with #3966: the queue no longer moves with the lock.

However, we should probably do something to detect a lock that is moved while being locked -- that seems like a rather dubious thing to do. The best way to do this probably is to store something non-zero in the lock whenever it is held, and to refuse initializing a new lock in os_unfair_lock_getid when the value is non-zero.

[RalfJung]

The best way to do this probably is to store something non-zero in the lock whenever it is held, and to refuse initializing a new lock in os_unfair_lock_getid when the value is non-zero.

Hm no that won't work -- one can leak the MutexGuard and then move the Mutex while it is "locked".

@joboet what is actually the behavior of that? Miri might be doing this wrong right now... calling lock() on such a moved-while-locked mutex should deadlock, but I think Miri will just give you the lock (since #3966). oops

use std::sync::Mutex;
use std::mem;

fn main() {
    let m = Mutex::new(0);
    mem::forget(m.lock());
    // Move the lock while it is "held" (really: leaked)
    let m2 = m;
    // Now try to acquire the lock again.
    let _guard = m2.lock();
}