Messages in this thread | | | Date | Wed, 28 May 2003 12:50:46 -0400 | From | Timothy Miller <> | Subject | Re: recursive spinlocks. Shoot. |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |