[BLOG] Why Rust mutexes look like they do - Cliffle
[BLOG] Why Rust mutexes look like they do - Cliffle
I started playing with rust last week (just converting a couple of C# projects so far), and I'm going to say that once you understand that mutexes/rwlocks are wrappers around the actual data, it (to me at least) feels better.
Don't get me wrong, it's an absolute headache for anyone that's acquired intermediate or better skill in one of the Cx languages. The paradigm shift is still hitting me hard. But this was one of the differences I actually think is an improvement in probably most use cases.
It's a massive win, and I would question the credibility of any systems programmer that doesn't recognize that as soon as they understand the wrapper arrangement. I would have to assume that such people are going around making egregious errors in how they're using mutexes in their C-like code, and are the reason Rust is such an important language to roll out everywhere.
The only time I've ever needed a
Mutex<()>so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.
Actually I think in this case you're still better off using a Mutex with "data" inside. I've done this before. The idea is that you make a unit struct
MyCFuncsor whatever and then you only call the C functions from methods of that unit struct. Then you can only access those methods once you lock the Mutex and get the instance of the unit struct. It feel elegant to me.
Looks like the author missed my main complaint about Rust mutexes, which is that the
lockmethod returns aResult. There should be atry_unlockmethod for when someone actually wants to handle the rather obscure failure case, and the namelockshould be used for a method that panics on failure but returns a value that doesn't need to be unwrapped first. I see the current arrangement as being about as sensible as having array subscripting return aResultto handle the case of a failed bounds check.If lock-ergonomicsⓒ is as relevant to you as indexing, you're doing it wrong.
I would rather take indexing returning
Results than the other way around.One can always wrap any code in
{||{ //.. }}()and use question marks liberally anyway (I call them stable try blocks 😉).I kind of disagree here.
.lock()has the following behavior:panic()if the lock is already held by this thread - should never happen- error - if the current lock holder paniced
The second case is incredibly rare, so it's one of the few cases where I think
.unwrap()makes sense in production code. But it should be an option to handle it in robust code that should never go down. This is rare, but it's not so rare that we should force all locks to exist in a context where we can recover from panics..try_unlock()should never exist because there should only be one way to release a lock:drop(). Having a way to maybe unlock a mutex adds a ton of issues. If we assume this was a typo,.try_lock()absolutely exists, and it's for a non-blocking lock.Just use the Mutex from the parking_lot crate.