Code review comment for lp:~mir-team/mir/fix-1339700

I admit Mir is the first project I've ever seen that employs callbacks from opaque and potentially unsafe locations, where you can't guarantee which locks are already held.

Maybe we need to start considering synchronization primitives without callbacks. That would also afford us the freedom to be more sensible with locking, and only have locks in regions of code which explicitly create/use threads in their own locality. One should start with no locking, and then only introduce it adjacently to the threads that necessitate it. Certainly you should never lock inside class methods if that class isn't the one creating the threads. Because you're just hiding more locks which when combined with callbacks will cause deadlocks like this.

But now I'm hand-waving. We need shorter term practical solutions first. Maybe not as short-term as removing locking like is proposed here though...