Date: Wed, 06 Sep 2000 11:00:15 -0700 From: joel boutros <jdb@layer8.net> To: smp@freebsd.org Subject: Re: Sept 5th patch ... Message-ID: <20000906180520.8B54A37B422@hub.freebsd.org> In-Reply-To: Your message of "Wed, 06 Sep 2000 19:37:51 %2B0200." <200009061737.e86Hbqd08340@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. your critical section can be finely-grained (data such as members of a structure or elements of a queue) or coarsely-grained (holding an exclusive lock on an entire subsystem, like the network stack). and your locks can appear in a number of varieties. the strategy employed depends on your implementation. i'd recommend picking up a book on threads programming. the real gist of the change is that instead of telling the system you don't want to be interrupted, you make your code more tolerant of interruptions, which is what multithreading really requires. - joel 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?20000906180520.8B54A37B422>