Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Surelock: Deadlock-Free Mutexes for Rust

notes.brooklynzelenka.com

Post reply on HN
Print view View original

71–80 of 90 posts

Re: Surelock: Deadlock-Free Mutexes for Rust

#71

Post by eru »

mamcx wrote: post #36
eru wrote: post #2

I agree with the author: it's a shame that TVars aren't catching on in more languages. They are a great idea from the database world, that we could use in the rest of computing, too.

Well, what means to support, truly, TVars? Is easy, or hard? Demand a new paradigm at large, or is only a inconvenience in the few places is used? Because if the answer is "turns the language into Haskell" then is a big NOPE!

Well, Haskell is a big language with lots of different aspects.

To nicely support TVars, it's good if your language can differentiate between pure code and code with side-effects. Haskell's type system is one way to get there; but eg something like Rust could probably also be coerced to do something appropriate.

Apart from that, you probably don't even need static typing to make it work well enough (though it probably helps). You definitely don't need laziness or Haskell's love of making up new operators or significant whitespace.

Re: Surelock: Deadlock-Free Mutexes for Rust

#72

Post by zozbot234 »

lifis wrote: post #27

I can't understand why address instability is a problem: if a Mutex is moved, then it can't be locked (because you need to hold a borrow while locked, which impedes moving), so using addresses is perfectly fine and there is absolutely no need to use IDs. Also the fact that it doesn't detect locking the same mutex twice makes no sense: a static order obviously detects that and when locking multiple mutexes at the same…

> Also the fact that it doesn't detect locking the same mutex twice

Reentrant mutexes https://en.wikipedia.org/wiki/Reentrant_mutex need interior mutability in Rust, i.e. you'd need something like ReentrantMutex>. You can't just lock the mutex and get a &mut T out of it, because then locking the mutex again would get you a second &mut T which would violate Rust's no-aliasing semantics for &mut. The Rust standard library AIUI does not provide this yet.

Re: Surelock: Deadlock-Free Mutexes for Rust

#74

Post by rcxdude »

avadodin wrote: post #73

I'm not a rust expert, but couldn't this be solved like memory safety? A few checks here and there.

How do you statically guarantee the order of lock acquisition for a thread? I think either you have simple enough control flow that it is somehow entirely visible to the compiler or you need to embed the order into the type system like this approach does.

Re: Surelock: Deadlock-Free Mutexes for Rust

#75

Post by SleepyMyroslav »

accelbred wrote: post #44

Most of the deadlocks I've faced are with different proccesses/devices both waiting on reads from each end of a socket/uart/etc. I've taken to putting timeouts on read calls, though then you have to deal with legitimate long request cycles timing out.

I have anecdata from my gamedev work that people tend to make mistakes when threads are pinned to some CPUs. Normally, when only time is a variable people can understand what can happen in their code. What confuses them is that space where those threads execute can be already taken. If a thread that should make whole system progress fails to grab a time slice these deadlocks are hard to reason about. Granted that lock ordering is the basic technique and if system did not had it all bets are off.

Re: Surelock: Deadlock-Free Mutexes for Rust

#76

Post by ramon156 »

noodletheworld wrote: post #62
lifis wrote: post #27

I can't understand why address instability is a problem: if a Mutex is moved, then it can't be locked (because you need to hold a borrow while locked, which impedes moving), so using addresses is perfectly fine and there is absolutely no need to use IDs. Also the fact that it doesn't detect locking the same mutex twice makes no sense: a static order obviously detects that and when locking multiple mutexes at the same…

> Overall it seems like the authors are weirdly both quite competent and very incompetent This is an unusually hostile take. The authors comment about address instability is only a minor point in the article: > happylock also sorts locks by memory address, which is not stable across Vec reallocations or moves. …specifically with regard to happylock, which has a bunch of commentary on it (1) around the design. You're…

A HN comment cherry-picking a sentence? No way!

Re: Surelock: Deadlock-Free Mutexes for Rust

#77

Post by imtringued »

mrkeen wrote: post #69
vlovich123 wrote: post #15

Earlier quoted context omitted.

I don’t think we read the same thing. > Models can be pulled along other axes, however, such as whether memory locations must be tagged in order to be used in a transaction or not, etc. Haskell requires this tagging (via TVars) so that side-effects are evident in the type system as with any other kind of monad. We quickly settled on unbounded transactions. Snip > In hindsight, this was a critical decision that had fa…

> unbounded TM is likely a fool’s errand It's the whole language, not just the TM code. Other languages have no way of opting out of the TM code, whereas Haskell does.

I think it is pretty sad how there are so many modern programming languages coming out that fail to actually do something novel.

The primary advantage of a new programming language is that there is no legacy code to be compatible with. The software ergonomics space has been thoroughly explored, but restricting programs to subsets with useful properties is still an untapped field. It's seen that way because professional programmers are not used to dealing with restrictions to expressive freedom. New languages are supposed to increase freedom.

The vast majority of new programming languages would benefit from the main language being as restricted as possible and then require you to opt into the features selectively.

Re: Surelock: Deadlock-Free Mutexes for Rust

#78

Post by surajrmal »

rowanG077 wrote: post #20

That's pretty awesome. Dead locks are extremely tough to debug. There are even cases where I saw behavior in code that might have been a dead lock. I never found out though.

If you can get a stack trace of the process it is usually pretty easy to figure you will see two or more threads waiting on different futexes. I would say async deadlocks are far trickier to debug - task a sends a message to task b and task b sends a message to task a. Both tasks wait on processing further messages until the other side replies to their message. At the end of the day you need strict ordering of who is allowed to call into the other and block.

Re: Surelock: Deadlock-Free Mutexes for Rust

#79

Post by jcalvinowens »

vlovich123 wrote: post #54
jcalvinowens wrote: post #51

Earlier quoted context omitted.

No, the entire point of what I was saying is that big_lock and little_lock are at two different levels.

If big lock and little lock are at different levels you won’t have a key at the appropriate level to create an inversion by trying to acquire in the first place. T2 might “spin” waiting for small lock but assuming small lock is released at some point you’ve not got a deadlock (and by construction it’s impossible for small lock to have it’s release blocked on the acquisition of a lock that depends on big_lock). That’s…

This reply is word salad that completely fails to engage with anything I've actually said to you... please don't waste my time with more LLM generated comments.

Re: Surelock: Deadlock-Free Mutexes for Rust

#80

Post by jcalvinowens »

gpm wrote: post #48
jcalvinowens wrote: post #6

The Level abstraction is a really neat way to have your cake and eat it too: you only need a consistent arbitrary order to avoid deadlocks, but the order can have performance consequences when some locks are more coarse than others. But the example seems backwards to me: unless every callsite that locks any item always locks the big global lock first (probably not true, because if you serialize all item access on a g…

> unless every callsite that locks any item always locks the big global lock first (probably not true, because if you serialize all item access on a global lock then a per-item lock serves no purpose...) A pattern I've definitely both seen and used is let guard1 = datastructure_containing_the_whole_world.lock(); let guard2 = guard1.subset_of_that_datastructure.lock(); guard1.unlock(); // Do expensive work guard2.unlo…

Agreed! But if you can reverse the acquire order, you can structure the function scopes such that you don't need the explicit unlock() calls, which is a bit nicer IMHO.
Post reply on HN