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

61–70 of 90 posts

Re: Surelock: Deadlock-Free Mutexes for Rust

#61

Post by expede »

airstrike wrote: post #57
expede wrote: post #46

Earlier quoted context omitted.

Author here! This post was human written, LLM proofread, and edited a couple times as folks pointed out broken links and minor errors when it was posted to r/rust a few days ago. As someone mentioned lower in the thread, there's a form of what is sometimes called Bay Area Standard that both very online humans and LLMs have absorbed. I find it FASCINATING that we're in an era where we have to prove our humanity, and t…

I use em dashes a lot and I'm chronically online, so that defense doesn't apply here. It's things like "perfectly invisible in code review, happy to pass CI a thousand times, then lock your system up at 3am under a request pattern that no one anticipated." which are a dead tell it was written by ChatGPT I'll bet you 2 beers the LLM you used to proofread the post was indeed ChatGPT.

Then you owe me two beers; I use Opus

Re: Surelock: Deadlock-Free Mutexes for Rust

#62

Post by noodletheworld »

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 asserting this is a problem that doesn't exist in general, or specifically saying the author doesn't know what they're talking about with regard to happylock and vecs?

Anyway, saying they're not competent feels like a childish slap.

This is a well written article about a well written library.

Its easy to make a comment like this without doing any research or actually understanding whats been done, responding to the title instead of the article.

Specifically in this regard, why do you believe the approach taken here to overcome the limitations of happylock has not been done correctly?

(1) - https://github.com/botahamec/happylock

Re: Surelock: Deadlock-Free Mutexes for Rust

#63

Post by cryptonector »

jcalvinowens wrote: post #19
vlovich123 wrote: post #10

Earlier quoted context omitted.

There’s no global lock. There’s a linear MutexKey that a lock of Level >= N has to be acquired with. Aquiring it consumes MutexKey and hands you back MutexKey where Level is the N of the level you’re locking. There’s no priority inversion possible because locks can only ever be held in decreasing orders of priority - you can’t acquire a low priority lock and then a high priority lock since your remaining MutexKey won…

In the example it seems pretty clear to me that: Mutex::new(AppConfig::default()); ...is meant to be acquiring a mutex protecting some global config object, yes? That's what I'm calling a "global lock". > There’s no priority inversion possible because locks can only ever be held in decreasing orders of priority T1 T2 -- -- small_lock(); big_lock(); small_lock(); ...and now any other thread that needs big_lock() spins…

> In the example it seems pretty clear to me that:

> Mutex::new(AppConfig::default());

> ...is meant to be acquiring a mutex protecting some global config object, yes? That's what I'm calling a "global lock".

You could certainly have a global lock at the top-most level, but you're not required to. The example is just an example.

Re: Surelock: Deadlock-Free Mutexes for Rust

#64

Post by forrestthewoods »

expede wrote: post #56
forrestthewoods wrote: post #49

Earlier quoted context omitted.

I'm aware. I'd be curious to hear the authors reason to not prefer a LockSet everywhere.

(Author here) it depends on your use case. If you need to incrementally acquire locks, then levels are helpful -- you can't do that with LockSets on their own. A place where this comes up is if you need to read a value out of one lock, and pick what to lock next based on that without releasing the first one, and then modify both. Of course you should think twice when doing this but when you need it, you REALLY need i…

Interesting example. Thanks for reply!

Re: Surelock: Deadlock-Free Mutexes for Rust

#65

Post by Groxx »

expede wrote: post #50
Groxx wrote: post #14

> Why a Total Order, Not a DAG? > This is a deliberate design decision. lock_tree uses a DAG, which lets you declare that branches A and B are independent — neither needs to come before the other. Sounds great, but it has a subtle problem: if thread 1 acquires A then B, and thread 2 acquires B then A, and both orderings are valid in the DAG, you have a deadlock that the compiler happily approved. Would it be possible…

(Author here). Early in development I did exactly this with a macro. It was confusing when you wanted to refactor the code to change lock orders, harder to make clear error messages, and so on. Forcing the user to assign in a level means that it's clear(er?) to users what's happening, we don't need fancy (and difficult to debug) macro magic, and users can still do the linearisation themselves. That's the HOPE at leas…

I can definitely believe explicit levels has more actionable errors. Type-shenaniganry without identifiable names can be pretty awful to unravel.

On that note though, I haven't found a whole lot of documentation or blog posts around trying to make better errors in macros or other compile-time checks. Have you looked at that/do you know of any decent detailed sources? I haven't looked too hard yet, but also I just don't have any good place to start, and Google's kind of garbage at the moment.

Re: Surelock: Deadlock-Free Mutexes for Rust

#66

Post by senderista »

vlovich123 wrote: post #59
senderista wrote: post #53

Earlier quoted context omitted.

Having worked a bit on a hobby STM in C++ (spun out of a DB startup) I would have to agree. Fully transparent STM that depends on a "sufficiently smart compiler" for an imperative language with unrestricted side effects is hopeless. But I do think that a much humbler version of STM is feasible for C++ or Rust, requiring much more explicit cooperation from the programmer. I haven't worked on this for 3 years but hope…

Haskell still needs TVar and it’s not an imperative language with unrestricted side effects. I think it’s bounded vs unbounded. Side effects make it more complicated perhaps but it sounds like even in a JIT language you could have done it.

It's possible (I've done it) in C++ but there are huge footguns that I'm still ambivalent about. I agree that the bounded/unbounded distinction is the key: data must explicitly be tagged as transactional. One of the benefits of bootstrapping an STM from an existing DB as I did is that this explicitness is already present.

Re: Surelock: Deadlock-Free Mutexes for Rust

#67

Post by senderista »

EffCompute wrote: post #24

I really agree with jandrewrogers' point about the insularity of the database domain. While working on a custom C++ engine to handle 10M vectors in minimal RAM, I’ve noticed that many 'mainstream' concurrency patterns simply don't scale when cache-locality is your primary bottleneck. In the DB world, we often trade complex locking for deterministic ordering or latch-free structures, but translating those to general-p…

An example of this is Linux adopting wait-die locks:

https://docs.kernel.org/locking/ww-mutex-design.html

Re: Surelock: Deadlock-Free Mutexes for Rust

#68

Post by senderista »

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!

Here is a C++ STM based on the Haskell STM API:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44...

Re: Surelock: Deadlock-Free Mutexes for Rust

#69

Post by mrkeen »

vlovich123 wrote: post #15
twoodfin wrote: post #9

Earlier quoted context omitted.

The canonical industrial explanation “why not” is probably this 2010 piece from Joe Duffy @ Microsoft: http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-...

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.

Re: Surelock: Deadlock-Free Mutexes for Rust

#70

Post by eru »

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.

Well, in a sense other languages opt-in to TM code by interfacing with a relational database. Similar to how in Haskell you put TVar in front of the relevant bits to opt-in.

In Haskell it's just more economic and better integrated with the rest of the language and its typesystem.

Post reply on HN