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

81–90 of 90 posts

Re: Surelock: Deadlock-Free Mutexes for Rust

#81

Post by gsliepen »

loeg wrote: post #42
gsliepen wrote: post #41

Earlier quoted context omitted.

What about mutexes living in shared memory, and each process having a different address mapping?

All bets go out the window with adversarial multi-process shared memory mutexes. The other process may not even be running the same locking code.

That's an easy answer, but multi-process mutexes are supported on Linux (and perhaps other OSes as well), and it would be nice if this could also be safely handled by something like Surelock. If it would, then it couldn't rely on VM addresses to order locks.

Re: Surelock: Deadlock-Free Mutexes for Rust

#82

Post by vlovich123 »

jcalvinowens wrote: post #79
vlovich123 wrote: post #54

Earlier quoted context omitted.

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.

None of it is LLM generated. You seem to fundamentally not understand how the system outlined in the blog post works and how it prevents deadlocks by construction (ie it’s impossible to write any program that deadlocks if the only mutexes used are from this library). You also seem to lack the appropriate terminology to describe what your concern is and use terminology in a way that belies either ignorance or fundamental misunderstanding of what words mean. So you lash out claiming my 100% human written comment is LLM as a way to distract from said ignorance.

I’ve tried to illuminate your ignorance for you but unfortunately I can’t do your thinking for you.

What I can do is recommend you try to write out the scenario you believe can create a deadlock and maybe then you’ll understand why it’s not possible and maybe my words will make a little bit more sense. If alternatively you succeed you can open an issue on the author’s open source library and create a blog post explaining their mistake. But until then you’re just unhappy you don’t understand and aren’t doing any being willful to remain uninformed.

Re: Surelock: Deadlock-Free Mutexes for Rust

#83

Post by ehtbanton »

jandrewrogers wrote: post #21
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.

The cross-fertilization of ideas across computer science domains is more limited than I think people assume. Databases are just one area that contains a lot of good ideas that never seem to leak into other parts of the software world. Supercomputing is another domain that has deep insights into scalable systems that is famously so insular that ideas rarely cross over into mainstream scalable systems. My detour throug…

I've had this thought myself too. Going off on a slight tangent: I think there's also loads of useful stuff in domains like either of these which maps amazingly well to AI agent system design, but there's such a huge discrepancy between the knowledge bases of the fields that no benefit ever really surfaces.

(Speaking from the perspective of someone who simultaneously loves high-performance compute and agentic AI haha)

Re: Surelock: Deadlock-Free Mutexes for Rust

#84

Post by bsder »

electromech wrote: post #18

I'm intrigued! I was fighting deadlocks in some Java code this week, and I'm working on a Rust project to maybe replace some of that. One thing I didn't see in the post or the repo: does this work with async code? I couldn't find the "search" button on Codeberg, and tests/integration.rs didn't have any async. For embedded, I have had my eye on https://github.com/embassy-rs/embassy (which has an async runtime for embe…

> I was fighting deadlocks in some Java code this week

Why? You have java.util.concurrent; you should never see a deadlock. You might see a performance degradation or maybe even livelock, but that's very, very, very rare.

What abjectly idiotic thing is in your Java codebase such that you have deadlocks?

Re: Surelock: Deadlock-Free Mutexes for Rust

#85

Post by eru »

imtringued wrote: post #77
mrkeen wrote: post #69

Earlier quoted context omitted.

> 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 profession…

> The primary advantage of a new programming language is that there is no legacy code to be compatible with.

Depends a lot on what you are doing. Clojure and Scala were new languages, but they had a lot of legacy code to stay compatible with. C++ falls in a similar camp.

Re: Surelock: Deadlock-Free Mutexes for Rust

#86

Post by yencabulator »

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…

I think what they're trying to say is that sure it's deadlock-free but it might be sacrificing performance.

T2 sits there waiting for small_lock to be available while holding big_lock for a long time.

This bit:

> ...and now any other thread that needs big_lock() spins waiting for T2 to release it, but T2 is spinning waiting for T1 to release the (presumably less critical) small lock.

Which of course leads to conversations like can big_lock be an RWLock, ArcSwap or such.

Re: Surelock: Deadlock-Free Mutexes for Rust

#87

Post by yencabulator »

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 makes no sense

This was prevented on Apr 6:

https://codeberg.org/expede/surelock/commit/4f86b1ea58c7d19a...

Re: Surelock: Deadlock-Free Mutexes for Rust

#88

Post by yencabulator »

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.

Putting timeouts on things that used to deadlock upgrades you to the next level of hell: livelocks.

Re: Surelock: Deadlock-Free Mutexes for Rust

#89

Post by vlovich123 »

yencabulator wrote: post #86
vlovich123 wrote: post #54

Earlier quoted context omitted.

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…

I think what they're trying to say is that sure it's deadlock-free but it might be sacrificing performance. T2 sits there waiting for small_lock to be available while holding big_lock for a long time. This bit: > ...and now any other thread that needs big_lock() spins waiting for T2 to release it, but T2 is spinning waiting for T1 to release the (presumably less critical) small lock. Which of course leads to conversa…

I can’t tell what they’re trying to say and it seemed to primarily be about priority inversion which is precisely impossible in the scheme outlined. This isn’t sacrificing any performance vs any other locking mechanism.

> Which of course leads to conversations like can big_lock be an RWLock, ArcSwap or such.

I’m not sure what you’re trying to say. This blog post is about a mutex type that is guaranteed to not dead lock.

And again, OP is horribly wrong on the terminology - there’s no spinning in any sane system. You ask the kernel to acquire the mutex for you if you fail and the kernel just puts your thread to sleep until the lock can be acquired. So all threads are guaranteed to be making forward progress. The ideal granularity of the locks themselves is completely irrelevant - that’s a domain-specific decision.

Re: Surelock: Deadlock-Free Mutexes for Rust

#90

Post by Guvante »

Seattle3503 wrote: post #55
Guvante wrote: post #28

Earlier quoted context omitted.

Don't address introduce ambiguous locking order across attempts? While not obviously problematic, that seems weird enough you would need to validate that it is explicitly safe.

If I need to grab 100 locks, they are all moving around a lot, but I've got the first 10, will the order be the same for someome trying to get the same 100? Eg maybe someone swaps two that neither of us has grabbed yet.

That makes sense you could only move locks that are "after" all taken locks
Post reply on HN