[yencabulator]

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.

[vlovich123]

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.