Messages in this thread | | | Date | Tue, 29 Apr 2008 18:03:26 +0200 | From | "Bart Van Assche" <> | Subject | Re: [PATCH 1/8] lockdep: fix recursive read lock validation |
| |
On Tue, Apr 29, 2008 at 5:15 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > On Tue, 2008-04-29 at 17:03 +0200, Bart Van Assche wrote: > > On Tue, Apr 29, 2008 at 4:57 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > > > > > > On Tue, 2008-04-29 at 15:16 +0200, Bart Van Assche wrote: > > > > On Tue, Apr 29, 2008 at 2:57 PM, Gautham R Shenoy <ego@in.ibm.com> wrote: > > > > > Subject: lockdep: fix recursive read lock validation > > > > > This means that the following sequence is now invalid, whereas previously > > > > > it was considered valid: > > > > > > > > > > rlock(a); rlock(b); runlock(b); runlock(a) > > > > > rlock(b); rlock(a); > > > > > > > > Why are you marking this sequence as invalid ? Although it can be > > > > debated whether it is good programming practice to be inconsistent > > > > about the order of read-locking, the above sequence can't be involved > > > > in a deadlock. > > > > > > Not for pure read locks, but when you add write locks to it, it does get > > > deadlocky. Lockdep does not keep separate chains for read and write > > > locks. > > > > Nesting writer locks inside reader locks is always a bad idea. So > > please come up with an example of how varying the reader lock nesting > > order can trigger a deadlock (when no writer locks are nested inside > > reader locks and nested writer locks are always nested in the same > > order). > > It can't deadlock when only readers are involved, but lockdep will not > be able to distinguish between the cases where only read locks are > involved and a mix of readers and writers is involved. > > Hence disallow both. > > But hitting this requires you do a series of rather unfortunate things: > > 1) use recursive locking > 2) don't have strict lock order > 3) make it work by using read locks only > > Seriously, any code that triggers this might want to have its locking > re-throught.
You did not get my point.
My point is that if you follow the following locking discipline, a deadlock will never be triggered: * Always obtain writer locks in a consistent order. * Never nest writer locks inside reader locks. * Nesting reader locks inside writer locks is okay, and nesting reader locks inside other reader locks is also OK.
Again: if you do not agree with the above, please post an example that proves me wrong.
Or: whether or not to allow a sequence like "rlock(a); rlock(b); runlock(b); runlock(a); rlock(b); rlock(a);" is something we can choose. We do not have to forbid this sequence -- we can choose whether or not we allow this sequence.
Bart.
| |