lkml.org 
[lkml]   [2008]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 7/7] lockdep: spin_lock_nest_lock()


On Wed, 8 Oct 2008, Steven Rostedt wrote:
>
> 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 ;-)

Well, teh thing is, as long as you think nesting is good, you end up being
very confused when it isn't.

> I just find that seeing something like:
>
> lock(A);
> lock(B);
>
> [do something]
>
> unlock(A);
> unlock(B);
>
> just seems to be sloppy.

Of course you'll often get nesting almost by mistake.

For example, any normal locking that is hierarchical tends to nest
naturally, especially if you end up using lots of small functions (which
you should). Or simply due to error handling.

So in that sense, nesting may be a "natural" thing, but partly exactly
_because_ it is fairly natural, we should not try to make it even more
than that, because then when things don't nest (and it does happen), if
the "things should nest" camp gets too strong, bugs happen.

They happen because somebody looks at the non-nesting case, and thinks
it's sloppy, and tries to fix it. And in the process just complicates
matters - and very likely introduces bugs.

And THAT is why people shouldn't think that locks "should" nest. Because
they shouldn't. They often do, but we're better off making people very
aware of the fact that 'often' isn't 'good design', it's just a matter of
'it happens in practice' rather than 'it should be that way'.

I know for a fact that some people thought unlocking in non-nested order
was a bug. And I believe that belief is a dangerous one.

Linus


\
 
 \ /
  Last update: 2008-10-08 18:23    [W:0.066 / U:1.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site