From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 28 09:52:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F4DF16A400 for ; Sat, 28 Apr 2007 09:52:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3B52813C458 for ; Sat, 28 Apr 2007 09:52:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CEF5A46B5D; Sat, 28 Apr 2007 05:52:16 -0400 (EDT) Date: Sat, 28 Apr 2007 10:52:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <46311708.5030002@elischer.org> Message-ID: <20070428104944.U28395@fledge.watson.org> References: <200704262136.33196.hselasky@c2i.net> <46311708.5030002@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: msleep() on recursivly locked mutexes 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: Sat, 28 Apr 2007 09:52:17 -0000 On Thu, 26 Apr 2007, Julian Elischer wrote: > Further the idea that holding a mutex "except for when we sleep" is a > generally bright idea is also a bit odd to me.. If you hold a mutex and > release it during sleep you probably should invalidate all assumptions you > made during the period before you slept as whatever you were protecting has > possibly been raped while you slept. I have seen too many instances where > people just called msleep and dropped the mutex they held, picked it up > again on wakeup, and then blithely continued on without checking what > happened while they were asleep. And interesting observation here is that FreeBSD 4.x and earlier were actually rife with exactly this sort of race condition, exercised only when under kernel memory pressure because sleeping occurred only then. The explicit locking model we use now makes these races larger due increased concurrency (preemption, parallelism, etc), but also makes our assertion model stronger. Robert N M Watson Computer Laboratory University of Cambridge