From owner-freebsd-hackers Tue Jun 15 1:22:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id B0C5614D6E for ; Tue, 15 Jun 1999 01:22:30 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 4112 invoked by uid 1001); 15 Jun 1999 08:22:29 -0000 To: mo@servo.ccr.org (Mike O'Dell) Cc: hackers@freebsd.org Subject: Re: coarse vs fine-grained locking in SMP systems References: <199906141047.GAA57400@servo.ccr.org> From: Ville-Pertti Keinonen Date: 15 Jun 1999 11:20:11 +0300 In-Reply-To: mo@servo.ccr.org's message of "14 Jun 1999 13:48:19 +0300" Message-ID: <86btehooxw.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG mo@servo.ccr.org (Mike O'Dell) writes: > very fine-grain-locked systems often display convoying and > are prone to priority inversion problems. coarse-grained Priority inversion problems are design flaws. Depending on the type of locks, they may not even be possible. Spin locks held for short periods of time (typical for very fine-grained systems) can't cause priority inversion because the process holding the lock can't block. > we published the best Unix SMP paper I've ever seen in Computing > Systems - from the Amdahl guys who did an SMP version of the kernel > by very clever hacks on SPLx() macros to make them spin locks and > a bit of other clever trickery on the source. they could take a stock An approach like that can't possibly be sufficient if code has been written with the assumption that only interrupt-like events or blocking calls can change things from under it. There is quite a bit of code in FreeBSD that relies on this. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message