On Sun, 18 May 2003, Peter T. Breuer wrote:
> Here's a before-breakfast implementation of a recursive spinlock. That
> is, the same thread can "take" the spinlock repeatedly. This is crude -
> I just want to focus some attention on the issue (while I go out and
> have breakfast :'E).
> The idea is to implement trylock correctly, and then get lock and
> unlock from that via the standard algebra. lock is a loop doing
> a trylock until it succeeds. We emerge from a successful trylock
> with the lock notionally held.
> The "spinlock" is a register of the current pid, plus a recursion
> counter, with atomic access. The pid is either -1 (unset, count is
> zero) or some decent value (count is positive).
> The trylock will succeed and set the pid if it is currently unset. It
> will succeed if the pid matches ours, and increment the count of
> Unlock just decrements the count. When we've unlocked enough times,
> somebody else can take the lock.
A looong time ago I gave to someone a recursive spinlock implementation
that they integrated in the USB code. I don't see it in the latest
kernels, so I have to guess that they found a better solution to do their
things. I'm biased to say that it must not be necessary to have the thing
if you structure your code correctly.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:31 EST