Understanding the FreeBSD locking mechanism
Chris Torek
torek at elf.torek.net
Wed Apr 12 18:53:45 UTC 2017
>> If you obtain the locks in the other order -- i.e., if you grab
>> the PROC_STATLOCK first, then try to lock PROC_LOCK -- you are
>> trying to take a spin-type mutex while holding a default mutex,
>Is this a typo? I guess you mean something like "you are trying
>to take a blocking mutex while holding spin-type mutex".
Yes, or rather brain-o (swapping words) -- these most often happen
if I am interrupted while composing a message :-)
>I think I get your point: if you take a spin-type mutex, you
>already disable interrupt, which in effect means that no other
>code can preempt you. Under this circumstance, if you continue to
>take a blocking mutex, you may get blocked. Since you already
>disable interrupt and nobody can interrupt/preempt you, you are blocked
>on that CPU, not being able to do anything, which is pretty much a
>"deadlock" (actually this is not a deadlock, but, it is similar)
Right. It *may* deadlock, and it is definitely not good -- and
the INVARIANTS kernel will check and panic.
Chris
More information about the freebsd-hackers
mailing list