Messages in this thread | | | Date | Wed, 08 Oct 2008 12:03:20 -0400 | From | Steven Rostedt <> | Subject | Re: [RFC][PATCH 7/7] lockdep: spin_lock_nest_lock() |
| |
Linus Torvalds wrote: > On Wed, 8 Oct 2008, Steven Rostedt wrote: > >>> And yes, if there is an outer lock, even the order of getting locks is >>> irrelevant, as long as anybody who gets more than one inner lock always >>> holds the outer one. >>> >> But I need to disagree on a programming practice style. Unlocking locks >> in a non nested order is just bad programming practice. >> > > No it is not. > > Unlocking locks in non-nested order can sometimes be very much the rigth > thing to do, and thinking otherwise is (a) naive and (b) can generate > totally unnecessary and pointless bugs. > > The thing is, sometimes you have to do it, and imposing totally made-up > rules ("unlocks have to nest") just confuses everybody. > > The FACT is, that unlocks do not have to nest cleanly. That's a rock solid > *FACT*. The locking order matters, and the unlocking order does not. > > And if you cannot accept that as a fact, and you then say "unlock order > should matter just to keep things nice and clean", then you end up being > screwed and/or confused when you can't hold to the unlock order. > > There are many perfectly valid reasons not to unlock in reverse order. > Don't create make-believe rules that break those reasons for no gain. >
Unfortunately, you cut out my comment that I stated "unless there is a good reason not to", which the below example is a good reason ;-) > For example: > - let's say that you have a singly-linked list of objects. > - you need to lock all objects, do something, and then unlock all > objects. > - the *only* sane way to do that is to just traverse the list twice. > - that means that you will unlock the objects in the same order you > locked them, _not_ in reverse ("nested") order. > - if you force a rule of "unlocks must be nested", then > > YOU ARE A F*CKING MORON. > > It's that simple. Don't do made-up rules that have no technical reason for > them. > > Lock ordering matters. Unlock ordering does not. It really is that simple. > Don't confuse the issue by claiming anything else. >
Yes, I totally agree that there are good reasons not to unlock in reverse order, and the example you gave happens to be one of them.
I just find that seeing something like:
lock(A); lock(B);
[do something]
unlock(A); unlock(B);
just seems to be sloppy.
I wont harp on this, it only came up in conversation in which someone pointed out your post.
-- Steve
| |