Giving names to "new" locking techniques
Hans Petter Selasky
hps at selasky.org
Wed Mar 11 12:16:51 UTC 2015
Hi,
What I'm writing here might become topic for a presentation educating
other kernel developers at the next EuroBSDcon, so be warned ;-)
Some of you familiar to farming knows what happens when you try to kill
a chicken using a simple axe. It runs around for a long time after the
head is off. This picture can also be used to explain what happens when
trying to stop a process in the kernel which is using many different APIs.
I think it would be benificial to all developers if new code techniques
and solutions to classic locking problems could have a name, that can
later be referred and explained, so that we don't go around and stumble
and re-invent the wheel when writing [new] code.
I attended a talk by Kirk McMusic some years ago where he explained how
turnstiles and the internals of the locking system in FreeBSD worked.
And I couldn't agree more. Many other people listening did not fully
understand what he said. I think there is a strong need to educate
people on how to properly use locks and mutexes inside the FreeBSD
kernel and not only how locks work internally.
I've recently been doing some work in the callout area and I would
recommend other developers reading the "AVOIDING RACE CONDITIONS"
section in "man 9 timeout" and making up your mind about the three
no-name techniques described there.
I think it would be fair to force everyone to avoid races using a any
kind of exclusivly locked mutex, which is described as "alternative 1"
in "man 9 callout".
Further I would like the "AVOIDING RACE CONDITIONS" techniques in the
callout subsystem to be the good example for everyone else. The USB
stack already does similarly to the callout subsystem and it works
excellent. And I would like the tools to be available in the kernel to
do this easily, like an any-lock API similar to the existing locking
classes in 11-current.
While at it I would like to collect some terms and words related to locking:
- Sleep/non sleepable lock (credits: ???)
- Shared/exclusive lock (credits: ???)
- Locking order reversal, LOR (credits: ???)
- Lock inversion (credits: des@ ???)
- Locking whole pieces of code and not only single variables or
structures (credits: hselasky@ ???)
- Applying locks before calling a function and not inside a function
(credits: hselasky@ ???)
- Any-locking API. A set of kernel functions that accepts any type of
mutex: mtx / SPIN / RM / RW / SX which can be used by API providers to
call callback functions locked (credits: ???)
Thanks for reading through!
Any comments?
--HPS
More information about the freebsd-arch
mailing list