Date: Wed, 06 Sep 2000 23:33:02 -0700 From: Jake Burkholder <jburkhol@home.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: joel boutros <jdb@layer8.net>, smp@FreeBSD.ORG, jake@io.yi.org Subject: Re: Sept 5th patch ... Message-ID: <20000907063302.C2598BA6D@io.yi.org> In-Reply-To: Message from Robert Watson <rwatson@FreeBSD.ORG> of "Thu, 07 Sep 2000 01:07:51 EDT." <Pine.NEB.3.96L.1000907010432.24406D-100000@fledge.watson.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 The general policy is outlined in the slides prepared by Chuck Paterson for the SMP meeting. Roughly: If lock "A" is held while lock "B" is acquired, then "B" can not be held while "A" is acquired. Further, if lock "C" is ever acquired while holding lock "B" then "A" can not be acquired after "C". (these slides are available from Jason's page, worth checking out) The witness code is meant to impose this lock ordering, now in kern_mutex.c :), but it may be a while before we have more than just the 2 main locks to think about, Giant and sched_lock. As far as primitives operating on sets of locks, I can definitely see a potential need, but its still remains to be seen how things will progress. Anyone interested is encouraged to get involved. > 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? :-) Well, interrupt threads are basically just high priority kernel threads. There is code to deal with priority inversion, propogate_priority() in sys/i386/i386/synch_machdep.c, but it is believed to still have bugs that need to be worked out and is currently unused. Jake > > 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 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?20000907063302.C2598BA6D>