From owner-freebsd-arch Thu Sep 28 1:29:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 1C04937B422 for ; Thu, 28 Sep 2000 01:29:47 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id BAA16382; Thu, 28 Sep 2000 01:28:20 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAa7aO9F; Thu Sep 28 01:28:14 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA11680; Thu, 28 Sep 2000 01:29:39 -0700 (MST) From: Terry Lambert Message-Id: <200009280829.BAA11680@usr02.primenet.com> Subject: Re: spinlocks and acquire pseudo-priority To: bmilekic@technokratis.com (Bosko Milekic) Date: Thu, 28 Sep 2000 08:29:39 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: from "Bosko Milekic" at Sep 27, 2000 10:30:11 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > B continues to spin and eventually the > loop index reaches the "tolerated" values and there's a panic(). > > Please also note that even if B hits the top of the while loop and > decides that the mutex is no longer owned, so it hits the top of the > infinite loop and tries to grab it again, just before it grabs it, it > could already be had by C. This isn't TOO much of a problem, because the > probability is low, but grows with the number of processors. The problem > I see is that the index i is never reset to zero and may eventually hit > the tolerated values and trigger a panic. > > Is there something I'm leaving out/forgetting? You are talking about non-deadlock starvation here. The simple answer is "use "for(;;)" instead of something with a loop index". The fact is, there is just as much probability of C losing a race with B for a contended resource formerly held by A under normal circumstances, as there is for it losing because of the conditions which you describe. The answer is: it doesn't matter -- you only ever use a spinlock to do one of two things: 1) Eat the overhead of a heavyweight non-spinning lock 2) Contend a resource which will be available in a small amount of time anyway, so it doesn't matter whether you get it first or second If you really cared about FIFO, FILO, or prioritization or some other policy based ordering on lock acquisition, you would not use spinlocks; you would use turnstiles and "wake one", or you would use some other policy cognizant mechanism for doing the granting. FWIW, this means you wouldn't use a mutex, either. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message