Re: recursive spinlocks. Shoot.

[Peter T. Breuer]

"A month of sundays ago William Lee Irwin III wrote:"
> At some point in the past, Peter Breuer's attribution was removed from:
> >> Here's a before-breakfast implementation of a recursive spinlock. That
> >> is, the same thread can "take" the spinlock repeatedly. 
> 
> On Sun, May 18, 2003 at 09:30:17AM -0700, Martin J. Bligh wrote:
> > Why?
> 
> netconsole.

That's a problem looking for a solution!  No, the reason for wanting a
recursive spinlock is that nonrecursive locks make programming harder.

Though I've got quite good at finding and removing deadlocks in my old
age, there are still two popular ways that the rest of the world's
prgrammers often shoot themselves in the foot with a spinlock:

   a) sleeping while holding the spinlock
   b) taking the spinlock in a subroutine while you already have it

The first method leads to an early death if the spinlock is a popular
one, as the only thread that can release it doesn't seem to be running,
errr..

The second method is used by programmers who aren't aware that some
obscure subroutine takes a spinlock, and who recklessly take a lock
before calling a subroutine (the very thought sends shivers down my
spine ...).  A popular scenario involves not /knowing/ that your routine
is called by the kernel with some obscure lock already held, and then
calling a subroutine that calls the same obscure lock.  The request
function is one example, but that's hardly obscure (and in 2.5 the 
situation has eased there!).

It's the case (b) that a recursive spinlock makes go away.

Hey, that's not bad for a small change! 50% of potential programming
errors sent to the dustbin without ever being encountered.

Peter