From owner-freebsd-hackers@freebsd.org Mon Apr 10 04:26:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 206B8D36AE0 for ; Mon, 10 Apr 2017 04:26:30 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (mail.torek.net [96.90.199.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elf.torek.net", Issuer "elf.torek.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F2186FBC for ; Mon, 10 Apr 2017 04:26:29 +0000 (UTC) (envelope-from torek@elf.torek.net) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.15.2/8.15.2) with ESMTPS id v3A4QRua042762 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Apr 2017 21:26:27 -0700 (PDT) (envelope-from torek@elf.torek.net) Received: (from torek@localhost) by elf.torek.net (8.15.2/8.15.2/Submit) id v3A4QR9Q042761; Sun, 9 Apr 2017 21:26:27 -0700 (PDT) (envelope-from torek) Date: Sun, 9 Apr 2017 21:26:27 -0700 (PDT) From: Chris Torek Message-Id: <201704100426.v3A4QR9Q042761@elf.torek.net> To: ablacktshirt@gmail.com, imp@bsdimp.com Subject: Re: Understanding the FreeBSD locking mechanism Cc: ed@nuxi.nl, freebsd-hackers@freebsd.org, rysto32@gmail.com In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (elf.torek.net [127.0.0.1]); Sun, 09 Apr 2017 21:26:27 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 04:26:30 -0000 >>> 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