Date: Sun, 28 Jun 2009 16:57:05 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Sebastian Huber <sebastian.huber@embedded-brains.de> Cc: hackers@FreeBSD.ORG Subject: Re: callout(9) and Giant lock Message-ID: <alpine.BSF.2.00.0906281653160.69417@fledge.watson.org> In-Reply-To: <4A4740B8.8090205@embedded-brains.de> References: <4A4740B8.8090205@embedded-brains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Jun 2009, Sebastian Huber wrote: > suppose that a certain time event triggered several callout functions. What > happens if the first of these callout functions blocks on the Giant lock? > Does this delay all further callout functions until the Giant lock is > available for the first callout function? What happens if one of the callout > function blocks forever? Does this deadlock the system? Callouts are marked as MPSAFE or non-MPSAFE when registered. If non-MPSAFE, we will acquire Giant automatically for the callout, but I believe we'll also try and sort non-MPSAFE callouts behind MPSAFE ones in execution order to minimize latency for MPSAFE callouts. Most callouts acquire locks of some sort, and stalling any callout indefinitely will stall the entire callout thread indefinitely, which in turn could lead to a variety of odd behaviors and potentially (although not necessarily) deadlock. In general, we do not allow callouts to "block", however, in the sense that with INVARIANTS enabled we will actually panic if a callout tries to call msleep() or related functions. Likewise, if another thread sleeps while holding Giant, it will automatically release it when it sleeps. Relatively few kernel subsystems use Giant at this point, FYI, and even fewer in FreeBSD 8. One of our goals for FreeBSD 9 is to eliminate all last remaining references to the Giant lock in the kernel. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0906281653160.69417>