Date: Fri, 19 Jan 2001 10:51:27 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: Soren Schmidt <sos@freebsd.dk>, rjesup@wgate.com, arch@FreeBSD.org, current@FreeBSD.org, bright@wintelcom.net, peter@netplex.com.au, Poul-Henning Kamp <phk@critter.freebsd.dk> Subject: Re: HEADS-UP: await/asleep removal imminent Message-ID: <XFMail.010119105127.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0101200438450.25410-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010119105127.jhb>