Unlike a bathroom key however, mutexes are only conceptual locks, not real locks, and as such they operate on the honor system.

If the programmer forgets to lock the mutex the system won't stop them from accessing the data anyways, and even then there's no actual link between the data being locked and the lock itself, we need to trust the programmers to both understand and respect the agreement. A risky prospect on both counts.

NB: This again varies by language. I'm pretty fine with the way mutexes work in Rust, where they wrap the value, something along the lines of:

{
    let mut balance = account.balance.lock().unwrap();
    let has_funds = balance >= amount;
    if has_funds {
        *balance -= amount;
        true
    } else {
        false
    }
} // lock goes out of scope here, unlocking the mutex

or, since locking the balance might fail, it might be possible possible to do something more monadic along the lines of (where I'm inventing some methods and ignoring the type signatures of real methods, e.g. checked_sub is real but doesn't modify anything, etc)

account
    .balance
    .lock()
    .and_modify(|mut balance|
         balance.checked_sub(amount))

There's also the RwLock construct which, like the Rust reference rules, allows multiple read-only locks XOR one write-lock to exist.

My only problem with it is that IMO the mutex terminology is kind of backwards for this kind of API, as the value is normally locked away in the mutex and protected from reads & writes, and I wind up thinking of it as needing to unlock the mutex to access the value within.

Or, my second problem with it is that it's pretty habit-forming, so going back to something like Go-style mutexes feels like some sort of joke, where they've only vaguely understood the assignment and seriously botched it.