>
>Mr. Lewis' solution fails to address the scenario of recursively
>taken read locks. Since in that case, the thread taking the lock
>already holds the lock, running some nops doesn't really give
>another thread the possibility of acquiring the write lock. So
>it works out to be the same situation only with a bunch of nops
>executed in the critical path.
>
>
>-Sean Griffin
>
Right. It's not a very good solution, just one of many hacks that might
work :(
What if we kept a value (in per-CPU or per-thread memory) that was a
pointer to the last r/w lock we'd gained? When we release ANY r/w lock,
we could blindly initialize the "lastLock" pointer back to NULL. Then
we have a very quick (i.e. not very good) heuristic for detecting
recursive locks; if the "lastLock" pointer equals the pointer to the
thing you're about to try to lock, then you know that you already hold
it and are about to grab it recursively...otherwise, you fall back to
other routines.
If you really wanted, you could keep multiple pointers per CPU (exact
number tunable by a kernel #define), and on release only clear the one
you are actually releasing. Most builds, I imagine, wouldn't need more
than just a single pointer, though.
-
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/