Date: Thu, 7 Sep 2000 01:07:51 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: joel boutros <jdb@layer8.net> Cc: smp@freebsd.org Subject: Re: Sept 5th patch ... Message-ID: <Pine.NEB.3.96L.1000907010432.24406D-100000@fledge.watson.org> In-Reply-To: <20000906180520.8B54A37B422@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Sep 2000, joel boutros wrote: > > So, are there going to be some documented guidelines for us neophyte > > kernel-hackers? I have just gotten used to the splfoo()/splx() idea, > > and now its gone. How, now, do we write canonical code that doesn't > > futz with itself when interrupts/threads/processes happen? > > the general trick is locking critical sections of code or data. > previously when you did an splXXX(), you were assured that you > weren't going to get interrupted by anything of specified priority > or lower, so it was safe to assume your data probably wasn't going > to change out from under you. now, you mark the critical sections > as in-use, and if something else does come in, it checks to see if > the section is "available" and, if not, figures out some strategy > to deal with it. Deadlocks seem to be a common problem in the system as it stands (especially the file system) -- usually the answer is a strict locking order. Will there be general kernel policies on locking order, or useful primitives for automatically ordering sets of locks (presumably sorted by address) and acquiring all of them, backing out in-progress operations when the current set of locks is found to be insufficient, etc? Also, we currently have some primitives for rudimentary atomic arithmetic operations. Also, any plans on priorities for kernel threads, so that we can introduce opportunities for priority inversion? :-) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000907010432.24406D-100000>