From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 28 15:57:06 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 227A5106566C for ; Sun, 28 Jun 2009 15:57:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2A6E8FC14 for ; Sun, 28 Jun 2009 15:57:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6845346B49; Sun, 28 Jun 2009 11:57:05 -0400 (EDT) Date: Sun, 28 Jun 2009 16:57:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sebastian Huber In-Reply-To: <4A4740B8.8090205@embedded-brains.de> Message-ID: References: <4A4740B8.8090205@embedded-brains.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@FreeBSD.ORG Subject: Re: callout(9) and Giant lock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 15:57:06 -0000 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