[grr, gmail -- I didn't actually intend to send that.] On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> wrote: >>> process 2 requests a write lock, gets -EDEADLK, unlocks and >>> requests a new read lock. That request succeeds because there >>> is no conflicting lock. (Note the lock manager had no >>> opportunity to upgrade 1's lock here thanks to the conflict with >>> 3's lock.) >> >> As I understand write lock priority, process 2 requesting a new read lock >> would block, once there is a write lock waiter, no further read locks would >> be granted that would conflict with that waiting write lock. > > ...which reminds me -- if anyone implements writer priority, please > make it optional (either w/ a writer-priority-ignoring read lock or a > non-priority-granting write lock). I have an application for which > writer priority would be really annoying. > > Even better: Have read-lock-and-wait-for-pending-writers be an explicit new operation. > > (Writer priority a Writer priority can introduce new deadlocks. Suppose that a reader (holding a read lock) starts a subprocess that takes a new read lock and waits for that subprocess. Throw an unrelated process in that tries to take a write lock and you have an instant deadlock. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
