Date: Fri, 22 May 1998 16:09:07 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: eivind@yes.no (Eivind Eklund) Cc: dyson@FreeBSD.ORG, grog@lemis.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: SMP resource locking Message-ID: <199805222109.QAA02498@dyson.iquest.net> In-Reply-To: <19980522225323.00501@follo.net> from Eivind Eklund at "May 22, 98 10:53:23 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Eivind Eklund said: > On Fri, May 22, 1998 at 12:01:18AM -0500, John S. Dyson wrote: > > Greg Lehey said: > > > I haven't paid much attention to SMP problems yet, but I need to now. > > > Can somebody point me to functions to ensure single-thread passing of > > > critical sections? In a UP environment I'd use splhigh (), but that's > > > obviously not enough for SMP. > > > > > For now, splhigh in a normal driver context will work. That is > > of course broken, but it will work fine. In the future, it won't. > > What's the right way to write this now? Add locks 'as one feel like', > or just ignore the lock-issues beyond spl(), or ? > For now, just do the spl thing. There is finer grained control available, but deadlocks are easy to cause. I am working aggressively on swtch.s right now and some of the other mp type issues, trying to improve things, schedule the code, get the smp TLB shootdown correct, and other things. mp_lock can be used to advantage, but deadlocks will happen without great care... So, to people working on the code, please stay away from swtch.s and to a lesser extent apic_vector and mp_machdep :-). At least let me know what you are doing, and we can work together :-). -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805222109.QAA02498>