Use lock addresses to enforce uniform locking order. Avoid deadlock

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 ]