Use lock addresses to enforce uniform locking order. Avoid deadlock

Re:Use lock addresses to enforce uniform locking order. Avoi... by masklinn on Sunday June 14, 2015 @10:17AM (#9714986)

Rust has an interesting take on that: the lock simply owns whatever data is locked, and only releases it on locking. Lock ordering becomes a property of which lock owns the other one.

Ownership semantics make it safer (can't leak the internal object), but considering how unsafe and dependent on proper usage locks tend to be, I wonder why I've never seen that idea in e.g. Python or Ruby, it would make the right thing easier to do either way, even if there would remain a possibility of leaking the internal object (and even then, I CPython might be able to check the lockee's refcount on lock/unlock, possibly optionally).

[ Parent | on HN ]

Re:Use lock addresses to enforce uniform locking order. Avoi... by cfallin on Sunday June 14, 2015 @10:45AM (#9715071)

The idea that Mutex<T> owns T and provides access to T only when locked is a really nice design, but...

Does it solve the case here? The two locks ordered by the address check are otherwise unordered, i.e., one is not inherently owned by the other. One could imagine the same data structure in a Rust program: a vector of runqueues, all on equal footing, and the programmer wants to lock an arbitrary pair (i, j) of them. This would have to look something like:

    {
        let mut guard1 = locks[i].lock().unwrap();
        let mut guard2 = locks[j].lock().unwrap();
        do_work(*guard1, *guard2);
    }

And you have the same problem as this post addresses: we need a total order over indices (e.g., ensure i < j) to prevent deadlock.

[ Parent | on HN ]