A saw this on Mastodon, and found it interesting. Rust already prevents a lot of race conditions, but deadlocks when using a mutex is still possible (and I have actually had one myself, though I caught it during testing). So, it would be nice if it would be possible to catch these cases at compile time. Now, seems to be just a proof of concept, but it is always nice to see the direction people are going and what areas are explored.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 8 months ago (3 children)

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?

[–] [email protected] 3 points 8 months ago (2 children)

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.

[–] naonintendois 5 points 8 months ago

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.

load more comments (1 replies)