Date: Mon, 13 Jul 2009 14:17:53 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Sebastian Huber <sebastian.huber@embedded-brains.de>, hackers@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: callout(9) and Giant lock Message-ID: <200907131417.53876.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.0906281653160.69417@fledge.watson.org> References: <4A4740B8.8090205@embedded-brains.de> <alpine.BSF.2.00.0906281653160.69417@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 28 June 2009 11:57:05 am Robert Watson wrote: > > 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. FWIW, we do not actually sort the callouts in this manner, so all callouts will be blocked until Giant is acquired. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907131417.53876.jhb>