Comment by lifis
12 hours ago
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.
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.
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.
> 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
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.