Use lock addresses to enforce uniform locking order. Avoid deadlock

Re:Use lock addresses to enforce uniform locking order. Avoi... by amelius on Sunday June 14, 2015 @09:05AM (#9714740)

Also, this solution is anti-modular in the sense that it becomes near-infeasible if different parts of the code that may contain locking directives are in different modules, and solving this may mean exposing an interface that becomes increasingly more complicated with increasing number of locks.

Therefore, for large scale systems, locks are an anti-pattern.

[ Parent | on HN ]

Re:Use lock addresses to enforce uniform locking order. Avoi... by ratboy666 on Sunday June 14, 2015 @09:36AM (#9714829)

This solution is brilliant. No interface is exposed. The observation is that locks themselves have addresses, and these addresses have an order. That gives the order that locking is to be done in to ensure no deadlocking.

Indeed, this extends quite naturally to locks that are not related from modules that are not aware of each other.

I repeat, just brilliant.

[ Parent | on HN ]

Re:Use lock addresses to enforce uniform locking order. Avoi... by amelius on Sunday June 14, 2015 @12:26PM (#9715436)

Sorry, but this is a too simplistic view of the problem. In reality, libraries perform locks, then invoke callback functions, which might perform other locks. Hence, you cannot always control the order of the locking without refactoring your code and messing up modularity.

[ Parent | on HN ]

Re:Use lock addresses to enforce uniform locking order. Avoi... by lukesandberg on Sunday June 14, 2015 @02:40PM (#9715883)

Which is why the maxim "don't hold locks while calling untrusted code" exists. Holding a lock while invoking a callback is extremely dangerous. Some situations demnd doing this (but not that often), in which case you need to document it like crazy.

[ Parent | on HN ]