On Thu, Jan 19, 2023 at 01:33:58PM +0000, Matthew Wilcox wrote: > On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote: > > Boqun wrote: > > > * Looks like the DEPT dependency graph doesn't handle the > > > fair/unfair readers as lockdep current does. Which bring the > > > next question. > > > > No. DEPT works better for unfair read. It works based on wait/event. So > > read_lock() is considered a potential wait waiting on write_unlock() > > while write_lock() is considered a potential wait waiting on either > > write_unlock() or read_unlock(). DEPT is working perfect for it. > > > > For fair read (maybe you meant queued read lock), I think the case > > should be handled in the same way as normal lock. I might get it wrong. > > Please let me know if I miss something. > > From the lockdep/DEPT point of view, the question is whether: > > read_lock(A) > read_lock(A) > > can deadlock if a writer comes in between the two acquisitions and > sleeps waiting on A to be released. A fair lock will block new > readers when a writer is waiting, while an unfair lock will allow > new readers even while a writer is waiting. > To be more accurate, a fair reader will wait if there is a writer waiting for other reader (fair or not) to unlock, and an unfair reader won't. In kernel there are read/write locks that can have both fair and unfair readers (e.g. queued rwlock). Regarding deadlocks, T0 T1 T2 -- -- -- fair_read_lock(A); write_lock(B); write_lock(A); write_lock(B); unfair_read_lock(A); the above is not a deadlock, since T1's unfair reader can "steal" the lock. However the following is a deadlock: T0 T1 T2 -- -- -- unfair_read_lock(A); write_lock(B); write_lock(A); write_lock(B); fair_read_lock(A); , since T'1 fair reader will wait. FWIW, lockdep is able to catch this (figuring out which is deadlock and which is not) since two years ago, plus other trivial deadlock detection for read/write locks. Needless to say, if lib/lock-selftests.c was given a try, one could find it out on one's own. Regards, Boqun
