Kristján Valur Jónsson added the comment: > I have implemented the simplest possible acquisition order. > The lock acquired first will be granted first. Without that (or a more > advanced policy) in applications with concurrent threads/processes > that are heavily using the shared lock, the exclusive lock can never > be acquired, because of there is always a shared lock acquired and > before it is released the next shared lock will be acquired.
I think you got that argument backwards. The simple greedy policy you implement works well provided there are not too many readers. Otherwise, the writers will be starved, since they have to wait for an oppertune moment when no readers are active to get a foot in the door, so to speak. Your approach is similar to my "SimpleSharableLock" from my second patch in that respect, and also to Microsoft's SRW Locks (http://msdn.microsoft.com/en-us/magazine/cc163405.aspx). They specifically state: " This means that if your application requires that data updates take priority over data reads, you might want to consider a different reader/writer lock that favors writers". While the test_threading.py showed ok results with the simple approach, my preliminary tests on multiprocessing show that writers need to be given priority if they are not to be starved. ---------- _______________________________________ 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
