Re: recursive spinlocks. Shoot.

[Timothy Miller (miller@techsource.com)]

Someone's probably already suggested this, but here goes...

If you REALLY have places where multiple levels may try to grab the same 
spinlock, and you would therefore have lock contention with yourself, 
why not just use multiple spinlocks?  So if you often call B(), which 
grabs lock X, but sometimes you call A() which also needs lock X, but 
A() calls B() which therefore causes self contention, why not have A() 
use lock Y instead?  Treat what A() uses as a separate resource?  Or 
here's another idea:  Why not have A() unlock before calling B()?

Oh, and there's the obvious idea of passing parameters around which 
indicate whether or not a lock has been taken, although that's certainly 
a pain.

I do see some value in tracking lock ownership.  But what do you do 
about the unlocks?  Do you keep a refcount and unlock when it reaches 
zero?  Now, not only do you have to deal with locks across function 
calls, but you have to make sure everything unravels properly.  Sounds 
difficult.

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