From owner-freebsd-current Fri Jan 19 10:53:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 92B1F37B402; Fri, 19 Jan 2001 10:52:56 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0JIn4L85589; Fri, 19 Jan 2001 10:49:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 19 Jan 2001 10:51:27 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: HEADS-UP: await/asleep removal imminent Cc: Soren Schmidt , rjesup@wgate.com, arch@FreeBSD.org, current@FreeBSD.org, bright@wintelcom.net, peter@netplex.com.au, Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19-Jan-01 Bruce Evans wrote: > On Fri, 19 Jan 2001, John Baldwin wrote: > >> rummage together a vinum stripe to build on or some such. However, after >> thinking some more, even in a preemptive kernel, Giant will protect against >> the >> *strategy() race you brought up, because we won't get a context switch in >> kernel mode that releases Giant until either we exit the kernel or we call >> tsleep(). The interrupt handler will block on Giant when its thread runs, >> so >> it won't run until the top half finishes and returns. Does that make sense? > > This would be a bug in the preemptive kernel. To work as well as old > kernels, everything that was not run because of a lock must be run when > the lock is released. This corresponds to splx() running all software > interrupt handlers that became runnable. I don't think we need to emulate every possible race condition of the old kernel. :) Eventually, what you ask _will_ be done because when we release a mutex, we make a process blocked on it runnable again, and if the new process has higher prioriry than the currnet priority. When you combine this with priority propagation, it will actually all work the way you want. It is just a more generic way of doing it since now any mtx_exit() of a sleep lock can effect this change, whereas before only splx() could effect this change. > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message