Kristján Valur Jónsson added the comment: Ah, you are implementing an FIFO lock. That should have been made clear. I see it now that you grant the lock in the order that the acquisition is attempted. Ok, this is fine, but with one important caveat: Explicit handoff such as that can suffer from "lock convoying". In contested situation this can result in the protected resource being much less available than it ought to be.
In my dayjob, I write locking primitives for Stackless Python. We used to employ handoff until we found out that this caused performance problems. All the locking primitives now used by Eve Online and in Stacklesslib are 'greedy' and don't attempt fairness. This has resulted in much improvement in resource usage. For this reason, I explicitly did not build any such mechanism into my RWLock implementation. Any thread coming in can claim the lock, provided the policy (writer priority policy) doesn't kick in. In those rare cases where a special locking policy such as FIFO fairness is _required_ it is always possible to construct such a thing in python using e.g. a queue of condition variables. For information on this, please see the following resource: http://www.bluebytesoftware.com/blog/PermaLink,guid,e40c2675-43a3-410f-8f85-616ef7b031aa.aspx ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8800> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
