39
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Mar 2024
39 points (97.6% liked)
Rust
5931 readers
6 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
I'm a bit confused by the need for the thread key. This makes me think I don't understand what problem this is supposed to solve. Does this crate do something more than what c++'s scoped lock offers?
I never used C++'s scoped locks but as far as I can tell they perform runtime deadlock detection while this crate is compile-time only with near to none code produced in the resulting binary.
This is done by enforcing to either lock every Mutex the thread needs at once or none at all. Thread keys are used to represent this with the type system.
I don't see how that can be used to make performant code though. I usually want to make my locked regions as small as possible to avoid how long other threads are blocked for.
So this is solving the problem of reentrant deadlocks, with a non compile-time enforceable exclusion mechanism in the form of a threadkey.
It's quite different from solving deadlocks in general, and mostly moves the problem to getting the thread key. It's an interesting thought experiment, but unless I'm missing something else, it has no practical purpose over a try_lock.
But anyway, thanks for taking the time to explain, I should have read more carefully