...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.
If small_lock is never ever acquired without acquiring big_lock first, small_lock serves no purpose and should be deleted from the program.
Mutex::new creates a lock, it doesn’t acquire one.
Look at the API - if big_lock and small_lock are at the same level, you would need to acquire the lock simultaneously for both locks which is accomplished within the library by sorting* the locks and then acquiring. If you fail to acquire small_lock, big lock isn’t held (it’s an all or nothing situation). This exact scenario is explained in the link by the way. You can’t bypass the “acquire simultaneously” api because you only have a key for one level
Your terminology is also off. A lock around a configuration is typically called a fine grained lock unless you’re holding that lock for large swathes of program. Global as it refers to locking doesn’t refer to visibility of the lock or that it does mutual exclusion. For example, a lock on a database that only allows one thread into a hot path operation at a time is a global lock.
* sorting is done based on global construction order grabbed at construction - there’s a singleton atomic that hands out IDs for each mutex.
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 the whole point of having a level to the locks and to the key that you have to give up to acquire that lock.
Your terminology is also off. Mutexes are not implemented through spin locks. It’s an atomic operation and when lock acquisition fails you call futex_lock (or whatever your OS api is) to have the thread be put to sleep until the lock is acquired.
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.
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.
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.
Usually a global lock is a lock that is taken outside all others and is taken for large parts of the runtime (or even, everywhere the thread isn't waiting on a condition variable, file descriptor and the like).
Mutex::new(AppConfig::default()) might very well be a small, leaf mutex.
> There’s no priority inversion possible because locks can only ever be held in decreasing orders of priority
...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.If small_lock is never ever acquired without acquiring big_lock first, small_lock serves no purpose and should be deleted from the program.