lkml.org 
[lkml]   [1999]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: recursive locks in kernel?
Date
In message <Pine.LNX.4.10.9909281414070.38044635-100000@csemt83.cse.iitk.ac.in>
you write:
> Hi Paul,

Hi Sushil,
> With recursive locks we no longer need two versions of a function. One
> that locks it and other that doesnot lock it on the assumption that it has
> already been locked by the calling function.

Having two versions of the function (raw `already-locked' and normal
`gets-lock-for-you') isn't that much of a problem; with various uses
of inline it doesn't even add to bloat. This is Free software, if you
need it you can write the raw version.

And it's important to make the programmer say what they really mean.
You ALWAYS need to know that a function grabs a (public) lock: there
may be ordering issues with OTHER locks.

It's not worth fixing the easy problems if it increases the chance of
hard ones. And locking order bugs are (in my non-kernel experience)
FAR worse than straight `already-locked' deadlocks, because they DON'T
happen every time.

This is just my opinion, for all I know Dr. Torvalds may patch
spinlocks to be recursive tomorrow...
Rusty.
--
Hacking time.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.064 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site