Date: Sun, 9 Apr 2017 21:26:27 -0700 (PDT) From: Chris Torek <torek@elf.torek.net> To: ablacktshirt@gmail.com, imp@bsdimp.com Cc: ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com Subject: Re: Understanding the FreeBSD locking mechanism Message-ID: <201704100426.v3A4QR9Q042761@elf.torek.net> In-Reply-To: <b69597cd-fab6-7ef8-7dfe-d097283c4064@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Is it true that a thread holding a MTX_DEF mutex can be descheduled?
>> Yes, they can be descheduled. But that's not a problem. No other
>> thread can acquire the MTX_DEF lock. ...
>Does that imply that MTX_DEF should not be used in something like
>interrupt handler? Putting an interrupt handler into sleep doesn't
>make so much sense.
Go back to the old top-half / bottom-half model, and consider that
now that there are interrupt *threads*, your ithread is also in the
"top half". It's therefore OK to suspend. ("Sleep" is not quite
correct here: a mutex wait is not a "sleep" state but instead is
just a waiting, not-scheduled-to-run state. The precise difference
is irrelevant at this level though.)
It's not *great* to suspend here, but all your alternatives are
*also* bad:
* You may grab incoming data and stuff it into a ring buffer, and
schedule some other thread to handle it later. But if the ring
buffer is full you have a problem, and all you have done is push
the actual processing off to another thread, adding more overhead.
* You may put the device itself on hold so that no more data can
come in (if it's that kind of device).
On the other hand, if you are handling an interrupt but not in an
interrupt thread, you are running in the "bottom half". It is
therefore *not OK* to suspend. You must now use one of those
alternatives.
Note that if you suspend on an MTX_DEF mutex, and your priority is
*higher* than the priority of whatever thread actually holds that
mutex now, that other thread gets a priority boost to your level
(priority propagation, to prevent priority inversion). So letting
your ithread suspend, assuming you have an ithread, is probably your
best bet.
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704100426.v3A4QR9Q042761>