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>