[lifis]

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 level all you need to do is check for equal consecutive addresses after sorting, which is trivial.

Overall it seems like the authors are weirdly both quite competent and very incompetent. This is typical of LLMs, but it doesn't seem ZlLM-made.

[noodletheworld]

> 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

[ramon156]

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

[zozbot234]

> 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<RefCell<T>>. 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.

[Guvante]

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.

[Seattle3503]

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.

[Guvante]

That makes sense you could only move locks that are "after" all taken locks

[drzaiusx11]

Doesn't multiple lock support then not make it a mutex anymore? I thought that becomes a monitor lock instead? I forget how standardized the terminology is though, there may be leeway in the mutex definition already.

[yencabulator]

> 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...

[gsliepen]

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

[loeg]

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.

[gsliepen]

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.