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