lkml.org 
[lkml]   [2003]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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